matcher: Generic matching API

Design doc: http://shorturl.at/ekW03
String is supported type in this PR, which is consistent with existing code. CEL matcher will be supported in next PR. Integer (e.g., for the DestinationPortInput) is supported with this API and could be added in future PR.
Also, remove absl::optional from the API as absl::monostate in absl::variant already achieves the same goal of representing the empty state.
Signed-off-by: tyxia<EMAIL_ADDRESS>

I can take a look while @snowp is out. @mattklein123 or @wbpcode would you be willing to provide non-Googler coverage on this review? Thanks.

could you make the design doc public available? Thanks.

I think this PR is try to make the input match could be used to match multiple different type datas rather than only string?
And I think only protocol-independent data type could be used as output because if the protocol-specific data type is used, we need rewrite all the value input matcher.

Just for discussion, would you consider using proposal in the https://github.com/cncf/xds/pull/59 as an alternative?
I think string is enough for most cases and the CustomPredicate could be used as a suppliment in some special case, e.g, port matching, ip matching, composite matching, etc. Then we can keep the core of the matcher simple and easy to understand.

One advantage off top of my head is that this proposal doesn't introduce any control plane or xDS API change. All of them are supported under the hood.

Yeah, but almost every matcher impl need check the input data type first to ensure the input data type is supported by the impl self.
And this make the input type of custom input must be compatible with match type of matcher (value_match, custom_match, etc.)
🤔

One advantage off top of my head is that this proposal doesn't introduce any control plane or xDS API change. All of them are supported under the hood.

Yeah, but almost every matcher impl need check the input data type first to ensure the input data type is supported by the impl self.
And this make the input type of custom input must be compatible with match type of matcher (value_match, custom_match, etc.) This's new implicitly constraint to the users and control plane.

I think the input should be compatible with match type, right? For example, if you want to match on int, you need to provide a int input. Actually this design can support mixed types. For example, int DestinationPortInput + string matcher. I have a prototype confirmed this but I didn't add IT because I feel it is hacky,
Currently there is no constraint is because we only have string input and string matcher.

In generally, this is a good solution for multiple types protocol-independent inputs.
But I still prefer the proposal in the https://github.com/cncf/xds/pull/59.
This initial design goal of https://github.com/cncf/xds/pull/59 is to solve matching problems of protocol-specific input/data or composite data.
But seems that it also could be used to solve the matching problems of non-string input/data.

In generally, this is a good solution for multiple types protocol-independent inputs.
But I still prefer the proposal in the cncf/xds#59.
Could you elaborate why? Maybe you are suggesting to keep both proposal. If protocol-independent is supported by this proposal, will that protocol-specific be implicitly supported as well?

For quick scan, IIUC your proposal seems to be a bit orthogonal here. You are suggesting the API/control plane change to existing input/predicate mechanism and control plane logic. Here is proposal of generic matching for existing input/predicate and control plane logic. Does you proposal also require the data plane/Envoy change to support CEL?
Also, as I replied above, IMO, the input type and match type should to be matched (even though the proposal here supports mixed type)

If protocol-independent is supported by this proposal, will that protocol-specific be implicitly supported as well?

sadly, the answer is no. although i didn't output a complete proposal,but I have thought similar method like this pr in my mind. I thought may be we could extend the custom input to return protocol-specific type rather than string.
But if we do this, we need implement all value matcher separately for every protocol. I think this is a unacceptable burden because in most cases string matching is enough.

If protocol-independent is supported by this proposal, will that protocol-specific be implicitly supported as well?

sadly, the answer is no. although i didn't output a complete proposal,but I have thought similar method like this pr in my mind. I thought may be we could extend the custom input to return protocol-specific type rather than only string.
But if we do this, we need implement all value matcher separately for every protocol (this protocol-specific data input will make the mather impl protocol-specific). I think this is a unacceptable burden because in most cases, the simple string matchers are enough.

Actually i don't get why all value matcher needs to be implemented separately. As shown in this PR, all the functionalities/cases of string type are well supported without introducing new matcher impl. The only thing need to be added is CEL matcher which is required regardless. Can you proposal avoid adding CEL matcher?
Maybe one step back, could you give some example/use cases of where protocol-specific is needed. Also, from your description, your proposal seems to address the issue that it's very flexible but isn't easy to use

Actually i don't get why all value matcher needs to be implemented separately. As shown in this PR, all the functionalities/cases of string type are well supported without introducing any new matcher impl.

Because this pr didn't introduce any protocol-specific data. 🤣 So we needn't change too much codes.

The question i asked is do you have example/use case of protocol-specific data that are required?   This seems to something to xDS API which is why I think your proposal might be a bit orthogonal here.  Also, can your proposal avoid adding CEL matcher?

Maybe one step back, could you give some example/use cases of where protocol-specific is needed. Also, from your description, your proposal seems to address the issue of ease of use : it's very flexible but isn't easy to use

Yeah, the initial goal is to handle the composite data.
And to avoid complex data extraction, the DataType (this is procotol-specific typically) of match tree will be used as the match input.
In fact, I didn't think it will be used to handle non-string procotol-independent data, until l I saw this pr.

The only thing need to be added for future is CEL matcher which is required regardless. Can your proposal avoid adding CEL matcher?

I think my proposal cannot avoid adding any custom matcher.
I think my proposal may could be used to implement CEL matcher in simpler way.
In my proposal, the CustomPredicate is generally a merge of SinglePredicate.input and SinglePredicate.custom_match.

If this pr is a pre work of cel matcher, could you talk a little more about how you will implement this cel matcher?
Or if the doc contains these content? (I still have no permission to access the doc 😭)

If this pr is a pre work of cel matcher, could you talk a little more about how you will implement this cel matcher? Or if the doc contains these content? (I still have no permission to access the doc 😭)

Yes, the implementation of CEL matcher is pretty simple:  in addition to adding it to absl::variant. Basically, just its own version of DataInput/DataInputFactory and InputMatcher/InputMatcherFactory.
There are some examples in design doc I shared with your email<EMAIL_ADDRESS>Is that right one?

Let me try to summarize the conversation for the convenience of other reviewers,  @wbpcode please correct me if anything is missing/wrong:

cncf/xds#59 is a proposal for a new xDS API and it doesn’t address the problems we want to solve here. (e.g., it still need the data plane support for CEL)

Moreover, given that it is a proposal for a new xDS API while this proposal is for existing xDS API, I think those two are orthogonal.

I am not entirely sure about the motivation of cncf/xds#59 (e.g., protocol-specific you mentioned).

It was mentioned to improve the ease of use. One thing I think I don’t get the clear answer is that if we have the production request/use case for this.

In this proposal, all we need to introduce is dataInput/InputMatcher for corresponding types. Existing string has covered all current needs. So the only one introduced here is a CEL matcher (Integer type is good to have)

If you are referring to use case in cncf/xds#59. it is not in scope of this proposal. Although i am interested in learning about the production case for that.
Future Introduction of CEL matcher in this proposal is not complicated as examples in design doc.

Another one I don’t get a clear answer is why we want input type NOT to be compatible with match type.

For example, if you want to match on int, you need to provide an int input.
Even so, this proposal supports hybrid case: for example int DestinationPortInput + string matcher)

I think if CEL attributes are going to be a essentially a singleton for a request, then something like the style of https://github.com/cncf/xds/pull/59, where you don't even have input-match split, might be easier to work with here. But if we might have multiple ways of synthesizing the CEL match inputs, then the input-match split helps. @kyessenov WDYT specifically for the CEL matching situation?

@htuch I tend to agree - the simplest is a self-contained function that outputs "true/false". The more complicated scenarios (partial input, attribute vocabulary) are useful, but are likely not the first priority. I think @markdroth convinced me at some point to split CEL into input/matcher, so CC'ing them here.

I'm not familiar with the Envoy implementation of the generic matcher API, but I'm speaking about this from the context of the xDS API and the original design discussions for the generic matcher API, which I was directly involved in.
The original intent of the generic matcher API was to decouple inputs and matchers into two separate extension APIs, so that we can choose the two independently.  When @snowp was implementing this API in Envoy, we did not have a use-case for any type of input other than strings, so that's all we implemented at the time, but we discussed the problem of different input types, and we agreed that the right way to implement that when we eventually came across such a use-case was to templatize the generic matching code to be able to handle any type of input.  The idea would be that a given input plugin would return a particular type of data, and any matchers used on that data would need to be compatible with that type of data.  If an xDS resource contains a matcher that does not handle the type of data provided by the input plugin, then that's a config error, and we should be able to reject the xDS resource that contains that error.
I don't see how https://github.com/cncf/xds/pull/59 solves this problem.  If the input plugin has no way to return data other than a string, then plugging in a custom matcher does not help, because it's still taking string data as input.

@htuch I tend to agree - the simplest is a self-contained function that outputs "true/false". The more complicated scenarios (partial input, attribute vocabulary) are useful, but are likely not the first priority. I think @markdroth convinced me at some point to split CEL into input/matcher, so CC'ing them here.

Initially, I did provide a self-contained approach (and have prototype) for CEL in Rate Limiting project. It reuse data Input field without input/matcher split. The doc is here (not open sourced though).  I agreed that is a bit hacky of reusing dataInput and @markdroth did convince me to avoid any xDS API change that could introduce tech debt.  Maybe if we introduce whole new xDS API, it is not that hacky. But if in the future the use case of CEL is not self-contained and requires input from configuration, then input/match split is also required. And how about the use cases other than CEL that requires input/match split.

https://github.com/cncf/xds/pull/59 is a proposal for a new xDS API, and it doesn’t address the problems we want to solve here. (e.g., For CEL, it still need the data plane support)

Moreover, given that it is a proposal for a new xDS API while the proposal here is for existing xDS API, I think those two are orthogonal.

I am not entirely sure about the motivation of https://github.com/cncf/xds/pull/59 (e.g., protocol-specific you mentioned).

