Refactor EIP handling

Work in progress to rebase the external EIP handling changes I've been working on to the latest codebase.
I still need to verify that these rebased changes work the same as the changes that I have in my fork that I've been testing (https://github.com/detiber/packet-ccm/tree/test).

Rebased now that #231 has been merged, but this PR also includes a fix from #232 as well.

The merger of #232 should make this even smaller post-rebase?

@deitch rebased on latest.

Also, it doesn't look like it checks the EIP address, only the node's?

I was just running through another test of https://github.com/detiber/cluster-api-provider-packet/pull/65 that adds kube-vip support to the cluster-api provider and I noticed that the Equinix Metal CCM is assigning the EIP to one of the control plane nodes. However, I don't the think the CCM should be doing this.

It only does this if you pass it the right tag for the EIP. If you do not, CCM ignores it. That is the flag that says, "you should control the EIP" or "you should ignore it".
if you are using kibe-vip in its mode of managing the control plane EIP, then the CCM should not have the tag set.

@deitch Thanks for the explanation, I just found that as well and updated my PR to reflect the change.

@detiber I get most of it - looks good - except for the core. The existing one depends on reconcileNodes() being called once in a while (e.g. 30 seconds), and then checking the health of the EIP. If it failed, it then went on to check the control plane node IPs and move the EIP around, as needed.
In this proposed one, it appears to change that. It only checks the health in doHealthCheck(), which only is called by UpdateFunc:, and it only checks if the node on which UpdateFunc was called actually currently has the EIP assigned.
How does this regularly check the status of the EIP and update it if necessary? I get that it would work when UpdateFunc is called, but why would it update it with any regularity?

Because the resync interval on the informer is set, every time a resync happens UpdateFunc is called for each of the Nodes, so that keeps us doing a health check at most roughly every minute, which is approximately the same as the old timer loop happening every 60 seconds.

Also, it doesn't look like it checks the EIP address, only the node's?

Yeah, that was the bit that I suspected to get some push back on...  In the case of Cluster API, we are configuring the EIP as a local loopback address: https://github.com/kubernetes-sigs/cluster-api-provider-packet/blob/main/templates/cluster-template.yaml#L30-L36, this was needed to work around how kubeadm expects the address to be resolvable when bootstrapping (since the external service/endpoints would not be configured yet, since CPEM is not yet deployed).
This resulted in issues during upgrade, where the local etcd instance is removed from the cluster prior to the machine being deleted, which would result in the local apiserver being unresponsive. Not necessarily an issue if CPEM is running on the machine being deleted, but becomes an issue when it's one of the control plane nodes that isn't running CPEM that is also currently assigned the EIP. CPEM is attempting to health check the EIP, which resolves to localhost and passes, so doesn't attempt to re-assign the EIP.

Because the resync interval on the informer is set, every time a resync happens UpdateFunc is called for each of the Nodes, so that keeps us doing a health check at most roughly every minute, which is approximately the same as the old timer loop happening every 60 seconds.

Ah, I didn't realize that. So basically every update-interval for resync it automatically will call the health check? Then that makes sense.

Yeah, that was the bit that I suspected to get some push back on... In the case of Cluster API, we are configuring the EIP as a local loopback address: https://github.com/kubernetes-sigs/cluster-api-provider-packet/blob/main/templates/cluster-template.yaml#L30-L36, this was needed to work around how kubeadm expects the address to be resolvable when bootstrapping (since the external service/endpoints would not be configured yet, since CPEM is not yet deployed).

Oh yes, I have suffered through that. I do wish kubeadm was a bit more configurable in that regards.

CPEM is attempting to health check the EIP, which resolves to localhost and passes, so doesn't attempt to re-assign the EIP.

So the reason you did it is so that we won't have a situation where the health check in CPEM thinks everything is healthy - because it is checking the EIP, which is on local loopback, but really it isn't OK when coming from the Internet?

Yeah, that was the bit that I suspected to get some push back on... In the case of Cluster API, we are configuring the EIP as a local loopback address: https://github.com/kubernetes-sigs/cluster-api-provider-packet/blob/main/templates/cluster-template.yaml#L30-L36, this was needed to work around how kubeadm expects the address to be resolvable when bootstrapping (since the external service/endpoints would not be configured yet, since CPEM is not yet deployed).

Oh yes, I have suffered through that. I do wish kubeadm was a bit more configurable in that regards.

CPEM is attempting to health check the EIP, which resolves to localhost and passes, so doesn't attempt to re-assign the EIP.

So the reason you did it is so that we won't have a situation where the health check in CPEM thinks everything is healthy - because it is checking the EIP, which is on local loopback, but really it isn't OK when coming from the Internet?

Exactly

@deitch Do you think it would make sense to make using the EIP URL or not a configurable option?
I'm not sure how others may be using CPEM outside of Cluster API to know if it's a broader issue or just a localized one.

I don't understand.

@deitch rather than just avoiding the use of the EIP automatically (like this PR is doing) for health checks, or would it make sense to make that behavior opt-in, with the default continuing to use the EIP url for health checks?

@deitch rather than just avoiding the use of the EIP automatically (like this PR is doing) for health checks, or would it make sense to make that behavior opt-in, with the default continuing to use the EIP url for health checks?

Now that I get it, yes, I think so. My concern is lack of consistent EIP behaviour by CPEM, but that can be acceptable I think.

Would it make sense to split the conversation? This PR is changing two things simultaneously: how we invoke health checks; what health checks test.
Does this PR have any value doing just the first, and then having a separate one focused just on the second? Or must it go together?

Both are really needed in order to unblock the CAPI v1 support for CAPP, so I'm not sure there is much value in breaking it up.
That said, more than happy to break it up if that is your preference.

This should be ready to go.

Reviewing now. @detiber can you add the new option env var to the README?

I still need to address the README updates, but did quite a bit of cleanup based on the other comments.
Working on validating that the Server Side Apply changes didn't break anything, though 😬

Server side apply changes seem to be working good, will pick back up on the README changes tomorrow.

This all looks solid. Just needs the README updated and that nodeFitler fixed, and we should be good to go.

@deitch README is updated and we are no longer fitlering anything.
I also squashed down the commits and cleaned up the commit message.

@deitch sgtm, I've been testing this code pretty regularly from an EIP perspective with the automated testing I've been doing for CAPP

Really nice on this one, thank you.


Multicast: cannot add membership

what i can do for this KNXUltimate-KNXEngine: Multicast: cannot add membership?

Are you sure you’re using a multicast IP?


add visual-studio-code ignore

Codecov Report

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

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


How to use Ruplacer in another function

I've tried to write an function:
fn run_ruplacer(path, foo, bar) {

}

but can not, is there any one can help me?

I'm not sure I understand your question. Do you want to use ruplacer's functionality from an other Rust program? Or to put it in an other way, do you want to use ruplacer's code as a library?
Ruplacer was not designed to be used as a library, but it should still be possible.
You can take a look at src/main.rs for inspiration.
Basically, you'll have to build a Settings struct, a Query struct and do something like this:
let settings = ruplacer::Settings::default();
let query = ruplacer::query::substring("foo", "bar");
let mut directory_patcher = ruplacer::DirectoryPatcher::new(path, settings);
let outcome = directory_patcher.run(&query);

Note that if you do want to use ruplacer as a library, we could also add more code in src/lib.rs so that it's a bit easier to use and less likely to break. Currently, the code that I showed you might break in the future.

Hi @pin-contract, I have some good news.
I've been working on a better public API. It's still a beta, but I appreciate it if you could take a look.
Here's how to patch source files in a directory:
https://docs.rs/ruplacer/0.6.0-beta1/ruplacer/struct.DirectoryPatcher.html
And you can also replace in arbitrary text:
https://docs.rs/ruplacer/0.6.0-beta1/ruplacer/fn.replace.html

Going to close this. Feel free to open a new issue if the new API does not work for you.
(Version 0.6.0 is out)


Don't try to call __getNativeTag() on styles that are not animated

I pushed similar fix as a part of c9e1d41d7744ef3fa3f9069facad5f164b921ede

Great :+1:


Handler without "OK" severity defined shouldn't handle "OK"/"RESOLVED" events.

I have a handler that has the following setting:
"severities": [
"warning",
"critical",
"unknown"
]
In this case I want to make sure this handler never gets called when the check returns a status of "0". Currently Sensu will call the handler when the event is resolved even though I have not defined OK as a valid severity.

@portertech I'm not sure I follow.  Do metrics checks ever have a "resolve" action?   I'd think they're always "create".  An event having a resolve action appears to be the only thing causing the normal filtering to get skipped (if I'm reading https://github.com/sensu/sensu/blob/81cf45d176c60bd03d09a9a0d677c1a823de42c2/lib/sensu/server/filter.rb#L148 correctly). Could you elaborate more on the metric-data scenario you're talking about?
In any case, the severities array is a per-handler config.  If on a certain handler that I know will never use with metrics checks (which always return 0), shouldn't I be able to filter however I want without duplicating logic in the handler code?  I'd think people are using certain handlers for certain types of checks (e.g. pagerduty for normal checks vs graphite for metrics checks) thus I might want to set the pagerduty handler to not handle OK (less noise) but the graphite one should always handle OK (needs to process all data).
An alternative, though maybe a bit redundant might be to add an "ignore_resolution" handler option for handle_severity to use?


Subtract commuting cost from bank balance

Each month, current commuting cost (cost of commuting from job region to home region) should be subtracted from the household's bank balance.

Need to implement commuting fees, not only times. Costs would be the sum of both, but only fees should be subtracted from bank balance every month.


Say "for M̶250" not "for $M̶250", again

This PR is identical to #2577, which was (accidentally?) reverted by @jahooma in d3483dfba19f601a34bd1cfadfe446e48e529f80.

Oops, yeah my bad, was a merge error.


It is possible to create qualitative evaluations with no relationship types

I created an SR which contained qualitative evaluations, which are passed in as a sequence of CodeContentItems to the qualitative_evaluations parameter of the various SRs. I constructed these CodeContentItems without the relationship_type parameter, and highdicom did not issue any warnings or complaints. However the dciodvfy tool raises an error saying that the RelationshipType is required and therefore the SR objects are invalid.
I am not sure exactly what the right level to solve this issue is.
The simplest way is simply to check the elements of qualitative_evaluations when constructing MeasurementsAndQualitativeEvaluations objects to ensure they have RelationshipTypes. However after thinking about this more I think that this specific issue may be a symptom of a broader problem. Currently the relationship_type is an optional parameter for a ContentItem and all its subclasses (e.g. CodeContentItem, TimeContentItem,NumContentItem, ...). I'm not sure that this is correct. I think it should probably be required.
My reading of table C.17-6 is that RelationshipType is a type 1 (required) attribute within a ContentSequence. I tried making relationship_type a required parameter of ContentItem and all subclasses, and the only tests that failed were tests where these objects were directly constructed without the relationship type parameter by test code. I.e. there is no place in the main codebase where an item is constructed without a relationship type (or at least not one with test coverage I suppose...). I haven't been able to think of a situation where a relationship type wouldn't be needed. The one place I'm unsure about is the very root of the content tree, which doesn't have a relationship to its parent. I'm not sure how to understand the recursive standard docs on this point. But even there it seems like highdicom is currently placing a RelationshipType attribute at the root of the tree anyway
Another option is that maybe the append method of ContentSequence should have a check to ensure that the ContentItem being appended has a RelationshipType.
@hackermd can you help please me understand at what level this issue exists?

Hmm... That's a tricky one!

Currently the relationship_type is an optional parameter for a ContentItem and all its subclasses (e.g. CodeContentItem, TimeContentItem,NumContentItem, ...). I'm not sure that this is correct. I think it should probably be required.

I think the parameter should definitely be optional for the base class, since there are content items that don't have a parent/target item or don't require a relationship type to be specified. I am not sure either what would be correct for the derived classes. Looking through the templates in Part16, I found several content items of value type CONTAINER or NUM that don't require a relationship type. I also found ones of value type CODE that do not seem to require a relationship type (e.g., TID 1200 Row 1). That's why I decided to make the parameter optional for all classes and handle the specification of relationships in the implementation of a Template class. However, I didn't realize that this would become a problem in cases where content items are passed by the caller, as you discovered with qualitative_evaluations.
I would suggest asserting the correct relationship type for a given row in the template class (or even set/overwrite the value as specified by the template?). In hindsight, it may have been better to not set the attribute on instances of ContentItem, but add them in the context of a template, such that a ContentItem instance itself only represents the content without the need to know the document context (i.e., the template row).
@dclunie @fedorov do you have any further insight or suggestion on how to best implement this?

I think your approach of not setting it as an attribute of ContentItem seems right. Maybe it should be a second parameter to the ContentSequence.append() method? If so, we could gradually phase this in, initially overwriting any RelationshipType already present in the ContentItem and retiring the parameter to ContentItem with a deprecation warning until 1.0 and then removing entirely?
For this specific problem, another solution might be creating a specific subclass of CodeContentItem for QualitativeEvaluation, which automatically sets up the RelationshipType correctly and then retiring CodeContentItem as a valid parameter type for the SR templates (again gradually through deprecation warnings).

I think your approach of not setting it as an attribute of ContentItem seems right.

I have previously modeled a ContentItem to represent a row in a SR template and decided to add the RelationshipType attribute upon construction of the item (resulting in high cohesion). However, there are clear advantages to adding the attribute only when adding an item to a ContentSequence, where the relationship is actually established (see C.<IP_ADDRESS> Content Sequence and Relationship Type).
In addition, the attribute is specified as part of a separate macro, i.e., in Document Relationship Macro Attributes rather than in Document Content Macro Attributes.

Maybe it should be a second parameter to the ContentSequence.append() method? If so, we could gradually phase this in, initially overwriting any RelationshipType already present in the ContentItem and retiring the parameter to ContentItem with a deprecation warning until 1.0 and then removing entirely?

That sounds like a good approach. If we do that now, we should probably also change all occurrences in highdicom.sr.templates and highdicom.sr.content (and potentially at other locations where the relationship_type parameter may be used) to facilitate subsequent deprecation and to not provide developers bad examples for copy-paste.
For example:
        name_item = TextContentItem(
            name=CodedConcept(
                value='111001',
                meaning='Algorithm Name',
                scheme_designator='DCM'
            ),
            value=name,
            relationship_type=RelationshipTypeValues.HAS_CONCEPT_MOD
        )
        self.append(name_item)

to
        name_item = TextContentItem(
            name=CodedConcept(
                value='111001',
                meaning='Algorithm Name',
                scheme_designator='DCM'
            ),
            value=name
        )
        self.append(name_item, relationship_type=RelationshipTypeValues.HAS_CONCEPT_MOD)

For this specific problem, another solution might be creating a specific subclass of CodeContentItem for QualitativeEvaluation, which automatically sets up the RelationshipType correctly and then retiring CodeContentItem as a valid parameter type for the SR templates (again gradually through deprecation warnings).

I am not sure whether this would work for all (current and future) templates that may use a "qualitative evaluation", which is a vaguely defined concept. I would prefer your suggestion to transition to specifying the Relationship Type when adding a content item to the ContentSequence where the relationship is established.

Looking through the templates in Part16, I found several content items of value type CONTAINER or NUM that don't require a relationship type. I also found ones of value type CODE that do not seem to require a relationship type (e.g., TID 1200 Row 1). That's why I decided to make the parameter optional for all classes and handle the specification of relationships in the implementation of a Template class.

I did not find where TID 1200 is used, but TID 300 has similar issue. I do not think this implies that the relationship type is not required. What I believe this means is that the relationship is defined in the parent template invoking the current template. As an example, TID 300 is invoked from TID 1501 row 10, and in that invocation the relationship for Row 1 of TID 300 will be CONTAINS.

However the dciodvfy tool raises an error

You should also consider running the SR validator from Pixelmed Toolkit - DicomSRValidator.sh in http://www.dclunie.com/pixelmed/software/index.html, which will validate content at the level of TIDs. dciodvfy does not do that.

I think I still don't understand this SR structure as well as you both do but that from my current understanding that seems like the right approach. As a general point, since we are pre-1.0 and have a small userbase I don't think we should be too scared of making backwards incompatible changes that are well thought-through and handled appropriately (deprecation warnings etc). Better that than be stuck with a sub-optimal design decision forever more

Alright. Let's do it via the phase approach you proposed:

Keep relationship_type as an optional parameter of ContentItem.__init__() (and derived classes) and add deprecation warning that this parameter will be removed in a future version.
Add relationship_typeas a parameter to ContentSequence.append(), making it optional for now and issue a warning that the attribute will be required in a future version if omitted.
Update package to consistently use ContentSequence.append(..., relationship_type=...).

@CPBridge did I get this right?

I dont have suggestions about the API as long as when serialized a value for Relationship Type is always supplied, so that invalid objects are not be created ... see http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.<IP_ADDRESS>.html http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.<IP_ADDRESS>.html
I.e., at some point it needs to be required, not optional.
On April 1, 2021 11:44:22 AM EDT, "Markus D. Herrmann" @.***> wrote:
I think I still don't understand this SR structure as well as you both do but that from my current understanding that seems like the right approach. As a general point, since we are pre-1.0 and have a small userbase I don't think we should be too scared of making backwards incompatible changes that are well thought-through and handled appropriately (deprecation warnings etc). Better that than be stuck with a sub-optimal design decision forever more
Alright. Let's do it via the phase approach you proposed:

Keep relationship_type as an optional parameter of ContentItem.init() (and derived classes) and add deprecation warning that this parameter will be removed in a future version.
Add relationship_typeas a parameter to ContentSequence.append(), making it optional for now and issue a warning that the attribute will be required in a future version if omitted.
Update package to consistently use ContentSequence.append(..., relationship_type=...).

@CPBridge did I get this right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@dclunie thanks for clarification!

Revisiting this stale thread in the hope of resolving soon...
Several weeks ago I spent a while working on implementing the solution proposed above, before getting disillusioned with it and then getting distracted by shinier things. You can see my aborted progress on the refactor_content_sequence_relationships branch if you are curious.
I now believe that the solution proposed above (moving responsibility for establishing relationships from the time of construction of content items to the the point at which the content item is appended to a template), while it sounds like a nice idea in principle, is in fact impractical given the design of the rest of the library. I started down this path by adding a required relationship_type parameter to the append() and extend() methods of the ContentSequence class. This lead to a couple of problematic observations:

Template classes derived from the ContentSequence python class are often added to other content sequences/templates by .extend()ing them, i.e. adding all items in the sequence/template to the other sequence at once. In order the establish the relationship type at this point would require passing the relationship types for the content items in the sequence to the .extend() method, which requires either passing a single relationship type and assuming it applied to all items in the sequence (which is too limiting for some templates) or passing a list of relationship types with one for each content item (which breaks the encapsulation of the template classes in a serious way and leads to a very ugly and confusing interface).

Content items may be added to sequences multiple times, leading to redundant establishment of relationships. This mostly occurs because constructors of templates perform self.append() and self.extend() operations, and then another append/extend operation is used when the template is added to the parent. Arguably it makes no sense to establish the relationship type within the constructor as avoiding this was the original purpose of this entire exercise. However, if relationship_type is a required parameter of append/extent, there is no way to avoid this. On the other hand If relationship_type were not a required parameter of append/extend, there is no way to guarantee that a relationship type is ever established.

For an example of both these problems, consider the ReferencedSegment class, with simplified constructor (I have added comments where the relationship types would need to be specified under the proposal):
class ReferencedSegment(ContentSequence):
    def __init__(
        ...
        source_images: Optional[
            Sequence[SourceImageForSegmentation]
        ] = None,
        source_series: Optional[SourceSeriesForSegmentation] = None
    ) -> None:
        super().__init__()
        segment_item = ImageContentItem(
            ...
            relationship_type=RelationshipTypeValues.CONTAINS
        )
        self.append(segment_item)  # CONTAINS
        if source_images is not None:
            for image in source_images:
                ...
                self.append(image)  # INFERRED_FROM
        elif source_series is not None:
            ...
            self.append(source_series) # INFERRED_FROM)