As I mentioned in my previous comments, this initial motivation of https://github.com/cncf/xds/pull/59 is to simplify the matcing conditions' combinations.
In the pratice, we will never expose the generic matching API to the end users directly because it's toooooo complex. Some common combinations (in our scenario, it's host + path + method + headers in AND semantics) will be provided to end users by an abtraction of control plane.
But it's still complex for the data plane/control plane developers or pe/sre to read/debug these configuration.
So, my initial idea is create a new extension point to represent a match that will accept the whole DataType instance (this is typically a protocol-specific data) as input and output a bool as result. We can aggregate these common matching conditions in one extension directly.
And of course, if the whole DataType instance (this is typically a protocol-specific data) is used as matching input, this extension almost could be used to implement any match logic, include the CEL matching. This is why I think https://github.com/cncf/xds/pull/59 could be used here. We can implement CEL matching with the new extension point.
But after these discussions, I found that maybe I can wrapper all my custom matching logic in the input extension (just like the ratelimit example in your doc). It's hacky, but should be useful (at least it could solve my problems).
And @markdroth convinced me that to decouple things to inputs/matchers may be better in lots cases. So, I am not in a hurry for the https://github.com/cncf/xds/pull/59 and will pend it up.

Another one I don’t get a clear answer is why we want input type NOT to be compatible with match type.

This is a comment about the implementation. I got that from your implementation. You check the input data type in every matcher implementation at runtime, and I think this is imply that there may a case that the input type may not compatible to the match type.
The better way is like @markdroth said,  If an xDS resource contains a matcher that does not handle the type of data provided by the input plugin, then that's a config error, and we should be able to reject the xDS resource that contains that error.

Sounds good. To confirm, @wbpcode you are good with this PR from a design perspective at this point and it makes sense to focus on the implementation?

In conclusion, after thinking in more details, I am convinced that decoupling inputs/matchers would be better. And my current problems could be around temporarily by wrapper all match logic in the custom input.
So, yes, now we can focus on the review/discussion on the implementation.

In particular, we probably want to explicitly agree or dive deeper on the variant vs. template discussion. I would prefer to avoid template complexity if it doesn't artificially limit us, see the thread in the doc for how this might work.

I think the template almost impossible? Because we may expect string input and cel input in a match tree at same time?

In conclusion, after thinking in more details, I am convinced that decoupling inputs/matchers would be better. And my current problems could be around temporarily by wrapper all match logic in the custom input.
So, yes, now we can focus on the review/discussion on the implementation.

Sounds good. Thanks for discussion and review on the design.

I think the template almost impossible? Because we may expect string input and cel input in a match tree at same time?

Yes, this section describe this and an example shows the difficulty/challenge to achieve this via template

I doubt that variant may no be a good option for this scenario. This is designed to enhance the generic matching API to support various input types, So we cannot only consider the CEL matcher. We must consider the case where the third-party developers may create a custom matcher that with a new input type. Typically we shouldn't expect that the developers to extended the variant when a new input type is necessary.

Ideally, we can provide a virtual base class to represent a type of data input. And we can validate the compatibility of input type and match type in the configuration loading phase.
After that, we can use a static_cast in the runtime to covert the virtual base class pointer to the specific type in the matcher impl.
But additional heap allocations and addressings are necessary by this way. Not sure this will bring how much performance overhead.

We must consider the case where the third-party developers may create a custom matcher that with a new input type. Typically we shouldn't expect that the developers to extended the variant when a new input type is necessary.

This is a valid concern from the design perspective. It may be better to use a base class with a method that identifies its "type". This may even be used for type safety checks during config processing.
It will have a small performance impact for type checking, but it is likely to be very small.

/wait-any

We must consider the case where the third-party developers may create a custom matcher that with a new input type. Typically we shouldn't expect that the developers to extended the variant when a new input type is necessary.
Ideally, we can provide a virtual base class to represent a type of data input. And we can validate the compatibility of input type and match type in the configuration loading phase.

I feel that is probably an ideal world for generic case that we can not support. If the developer provides the input type that we don't support, data plane EITHER reports it’s not_supported OR needs to do some work to support it anyway We need to add corresponding dataInput/dataInputFactory implementation and registration. Extending the variant will be just a small part of that.

After that, we can use a static_cast in the runtime to covert the virtual base class pointer to the specific type in the matcher impl. But additional heap allocations and addressings are necessary by this way. Not sure this will bring how much performance overhead.
Maybe hybrid the variant the virtual base class could be a possible solution. Then for the simple and (matcher/protocol)-independent types, we can access the data via variant and no any heap allocations are necessary.
class InputDataType {
  virtual ~InputDataType() = default;
};
using InputDataTypePtr = std::unique_ptr<InputDataType>;

// This is similar to the proposal of @tyxia, except a virtual `InputDataType` is used here rather than the cel's data interface.
using InputData = absl::variant<absl::monostate, std::string, InputDataTypePtr>;

This is a very good idea for the next PR that introduces CEL. I add some details to the design doc here

The better way is like @markdroth said, If an xDS resource contains a matcher that does not handle the type of data provided by the input plugin, then that's a config error, and we should be able to reject the xDS resource that contains that error.

There is currently no way to make this check at config processing time, since the API does not specify what types data provider and matcher would use.

yeah, so this is a thing need to be resolved.
A possible solution in my mind is to extend the data input factory and custom match factoy to add a new interface. This new interface will return a typed id. And we can evaluate if the id is matched or not.

This is a very good idea for the next PR that introduces CEL. This is aligned with our NonPoD abstraction approach that has been discussed in that design doc. Please see the details/example here ,

Oh, it was updated. Just got it. Haha, seems that we finally figured out some similar things.

The better way is like @markdroth said, If an xDS resource contains a matcher that does not handle the type of data provided by the input plugin, then that's a config error, and we should be able to reject the xDS resource that contains that error.

There is currently no way to make this check at config processing time, since the API does not specify what types data provider and matcher would use.

yeah, so this is a thing need to be resolved.
A possible solution in my mind is to extend the data input factory and custom match factoy to add a new interface. This new interface will return a typed id. And we can evaluate if the id is matched or not.

I feel strongly that we need this property.  As a general design principle, any time we can detect a problem at config-validation time instead of waiting until run-time, we'll be better off, because it provides us with a way to reject config changes that break things.  I think it's much worse to accept a config that know cannot possibly work, since that will result in us accepting the bad config and then failing data plane requests.
I think the right way to model this is to say that the data type generated by the input plugin is part of the extension type for the matcher.  We can have a separate registry for each extension type -- e.g., one for matchers that take string input, one for matchers that take numeric input, one for matchers that take CEL input, etc.  When we see a matcher tree config, we will look up the matchers in the registry for the data type provided by the input plugin, and if the matcher is not found in that registry (either because it does not exist or because it does not support that data type), then we can reject the config.

LGTM from me. Looking for non Google reviewers.

Thanks all very much for discussion! Fully agree that we must have configuration validation.
https://github.com/envoyproxy/envoy/issues/27007 has been created to fix this issue. It will be handled in a separate PR from this one, because std::string is still only allowed type in this PR. But it will be sure handled before we introduce new matcher type like CEL.

yeah, so this is a thing need to be resolved. A possible solution in my mind is to extend the data input factory and custom match factoy to add a new interface. This new interface will return a typed id. And we can evaluate if the id is matched or not.

Yes, config validation is needed. That solution is also same as idea in my mind. Basically, we need to check mismatch like here when both data_input and input_matcher.

Oh, it was updated. Just got it. Haha, seems that we finally figured out some similar things.
Definitely more than :) . I think we are now on the same page of general direction (need input/matcher split as it is); implementation details (variant with abstract class when CEL is introduced) and need to have config validation (before CEL is introduced).

Do you want to take a pass on this PR? Thanks!

I will take a look today, thanks for your great contributions.

/retest

There are still build problems: https://source.cloud.google.com/results/invocations/de09f0c7-bcce-4fd4-8ed2-92a0529659d2/log
/wait

Yea, Suggested review comments break some small things. Fixing and testing now...

/retest

cc @yanavlasov for final merge.

JuniorHsu

That design doc was created using my corporate account and looks like I cannot make it public. I shared with your pinterest email.
I am writing a new design doc that can be public using my personal account and will post it here

Just FYI, I have recreated the design doc using my personal account here https://shorturl.at/kQTZ1 so that it can be accessed publicly.

This short link https://shorturl.at/kQTZ1 is not working for me (it just shows me a form to enter a new long URL to be shortened). Is there anyway you can paste the original long form URL here?


retrigger mode in [voices]

0 (default) - ignore (goes to extra)
1 - same output
2 - different output

3rd argument


allow "domains" on each BoundSubstrand and Loopout

See description here: https://github.com/UC-Davis-molecular-computing/scadnano-python-package/issues/4

Closing this as unlikely to be implemented. We've now switched to calling Substrands "Domains", and it is possible to have several consecutive domains on the same helix, so this feature is not needed and would overly complicate the model.


NGA NSG PROFILE

Has ios SDK been updated to support NGA NSG TILING SCHEMA/profile?

GeoPackage iOS been updated to support the NGA's NSG GeoPackage Tiling Profile Specification?  (NSG) GeoPackage Encoding Standard 2.0
Interoperability Standard
(2016-09-14)

Please see ngageoint/GeoPackage#4

NSG is fully supported except for NGA CRS authored WKT coordinate system values.  This can be supported currently by providing those values in advance.  Will be handled automatically as part of: ngageoint/simple-features-proj-ios#1


NetCore

I think this is all that is needed to support Core.
First time doing it.

Yup, looks good. :D


i did all the steps carefully and got my OLLAMA_HOST link as well, but in my terminal when i run the export command with the link provided by jupyter (colab) it gives me an error message:

Error: something went wrong, please see the ollama server logs for details

Can you attach the ollama logs?
Seems to be some networking issue (first guess)

@varun-g91 had the same issue earlier, probably it has to do with ngrok tunneling with ollama version > 1.2.8
can you try replacing:
run_process(['ngrok', 'http', '--log', 'stderr', '11434'])
with:
run_process(['ngrok', 'http', '--log', 'stderr', '11434', '--host-header', 'localhost:11434'])
and see if it works.

@skt7 I merged your PR!
@varun-g91 check if this helps please

@varun-g91 had the same issue earlier, probably it has to do with ngrok tunneling with ollama version > 1.2.8
can you try replacing: run_process(['ngrok', 'http', '--log', 'stderr', '11434'])
with: run_process(['ngrok', 'http', '--log', 'stderr', '11434', '--host-header', 'localhost:11434'])
and see if it works.