which is then used in the _ROIMeasurementsAndQualitativeEvaluations constructor, simplified below:
class _ROIMeasurementsAndQualitativeEvaluations(
        MeasurementsAndQualitativeEvaluations):

    def __init__(
        self,
        ...
        referenced_segment: Optional[
            Union[ReferencedSegment, ReferencedSegmentationFrame]
        ] = None,
        ...
    ):
        super().__init__(
        ...
        elif referenced_segment is not None:
            group_item.ContentSequence.extend(referenced_segment)  # what relationship type here?

Notice:

The ReferencedSegments sequence contains content items with different relationship types to the parent (CONTAINS and INFERRED_FROM), that under the proposal would need to be established in the self.append() methods (marked) in the ReferencedSegment constructor.
The relationship types would need to be re-established in the constructor of _ROIMeasurementsAndQualitativeEvaluations, when the entire ReferencedSegment content sequence is .extend()ed onto the _ROIMeasurementsAndQualitativeEvaluations sequence. This would require somehow specifying the three relationship types again, redundantly.

Given this example, you might be tempted to think that the solution is to require a relationship type to be established during a call to .append() and not .extend(). I don't totally rule this out but I think it is not the right solution because it does not seem self-consistent, and gives rise to awkward issues elsewhere.
I therefore believe that we should drop the approach proposed above and focus more narrowly on solving the original issue by:

Deprecating construction of ContentItems with no relationship type, as I believe the consensus reached above is that this is never valid. I have come to the conclusion that establishing the relationship type once here is the only sensible way to guarantee that one is established. Furthermore, after seeing several examples, it has become clear that the relationship_type is unambiguous at the time of construction of the content item in all the examples I have seen so far.
Checking that qualitative evaluations have the correct relationship type (which I believe should be CONTAINS) after they are passed to the MeasurementsAndQualitativeEvaluations constructor and overwriting it with a warning if it is incorrect. Unfortunately this requires the user to manually specify the relationship type, which feels rather low-level. Another alternative is creating a CodeContentItem subclass specifically for QualitativeEvaluation which correctly establishes the relationship type automatically upon construction. I personally lean towards the latter approach, but note that a qualitative evaluation is not a well defined DICOM concept.

Thoughts @hackermd, all?

I like the idea of introducing highdicom.sr.content.QualitativeEvaluation. To me, a "qualitative evaluation" is a content item of value type CODE that represents a categorical feature when compared to a "measurement", which is a content item of value type NUM that represents a discrete or continuous feature.

@CPBridge and I just realized that content items may not specify a relationship type because according to DICOM PS 3.16 6.1.3 Relationship With Source Content Item

Acquisition Context and Protocol Context Templates have no Relationship field


Suggestion: Don't register preCreateChatMessage until "ready" hook has fired

Hi, I'm the author of the Cautious Gamemaster's Pack module.
Currently Simply Portraits registers its preCreateChatMessage hook as soon as the module is loaded.  This means that your hook gets in very early in the call chain of preCreateChatMessage functions.
CGMP's preCreateChatMessage does not get registered until the setup hook has fired.  This means that my preCreateChatMessage function is always called after yours.  This creates a problem, as CGMP may alter the speaker of a message.  Therefore Simply Portraits calculates the speaker's portrait from the old speaker data, i.e. before CGMP has had a chance to alter it.
Therefore, can I request that Simply Portraits does not create its preCreateChatMessage hook until the ready hook has fired?  This will move it down the call chain, and let other modules get in first, and allow them to make changes to the message before you calculate the token image?
E.g...
Hooks.once("ready", () => {
    Hooks.on("preCreateChatMessage", () => {
        // Do stuff
    })
});

You don't have to ask so politely, I'll set my jerk of a module straight presently. Clearly it needs to learn some manners about sharing hooks with others

Thanks!

Any update on this? Thanks.


Not Working on After Effects 13.1.1 ... Need Help...

Hi Futurecom,
When i run the main.jsx in AE 13.1.1 on windows 7 "64bit", it triggered succesfully at initial, but suddenly stops at stroke.js while rendering the morph.json file, when i try to run the file again excluding the stroke.js script, it then showing me error of extra brackets in main.js, so i remove them too. Then it finallly render the JSON file, but nothing showing on any browser. Apology, i know that removing those lines might have bring further issues, but i didnt get the very first error which i face with stroke.js, why it is facing that error , when everything is as it is , as it was pushed by you.  Please can you guide me what shall i keep in mind before exporting the animation. I will be very thankful to you.
More on, great work guys and thanks a ton for sharing such great scripts.
Thanks & regards
Anol

Hi Anol
I pushed a new version, please try again with this one.
Thanks
Luc


README.md: Add bubblewrap

(Is something really parsing this list?)

(Is something really parsing this list?)

Yes, a human called Jonathan :). There is a small amount of backend work that still isn't automated. This will probably require migrating away from GHPRB.
You should be all set up, though you might want to turn on github2fedmsg on the repo to get faster feedback: https://apps.fedoraproject.org/github2fedmsg.


feat: Relation details panel improvements

Overview
This PR implements improvements to the relations list based on the accepted [prd: Relations list improvements]
See #5689 #5447 #5446
https://github.com/HumanSignal/label-studio/assets/87583799/ec5276b1-b940-4d55-ac54-546380a6ef0b
Changes
Relations list ordering

Added ordering options to relations list sidepanel
Ordering by creation time (ascending or descending)
Ordering preference persists between sessions

Relations visibility toggle

Added toggle icon next to "Relations" label
Toggle hides all relations when one or more are visible
Toggle shows all relations when all are hidden
Visibility state persists between sessions

Testing

Added unit tests for ordering and visibility functionality
Updated documentation with usage instructions

PR Requirements

[x] Commit message(s) and PR title follows the format
[x] Tests for the changes have been added/updated
[x] Docs have been added/updated
[x] Best efforts for concise/coherent code

Areas Impacted

[ ] Product design
[ ] Backend (Database)
[ ] Backend (API)
[x] Frontend

Change Details
This is a new feature implementing relations list ordering and visibility toggling based on the provided requirements.
No libraries were added or updated.
This change should have a positive performance impact by allowing users to easily focus on relevant relations.
This change does not impact security.
Alternatives were manually hiding relations and scrolling down which is tedious.
No feature flags were used.
Breaking Change

[ ] Yes, and covered entirely by feature flags
[ ] Yes, and covered partially by feature flags
[x] No
[ ] Not sure

Testing

[ ] e2e
[ ] integration
[x] unit

Affected Domains

Relations Details Panel

Acceptance Criteria

[x] Adds options to order relations list by creation time (ascending and descending)

[x] Persists ordering preference between sessions

[] Unit tests for ordering functionality

[x] Adds a toggle icon next to "Relations" label

[x] Toggle hides all relations when one or more are visible

[x] Toggle shows all relations when all are hidden

[x] Persists visibility state between sessions

[] Unit tests for visibility functionality

Closes #5689 #5447 #5446

Looks good to me from the product side. @hlomzik @jombooth do you mind checking the code?

See #5446 #5447


Chocolatey: Composer has a PHP dependency which is disrupting my workflow

Hello!
I couldn't fit what I wanted to say into the issue template so I hope you will excuse me for not using it.
I am using Laragon on Windows which already comes bundled with PHP. When installing composer, it automatically installs PHP to C:\tools. Alternatively, I can specify an already installed PHP but it must be an .exe file.

This is already not possible with my setup, since I need to switch between different PHP version frequently, depending on which project I am working on and as such, I have created a .bat file, to point to the desired php executable I would like to use (and I set it in my PATH environment variable).
When Composer (or more specifically PHP) is updating, it keeps adding the environment variable to C:\tools, and so when I use the CLI, it's often set to the newest PHP version, instead of the version I want to use.
Extracting 64-bit C:\ProgramData\chocolatey\lib\php\tools\php-8.3.6-nts-Win32-vs16-x64.zip to C:\tools\php83...
C:\tools\php83
PATH environment variable does not have C:\tools\php83 in it. Adding...
Please make sure you have CGI installed in IIS for local hosting
Environment Vars (like PATH) have changed. Close/reopen your shell to
 see the changes (or in powershell/cmd.exe just type `refreshenv`).
 The upgrade of php was successful.
  Software installed to 'C:\tools\php83'

Right now, I always need to remove the PHP executable from my PATH environment variable after every composer/php update.
An ideal solution for me would be any of the following options:

Installing composer without a PHP dependency
Installing composer and being able to add a .bat file as a PHP-executable
Installing composer/php without environment variables being set automatically

Is my setup just weird/wrong or is this an issue with composer or php?
In any case, your advice is very appreciated!
Thank you for your eye balls.

Moved to windows-setup repo, maybe @johnstevenson has a clue. I'd tend towards "your setup is weird" but I am not familiar with Laragon and I haven't been running php outside of WSL in quite a few years now so 🤷🏻

Right now, I always need to remove the PHP executable from my PATH environment variable after every composer/php update.

To update Composer you should use the command composer self-update. Running an update through Chocolately will also install the latest PHP, because the Chocolatey Composer package has a dependency on it.
I suggest that you uninstall the Choclolatey Composer package and do a manual installation, as described in the docs: https://getcomposer.org/doc/00-intro.md#using-the-installer

Thank you both for your valuable feedback!
I think I will try a compromise and pin the composer package (so chocolatey stops updating it) and I will simply use the composer self-update command in the future.


[expat] Build error with VS 17.4.0 --triplet x64-windows

Host Environment

OS: Windows 10
Compiler: VS 17.4.0

To Reproduce
Steps to reproduce the behavior:
cd \vcpkg
git pull
C:\dev\vcpkg>vcpkg install expat --recurse --triplet x64-windows
Failure logs
C:\dev\vcpkg>vcpkg install expat --recurse --triplet x64-windows
Computing installation plan...
warnivvcng: vcpkg appears to be in a Visual Studio prompt targeting x86 but is installing packages for x64-windows. Consider using --triplet x86-windows or --triplet x86-uwp.
The following packages will be built and installed:
expat[core]:x64-windows -> 2.5.0
Detecting compiler hash for triplet x64-windows...
Restored 0 packages from C:\Users\mtahi\AppData\Local\vcpkg\archives in 205.6 us. Use --debug to see more details.
Installing 1/1 expat:x64-windows...
Building expat[core]:x64-windows...
-- Using cached libexpat-libexpat-R_2_5_0.tar.gz.
-- Cleaning sources at C:/dev/vcpkg/buildtrees/expat/src/R_2_5_0-56671c0753.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/dev/vcpkg/downloads/libexpat-libexpat-R_2_5_0.tar.gz
-- Using source at C:/dev/vcpkg/buildtrees/expat/src/R_2_5_0-56671c0753.clean
-- Found external ninja('1.11.0').
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
CMake Error at installed/x64-windows/share/vcpkg-cmake-config/vcpkg_cmake_config_fixup.cmake:36 (message):
'C:/dev/vcpkg/packages/expat_x64-windows/debug/lib/cmake/expat-' does not
exist.
Call Stack (most recent call first):
ports/expat/portfile.cmake:24 (vcpkg_cmake_config_fixup)
scripts/ports.cmake:147 (include)
error: building expat:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest port files with git pull and vcpkg update.
Then check for known issues at:
https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+expat
You can submit a new issue at:
https://github.com/microsoft/vcpkg/issues/new?template=report-package-build-failure.md&title=[expat]+Build+error
Include '[expat] Build error' in your bug report title, the following version information in your bug description, and attach any relevant failure logs from above.
vcpkg-tool version: 2022-05-05-67e17c1782801cf481be9ac0b3765dff3e4bdeb8
vcpkg-scripts version: e79c0d2b5 2022-11-08 (13 hours ago)Add any other context about the problem here, such as what you have already tried to resolve the issue.

It seems that
.\bootstrap-vcpkg.bat
and the installing again works.

I'll close this issue as .\bootstrap-vcpkg.bat fixed it, however, wouldn't it be better that any vcpkg action, such as install, update, upgrade would first bootstrap-vcpkg first, or at least suggest doing that ?


[Feature Request]: Parallel Building

I'd like to request parallel building. For example, using the same flags as cargo build. An example is using cargo deb -j 4 --target=aarch64-unknown-linux-gnu --variant=rasberrypios when there's 2 logical CPUs.

cargo deb just runs cargo build, and Cargo builds in parallel by default, i.e. the default for -j is the number of cores you have. So it should be parallel already. Note that it can be parallelized only on the crate level, so if you're building one crate it will just build that one.


Three portals, not one

"Sign in to LUIS portal" ... only a single link to the portal identified in this doc.
According to Azure Portal LUIS Quickstart, there should be three separate links:

https://www.luis.ai/ - US Portal
https://eu.luis.ai/ - Europe Portal
https://au.luis.ai/ - Australia Portal

Impact:  For example, use the US link currently documented, we cannot see any previously created LUIS European resources listed.
also,
"select your country" - I didn't see any selection option in the LUIS portal

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

ID: b3f39d29-a4cf-3435-5987-ad38c72e932f
Version Independent ID: feefcf7d-cfc1-1490-1f5f-06e6bdfa7ef0
Content: Create a new app - LUIS - Azure Cognitive Services
Content Source: articles/cognitive-services/LUIS/luis-how-to-start-new-app.md
Service: cognitive-services
Sub-service: language-understanding
GitHub Login: @diberry
Microsoft Alias: diberry

@Thanks for your question. We are checking on this and will respond to you soon.

@SiliconOrchid If you see My Apps tab, that means a LUIS resource already exists and you should skip ahead to create new app section. Furthermore, supported regions and endpoint details are provided in this document. However, I agree that it would be helpful to reference it in this document. Will create a PR to update document accordingly. Thanks for your feedback.


Webpack optimization step 1

[x] upgrade webpack to v4
[x] DevTools failed to parse SourceMap: performance-now.js.map (should upgrade less to v3)
[x] add min output files in dist

upgrade guide

Breaking changes:
https://juejin.im/post/5c07c9d3e51d451d97172d91
https://webpack.docschina.org/migrate/4/#import-and-commonjs

#56


Not able to sort or filter oneview_firmware_driver_facts

Scenario/Intent
I'm trying to get the OV firmware bundle facts, filtered by status="OK' and sorted by date in descending order. It doesn't seem to work. The playbook runs but the firmware driver facts displayed in the debug message are not filtered nor sorted. Can you please take a look at my task and see if there is anything that I may have missed?
Environment Details

OneView 5.5
API version 2200
SDK version 6.00

Steps to Reproduce
Here is my task:
oneview_firmware_driver_facts:
  hostname: "{{ov_hostname}}"
  username: "{{ ov_username }}"
  password: "{{ ov_password }}"
  api_version: 2200
  params:
    sort: 'created:descending'
    filter: status='OK'
  delegate_to: localhost

debug: var=firmware_drivers

Expected Result
I'm expecting the debug message to display only the filtered list of firmware bundles and sorted by most recently created first.
Actual Result
The debug message displays all of the firmware bundled. Nothing was filtered and the list was not sorted.

We will take this as an enhancement request and will try to fix ASAP.

The fix will be available in Ansible Collections whenever OneView fixes the issue. Closing it here


[stable/oauth2-proxy] More configurations and fixes

What this PR does / why we need it:
On top of fixing some documentation and naming, this PR adds:

the possibility to configure a Google service account
to specify a ConfigMap for oauth2-proxy configuration (instead of inlining it in the values)
move default configuration from extraArgs to the default configFile

it is unusable as-is if one wants to set the upstream or the domains via the config file because the arguments take over the configuration
:warning:  this maybe is breaking change :warning:

add checksums of the configuration in annotations for automatic reload of the pod when needed

Special notes for your reviewer:
@Miouge1 tell me how the chart version number should be bumped :)
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[ ] Chart Version bumped
[x] Variables are documented in the README.md

@Miouge1 @unguiculus hi, anyway to get some feedback on this? :)

@Miouge1 see my answers to your comment above. I've also added a commit to bump the version to 0.10.0.

Another PR already bumbed the version to 0.10.0, so you need 0.11.0

/ok-to-test

@Miouge1 here it is (and rebased onto master)

I did a test upgrade from current version to this patch, it worked fine. Before merging, I'm considering if this is backwards compatible or not, I see 4 situations:

extraArgs
configFile
Outcome

Default
Default
✅

Custom
Default
✅

Default
Custom
🔴

Custom
Custom
🔴

Is that correct?

I did a test upgrade from current version to this patch, it worked fine. Before merging, I'm considering if this is backwards compatible or not, I see 4 situations:
extraArgs 	configFile 	backwards compatible?
Default 	Default 	white_check_mark
Custom 	Default 	white_check_mark
Default 	Custom 	red_circle
Custom 	Custom 	red_circle
Is that correct?

I think for the second one, it's correct as long as we expect the args to take over the configuration (which is what I have observed).
For the third one, it depends on what was in the config file, but mostly yes, it's not backward compatible. The last one is similar to this one.
So I agree with this table :)

OK, then as per SemVer, I suggest to release this as version 1.0.0.

OK, then as per SemVer, I suggest to release this as version 1.0.0.

An alternative is to consider that versions starting with 0. are non stable and thus can be breaking when you change the second digit: see https://semver.org/#spec-item-4.
In that case, it would be better to keep this in 0.x.x until we are sure we are not going to break more things :)

Either way works for me.

@Miouge1 then let's keep it at 0.11.0 as it is now and merge it if there are no other changes to make :)

Sounds good.
/approved
/lgtm


false positive entry

Hi. In the following DNS list:
https://raw.githubusercontent.com/AdguardTeam/cname-trackers/master/combined_disguised_trackers_justdomains.txt
The domain "services.chipotle.com" is listed. Having that domain blocked breaks the online food ordering functionality of the website.

Please note that this list should not be used as a blocklist if you want to avoid false positives like that.
The purpose of that list is to show which third-parties are disguised as first-parties. It is up to the downstream blocklists to filter out false positives.


Fix: gevent API change

This will fix:
#174
#177

ah damn.. python2.6 ... its support should be dropped ideally IMO.. can that be ?

hi, again ping ? :?

Could you make new release? Thanks! > @iancmcc

Uploaded 0.8.2 to pypi.
On Fri, Apr 26, 2019 at 9:02 AM Mori Atsushi<EMAIL_ADDRESS>wrote:

Could you make new release? Thanks! > @iancmcc
https://github.com/iancmcc
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/iancmcc/ouimeaux/pull/184#issuecomment-487067999, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAOE44WBAFK5RYDHUN35S3PSMDOLANCNFSM4GHABT7Q
.

--
Ian McCracken


Create how-to on shutting down a node

We are overloading the cockroach quit command to double as command reference and broader explanation of the process of shutting down a node. Instead, we should have a distinct page, Stop a node, that explains best practices and exactly what happens during the shut down process, and how to do it.

xref: https://github.com/cockroachdb/cockroach/pull/45149
xref: https://github.com/cockroachdb/cockroach/pull/46396

update on this: the new flag --only-drain to cockroach quit introduced in https://github.com/cockroachdb/cockroach/pull/45149 now reports a progress indicator, which can be used to determine when it's safe to stop the process.

Add links to this article from cockroach-quit.md, planned-maintenance.md.

Also this thread: https://cockroachlabs.slack.com/archives/C01PHNMUFLN/p1635774345034000


drivers/serial: Make serial_test a proper emul

Add emulator functionality to the serial_test driver, so that it can be
used to simulate a device on the other end of the uart.
If you don't set the buffer-size property in the dts node, there should
be effectively no change from the previous behavior.

Somehow I combined the two commits, let me fix that.


Appstudio update test-component-pac-aetr

Pipelines as Code configuration proposal

Pipelines as Code CI/test-component-pac-aetr-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
14 seconds
clone-repository

✅ Succeeded
25 seconds
build-container

✅ Succeeded
9 seconds
deprecated-base-image-check

✅ Succeeded
10 seconds
inspect-image

✅ Succeeded
2 minutes
clair-scan

✅ Succeeded
38 seconds
clamav-scan

✅ Succeeded
9 seconds
sbom-json-check

✅ Succeeded
16 seconds
label-check

✅ Succeeded
16 seconds
optional-label-check

✅ Succeeded
6 seconds
show-summary

Pipelines as Code CI/test-component-pac-aetr-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
14 seconds
clone-repository

✅ Succeeded
25 seconds
build-container

✅ Succeeded
10 seconds
inspect-image

✅ Succeeded
9 seconds
deprecated-base-image-check

✅ Succeeded
2 minutes
clair-scan

✅ Succeeded
38 seconds
clamav-scan

✅ Succeeded
9 seconds
sbom-json-check

✅ Succeeded
16 seconds
optional-label-check

✅ Succeeded
16 seconds
label-check

✅ Succeeded
6 seconds
show-summary

Pipelines as Code CI/test-component-pac-aetr-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
19 seconds
clone-repository

✅ Succeeded
40 seconds
build-container

✅ Succeeded
14 seconds
inspect-image

✅ Succeeded
15 seconds
deprecated-base-image-check

✅ Succeeded
8 seconds
clair-scan

✅ Succeeded
34 seconds
clamav-scan

✅ Succeeded
9 seconds
sbom-json-check

✅ Succeeded
17 seconds
label-check

✅ Succeeded
17 seconds
optional-label-check

✅ Succeeded
6 seconds
show-summary

Pipelines as Code CI/test-component-pac-aetr-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
19 seconds
clone-repository