okay ill check and let u know, thanks.

@skt7 I merged your PR! @varun-g91 check if this helps please

ye sure.

run_process(['ngrok', 'http', '--log', 'stderr', '11434', '--host-header', 'localhost:11434'])

Thank you so much it actually worked.


[bounty] windows update should properly terminate all the running processes before triggering the update

i think we had this issue before and had put a bounty on it and thought it was solved but saw someone having issue again with this
definition of done:

when windows user receive update of screenpipe it should properly CLOSE both screenpipe backend and any embedded AI running (llm_sidecar.rs)

bonus:

something to improve the update UX and not spamming users with a dialog or something better UX (check how screen studio or other app do it)

/bounty 100

ERROR: Permission to mediar-ai/screenpipe.git denied to RichardGrant-93.
fatal: Could not read from remote repository.

/claim #774
https://github.com/mediar-ai/screenpipe/pull/777

something to improve the update UX and > not spamming users with a dialog or > > > something better UX (check how screen > studio or other app do it)

@louis030195 if dialogs are feelings spammy, what about a update button in app status? when update is available it'll notify user with a app notification or a toast and user can start downloading update from the status ui?


Import scheduled Whitehall documents

We want to have the ability to import a document that is scheduled for publication.
In Whitehall you can determine that an edition is scheduled as it has a state of “scheduled” and a field of scheduled_publication with the time.
In Content Publisher the scheduled publishing is represented by a status of “scheduled” with a Scheduling object that knows:

who created the scheduling. This is handled in the existing build_status method
whether the content was reviewed before scheduling. This is set based on the value of force_published on the whitehall_edition. If this is true, reviewed should is false otherwise this is true.
the status prior to the scheduling to allow rolling back to that. We determine the status using whitehall document's revision_history by checking if the previous one is "submitted". If it isn't we the pre scheduled status is "draft".
publish time

After unscheduling

Trello card

@ChrisBAshton this should be good for another look now.


Dependency Build Paths

At present the dependencies for the project (GLFW, GLAD and ImGui) are building into their own sub folders inside vendor.
I was unsure if this was intended or not, but in the case that it wasn't intended the following changes could be made to the dependencies premake5.lua files to fix the issue.
targetdir ("%{wks.basedir}/bin/" .. outputdir .. "/%{prj.name}")
objdir ("%{wks.basedir}/bin-int/" .. outputdir .. "/%{prj.name}")

A number of other changes could be made to their premake files as well to keep them in line with the main project's setup such as the staticruntime, runtime, symbols, systemversion "latest" and optimization options.
I can create pull requests for this change in the relevant repositories if anyone else thinks this is worth changing.

Since the dependency projects are being statically linked into the main Hazel DLL we're probably never going to have to access them individually, so I don't see the need to put them together in the main bin/ folder.
That's just my thought...

Alternatively, perhaps we could add the bin/bin-int folders inside those sub-projects to the .gitignore.
This would at least stop git from complaining there are un-tracked or unmodified files in the sub modules.

Thinking about it, they are already being ignored in the .gitignore thanks to bin/ and bin-int/.
Going to close this off, as I can see the reasoning behind it as @SeppahBaws suggested.


Broken after update to 2021.11.0b1

🐛 Describe the bug
After updating to HA 2021.11.0b1 I get these errors and I'm not able to add a new integration entity:

I also tried to reinstall the integration, but that did not help.
💥 When did the bug occurred.*

[x] Installation / First-run
[ ] Configuration
[ ] Other

👣 To Reproduce
Steps to reproduce the behavior:

Update HA to 2021.11.0b1
Install RKI Covid
Add new integration

🧐 Expected behavior
Work
💻 Versions (please complete the following information):

OS: 2021.11.0b1
Supervisor: supervisor-2021.10.8
Browser: edge

🗄 Logfiles (Configuration > Logs)
2021-10-29 12:22:21 ERROR (MainThread) [custom_components.rki_covid] Error fetching rki_covid data: Error reading data from rki-covid-parser timed-out:
2021-10-29 12:22:21 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/aiohttp/web_protocol.py", line 422, in _handle_request
    resp = await self._request_handler(request)
  File "/usr/local/lib/python3.9/site-packages/aiohttp/web_app.py", line 499, in _handle
    resp = await handler(request)
  File "/usr/local/lib/python3.9/site-packages/aiohttp/web_middlewares.py", line 119, in impl
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 60, in security_filter_middleware
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 220, in forwarded_middleware
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 24, in request_context_middleware
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 138, in auth_middleware
    return await handler(request)
  File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 135, in handle
    result = await result
  File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 130, in post
    return await super().post(request)
  File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 62, in wrapper
    result = await method(view, request, *args, **kwargs)
  File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 71, in post
    result = await self._flow_mgr.async_init(
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 197, in async_init
    flow, result = await task
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 224, in _async_init
    result = await self._async_handle_step(flow, flow.init_step, data, init_done)
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 320, in _async_handle_step
    result: FlowResult = await getattr(flow, method)(user_input)
  File "/config/custom_components/rki_covid/config_flow.py", line 40, in async_step_user
    for case in sorted(coordinator.data.values(), key=lambda case: case.name):
AttributeError: 'NoneType' object has no attribute 'values'

Can't be reproduced. Perhaps there was a server issue with the API.


Angular 6: Unexpected token ] in JSON at position 970

Bug Report or Feature Request (mark with an x)
- [x ] bug report -> please search issues before submitting
- [ ] feature request

Command (mark with an x)
- [ ] new
- [ ] build
- [ ] serve
- [ ] test
- [ ] e2e
- [x ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Versions

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.6.8
@angular-devkit/build-angular     0.6.8
@angular-devkit/build-optimizer   0.6.8
@angular-devkit/core              0.6.8
@angular-devkit/schematics        0.6.8
@angular/cli                      6.0.8
@ngtools/webpack                  6.0.8
@schematics/angular               0.6.8
@schematics/update                0.6.8
rxjs                              6.2.2
typescript                        2.7.2
webpack                           4.8.3

node --version: v8.10.0
npm --version: 6.2.0
Windows (10)
Repro steps

ng g c name
The log given by the failure

Unexpected token ] in JSON at position 970
Desired functionality

I'd like to create Angular component.
Error just randomly occured when I started coding.
Mention any other details that might be useful

Heya, can you show us your angular.json file please?

This issue is likely resolved with PR #11132 which is included with the version 6.1.0 release.

Closing this as fixed with PR #11132. If you upgrade to 6.1.1 and this still happens please file a new issue passing in your JSON files.


add new option for spliting multi-valued cells: by transition between lowercase and uppercase, and number and text

Is your feature request related to a problem or area of OpenRefine? Please describe.
I discoverd interesting options in MS PowerQuery. It could be nice to have the same in OR : split by transition between lowercase and uppercase, split by transition between number and text
Here is the menu (in french) in PowerQuery :

Describe the solution you'd like
Describe alternatives you've considered
Additional context

You mentioned in the title that "for spliting columns"...
But I'm wondering if you meant splitting multi-valued cells, instead?
If so, you would like to see this box made a bit bigger and have some additional "radio button" options?

I changed the title of the issue ;-)
It could be a new menu (like MS PowerQuery) or more options in the dialog box. I don't know what would be the best...

Split by capitalisation was something I was asked by a collegue. See https://stackoverflow.com/questions/58845900/how-to-split-a-string-based-on-capitalized-initials

Can I take up this issue?

@lisa761 Thanks for volunteering Lisa!  Assigned to you.
I see this new feature as expanding the existing Split multi-valued cells dialog with 2 additional radio buttons:

Split between a Lowercase and Uppercase letter
Split between a Number and Letter (and vice versa)

Agree?

@thadguidry yup, okay

Hi, So I was thinking would it be better if we provide an option for transition between all, i.e. one from lowercase to uppercase and another for uppercase to lowercase, one from letters to numbers and one from numbers to letters? Or we just give two options and then split whenever there is a transition from either uppercase or lowercase to lowercase or uppercase respectively.
For eg. If the value was, say 'fooBarABABFooBar'
Then split for both transitions upper to lower and lower to upper case would be:

foo B ar ABABF oo B ar

Only lower to uppercase would be:

foo Bar ABABFoo Bar

Uppercase to lowercase would be:

fooB arABABF ooB ar

So should we provide all the options or only the first one?

Normal English capitalization rules tell us that only the 2 options I mentioned would be useful.
This issue is just to have some quick menu options to support those 2 common use cases.  If users have other use cases, they can resort to having the power of GREL and other languages we support.  If users REALLY want to have additional options in the menus, they can request an enhancement issue and then upvote.
As a general rule, we typically try not to over engineer until we know the usefulness based on user feedback (mailing lists, surveys, issues).

so I was thinking would it be better if we provide an option for transition between all, i.e. one from lowercase to uppercase and another for uppercase to lowercase, one from letters to numbers and one from numbers to letters?

The PowerQuery example given by the original requestor provides all four options, although it appears that they are mutually exclusive (they each appear to be a separate drop down menu pick).
I'm not convinced that splitting on uppercase to lowercase transitions is very useful, but all four were originally requested.

@tfmorris The split from uppercase then lowercase can still be useful in scientific domains where its much more prevalent than newsrooms.
 ;-)


integrate a more sophisticated query DSL

Esqueleto might be cool:
https://hackage.haskell.org/package/esqueleto

We now have a nice query dsl


bug/INTEGRA-915: Anaplan Data Source Definition getting reset to  using connector

Bug fix that addresses an issue where ServerFile.getUploadCellWriter() had the columnn-separator hardcoded to , resulting in it getting corrupt. So the fix is to upload the data in stream-chunks of 2k to the server. Only fallback is that the row-count is now an apporximate (based on a regex match to find the number of carriage-returns in a stream-chunk, then summing up the counts to give a final approximate count). Its approximate because the regex is not foolproof. Typical scenario is the server returns the processed row count. Unfortunately thats not immediately available using the Anaplan API, so an approximate is reported from the client.

Coverage decreased (-1.3%) to 81.629% when pulling 9bb36a179fdeb694bae86c41a3eff72e58abcd4e on bug/INTEGRA-915 into dad7d3ca4606a20ec41b84cc4f5b5eb8240acce3 on develop.