✅ Succeeded
40 seconds
build-container

✅ Succeeded
15 seconds
deprecated-base-image-check

✅ Succeeded
14 seconds
inspect-image

✅ Succeeded
34 seconds
clamav-scan

✅ Succeeded
8 seconds
clair-scan

✅ Succeeded
9 seconds
sbom-json-check

✅ Succeeded
17 seconds
optional-label-check

✅ Succeeded
17 seconds
label-check

✅ Succeeded
6 seconds
show-summary


[Quesiton] Gh-pages Deployment

I am using the gh-pages method for deployment and I got it to work however it breaks all my CSS. I believe I'm doing something wrong in my code because I've followed the instructions to a tee.
I noticed that when I run:
yarn deploy

I am automatically generated a gh-pages branch with the static assets here. I looked at the html file and my styles.css which I can see has been populated in the branch is not present. So I know why the styles are not being applied I'm just unsure of why the code behind the scenes of the script is not building the styles.css into the main.css. My thought is perhaps it is a file structure issue.
file structure
public/
  favicon.ico
  index.html
  styles.css
src/
  components/
    App.js
    Content.js
    Header.js
    index.js
  index.js
package.json
yarn.lock

I did give import '../public/styles.css'; a try in index.js; but still was unsuccessful in getting the styles to work.
Any help or pointers at all would be greatly appreciated.

Mind blown
I just tried the link again and it works....

Update
I realize now that:
import React from 'react';
import { render } from 'react-dom';
import { App } from './components';
import '../public/styles.css'; // This actually was the fix!
import 'font-awesome/css/font-awesome.css';

render(
  <App />,
  document.getElementById('root')
);

I removed the <link> for styles.css from the html since now the webpack.config for CRA will bundle all the css in one file called main.css. I feel really dumb at the moment. Hopefully this will help someone else out who has epic brain farts like this!

I also suggest moving styles.css from the public folder. Otherwise it's confusing which delivery mechanism you are using (public folder or bundling CSS). Just put it into src folder.
This might be helpful:

Adding a Stylesheet
Alternatively, Adding Assets Outside of Module System

Thanks for the advice @gaearon!


[DEVO-851] set repo from nexus to artifactory

DO NOT MERGE!  Will be merged by automation after validation

:white_check_mark: Build finished in 4m 25s
Build command:
mvn clean verify -B -e -Daudit -amd

:ok_hand: All tests passed!
Tests run: 101, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message


add tls support to rest api

Codecov Report

Merging #155 into dev will decrease coverage by 0.11%.
The diff coverage is 0%.

@@             Coverage Diff              @@
##                dev     #155      +/-   ##
============================================
- Coverage     13.63%   13.52%   -0.12%
- Complexity      146      148       +2
============================================
  Files            98       98
  Lines          2676     2714      +38
  Branches        199      204       +5
============================================
+ Hits            365      367       +2
- Misses         2290     2326      +36
  Partials         21       21

Impacted Files
Coverage Δ
Complexity Δ

...in/java/com/webank/wecross/config/ZonesConfig.java
6.25% <ø> (ø)
2 <0> (ø)
:arrow_down:

...ava/com/webank/wecross/config/WebServerConfig.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...java/com/webank/wecross/p2p/netty/common/Node.java
38.46% <0%> (+3.84%)
5% <0%> (+1%)
:arrow_up:

src/main/java/com/webank/wecross/peer/Peer.java
30.43% <0%> (+4.34%)
2% <0%> (+1%)
:arrow_up:

Continue to review full report at Codecov.

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


Strava API registration

https://www.strava.com/settings/api
My API Application
Details
Category
SocialMotivation
Club
Client ID
101485
Client Secret

Your Access Token

scope: read
expires at: 2023-01-31T23:58:57Z
Your Refresh Token

scope: read
Rate Limits
100 requests every 15 minutes, 1000 daily
API Usage


newPage() requires arguments

newPage() requires argument, though mac's drawbot doesn't. This breaks compatibility of code that can be shared in class for both drawbot app and drawbot-skia. Is it intentional? Can I make a PR?

It's in between intentional and an oversight... (I'm not super happy with the argument-less version, but let's make it compatible.)
A PR would be great! Best with a test case.

Initial newPage() without arguments: 1000 x 1000
Second newPage() without arguments: same as previous page

Thanks.

Well the test fails with pdfs, f.e. arcTo.pdf differ on 4th byte.
expected:b'<</Producer (Skia/PDF m87)>>\n'
output:b'<</Producer (Skia/PDF m86)>>\n'

so just update skia, I guess :)

Yes pip install --upgrade skia-python please :)
I've been meaning to make the tests accept these differences, but didn't manage yet.

Fixed with 0bc14c38e00b61fbb80027ece7220c9a5650b930


[website]: Use Glamor to inject global css

Description

Uses Glamor to inject global CSS rather than css-loader and style-loader
Improvement of "live" code block legibility on small screens

Removes forced line wrapping inside code blocks as this no longer appears to be needed

Motivation and context
We already use Glamor, so there is no need for those other dependencies and extra configuration.
@kylegach - This removes ~112 packages from node_modules including all of those postcssmodules that you were inquiring about.
How to test

View contents of styles in header and note that the global styles are injected
View "live" code blocks in smaller screens and ensure that they don't break layout, content is horizontally scrollable, lines don't wrap, and that they are generally more legible

Types of changes

Other (provide details below)

Refactor of global css loading technique.
Improvement of "live" code block legibility on small screens
Checklist

[x] Renders and functions properly in all supported browsers
[x] Automated tests written and passing
[x] Accessibility and inclusivity considered
[x] Rendering performance (initial load time & 60fps) and perceived performance considered
[x] Documentation created or updated
[x] Tested in sandbox if new component or breaking change

Closing...
Style changes have been extracted and committed to master via 1628da74b3fcb467182c70b1878e8f6dbb8eef2e
It turns out that Glamor's css.insert only works with a single rule, which may have had something to do with why it worked locally and not on netlify.


User package management

Fixes #553

@anatawa12 the key for packages is capitalized Packages in SideBar.tsx, breaking translations.
Please change to packages.

sorry. Thank you for notice that

選択出来る感(項目としての主張?)が若干弱い気がします


Implement using API Gateway V2 (http api)

I'm not currently seeing a way to do the Http api -> SF direct integration using CDK unless I use cfn L1 constructs (https://serverlessland.com/patterns/apigw-sfn-cdk).
The current setup is using Api Gateway REST which is more expensive and slower than http api.

Oooo looks like it exists now<EMAIL_ADDRESS>🙌🏻

These constructs are alpha...closing for now, but might consider the move later.


Better documentation for passing values to Execute in NanAsyncWorker

I'm having a really hard time trying to figure out what the best practices is for passing values between threads when using NanAsyncWorker. It would be great if we could expand the documentation for this a  bit, especially for passing strings and custom structs.
Currently I'm doing this to pass strings but I'm not 100% sure that it's correct. Am I using memory that is deallocated?
class CaptureWindowWorker : public NanAsyncWorker {
public:
  CaptureWindowWorker (v8::Local<v8::Value> bundle, NanCallback *callback)
    : NanAsyncWorker(callback), bundle(bundle) {}
  ~CaptureWindowWorker () {}

  void Execute () {
    NSString *nsBundle = [NSString stringWithUTF8String: *bundle];

    // ...
  }

  void HandleOKCallback () {
    NanScope();

    v8::Local<v8::Value> argv[] = { NanNull(), NanNew(*bundle) };
    callback->Call(2, argv);
  }

private:
  NanUtf8String bundle;
};

NAN_METHOD(capture_window) {
  NanScope();

  NanCallback *cb = new NanCallback(args[1].As<v8::Function>());
  NanAsyncQueueWorker(new CaptureWindowWorker(args[0], cb));

  NanReturnUndefined();
}

Full project here: LinusU/node-capture-window.

What you pasted looks correct. NanAsyncQueueWorker ensures that the provided worker is deleted after it has executed. Essentially it all comes down to subclassing NanAsyncWorker to add on additional data members to access from the Execute method. Strings, structs, whatever are all handled the same way.


Incomplete Translation of 'In Progress' Tag in Arabic Language for My Orders Section

Description:
When switching the language to Arabic in the Enatega Multivendor Rider App, there is an issue with the translation of the 'In Progress' tag in the My Orders section.
Steps to Reproduce:
Open the Enatega Multivendor Rider App.
Navigate to the My Orders section.
Switch the app language to Arabic.
Observe that the 'In Progress' tag is not translated and remains in English.
Expected Behavior:
The 'In Progress' tag should be translated into Arabic when the app language is switched to Arabic in the My Orders section.
Actual Behavior:
The 'In Progress' tag is not translated and remains in English when the app language is switched to Arabic in the My Orders section.

Resolved!

Resolved!

waiting for publish


Migration to VS Code

Hi, as Adobe is about to abandon Brackets, have you considered porting you theme to VS Code? It's by far the best I've ever seen, especially for PHP/JS/CSS/HTML combo! The Monokai Dark Soda available in VS Code Marketplace is not even remotely as good:(

Hey, I'll take a look at it, I'm using vs code aswell but got used to Monokai Pro.

That would be awesome! I'm trying getting used to Monokai Pro as well but your scheme is still a lot easier to read:)

That's (mostly) great news! There are unoubtedly several differences between the editors, however I've alway appreciated the readability of your color sheme in HTML/JS/CSS/PHP. The neon brackets highlight was superb! I always struggle with the VSCode approach to this.

Hey there! Any news on the port of your superb theme?))


Touch pinch zoom doesn't work on Windows touch screens

Subject of the issue
Your live demo doesn't work on all modern touch screen devices. Has this been tested with touch screens powered by Windows 10? I'm willing to bet the same might happen for Dell P2314T touch screens.
 The only demo that touch pinch zoom partially works is the second demo ('Pan only when zoomed area').
Expected behaviour
Touch pinch (two fingers touch screen and move apart / together) should result in the image zoom level being adjusted. In the second Demo, this should happen even if the fingers have stopped touching the screen, perform a pan (touch move), then a second touch pinch to zoom is done.
Actual behaviour
Only the second demo works, and then only zooms for the first touch. After zoom then pan, zooming with touching only pans.

Can confirm.  I am experiencing this same issue.

me2

This issue has been there since Chrome 56 I think as they introduced PointEvent.

Is there a hacky fix to work around that?

I can't zoom using touch pinch on Android 7/Chrome 62 too. I've tested all demos on the website.
Ping @timmywil

See also #360

Can comfirm, am experiencing this on Android 5.0.2 and 8.1.0 - Chrome version 63 0.3239.111


I found a broken link

Page: https://docs.docker.com/install/linux/docker-ce/ubuntu/
Many of the links are missing /ubuntu/:
Upgrade Docker CE
To upgrade Docker CE, first run sudo apt-get update, then follow the installation instructions, choosing (...)
Installation instructions points to https://docs.docker.com/install/linux/docker-ce/#install-docker-ce and it should point to https://docs.docker.com/install/linux/docker-ce/ubuntu/#install-docker-ce

Problem resolved. Closing ticket.


made union of s_primes and concurencyLevels an empty set

removed 197 from s_primes, because 197 already presents in concurrencyLevels and this two sets should not intersect. If this two sets intersects it is possible for SingleWriterDictionary to degrade in performance.

Thanks!


not notEquals - differs from equals?

Hi @mrajess
Very quick question on the (rather nice) deny-ports-nsg policy which I'm adapting for JIT restrictions.
Is there any reason why it uses:
{
  "not": {
    "field": "Microsoft.Network/networkSecurityGroups/securityRules/sourceAddressPrefix",
    "notEquals": "*"
  }
}

on lines 12-17 rather than
{
  "field": "Microsoft.Network/networkSecurityGroups/securityRules/sourceAddressPrefix",
  "equals": "*"
}

I think they're the same but is there a nuance I'm unaware of?
Thanks - Rich

I'm interested in this question as well...it does appear that { not :{ notEquals: * }} is the same as { equals: * }
I imagine the code was at some point originally
{
  "not": {
    "field": "Microsoft.Network/networkSecurityGroups/securityRules/sourceAddressPrefix",
    "equals": "*"
  }
}

Then was changed to current state as a quick fix.

It should be the same.


dalle-3 image generator is broken

Hi there,
not sure you noticed but the API call is broken.
I need to debug it and see what's going on.

I recommend you check out my fork, It started a couple of months ago and I update it regularly, expanded it quite a bunch
https://github.com/FlamingoFiesta/Chatgpt_telegram_bot_with_payment_system


chore(sinsp): add pragma once directive to thread pool headers

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area API-version

/area build

/area CI

/area driver-kmod

/area driver-bpf

/area driver-modern-bpf

/area libscap-engine-bpf

/area libscap-engine-gvisor

/area libscap-engine-kmod

/area libscap-engine-modern-bpf

/area libscap-engine-nodriver

/area libscap-engine-noop

/area libscap-engine-source-plugin

/area libscap-engine-savefile

/area libscap

/area libpman

/area libsinsp

/area tests

/area proposals

Does this PR require a change in the driver versions?

/version driver-API-version-major

/version driver-API-version-minor

/version driver-API-version-patch

/version driver-SCHEMA-version-major

/version driver-SCHEMA-version-minor

/version driver-SCHEMA-version-patch

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: mrgian
Once this PR has been reviewed and has the lgtm label, please assign andreagit97 for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/milestone 0.18.0

LGTM label has been added.  Git tree hash: f2ea11b3177b83b7e56ac59e9af6b5a21335005d

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, mrgian
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

Didn't notice this was a draft :)

It wasn't :)
I took the opportunity to make another change in the same PR and I put it in draft just to let maintainers know to not to merge it yet (since it was already approved).
However, it is ready now!
@FedeDP This should be in milestone 0.18.0 IMO

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, mrgian
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/milestone 0.18.0
I agree!


Ask users to open Android issues in respective forum

LGTM @bmuschko

@jjohannes I went ahead with the merge. Feel free to directly edit the file if you would like to incorporate additional changes.


getting istanbul cover to show 0% coverage for files with no tests

Hi,
I was very reluctant to open this issue -- it's more of a question really -- but I cannot find an answer to it anywhere. And it seems such a basic thing that I'm sure I'm just missing something in here...
If I have a node project with a couple of .js files. And I have created a single test file which tests a couple of functions from one file only.
The test is a jasmine test, inside test directory, which is run by doing jasmine test. I get my 2 tests, 2 assertions, all ok.
Now I want to get coverage data for my code.
I do istanbul cover jasmine-node -- test and I get coverage results only for the .js file I tested, i.e., I'm getting 83% coverage when in fact there's one file in there that's not even being tested.
So, am I doing this wrong or do I have the wrong expectation here?
Is there a way to get istanbul cover to give me results which reflect also the files which weren't tested?
Many thanks,
L.

This one confused me a lot too. It doesn't seem like the coverage report is much use if its leaving out files that are untested. The purpose of the report, at least for my use case, is to see where code is and isn't covered to inform tasks to go and cover a section of code that isn't being covered.
I would expect my instrumented code to include all of the code I want reported, and the report to show me a line item for each instrumented file and their corresponding coverage.
This is a great tool but unfortunately i'll have to find something else because of this issue.

Maybe what you're looking for is the includeUntested option. I set that to true and get a full report for all of my files.

@domrein where did you find the includeUntested option and how are you setting it? I don't see it mentioned anywhere in the documentation

@morficus you can find it in help, istanbul help cover

@morficus @domrein probably used gulp-istanbul. I've seen it there where it does some foo as a workaround to require all source files. I don't think its a standard. I've not tried but maybe: 'include-all-sources': true helps.

Having the same issue include-all-sources': true does not help.
any help !!
my karma.config
`module.exports = function(config) {
config.set({
    basePath: '.',

    frameworks: ['jasmine'],

    files: [
        // paths loaded by Karma
        {pattern: 'node_modules/angular2/bundles/angular2-polyfills.js', included: true, watched: true},
        {pattern: 'node_modules/systemjs/dist/system.src.js', included: true, watched: true},
        {pattern: 'node_modules/rxjs/bundles/Rx.js', included: true, watched: true},
        {pattern: 'node_modules/angular2/bundles/angular2.dev.js', included: true, watched: true},
        {pattern: 'node_modules/angular2/bundles/testing.dev.js', included: true, watched: true},
        {pattern: 'node_modules/angular2/bundles/http.dev.js', included: true, watched: true},
        {pattern: 'karma-test-shim.js', included: true, watched: true},

        // paths loaded via module imports
        {pattern: 'dist/**/*.js', included: true, watched: true},

        // paths to support debugging with source maps in dev tools
        {pattern: 'src/**/*.ts', included: false, watched: false},
        {pattern: 'dist/**/*.js.map', included: false, watched: false}
    ],

    // proxied base paths
    proxies: {
        // required for component assests fetched by Angular's compiler
        '/src/': '/base/src/'
    },

    port: 9876,

    logLevel: config.LOG_INFO,

    colors: true,

    autoWatch: true,

    browsers: ['Chrome'],

    // Karma plugins loaded
    plugins: [
        'karma-jasmine',
        'karma-coverage',
        'karma-chrome-launcher'
    ],

    // Coverage reporter generates the coverage
    reporters: ['progress', 'dots', 'coverage'],

    // Source files that you wanna generate coverage for.
    // Do not include tests or libraries (these files will be instrumented by Istanbul)
    preprocessors: {
        'dist/**/!(*spec).js': ['coverage']
    },

    coverageReporter: {
        reporters:[
            {type: 'json', subdir: '.', file: 'coverage-final.json'}
        ]
    },

    singleRun: true
})

};
`
Does any other coverage reporter works better than istanbul?
It is important for us to get coverage of non tested files.

@shaikhspear16 Don't know what you mean that it doesn't work? What are you trying to achieve?
have you tried the code below?
        coverageReporter: {
            includeAllSources: true,
            reporters:[
                {type: 'json', subdir: '.', file: 'coverage-final.json'}
            ]
        }

I know this thread is old (and closed), but I wanted to add another possible solution for the benefit of people arriving here via google. Using --include-all-sources gave weird coverage stats for the untested files for me and I didn't want to just require all my sources, as that would give false results for the coverage (initialisation code in those modules would make it look like those files were partly covered). My solution does need quite a few steps though:

Write a test that requires all the source files, and run just this test (and record coverage).
Zero out all the coverage values in the resulting file.
Run the real tests and record coverage.
Merge the zero'ed out coverage file with the real coverage file. This gives you a file that contains all your sources, but the untested ones will show up as zero.

You can see this in action here (hacky but working): https://github.com/tstibbs/os-map/blob/50b6ae026a261927d1d9cbd0f4fa88252c6ec014/package.json#L6

where should the --include-all-sources option go at the command line?

@ORESoftware The --include-all-sources option is an option for the command cover. You can see this by typing in istanbul help cover and it will list the options for this command. So you put the option just after you specify cover.
I use mocha, es6 and want to run all coverage inside my /src folder on a windows PC (have to specify full _mocha path or it errors).
Here's what I use:
"test": "babel-node ./node_modules/babel-istanbul/lib/cli.js cover --include-all-sources --root ./src ./node_modules/mocha/bin/_mocha -- --opts ./mocha.opts"

Set up istanbul-instrumenter-loader for use with TypeScript and webpack.

easy way to get 0% coverage.
add following function to core.js in istanbul middleware.
function createNonTestedFilesCoverage(opts){
console.log("opts for testing");
console.log(opts.staticdir);
var allFiles=walkSync(opts.staticdir,[]);
for(var i=0;i<allFiles.length;i++){
var contents = fs.readFileSync(allFiles[i], 'utf8');
var datastr=contents.toString();
var covStubRE = /{."path"."fnMap"."statementMap"."branchMap".*}/g;
var covStubMatch = covStubRE.exec(datastr);
var coverage1 = getCoverageObject();
if (covStubMatch !== null) {
var covStub = JSON.parse(covStubMatch[0]);
console.log(covStub);
var coverage1 = getCoverageObject();
coverage1[covStub.path]=covStub;
}
}
console.log(allFiles.length);
}
call above function in post method in handler.js in istanbul-middleware folder.
and finally provide "staticdir: your path//public-coverage" inside coverage.createHandler function in express file.
run express file and run your test cases and you will get all 0% coverage in your report.

I have taken few changes from gulp-istanbul and solved the above issue by modifying code in istanbul-middleware. Please go through the below link:
http://litutech.blogspot.in/2017/09/adding-0-coverage-in-istanbul-code.html

So does it mean that Istanbul don't work at all with ES Modules that use import instead of require? I have 0% after refactored into ES modules.