Coverage decreased (-0.2%) to 82.726% when pulling 9bb36a179fdeb694bae86c41a3eff72e58abcd4e on bug/INTEGRA-915 into dad7d3ca4606a20ec41b84cc4f5b5eb8240acce3 on develop.

Coverage increased (+1.4%) to 84.261% when pulling 983c2f72a7a1783beba623c507cb261809deb269 on bug/INTEGRA-915 into dad7d3ca4606a20ec41b84cc4f5b5eb8240acce3 on develop.

Closing this as the actual story is feature/INTEGRA-921. New branch and PR will be created for that.


0.6.8 Infinite loading or Error  while parsing item

I had the same issue on 0.6.7: updated to 0.6.8 and still unable to use it. I either get a bottom red text "Error while parsing" or the popup opens but fetch forever and doesnt return any info. Any idea ?

Same for me

I'm getting the same errors-- either "error while parsing" or infinite loading.

Me too

This is likely related to #392 and it's just showing the issue with contacting GGGs api's in various ways

Same but I am still on 0.6.7 despite the fact that I saw the new version popup and try to relaunch, I cant update to 0.6.8

Same issue here was working fine for few hours then Kyusung pushed the 0.6.8 update and it started having this error.

same, i'm getting this error too

I've noticed a slight oddity, when I relaunched it on 0.6.7. it did the update but when hovering over the icon, it still shows 0.6.7 so either a typo or possibly the update failed. Yet, when launching the downloaded setup exe for 0.6.8, it does not start to reinstall, instead it launches 0.6.7. Closing it and launching the installed version still launches 0.6.7. Plenty of weirdness.

Same but I am still on 0.6.7 despite the fact that I saw the new version popup and try to relaunch, I cant update to 0.6.8

Exact same problem

I just got the prompt to update to the latest 0.6.9, no problem instaling it, and no more errors while parsing! thx for the update

Should be fixed with #392


only apply on a language

Hi, may I ask how to enable prettify only on one language, like Coq but leave OCaml and Haskell their original text format?

@arbipher You can copy the default substitutions (auto-completion should do it when you edit the settings), then remove the languages you want.

Got it. Thank you.


Config project dependent

I think this is a feature request,
I would be great if we could set the typescript analyser settings project dependent, e.g. a .json config file for the following settings:

Not sure I understand what you mean I'm afraid, can you elaborate?

The settings, eg ignore pattern, is now for all projects on one machine.
It would be great to set the ignore pattern for one project (on multiple machines by checking in the config it git for example)

Wait - within that Visual Studio extension, or were you just using it as an example?

Ah oops, wrong github repo. Sorry!

Haha, no worries - I was trying to think of a way to break it to you gently...


Add Shape Annotation after the chart render on click?

I am wondering if it is possible I can add new shape Draw on chart Add tool tip after the graph render by using on click event from button ? is is possible because I want to show annotation shapes when I click from button not on graph?

Try v9.


Reduce usage of afterEvaluate as much as possible

Problem:
The plugin overuses afterEvaluate which causes issues if a user wants to make additional changes to task. At the moment this only possible if this is done in another afterEvaluate block in a build script.
Solution:
A lot of the afterEvaluate code be avoided by using the lazy configuration concept aka Provider API.

I completely agree. I've used the providers and properties in more recent (non-public) gradle plugins and that is clearly a better solution. I've meant to give this plugin some love, but as I mentioned, it's a pretty low priority for me lately.


CH-8219 Support for php 7.2

Not sure if this is worth merging yet but it is what I will be using locally with php 7.2
If and when we upgrade, we'll want to merge this sucker in for testing.

wow what weird syntax that was. Looks good to me!


Does it support rotation ?

Looking for support for rotated boxes...

We are working on this. I'll message this issue when we have something to share.

@james-nvidia Any timeline you can share ?

Not at the moment, but we are actively working on it. Do you have any use cases planned?

Yes we already have a client on board. The sooner you implement the sooner we will be able to put this in production.

@jamessmith90 and @dexception
We have just pushed rotated bounding box detections. We will improve the inference speed over the next few weeks.


Patches cannot be applied twice

If an external build project with patch command is run a second time, the patching step fails.
For example :
[ 16%] Performing patch step for 'cactus-amc13'
patching file amc13/src/common/AMC13.cc
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file amc13/src/common/AMC13.cc.rej
make[2]: *** [CMakeFiles/cactus-amc13.dir/build.make:101: thirdparty/cactus/amc13/src/cactus-amc13-stamp/cactus-amc13-patch] Error 1
make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/cactus-amc13.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

This should be handled robustly and gracefully. As there are no appropriate option in the patch command, a .cmake script should be used.
Also, use the opportunity for applying all patches in a directory instead of listing them one by one.

Move to GitLab.


Cannot update user

Bug Report

User data are not saved to the database.
Expected Behavior

When I edit the user, entered data should be in the database.
Current Behavior

When I edit the user, entered data are not in the database.
Possible Solution

Steps to Reproduce

I am unable to reproduce it. I have similar project and it does work in it.
import { CollectionConfig } from 'payload/types'

const Users: CollectionConfig = {
  slug: 'users',
  auth: true,
  admin: {
    useAsTitle: 'email',
  },
  access: {
    read: () => true,
  },
  fields: [
    {
      type: 'text',
      name: 'fullName',
      required: true,
    },
  ],
}

export default Users

This is my user. The field is shown, however the data from the input are not saved. The same goes for registrating the first user.
Detailed Description

Okay, I tried to dig into that. I deleted .cache in node_modules folder. It compiled .js files right next to the .ts ones. It should be compiled to dist folder.
I was then able to save the user. However, I could not save profile photo. It logged out me and broke login. When I manually deleted the profile photo field in the database, I logged in again without problems.
Then I saved the profile photo again without problems, but it saved ID as a string instead of ObjectId. It does not work as expected. It's all weird

Hey @lukeeno — can you give a bit more detail regarding exactly what you're trying to do, where it's failing, and what the error is that you're facing?
When you are saying "could not save profile photo", are you referring to a separate document in a Media collection or similar? Or, are you trying to add a profile photo to a User document via a relationship field?
Document ids should be saved as an ObjectID, but when saving relationship field data, we store related document IDs as strings. This is actually deliberate and will help us when we support additional databases in the future. Is that what you mean?

Hey @lukeeno — I'm gonna convert this into a discussion but if we can parse out specific things that are broken, I will open new issue(s) with the bugs that you find. But my hunch is this is just related to bad data in your database.
We are 100% around to help though - let's keep this going in the discussion!


nvim-autopairs import called without required argument 'config'

error: anonymous function at /nix/store/d1q0xzp2pf4z22yksllswm0r7yd94kf7-source/plugins/helpers.nix:1:1 called without required argument 'config'

       at /nix/store/d1q0xzp2pf4z22yksllswm0r7yd94kf7-source/plugins/utils/nvim-autopairs.nix:5:13:

            4|   cfg = config.programs.nixneovim.plugins.nvim-autopairs;
            5|   helpers = import ../helpers.nix { lib = lib; };
             |             ^
            6| in
(use '--show-trace' to show detailed location information)

I believe this should be called with inherit.

I have a similar issue with neogit

inherit lib is semantically equivalent to lib = lib. The problem was actually that the config = config or rather inherit config was missing. Should be fixed.
Thanks for reporting


x86-interrupt requires feature flag