I really think the istanbul maintainers should reopen this issue. If I have one file tested with 100% coverage in a project of 10 files, the other 9 files should at least report 0%, giving me a combined 10% total coverage. But instead it gives me 100%.
I realize Istanbul needs the files to actually be imported somewhere to know they exist. So is there some way we could specify the files we'd like coverage for that will be automatically added to the overall coverage number (even if they don't have tests)?
@gotwarlost already made a great suggestion in https://github.com/gotwarlost/istanbul/issues/112#issuecomment-29679800 on how to work around this issue

You could work around this issue by requir-ing all files in your codebase using some generic code in a test case.

It's what I've been doing for my projects. But why couldn't this workaround be implemented into istanbul?


fix: agent tool metadata not updating

This pull request includes several changes to the src/backend/base/langflow directory, focusing on deprecating the agent description feature and updating tool handling. The most important changes include marking the agent description as deprecated, updating tool metadata handling, and importing necessary modules.
Deprecation and updates to agent description:

src/backend/base/langflow/base/agents/agent.py: Marked the agent_description field as deprecated and added a note that it will be removed in future versions.
src/backend/base/langflow/base/agents/agent.py: Updated the to_toolkit method to reflect the deprecation of the agent description feature and added handling for tools_metadata.

Tool handling improvements:

src/backend/base/langflow/components/agents/agent.py: Added a blank line for better readability in the message_response method.
src/backend/base/langflow/custom/custom_component/component.py: Updated imports to include BaseTool and removed unnecessary # noqa: TC001 comment. [1] [2]
src/backend/base/langflow/custom/custom_component/component.py: Modified _process_connection_or_parameters method to include Tool and BaseTool in the type checking for list values.

awaiting fix: https://github.com/langflow-ai/langflow/pull/5248

Closing the PR: Merging the Fix with: https://github.com/langflow-ai/langflow/pull/5248


Allow users to set no height/height in percentage on Stack Panel Control and its children in GUI Editor

Related forum discussion: https://forum.babylonjs.com/t/gui-editor-bug-cannot-enter-percentage-value-with-toolbox-button/33225/7
In code, it's possible to set a Stack Panel container to have no height, which allows it to adapt to its children's height. It is also possible to add children with sizing in percentage. This is not possible in the Editor right now.

https://forum.babylonjs.com/t/allow-users-to-set-no-height-height-in-percentage-on-stack-panel-control-and-its-children-in-gui-editor/52139


Test skip build

[skip build] you monkey

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/6452/
Test FAILed.

closing test PR


[create new rule] gce_instance_service_account / no_default_service_account

@BrunoReboul

[x] create an issue

@MarcFundenberger
[x] create topic branch named rulename
[x] create .rego rule file
[x] create .yaml constraint file
[x] create readme.md
[x] Initiate PR
@BrunoReboul
[ ] review PR, iterate
[ ] create system tests, iterate
[ ] merge to dev

See PR #72


Expand IStoragePool.create to document expected error results

Some errors (e.g. creating already-existing filesystem) are pretty standard and should be explicitly exposed and documented.

We are moving our development planning to JIRA. This issue is now being tracked at https://clusterhq.atlassian.net/browse/FLOC-59. You are welcome to file additional issues in GitHub if that's easier for you.


Cannot create Data Service/ Data Source Project

Description:
The project creation wizard gets completed but the project is not created and no errors displayed.

This is fixed


tests, multus: Add integration test for bridge CNI MAC spoof check

What this PR does / why we need it:
Bridge CNI now supports MAC spoof check feature, which permits outbound
communication only to MAC addresses it knows.
In our context, with this feature enabled - a VM connected to a bridge CNI
can only send data through it - if its MAC address hasn't changed from
its initialization (supplied by the user or by the system).
This PR requires PR kubevirt/kubevirt#6774
Signed-off-by: Orel Misan<EMAIL_ADDRESS>
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
The NetworkAttachmentDefinition used in the test uses 'cnv-bridge'
(deployed by CNAO), since containernetworking plugins haven't yet released the feature.
Release note:

NONE

/cc @EdDev

/retest

Rebased on main and used the change from PR #6797 to replace a struct literal with a function call

/approve


Raise notification in Chrome OS from chrooted environment

There is a script croutonurlhandler for opening URL in Chrome OS and optionally switching to it. It could be great to be able to raise HTML5/Chrome notifications like this. So someone who prefer to work with crouton from crosh/Secure Shell could be notified using the command like notify-send.

FWIW we would basically make a libnotify implementation that would either dispatch to another notify daemon or to the extension, depending on the focus.

is there a how to on how to do this on the wiki? I'd love to be able to have a shell script send a notification

Nope, no wiki yet.

Install the extension target into your chroot, and make sure the crouton extension is installed on Chromium OS (it'll let you know at the end of the terminal output if you don't have the extension installed and will give you a link to download it).
Inside the chroot, make sure the websocket server is running.  If you have some graphical session open, it's running.  Otherwise, you may have to run it manually: croutonwebsocket &.  The extension icon will turn green if it's connected.
Play with the croutonnotify command.  If you run it without parameters, it'll print out help text.

Thanks,
I'll take some time this weekend to play with it, and post a how-to
somewhere.
On Fri, Feb 20, 2015 at 4:35 PM, David Schneider<EMAIL_ADDRESS>wrote:

Nope, no wiki yet.

Install the extension target into your chroot, and make sure the
crouton extension is installed on Chromium OS (it'll let you know at the
end of the terminal output if you don't have the extension installed and
will give you a link to download it).
Inside the chroot, make sure the websocket server is running. If you
have some graphical session open, it's running. Otherwise, you may have to
run it manually: croutonwebsocket &. The extension icon will turn green
if it's connected.
Play with the croutonnotify command. If you run it without parameters,
it'll print out help text.

—
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/581#issuecomment-75339316.

--
ahamblin
Q: Why is this email five sentences or less?
A: http://five.sentenc.es


one tflite model padding layer , the data is error(flatbuffers)

Click to expand!
Issue Type
Bug
Have you reproduced the bug with TF nightly?
Yes
Source
source
Tensorflow Version
2.10 or 2.11
Custom Code
Yes
OS Platform and Distribution
android
Mobile device
android
Python version
3.7
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
No response
GPU model and memory
No response
Current Behaviour?
A bug happened!
I call tflite::FlatBufferModel::BuildFromFile(model_name.c_str());
then on first padding layer I print the pad data (paddings)，and find the data is 0 0 0 0 8 0 8 0 ，
but using netron open it correct data is  [
    [
        0,
        0
    ],
    [
        8,
        8
    ],
    [
        8,
        8
    ],
    [
        0,
        0
    ]
]

Standalone code to reproduce the issue
this pad layer   Connect three outputs later,it is one Transpose and two StridedSlice layers.
I guess it is flatbuffer bug

Relevant log output
No response

@mengran1234,
Thanks for opening the issue. In order to expedite the trouble-shooting process, could you please provide a minimal code snippet you are trying to execute. Thank you!


Refactor platform API call

Description
Refactored platform/api call code to remove unnecessary duplicate and improve error processing. No functional changes should be observed.
Type of Change

[ ] Bug Fix
[ ] New Feature
[ ] Breaking Change
[X] Refactor
[ ] Documentation
[ ] Other (please describe)

Checklist

[X] I have read the contributing guidelines
[ ] Existing issues have been referenced (where applicable)
[X] I have verified this change is not present in other open pull requests
[X] Functionality is documented
[X] All code style checks pass
[ ] New code contribution is covered by automated tests
[X] All new and existing tests pass

Codecov Report

Merging #40 (ad1387a) into main (e2b2fa3) will increase coverage by 1.29%.
The diff coverage is 0.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main      #40      +/-   ##
==========================================
+ Coverage   30.26%   31.56%   +1.29%
==========================================
  Files          23       24       +1
  Lines        3000     2877     -123
==========================================
  Hits          908      908
+ Misses       2023     1900     -123
  Partials       69       69

Impacted Files
Coverage Δ

platform/api/call.go
0.00% <0.00%> (ø)

platform/api/collection.go
0.00% <0.00%> (ø)

platform/api/problem.go
0.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


fixed issue #8432

The remove function now checks that the parent contains this child before attempting to remove.
Please review and accept @Falke-Design

Does this prevent some kind of error? Is there an issue related to this PR that has more information?

Does this prevent some kind of error? Is there an issue related to this PR that has more information?

issue #8432  I mentioned in PR title too

@ShivangMishra when opening a PR try to give it a descriptive title that makes it easy to understand what your change does. This helps us compile a changelog that makes sense to users when we do a release.
Also if there is an existing issue you can use keywords in your description to ensure it is linked properly.

I'm closing this PR as I am not convinced this actually resolves the issue it relates to.


[ERROR] Tx Calibration: MCU error 5 on LimeSDR-Mini

Hello,
on starting a program which is using SoapySDR with a LimeSDR-Mini as the SDR allways a Tx Calibration error is coming.
-------- Error Log
Input
Type: edi
Source: tcp://localhost:9100
Output
SoapySDR
Device:
master_clock_rate: 32768000
Sampling rate: 4.0960 MHz
Soapy:Creating the device with:
RC: Waiting for connection on port 2121
[INFO] Make connection: 'LimeSDR Mini [USB 3.0] 1D4C296EC121C3'
[INFO] Reference clock 40.00 MHz
[INFO] Device name: LimeSDR-Mini
[INFO] Reference: 40 MHz
[INFO] LMS7002M calibration values caching Disable
SoapySDR:Actual master clock rate: 32767.9995 kHz
SoapySDR:Actual TX rate: 4096.0000 ksps.
[INFO] Selected TX path: Band 2
SoapySDR:Actual frequency: 223936.000 kHz.
SoapySDR:Actual TX gain: 40.00
SoapySDR:Actual TX antenna: BAND2
Setting up timestamp decoder with 0 offset
Opening EDI :tcp://localhost:9100
EDI TCP connect to localhost:9100
[ERROR] Tx Calibration: MCU error 5 (Loopback signal weak: not connected/insufficient gain?)
[INFO] Rx calibration finished
-------- End Error Log
The calibration process works without an error in Lime  Suite Gui (Ver. 19.04.0-gabf82140). The Log of Lime Suite Gui as an attachement Please rename the fielextension to bz2. GitHub did not support bz2-extension.
LIMEMiniSDR_LimeSuiteGui_Log.txt.zip
Any ideas ?
Thanks, Martin

I found that in order to avoid this issue, I need to set the gain very high, then activate the streaming, then lower it down to the level I need. This seems to be necessary for TX calibration.