error: x86-interrupt ABI is experimental and subject to change (see issue #40180)
  --> src/interrupts.rs:17:1
   |
17 |   extern "x86-interrupt" fn breakpoint_handler(
   |  _^ starting here...
18 | |     stack_frame: &mut ExceptionStackFrame)
19 | | {
20 | |     println!("EXCEPTION: BREAKPOINT\n{:#?}", stack_frame);
21 | | }
   | |_^ ...ending here
   |
   = help: add #![feature(abi_x86_interrupt)] to the crate attributes to enable

Err, to be more specific, it's needed in Handling Exceptions, but not mentioned in there.

Thanks for reporting!


extension of the callToString method

In my case angular web application throwing error
    /** @internal */
    _checkAllValuesPresent(value) {
        this._forEachChild((control, name) => {
            if (value[name] === undefined) {
                throw new Error(`Must supply a value for form control with name: '${name}'.`);
            }
        });
    }

'cypress-fail-on-console-error' was catch this exception but when i'm want to exclude it by config - it's was not excluded
my config
failOnConsoleError({
  excludeMessages: ['Must supply a value for form'],
});

It was happen because method callToString return wrong string for throwing error. It was ERROR {}
I'm trying to fixing this method adding more ternary handling to be able return correct string.
I also extended the unit test for callToString

I a nutshell: callToString() -> JSON.stringify(new Error('error msg')) is returning "{}" but we expect to get the message 'error msg' for message exclusion.
I put one comment on your code as an idea. Next to that I am confident with your changes and like to merge it.


prop-types

Use PropTypes from prop-types instead of react package

Warning: Accessing PropTypes via the main React package is deprecated. Use the prop-types package from npm instead.
React.PropTypes is deprecated since 15.5 and will be removed in the future.

v4.1.0 released


Added CLValue.Some() method to extract values wrapped in Option(CLType)

Summary
When the network returns an Option(CLType) with a complex type like List or Map, it's not easy to extract the value inside.
Implemented the method Some() in the CLValue class to extract easily these values.
TODO
n/a
Checklist

[X] Code is properly formatted
[X] All commits are signed
[X] Tests included/updated or not needed
[X] Documentation (manuals or wiki) has been updated or is not required

Many thanks for the review @mrkara !!


Add cypress dashboard

Added parallelization of unit tests and cypress tests. Unit test is now one stage of the build, and takes up one of the travis machines. Cypress tests run on 4 travis machines and is now takes a little over 3 minutes (previously took 12 minutes) to run.

stale


Imagegick : [ERROR] Unable to read image from path (/tmp/GlideDSyBW4)

OS: Ubuntu 20.04
PHP: 7.4.3
imagick extension: 3.4.4 (it is enabled)
imagemagick OS package: 6.9.10-23 Q16 x86_64
Problem
The following code throws the error (at line where save() function is called):
$image = Image::load('PATH_TO_MY_IMAGE');
$image->useImageDriver('imagick');
$image->width(200);
$image->height(150);
$image->optimize();
$image->save('ANOTHER_LOCATION');

[ERROR] Unable to read image from path (/tmp/GlideDSyBW4)

But without $image->useImageDriver('imagick'); it works as expected.
Tried solutions
I've tried to change the /tmp path. The error reflects my changes by the way, but no effect:
[ERROR] Unable to read image from path (/another_tmp_location/GlideDSyBW4)

I'm not sure that the problem is with /tmp permissions, because the file GlideDSyBW4 doesn't exist. However it does exist when imagick driver is not used.
I took a look at this issue spatie/laravel-medialibrary#1293. But it doesn't seem to be my case (no sharing hosting).

@kalitine kalitine
I have this problem too
Did you find a solution to it?

@MH-Zarkhani sorry, I have not. I had to comment the $image->useImageDriver('imagick'); code line.


[docs] Update the README.md to better cover the different products

The MUI Core repo readme currently features outdated copy that could be confusing to new users. Installation details only cover Material UI, and there are no mentions of Base or System.
This PR updates the repo readme to bring more clarity to the Core product line. I also made some small grammar changes throughout to make it sound more like native US English.
Preview: https://github.com/samuelsycamore/material-ui/tree/update-readme#readme

👆 Also, guess we should update the GitHub about field too so it matches the new Core description.

For sure. What do you think about sticking with the tagline we established in #32181 ? Could also mention each product by name.

MUI Core: ready-to-use foundational React UI components. Free forever. Includes Material UI, MUI Base, and MUI System.


Add github actions & remove travis-ci

Travis-CI is not in a good place.
many open source projects have moved away from it.
this PR removes the travis ci config (which stopped working a while ago) and adds GH actions.
The only issue I am unable to fix is the testBigGetMulti is failing in CI.
reducing the count to 10**3 fixes the issues so something tells me we are hitting some kind of limit.
However, I am not that familiar with memcached and pylibmc to be able to debug this, so any guidance here will be appreciated.
You can see the issue in my fork: https://github.com/asherf/pylibmc/actions/runs/1430630588
specifically:  https://github.com/asherf/pylibmc/runs/4129034995?check_suite_focus=true#step:10:71

Other than this issue, all other tests pass:

Fixes: https://github.com/lericson/pylibmc/issues/272

@lericson I am happy to incorporate any feedback you might have.

I haven't been able to figure out why the test might be failing. I have no issue with memcached 1.5.22 locally. It seems like the test is failing because values are evicted from the cache on CI but both my machine and CI show STAT maxbytes 67108864.

I haven't been able to figure out why the test might be failing. I have no issue with memcached 1.5.22 locally. It seems like the test is failing because values are evicted from the cache on CI but both my machine and CI show STAT maxbytes 67108864.

that was my guess as well, then I looked at the values in the Travis runs (from a few months back when they still worked) and those seem the same. I.e. maxmbytes is 64mb
Also note that under the test we get non of the values we requested (empty dict) , if some where evicted, wouldn't we get at least some values?

I manually installed the latest memcached (1.6.12) on my machine and get this error:
======================================================================
ERROR: testBigGetMulti (tests.test_cmemcached.TestCmemcached)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/tim/code/pylibmc/tests/test_cmemcached.py", line 58, in testBigGetMulti
    result = self.mc.get_multi(keys)
pylibmc.SomeErrors: error 19 from memcached_mget: (0x564136d71070) SYSTEM ERROR(Broken pipe),  host: <IP_ADDRESS>:11211 -> libmemcached/io.cc:392

As you said, reducing the count to 10**3 resolves the issue. Investigation to continue...

I put get_multi() calls inside the test's loop:
diff --git a/tests/test_cmemcached.py b/tests/test_cmemcached.py
index 97e7c53..b921a86 100644
--- a/tests/test_cmemcached.py
+++ b/tests/test_cmemcached.py
@@ -50,13 +50,19 @@ class TestCmemcached(PylibmcTestCase):
         # only contain bytes that can be implicitly decoded as ASCII.
         keys = ['key%d' % i for i in range(count)]
         pairs = zip(keys, ['value%d' % i for i in range(count)])
-
+        subkeys = []
         d = {}
         for key, value in pairs:
             d[key] = value
+            subkeys.append(key)
             self.mc.set(key, value)
-        result = self.mc.get_multi(keys)
-        eq_(result, d)
+            result = self.mc.get_multi(subkeys)
+            try:
+                eq_(result, d)
+            except AssertionError:
+                print(key)
+                print(value)
+                raise

     def testFunnyDelete(self):
         s = ""

and found that it works correctly until the 2187th iteration (keys start at key0, so key2186) at which point get_multi() returns nothing. It would be interesting to see if the same iteration fails on CI.
Anyway, I think we should just update the test to use a smaller count as I think this is more likely an issue in memcached than in pylibmc.

updated based on @timgraham suggestion (thanks for looking into it)
and tests seem to pass: https://github.com/asherf/pylibmc/actions/runs/1441134908

@lericson ping
any feedback here? Happy to incorporate any feedback you have.

Looks good to me. I think you could squash those commits.
You could try adding support for Python 3.10 (https://github.com/lericson/pylibmc/pull/271) in a separate commit. nose isn't compatible but maybe nose-py3 would be a drop in replacement.
Do you know what needs to be done so the workflow runs here?

@timgraham squashed.
I am happy to add support to 3.10, but I think it would make sense to have that in a follow up PR once this is merged (I'll do it).
I can also try to move things away from nose and to use pytest, that would probably help too...
But I think landing this PR and bringing back CI to this repo should be done first.
I think once this PR lands CI github actions will automatically enable.
It doesn't run now since this change is not on master.

@lericson ping

I'd move "& reduced num of keys tested in testBigGetMulti" to a separate line in the commit message with more information. Something like:
The number of keys in testBigGetMulti is reduced because the larger number
doesn't work with memcached 1.6.12. For an unknown reason, get_multi()
with more than 2186 keys here returns nothing.

@lericson ping

@lericson ping

Why was this closed and removed?

I will merge this even so.


Remove redundant ingress-class chart.

https://github.com/alphagov/govuk-infrastructure/issues/1196

Might clean up the places where we're specifying the default class in Ingress resources later.


Module doesn't work in python 3.5.3

There is an error when trying to run module under python 3.5.3.
import whois
File "---/python3.5/site-packages/whois/init.py", line 98
print(f"filterTldToSupportedPattern returns tld: {tld}", file=sys.stderr)
This issue is caused by using the new format string intruduced in python 3.6.

i suggest strongly you upgrade to at least 3.6
https://www.python.org/downloads/release/python-3510/
Python 3.5.10
Python 3.5 has reached end-of-life. Python 3.5.10 is the final release of
3.5.
Python 3.5.10 was released on September 5th, 2020.
Python 3.5.10 is the final release in the Python 3.5 series. As of this
release, the 3.5 branch has been retired, no further changes to 3.5 will be
accepted, and no new releases will be made. This is standard Python policy;
Python releases get five years of support and are then retired.
If you're still using Python 3.5, you should consider upgrading to the current
version. https://www.python.org/downloads/ Newer versions of Python have
many new features, performance improvements, and bug fixes, which should
all serve to enhance your Python programming experience.
On Wed, 8 Feb 2023 at 11:26, MBWlodarczyk @.***> wrote:

There is an error when trying to run module under python 3.5.3.
import whois
File "---/python3.5/site-packages/whois/init.py", line 98
print(f"filterTldToSupportedPattern returns tld: {tld}", file=sys.stderr)
—
Reply to this email directly, view it on GitHub
https://github.com/DannyCork/python-whois/issues/275, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACU73CQKNRAZBLNESK46V2TWWNYGJANCNFSM6AAAAAAUVCGSIY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Thanks for quick reply, i'm closing the issue.

;-)


About the TP parameter in the paper

Dear author, thank you for your excellent work. I recently read your paper and you described the TP indicator as: "Here TP [%] stands for the ratio of the number of tracked frames to the number of the frames of the object's ground truth trajectory." I would like to ask why the TP indicator of most sequences is not high for 3D object tracking?

The IoU threshold for evaluating TP is taken as 0.25. This threshold is not very high and thus leads to frequent id switching during tracking, I removed the part where the id switches frequently and only evaluated trajectories where the tracing id is constant and continuous. Therefore the TP here is not meant to reflect the tracking performance, but just to show the relative tracking length of the object. In the previous version of this paper, here we directly use "Tracked frame length" instead of TP. I hope my answer solved your question.


Update vm or template factories

@Fryguy Based on the discussion [here] (https://github.com/kbrock/manageiq/commit/607c7441b8a05095163669dae5f7e82c115514d4#commitcomment-9209455)

Cool...will merge when green.

Updated to correct location strings


Convert notebooks to canvas quizzes

Now working in https://github.com/bkchang-97/e340quizzes

[ ] Use read api token from a .env file that's not checked in to git

[ ] dump file listing to yaml for easy editing

[ ] read edited file list and delete listed files from sandbox

[ ] parameterize questions using https://pypi.org/project/papermill-jupytext/

[ ] create pdf files for the student and solution notebooks

Just commenting progress here. The work for this is being done in this repo.
As of writing this comment the following is functional:

Reading .md, .ipynb, and .json files for parsing
Parsing the files, including converting latex to the Canvas format
Multiple choice questions
Question groups

Things to continue working on:

When updating an existing quiz, don't add duplicate groups or questions
Add all other question types
Add references to other files such as images or hyperlinks

Then we can work on paramaterizing the quizzes.

All of the todos from my last comment are done.

that's great -- before we get to parameterization, I think it would be good to add a docs folder and start a jupyter-book markdown page, since this is getting more complex.   At some point we'll figure out readthedocs, but for now just fake it with a github action to build a gh-pages deployment.   Go ahead and free-associate as far as a walkthrough of what you've got so far.   Put in placeholders for  1) working with a solution key notebook that can includes answers to questions that can be filtered out for the student version, 2) quiz parameterization 3) printing quizzes using paged_html_theme and trio_chrome.

continue work on https://github.com/eoas-ubc/md2canvas

https://github.com/bkchang-97/md2canvas/tree/master/examples/e340quiz

documentation script/playbook/narrative that walks through the canvas e340 quiiz from nose to tail
i) run phil's script  -- link repo
ii) clean markdown -- 3 most common issues
...

file upload/list/destroy in same manner


Translate Volume page to Indonesian

Addresses #15341
It's a lengthy one, I expect a horde of comments!
@irvifa @girikuncoro

/assign @irvifa

@phanama hello.. it's already sometime, ny update on this?

@irvifa Actually I was waiting for your reply on the comments above. Thought you were busy. Can we continue the discussion above?

/retest

/test all

just remember, I would want to see the netlify link of this page first in order to make sure formatting is ok, nothing breaks the page, etc. any idea how to get the link?
/lgtm cancel

@girikuncoro Any idea why the netlify is not working?

/hold

/retest

Closing and reopening to check if it triggers netlify

I think there is a problem with the Netlify build. It has been in the processing state since Aug 30th. Can someone with access please cancel it and we could do a /retest here?

@irvifa @hvaara @nikhita thanks for your help! got the netlify preview link now, appreciate it!

/lgtm

/approve

/approve

/approve

/hold cancel


Rephrase introduction for better clarity

Signed-off-by: Baiju Muthukadan<EMAIL_ADDRESS>

Is there a broad grammatical rule you’re trying to apply here?

I used the Grammarly app: https://www.grammarly.com


DisableErrorsInGeneratedCode

Would you consider adding a DisableErrorsInGeneratedCode option?
As its name implies, it would, just like it's existing inspiration DisableWarningsInGeneratedCode, prevent errors from being raised on anything annotated with @Generated.
I'm expecting you :innocent:  to reply and close this as you "NEVER!", because "why would anyone possibly want to ignore errors even in generated code?!", but here's the rationale:
Some of error-prone's (great!) checks are not necessarily flagging clear errors only. For example, Var is more of a best practice style which can help prevent errors - but a violation of it is not an error. I really like Var though, and have cleaned up an existing code base to that style (because I now have one small reason less to adopt Kotlin and Xtend which have this same concept), and would now like to enforce it to fail builds running on Gerrit code review if my colleagures re-introduce unnecessary ugly final.
But I cannot use e.g. -Xep:Var:ERROR because my project uses a code generator which is not (yet) peperring the @Var annotation over it's generated code - so I'm stuck. Of course one can try to get that code generator to comply - but, generally speaking, that is not realistic - nor neccesary.

In this specific case, I've suggested that the Immutables.org code generator could emit @Var, but there will be other people running into similar isuses with other Bug Patterns and other Code Generators.

FYI now that #599 has landed you can probably achieve this by excluding the paths to the generated code

@msridhar yeah as soon as #599 is actually released... waiting for https://github.com/google/error-prone/issues/821

I now use XepExcludedPaths to achieve what I originally filed this issue for; just using like:
-XepExcludedPaths:.*/target/.*
So at least from my side this issue could just be closed now, there's no "need" for this, actually.

I mean, I'm using -XepExlcludedPaths too, but I also kind of like the idea of ignoring things based on annotation. perhaps even just excluding generated code by default because this is a tool to audit my team's code not generated, and not libraries.

This can be closed now?


(minor) When getting crushed between a starport and a hub, you can have negative HP

This one is kinda rare since it involves having a save where a planet generates so close to a hub that it's startport will intersect  the hub within a reasonable timeframe. It also doesn't affect gameplay (all effects clear on respawn), so it's a really low priority unless there's another way to trigger it (maybe you don't need 2 immovable objects?)
Issue: see title
Repro:

Generate a world where a starport passes through a hub
get crushed in the gap
Sometimes your HP bar will show up as negative

V2.0.0
LGK20, Android

For anyone interested in fixing this, it should be easy enough to clamp ship health so that it doesn't go below zero. If it does, then it should just be reset to 0. The code referenced below should be responsible for ship damage:
https://github.com/MovingBlocks/DestinationSol/blob/fa2a67e059b8bbd6d7a25836d04d999ffb0b860b/engine/src/main/java/org/destinationsol/game/ship/SolShip.java#L450-L464


RTL-SDR OGN: libjpeg package not found during installation

Hi,
during installation of RTL-SDR OGN the installation routine tries to install the package "libjpeg" which is not available in the Debian (Raspbian) Stretch repo as far as I can see (E: Unable to locate package libjpeg). That's why the adsb-receiver setup gets halted.
Is there any additional repo required to get libjpeg?
Best wishes,
Alex

Yes it does. I do plan on getting back to that script. libjpeg was renamed I think libjpeg8 because for some reason the people maintaing distro's, especially Unbuntu feel the need to make things more a pain in the ass... Anyways I had not heard from anyone since I first began initially created the Open Glider Network script which never made it as an option into a release back quite some time. I think @Romeo-Golf had the script modified to work at one point but I removed it from the options due to the exact issue you are having.
I am sorry to have not addressed this sooner and will work on getting a working script up and running as well as adding as an actual installation option once again within the next minor v2.x release. Keep in mind it will be a proof of concept process being it is pretty much a strictly Europian thing.
BTW how did you stumble accross the option to install it? LOL!

OGN support is yet to implemented. Once this happens issues such as this will be addressed.


Code

This doesn't have any information as to what the issue is. Feel free to reopen if you'd like to write a description of the issue.


Dragging inner content

Hey, is there a way to move the outer view by dragging only the inner scroll?
(like in Apple Maps app, Find My by Apple, Google Maps)
for example UIKit solutions:
UBottomSheet - https://github.com/OfTheWolf/UBottomSheet
ClassPass app - https://medium.com/classpass-engineering/creating-a-fluid-scroll-experience-on-ios-faeb29be3bdb

Yes currently we don’t support this behavior by default, but you can implement it your own like this:
(...), mainContent: {
    if self.bottomSheetPosition == .top {
        ScrollView {
            Text("Hello World!")
        }
    } else {
        Text("Hello World!")
    }
}
(...)

Yes currently we don’t support this behavior by default, but you can implement it your own like this:
(...), mainContent: {
    if self.bottomSheetPosition == .top {
        ScrollView {
            Text("Hello World!")
        }
    } else {
        Text("Hello World!")
    }
}
(...)

I believe the issuer wants to have it to behave like this
By modifying the following code in VStask {}

The current version can not be dragged when for example you hold on the text , instead of the upper BottomView in the drawer , and drag it .
the photo code fixes it .

I believe the issuer wants to have it to behave like this
By modifying the following code in VStask {}

I’m not sure about that. If you have a look at Apple Maps for example you will see that Apple has the content in a ScrollView, but you can’t scroll the ScrollView until you are at the top position.
https://user-images.githubusercontent.com/63545066/119891580-6eed0400-bf39-11eb-9afd-d05916b869ef.mp4
But maybe @Thongvor can bring light in the dark :)

I will now close this issue because all features have been moved to #11.


Improve display of reconciliation results

Problem Description
During user interviews conducted in September on the redesign of the reconciliation dialog feature, a common pain point identified by reconciliation was the challenge of dealing with a large number of results displayed after selecting a reconciliation service. The feedback highlighted issues with both the accuracy and the overwhelming nature of the displayed results. Users expressed the need for improved visibility and control as they often had to sort through numerous irrelevant results and this also causes a distatsteful UI by expanding cells thereby creating too much whitespace.
Proposed solution
To address the identified problem, I propose an enhancement to the reconciliation feature in OpenRefine. The suggested solution involves introducing a more user-friendly way for managing the display of reconciliation candidates.

We start of displaying limited number of resuts, say limited to 2 by defaut.
A "See More" button: Users can reveal additional candidates beyond the initially specified limit.
A "See less" buton (link) to reverse the previous action and return back to the default display of 2 results.

This solution aims to provide users with greater control over the display of results, making the reconciliation process more efficient and user-friendly.
Alternatives considered
An alternative is a straightforward "truncate results" option added to the dropdwon options of each reconciled cell. On click, a pop-up containing an input field appears where users can input the number of results they want displayed.
Additional context
The proposed solution is a response to direct user feedback about the challenges faced when reconciling data, particularly in scenarios where a large number of candidates are presented. By allowing users to control the visibility of results, the proposed feature seeks to enhance the overall user experience, improving accuracy, and reducing the time and effort required for reconciliation tasks.
Proposed defaukt display of results

When user clicks on "See more"

Alternative proposed

Thanks @Lydiaofficial - I think this is a good & elegant solution to add "See more" after 2 suggested matches. I just wonder if we should make the Search for match link available already in the first view, so something like "See more | Search for match" & then "See less | Search for match", but will let others comment on this as well.
Another point is that maybe we need a better way to indicate scores / ranks to users because this (100) is really unclear to me (I had at some point thought it's indicating a QID 🤦🏻♀), but I can make a separate issue about that.

Thanks for working on this! The current situation is definitely seriously sub-optimal. Something it might be worth considering doing is rather than fetching lots of results and then hiding a portion of them, instead returning the default number of results requested to its previous value of 3. We could also consider making the control for the number of choices more obvious, but I think an appropriately chosen default should fix the bulk of the problem.
You can see what the original UI looked like here: https://youtu.be/5tsyz3ibYzk?si=eDtVXpWcKZfRJjiG&t=219
Reconciliation really needs to be looked at from a systems point of view because the behavior of the reconciliation services greatly influences the user's perceptions. I suspect part of the reason that so many results are being returned is because poor ranking means there's a good chance that the desired result isn't in the top 3. I think a better fix than showing more results would be to improve the ranking.
I got the screen below when doing some work reconciling authors today. It's clearly not acceptable from several different points of view.

No user is going to look at 25 results, so there's no point in returning them all
Results with very low scores are likely to be irrelevant and shouldn't be returned to the user
A half dozen results with precisely the same score gives the user no information

Another historical note is that Wikidata is structured differently than Freebase was so that useful Freebase types like Author, Politician, Professional Athlete, etc don't exist in Wikidata. Instead they're all just Humans (Q5), so it may be worth putting some thinking into how we help users with this structural difference. There's been some discussion of supporting reconciling against a constant e.g. Occupation == Writer so that they don't have to add an Occupation column to their data if it doesn't naturally exist there, but perhaps there are more clever solutions, particularly for the common case of reconciling people.

[The difference between the two sets of results is that Author2 on the right was reconciled using the added Occupation column, while Author on the left was reconciled just against type Q5 with the book title as Notable Work (which I doubt helped much since this isn't well populated in Wikidata]

I definitely agree with @tfmorris in regards making it super easy to reconcile against higher types. A mini facet might be one way to show the distribution of higher types than what the user might have initially picked to reconcile against.  If a user picked a subtype initially it would be fantastic to show them the distribution (count/percentage) of candidates returned so that a user could 1-click to reconcile against a suggested higher type.  Another example, this might even help show that 80% of returned candidates are not even in the same type hierarchy as initially requested by the user.  I still stand by my idea of making the reconciliation suggestion dialog by default a much larger or expandable thing, especially for showing type distribution counts (mini facet in the expanded dialog). I also see the need for an extension that can support browser tabs for users with 2 monitors or split browser on 1 monitor which allows a reactive user interaction with a recon dialog in 1 tab and grid in the other tab.

Sorry, I guess I should have kept my comment more focused. My main suggestion is to reduce the default number of returned results to 3.

Here are the mockups.
1: 3 displayed results and the "see more" and "serach for match" options as defaults

2: More results on expand and the "see less" action after "see more" is clicked.


tests: more integration tests for notifications

Verify that multiple status-types are taken into account as expected.
Refs: https://github.com/go-gitea/gitea/issues/16796

Codecov Report

Merging #17845 (adad8cc) into main (24a8d54) will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main   #17845      +/-   ##
==========================================
+ Coverage   45.54%   45.56%   +0.01%
==========================================
  Files         808      809       +1
  Lines       90059    90059
==========================================
+ Hits        41019    41031      +12
+ Misses      42491    42469      -22
- Partials     6549     6559      +10

Impacted Files
Coverage Δ

models/user/email_address.go
49.80% <0.00%> (-5.67%)
:arrow_down:

modules/charset/charset.go
71.71% <0.00%> (-4.05%)
:arrow_down:

modules/notification/mail/mail.go
35.29% <0.00%> (-2.95%)
:arrow_down:

models/userlist.go
88.88% <0.00%> (-2.78%)
:arrow_down:

modules/queue/queue_channel.go
95.00% <0.00%> (-1.67%)
:arrow_down:

modules/notification/ui/ui.go
60.86% <0.00%> (-1.45%)
:arrow_down:

models/access.go
69.67% <0.00%> (-0.88%)
:arrow_down:

models/notification.go
64.79% <0.00%> (-0.87%)
:arrow_down:

models/repo_list.go
78.40% <0.00%> (-0.80%)
:arrow_down:

services/pull/pull.go
41.78% <0.00%> (-0.41%)
:arrow_down:

... and 58 more

Continue to review full report at Codecov.

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

:rocket:


fix(cleaner): change dd to wipefs

Fixed high cpu/io utilization of cleanup job. Using dd caused heavy load on the CPU, and prevented other pods from getting scheduled on the node. It also caused kube-api server crash at times. By using wipefs instead of dd only the file-system signatures will be erased. This process is much faster than writing zeros, since we are only working with certain block(superblocks).
Signed-off-by: Akhil Mohan<EMAIL_ADDRESS>

Codecov Report

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

@@           Coverage Diff           @@
##           master     #273   +/-   ##
=======================================
  Coverage   52.19%   52.19%
=======================================
  Files          51       51
  Lines        2395     2395
=======================================
  Hits         1250     1250
  Misses       1046     1046
  Partials       99       99

Continue to review full report at Codecov.

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


[FLINK-5480] Introduce user-provided hash for JobVertexes

This PR allows users to provided (alternative) hashes for operators in a StreamGraph. This can make migration between Flink versions easier, in case the automatically produced hashes between versions are incompatible. For example, users could just copy the old hashes from the web ui to their job.

cc @uce

Thanks a lot for the reviews @zentol and @uce . I made another commit that addresses the review comments.

Thanks for addressing the comments.
I had a quick offline chat with Stephan regarding the naming of setAdditionalNodeHash. He also agrees that the name moves internal implementation details to the user API. Furthermore he raised the point that there is no way for the user to get the relation between uid and setAdditionalNodeHash.
He proposed the following, which I liked.

Rename setAdditionalNodeHash to setUidHash. Add a big fat comment that this should be used as a work around or for trouble shooting.
Add a comment to uid saying that the given String will be hashed to the ID that corresponds to the JobVertexID in the logs/web UI so users now what's happening.
Make in both Javadocs clear how the methods relate to eachother.

What do you think?

Ok, I changed method names and commented as proposed.

Thanks! Looks good. Just tested this with a job where I did not set any UIDs. After changing in an incompatible way (with respect to auto generated IDs) I was able to restore my state with setUidHash. I further played around with it by adding a completely new operator, which also restored the state of an operator in addition to the regular one. I think this will be very powerful once we provide some less low level plumbing around it. The biggest pain point right now (independent of this PR) is figuring out the old IDs.
I will go ahead and merge this for master and release-1.2.

Thanks a lot for the review and such intensive testing @uce !

Hey @uce, @StefanRRichter
I too have a flink job running in production where operators doesn't have uids. Now, I have to add new operators and the job doesn't restart from savepoint.
I came across this PR, and I tried setting the uid hash of the operator-chain before adding a new operator but still loading from savepoint doesn't work.
I'm sorry to bother you, and I know this has been a long closed PR, but can you help me out in figuring out how to restart from savepoint when we don't have uids set initially.
Thank you so much. :)
PS. Sorry to spam here.

@ShashwatRastogi-Reflektion

For each task to load from the savepoint S1:

Determine the existing hash by searching for the task ID in the logs/UI
Set the uidHash for that task to that value via SingleOutputStreamOperator#setUidHash

For each task:

Set the uid to whatever value you wish in the future to use via SingleOutputStreamOperator#setUid

Resume the job from the savepoint S1.
Create a new savepoint S2, and remove all calls to setUidHash
Resume the job from the savepoint S2.

Hey @zentol
Thank you for replying back. I was trying to do exactly the same thing, but I think I am messing something up that is why it isn't working in my case.
In my logs, i get the task description like:
2018-04-03 12:24:45,876 INFO  org.apache.flink.runtime.executiongraph.ExecutionGraph        - Source: Custom Source -> Filter -> events-with-timestamp -> filtered-events-with-timestamp -> events-mapped-to-session (1/1) (5c69d4ad31a844978a740c1d24297b68) switched from CREATED to SCHEDULED. Is the hash present in this log statement called uid hash?
This hash is not the same which I get in the UI.

I have tried using both and both of them doesn't work.
Also, my operators are chained together so I will get one uid-hash for the entire chain, right?
And, I would be setting the same uid-hash for all operators in the chain?


Generic type hint not working right with nested class

Type: Bug
With this first example, B[int] is correctly seen as A[int]
Sample 1
import typing
import typing_extensions

T = typing.TypeVar('T')

class A(typing.Generic[T]):
    pass

B: typing.Type[A] = A
a: A[int]  # seen as A[int]
b: B[int]  # seen as A[int]

But with this second example the int generic info is missing:
Sample 2
import typing
import typing_extensions

T = typing.TypeVar('T')

class A(typing.Generic[T]):
    pass

class Properties:
  C: typing.Type[A] = A

c: Properties.C[int] # seen as Type[A] only, no int info

Can vscode be fixed to correctly show that c should be type A[int]?
Extension version: 2023.8.0
VS Code version: Code 1.78.1 (Universal) (6a995c4f4cc2ced6e3237749973982e751cb0bf9, 2023-05-04T09:57:42.343Z)
OS version: Darwin x64 21.6.0
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-5250U CPU @ 1.60GHz (4 x 1600)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
4, 6, 6

Memory (System)
8.00GB (1.66GB free)

Process Argv
--crash-reporter-id c48e9027-7f92-4e80-b41f-684aa4a6e195

Screen Reader
no

VM
0%

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdc:30486549
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
2e4cg342:30602488
pyind779:30671433
f6dab269:30613381
pythonsymbol12:30671437
a9j8j154:30646983
showlangstatbar:30737416
vsccsb:30705552
azdwalk:30721579
pythonms35:30701012
pythonfmttext:30731395
fixshowwlkth:30730052
showsbindicator:30730056
pythongtdpathcf:30739705

This is a duplicate of https://github.com/microsoft/pylance-release/issues/4350, which was closed.

Do you intend for C to be a type alias or a variable? You have defined it as a variable, but you're trying to then use it as though it's a type alias. You can't specialize a variable using brackets.
If you want to define a generic type alias scoped to class Properties, you can define it as follows:
class Properties:
    C: typing.TypeAlias = A[T]

If you want to define a variable C scoped to class Properties, you must specify its type arguments in the type annotation. If you omit the type arguments, a static type checker will assume that you meant Any.
class Properties:
  C: type[A] = A # This is equivalent to `C: type[A[Any]] = A`

I do not intend it to be a type alias, I intend it to be a variable that stores the class.
My intention is to have the behavior be the same in Sample1 as in Sample 2.
Why should the behavior differ?
In both cases a class is first defined.
Then a variable is set equal to that class.
Then a new variable references the last variable and adds the generic type info.
It works in sample 1 but not in sample 2. The code has the same steps.
Why must a type alias be used in sample 2 but not sample 1?

The difference between sample 1 and sample 2 is that you're referencing a symbol from the same execution scope in sample 1 but a different execution scope in sample 2. Assignment-based type narrowing is applied within an execution scope but not across scopes. The type of B in sample 1 is therefore narrowed based on the assignment of A. This narrowed type also takes into account the fact that you have specifically assigned A, not a value of type type[A] (which represents "any subtype of class A").
In sample 2, you are referencing C from outside the execution scope in which it is declared. That means its type is simply type[A], which is interpreted as type[A[Any]] because you omitted the type argument. This type represents "any subtype of type[A[Any]]" in the Python static type system.
It sounds like you might be new to static typing in Python. You're stumbling on some basic concepts. You may find it useful to read this documentation and this documentation.
I recommend that you enable type checking (set python.analysis.typeCheckingMode to either "basic" or "strict"). Pyright will then provide you with error messages that will help guide you. You're doing a number of things that are not allowed in the Python static type system.

Thank you for explaining this and for the resources.


Atom IDE throwing errors

No matter which ide packages I have enabled within atom, they all throw the same error. (ide-html, ide-typescript, ide-css)
I believe this problem is related to the fact that I'm using npm link in a subdirectory to reference a local package in it's parent directory.  I don't know if the directory structure is parsed by atom or by your package.
Error: Message header must separate key and value using :
    at C:\Users\xxxx\.atom\packages\ide-html\node_modules\vscode-jsonrpc\lib\messageReader.js:68:23
    at Array.forEach (<anonymous>)
    at MessageBuffer.tryReadHeaders (C:\Users\xxxx\.atom\packages\ide-html\node_modules\vscode-jsonrpc\lib\messageReader.js:65:17)
    at StreamMessageReader.onData (C:\Users\xxxx\.atom\packages\ide-html\node_modules\vscode-jsonrpc\lib\messageReader.js:194:43)
    at Socket.<anonymous> (C:\Users\xxxx\.atom\packages\ide-html\node_modules\vscode-jsonrpc\lib\messageReader.js:185:19)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)
    at readableAddChunk (_stream_readable.js:250:11)
    at Socket.Readable.push (_stream_readable.js:208:10)
    at Pipe.onread (net.js:594:20)

If I examine the contents of the buffer that is leading to the exception: I can see the following
<— Last few GCs —>

[13628:078B3110] 573401 ms: Mark-sweep 1076.6 (1354.8) -> 1076.5 (1354.8) MB, 801.9 / 0.2 ms allocation failure GC in old space requested
[13628:078B3110] 574240 ms: Mark-sweep 1076.5 (1354.8) -> 1076.5 (1323.3) MB, 838.6 / 0.2 ms last resort GC in old space requested
[13628:078B3110] 575071 ms: Mark-sweep 1076.5 (1323.3) -> 1076.5 (1315.3) MB, 830.5 / 0.2 ms last resort GC in old space requested

<— JS stacktrace —>

==== JS stack trace =========================================

Security context: 0EA5B091
1: inflight [C:\Users\xxxx.atom\packages\ide-typescript\node_modules\inflight\inflight.js:~7]
[pc=389204DB](this=0E385525 ,key=576F50E9
<String[459]: readdir\x00
D:/repositories/daterangepicker/website-angular/node_modules/knockout-daterangepicker-fb/website-angular/node_modules/knockout-daterangepicker-fb/website-angular/node_modules/knockout-daterangepicker…

@frost-byte the exception thrown indicates that someone sends a message with a malformed header. The header to be sent is explained here: https://microsoft.github.io/language-server-protocol/specification
Have you ask the Atom IDE guys for help. I am a little puzzled here?

If you look at the content of the final block of text that I pasted above, the exception is thrown because that is the content of the header; when it starts parsing the header it interprets the < as a key and expects the next character to be a : but it reads the - instead in <- Last few GCs ->.  I believe this might be a dump generated as a memory error - a result of recursion in a circular manner, leading to an overflow in a buffer?  Incidentally I did open an issue with atom for the package that all ide packages interact with - there are packages written for many languages and they each provide autocompletion, outlining, type resolution, and resolving docs for types.  This error is being thrown by several different ones.  If you look at the last line of my post, you’ll see a directory path being referenced in a circular manner because it appears to be following the symbolic link

@frost-byte I am still not sure what I can do to fix this. The reason why this happens is very likely as follows:

Atom communicates with the server using stdin / stdout using the vscode-rpc package
either server or client writes to stdout <— Last few GCs —> ... which is then interpreted as a JSON RPC message which of course fails.

To avoid this the client  / server communication should happen using one of the other transports. For example Node IPC, socket, pipe, file streams, ...
But this needs to be fix in Atom which spawns the server and sets up the communication channel.
Any objection to close?

I suppose that will be fine, it appears to be atom specific.

OK. Closing then.


How do you reconstruct the structure from the embeddings (Figure 5)

In the paper, you don't mention what is this structure that you depict (e.g. its UniProt ID), or you mention exactly how you get the structure from an embedding. Do you do some additional training of some module?

Hello jaku! I believe, based on the paper, and this figure (linked here)

CHEAP is used as an embedding space compression algorithm to enrich the expressivity of the pre-existing and pretrained ESMFold. If what I am understanding is correct, CHEAP exists due to the author's observation of strange activation functions within the model, and created as a way to also couple seq/structure representations in a model. In this sense, you can think of CHEAP as a model that is trained to optimize the information captured by embeddings generated by ESMFold
Hope this helps! If I am incorrect at any point, please feel free to correct me as well!

Hey @patjiang, thanks for the message. I went through the Appendix and they actually mention it in one of the comments in the pasted code. Effectively, what they do is that they use the CHEAP decoder to get back into the ESM embedding, which is then compatible with ESMFold and then use the original ESMFold.
Still, this is not apparent from the paper straight away, nor is the experiment with structure reconstruction adequately describe (including, for instance, the exact dataset, or what protein is shown in the figure).


Add a keyboard shortcut option for Awake's "Keep screen on" toggle

Description of the new feature / enhancement
It would be nice if I could just use a shortcut to enable "keep screen on" without having to click the taskbar icon.
Scenario when this would be used?
It would reduce the time required for enabling/disabling the functionality and therefore decrease the resistance compared to just moving the mouse every once in a while.
Supporting information
No response

Duplicate of #12661.


Could not find a declaration file for module 'uwebsockets-express'.

I'm experiencing this error after upgrading to the latest version 1.3.9:
src/core.ts:8:24 - error TS7016: Could not find a declaration file for module 'uwebsockets-express'. '/home/matteo/colyseus-example/node_modules/uwebsockets-express/build/index.mjs' implicitly has an 'any' type.
  There are types at '/home/matteo/colyseus-example/node_modules/uwebsockets-express/build/index.d.ts', but this result could not be resolved when respecting package.json "exports". The 'uwebsockets-express' library may need to update its package.json or typings.

8 import expressify from "uwebsockets-express";
                         ~~~~~~~~~~~~~~~~~~~~~

Hi @Byloth, sorry and thanks for letting me know - please stick with version 1.3.6 for now 🙏
I'm updating how to build this project in order to support ESM and it seems build is bad on versions higher than 1.3.6.

Sure, no problem... I noticed it!
Don't worry... I've already rolled back to the previous version.
This was just to let you know! 😉

Thank you for raising this issue so fast, I believe this got fixed on https://github.com/colyseus/uWebSockets-express/commit/a78e8d2b0c8ce56866a063e9788002f728826772 🙏


Test: add missing imports and remove unused source actions

Refs: #95831

[ ] anyOS @kieferrm
[x] anyOS @dbaeumer

Complexity: 3
Create Issue

Summary
This iteration, we added two new source actions: add missing imports and Remove all unused code. This actions let you trigger add missing imports or remove unused from anywhere in a file
You can also use them with editor.codeActionsOnSave or configure a keybinding for them
    {
        "key": "ctrl+shift+i",
        "command": "editor.action.sourceAction",
        "args": {
            "kind": "source.addMissingImports",
            "apply": "first"
        }
    },

Test these new source actions and their behavior. Add missing imports should pretty much always work (although it may not select the ideal import in all cases).
Remove all unused code has more limitations due to current TypeScript APIs

@mjbvz it is not clear to me how extensively I should test this from a TS perspective. General impression is 'Add missing import' works as expected. Remove unused code is not.

I get the error No source actions available for 'source.addMissingImports' when trying to run this.


npm test doesn't work from WebStorm interface

WebStorm provides an interface to run tests by click:

But when I run tests this way, one of them is broken, because WebStorm's console prints colored text:
1) Mocha should not output colors to pipe:

      Uncaught AssertionError: false == true
      + expected - actual

      -false
      +true

      at test/color.spec.js:15:7
      at ChildProcess.exithandler (child_process.js:204:7)
      at maybeClose (internal/child_process.js:827:16)
      at Socket.<anonymous> (internal/child_process.js:319:11)
      at Pipe._onclose (net.js:477:12)

There is one more problem with WebStorm: https://github.com/mochajs/mocha/issues/2775

@Elergy Interesting.  It's not the console, because running npm test in a console from WebStorm doesn't exhibit this behavior.  Anyway, I would probably file this at youtrack.jetbrains.com

@boneskull I debugged this behavior and found that if we run code inside WebStrom's npm-test console:

process.stdout.isTTY is always true
process.env.FORCE_COLOR is always true

Therefore supports-color library tells us that the console supports colors (and it's true).
Then we wrap the strings we want to log into ANSI-escape-colors
How do you think, can it be a problem for users or it can affect only Mocha-contributors?


Custom model data not supported by randomize icon property

I can't get custom model data to work with the randomize_icon property of wands.
Ex:
randomizedpotterwand:
  icon: wooden_hoe:{CustomModelData:1}
  randomize_icon: wooden_hoe:{CustomModelData:3}

Comes out as a basic wooden hoe that turns into the correct custom model data attached to the icon property.

I think this may have been fixed by the fix for #639 - can you please let me know if not?

Yep! Everything looks to be working correctly. Thanks Nathan!


Fix: make some functionality public to enable API extension

The current API in the Controller classes marks .requestController member internal. This prevents creating API extensions in the apps that use HarvestKit-Swift e.g
extension HarvestController {
 func yetAnotherGetFunction() // <- this needs to use requestController
}

Same goes for the initializer of the Timer class. If it is marked as internal there is no way to extend TimersController in the client app with functions that would require to create Timer objects.

Nice spot, hadn't thought of this. Would be better to set these as private(set) public var though so that the request controllers themselves don't get replaced by extending applications I think.

Yeah, that's good too. The main point to make .requestController accessible from extensions in the apps.

Yep that's cool. If you could make that change and commit it then I'll approve and merge this.

Sorry, I've answered to quickly before. The current PR is better because it uses
public let requestController: <RequestControllerType>

The requestController cannot be replaced by the extensions because of the let keyword.
And actually we don't want to replace the requestController objects once they are set. So, let is the way to go.