I have the same issue and nothing fixed my issues. Any pointer peeps???


MSI Z87-G43 Gaming - Haswell Mobo without 4G Decoding Entry

System

Motherboard: MSI Z87-G43 Gaming
BIOS Version: AMI BIOS A.7 (Within UEFI firmware it shows Version 10.7)
GPU: MSI Armor RX 580 8GB
[✔] CSM is turned off. Make sure to confirm this in the BIOS and not with GPU-Z or similar since it can be inaccurate
[❓] 4G decoding is enabled. Make sure to confirm this in the BIOS and not with GPU-Z or similar since it can be inaccurate
[✔] UEFIPatch is applied (see Using UEFIPatch for more information). On some motherboards DSDT Patching is also needed. Since this is an MSI board, no DSDT Patching was done
[✔] I have read Common issues (and fixes)

Description
After following the steps up to flashing the BIOS/UEFI firmware, I'm still not able to view the 4G Decod. I tried looking to see if there is any hidden option but all I found was a string. Based on the decoded text, the entry should be right above the PCI subsystem entry "PEG #" which sits above "PCI Latency Timer".

Here's the bin file
97E409E6-4CC1-11D9-81F6-000000000000_Setup_Compressed_body.zip
I'm able to boot into the custom GRUB efi via flash drive, but I don't know the offset related to my mobo.
Also, I'm able to enable up to 1 GB Rebar and my performance in games like Resident Evil 4 (Remake) has better 1% lows (better overall frames).

Lastly, here's a copy of the UEFI firmware modded with the Haswell USB 3 patch and the provided patches.txt
E7816IMS.zip

Duplicate of #14


Corrupt  package.

Package present in repository but gives installation error for yay (AUR-helper).
@AlvinJian
~]$ yay -Ss autobgch
   aur/python-autobgch 0.4-4 (+1 0.00%)
   A simple and automatic wallpaper changer supporting various backends for Linux

~]$ yay -S autobgch
==> Error: Could not find all required packages:
    autobgch (Target)

In AUR, my package is called python-autobgch. I followed their naming convention.


Fix typo in modules-and-packages.md

Just a small typo

bah, I make this mistake all the time...
Thanks for the edit!
Gonna have to update this page a lot, cue mod is starting to land!


Breaking changes in pydantic 2.9 (part 2)

======================================================================
FAIL: test_validate_ecephys_metadata (__main__.TestMetadata.test_validate_ecephys_metadata)
Tests that ecephys validator works as expected
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/dan/proj/aind/aind-data-schema/tests/test_metadata.py", line 189, in test_validate_ecephys_metadata
    self.assertIn(
AssertionError: 'Missing some metadata for Ecephys. Requires subject, procedures, session, rig, and processing.' not found in "1 validation error for Metadata\n  Value error, Expected 21 fields but got 14 for type `NanojectInjection` with value `NanojectInjection(recovery_time=None, recovery_tim...jection_volume_unit=<VolumeUnit.NL: 'nanoliter'>)` - serialized value may not be as expected. [type=value_error, input_value={'name': 'ecephys_655019_..._axes=None, notes=None)}, input_type=dict]\n    For further information visit https://errors.pydantic.dev/2.9/v/value_error"

======================================================================
FAIL: test_validate_smartspim_metadata (__main__.TestMetadata.test_validate_smartspim_metadata)
Tests that smartspim validator works as expected
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/dan/proj/aind/aind-data-schema/tests/test_metadata.py", line 148, in test_validate_smartspim_metadata
    self.assertIn(
AssertionError: 'Missing some metadata for SmartSpim. Requires subject, procedures, acquisition, and instrument.' not found in "1 validation error for Metadata\n  Value error, Expected 21 fields but got 14 for type `NanojectInjection` with value `NanojectInjection(recovery_time=None, recovery_tim...jection_volume_unit=<VolumeUnit.NL: 'nanoliter'>)` - serialized value may not be as expected. [type=value_error, input_value={'name': 'ecephys_655019_...oftware=[], notes=None)}, input_type=dict]\n    For further information visit https://errors.pydantic.dev/2.9/v/value_error"

These remaining issues are due to the use of model_construct() on classes with required fields (that then don't get generated. Something about pydantic 2.9 changed and these are sneaking past our attempt to ignore validation errors. Separating this from the issues Bruno fixed already

A future release may fix this https://github.com/pydantic/pydantic/issues/10344.
If time is short for fixing this may be worth pinning for a couple of weeks.

A future release may fix this pydantic/pydantic#10344.
If time is short for fixing this may be worth pinning for a couple of weeks.

Okay finally had the time to look at what you had posted over there and I finally get the error. Thanks for posting that and getting it fixed (hopefully) upstream.
Another option would be to write a version of model_construct() for ourselves that creates required fields with None. I think it's just a matter of an else in this statement https://github.com/pydantic/pydantic/blob/204e109691c69583e656c6e16a62ad79da2f59b9/pydantic/main.py#L291C1-L291C39 that sets the value to None


Fix the Docker Hub container thingy

Yeah, its been broken since we forked. I don't have a hub account and should probably think about getting one or something.
I want this done before we release the first (real) version... so let's see if we get it done within 5 versions :D

I think we are publishing docker images. What's probably lacking is documenting that + actually tagging releases.

Oh nice! so I'll just need to update the docs to use rpki/stayrtr then. I'm guessing @job set this up or something.

Me and @robert-scheck have access to the Docker Hub account for the rpki org,
We're riding the free tier which permits 3 accounts: 2 humans and 1 robot. The robot is hooked up to this repo.

My two cents
In GoFlow2, was able to use API keys and have the docker build inside Actions
https://github.com/netsampler/goflow2/blob/main/.github/workflows/docker-release.yaml

@lspgn we're using the API keys of a robot user called rpkier

I've performed the Docker Open Source Community Application (which might wipe this limit as well), but we are still under evaluation.
And rpki-client uses also the GitHub Actions, thus I guess the same might work for stayrtr, too.

My two cents
In GoFlow2, was able to use API keys and have the docker build inside Actions
https://github.com/netsampler/goflow2/blob/main/.github/workflows/docker-release.yaml

Nice way of doing the ARM build and doing the releases on tags. Would be good to incorporate this for release tags as well.
(In general I've started to really appreciate GitHub actions)


Warnings as errors only in CI

Let me know if this is controversial, in particular @ryanbrandenburg, but our "warnings as errors" policy really annoys me in the IDE, because it interupts me about inane things when I'm just trying to get my hacky code changes in. I think by coding and debugging, so often don't have fully-formed thoughts, and having unused variables, or uncalled private members, is not uncommon for me.
I do, however, understand the desire for a clean codebase, and I have the same desire, so having this on in CI makes sense. This does mean you could get a local build pass, which fails in CI, so perhaps that will annoy people more than I get annoyed by having to comment out unused locals, I don't know, but I'm open to all feedback.

but our "warnings as errors" policy really annoys me in the IDE, because it interupts me about inane things when I'm just trying to get my hacky code changes in.

Fair.

This does mean you could get a local build pass, which fails in CI

This will be quite annoying for me. Do we think we could get Warnings-as-errors for build.cmd or as a parameter to build.cmd (so finicky people like me can create an alias) but off for the IDE? I pretty much always run build.cmd before I push as a final sanity check, so if that caught any errors that would catch me out I'd be happy.

Do we think we could get Warnings-as-errors for build.cmd

Yep, that makes sense to me, and I have no problem just making it the default without even needing a parameter. Will update.


Improved indentention and some fixes

There are alot of really simple getters and setters, these should be removed at some point. Direct access to class members should be allowed, and this will result in smaller and simpler code. Bjarne Stroustrup agrees with this btw:)
Some cleanup should also be done with respect to model, view, controller as well. Not entirely sure how best to do this yet however. I could try to clean up source.h and source.cc maybe, and we could use this as a base for the rest of the classes. This would include getting rid of the simple getter and setter methods in these classes (source.h).
I will also try to find the reason behind the segmentation fault when you open/close tabs several times.

The segmentation fault when opening/closing tabs several times is now fixed.

Not much left now before one can start develop Juci++ with Juci++! Some more smart indentation and of course search, and we might be there.

I merged this and added some configurations. Background color etc can now be set in config.json. I also moved the Gsv::init to source::view constructor.
I'm having problems with line numbering and indention on current debian stable. Line numbers are not shown and indention works sometimes. In Debian testing there was some support. This needs to be investigated.

What version of gcc do you have in debian stable? One needs g++-4.9 for regex support. One solution is to use boost::regex, but gcc-4.9 should become standard in most distributions soon.
The indentation is more of a temporary solution just to be able to write code in Juci++ without the need of too many key-strokes. It is currently very simple, but works ok in most of the cases. A better solution would perhaps be to search for the first open "{" and perform indentation based on this, and also search for open "(" and "[" (from the cursor to the first open "{") to perform appropriate indentation when functions and the like are on several lines. I can create this module when I got the time. It should not require too much work. However, why line numbers do not work in debian stable I do not know. Older gtk* versions?
Both line numbers and indentation worked in my Debian testing.

I will check versions when I get home. It could be because I installed the sourceview from git instead of aptitude. I will investigate by running a fresh install of Debian on my virtual machine.

I installed a new Debian stable box. It supported the following of the new features

line numbers
highlighting of current line

There was no indention support. I haven't had time to investigate more. I should make a clone of this box and try to run it in testing later.

What is the installed gcc version on debian stable?

https://packages.debian.org/jessie/gcc

Just to be sure, what does this say: "g++ -v"?

I'm not at the same computer right now, but it also got debian stable. I tested support and I got the same result as at home.
gcc version 4.9.2 (Debian 4.9.2-10)

I opened notebook.cc and edited line 274 and tried to write an if-statement. No indention on any use cases.

Ok, I'll install debian stable on a VM and check.

Ok, could you try with this command?
sudo apt-get install libboost-python-dev libboost-filesystem-dev libboost-log-dev libboost-test-dev libboost-thread-dev libboost-system-dev libgtkmm-3.0-dev libgtksourceview2.0-dev libgtksourceviewmm-3.0-dev libpython-dev libclang-dev make cmake

I'm working on a dependency list, so if I missed one please tell me.

Sure thing, after the installation later tonight.

 I also manually installed g++ (doh).
Indentation worked, as far as I tested, on my newly installed debian stable, however. Installed on VirtualBox that is.

Be aware though that latest debian stable (8.1) arrived 9 days ago.