[POC] Annotated meta-data

The purpose of annotated meta-data is to provide better runtime-introspection abilities with less code. Annotations are just properties created with reusable function or functional object.
https://github.com/Innokentiy-Alaytsev/entt/tree/runtime-annotations
I've implemented one of the functions I think is useful. I've renamed the concept from 'decoration' to 'annotation' - I think the new word better represents the purpose. I've only implemented the function for registering meta-data without setter and getter. If you say everything is fine, I'll add implementations for annotated meta-data with setter and getter, annotated meta-type (reflect_annotated), maybe annotated meta-function (func_annotated). Also, I'll try to find a way to minimise the amount of the required code - it's very straight forward, but it may be a support burden.

As a side note, I want to mention here another nice-to-have feature for the properties.
I'm often adding properties as:
data<...>("*"_hs, std::make_pair(property::type, type::foobar));

That is, the pair-like approach is useful but it can be also annoying and pointless sometimes. Especially when you want to set a single property like:
data<...>("*"_hs, property::foobar);

Then probes it for existence. In this case, the value can easily be represented by an invalid meta_any object to maintain the same interface for meta_prop.
In other terms, it would be useful a sort of key-only property model.

I've reworked the meta_factory::data function (without a getter/setter) to work with a mixed list of properties and annotations. Just like before, the annotation is a function returning a property. They are just no longer packed in std::tuple.
To distinguish between properties and annotations new functions are implemented. They are not great, because is_property function fails miserably in case of anything that is not property.
I've reworked static prop variable initialisation inside data() - now it is initialised right away, without first initialising it with a default constructed value. The main reason is that it's simpler to get the type from make_property() function result than deduce it. The make_property() function does approximately the same, as the old code with an additional check for properties and annotations and application of annotations.
Most of the other functions may be reworked in the same way that the data() was. The only difference for some of them is the absence of a name to pass to annotations. I don't think that it is a problem, because annotations on some things make little sense (e.g. constructors and destructors).
Another point: should I generalise the functions to accept not only entt::hashed_string, but any type, as long as it provides value() function, returning ENTT_ENTITY_ID? My first try was a failure because I've made some mistakes, but I think it should be possible.

FYI, I put my functions in front of the old ones to keep (quasi-) lexicographical ordering and for no other reasons. In my world lexicographical is the default ordering.

Thank you very much for your effort!
I'm integrating a new sorting algorithm at the moment, then I'll look into this so as to merge it somehow.
Don't worry for the hashed string, I can easily rework it if all the other parts fit well. :+1:

I'll try to add support for annotations returning multiple properties at once. It should allow creating a kind of concepts, e.g. SerializedData which has properties name, min, max and json_type.
P.S. The code formatting is a bit ruined by me right now. I'll fix it.

I've implemented a bunch of property traits for checking whether a type if property, annotation (a callable returning a property) or annotation builder (a callable returning a tuple of annotations). I've checked them with godbolt so far and it seems to work. Tomorrow I'll add some tests. After this I'll rework my current implementation to use property traits and shall try to introduce support for annotation builders alongside properties and annotations as arguments for entt::meta_factory::data.
The property traits are created to work with entt::hased_string, but I think it should be a bit easier to rework them to work with arbitraty argument list for annotations now when they are in separate file. I'll do it as soon as you say so.

As a side note, I want to mention here another nice-to-have feature for the properties...

I think it should be possible. I guess the argument type for this single property should still satisfy some requirements. But with property traits as long as it is not property, annotation or annotation builder it should be possible to take this single property and build a pair-based property from it to use the existing mechanics or some special kind of meta_prop.

I think it's possible to avoid those traits with a bit of template magic and a couple of overloads put directly within the factory class.
Before to proceed, what about defining exactly the goal without caring for the code?
To sum up and correct me if I'm wrong, please:

Allow setting key-only properties.
Allow to use functions that return a pair as properties (annotations).

Is it?

Allow setting key-only properties.

Apparently, yes.

Allow using functions that return a pair as properties (annotations).

Yes. With the extension for functions returning multiple properties. This should allow creating some kind of premade concepts within the application and further eliminate code duplication.

I think it's possible to avoid those traits with a bit of template magic and a couple of overloads put directly within the factory class.

The good things I see about traits are:

They are reusable. However, I don't know if they are or will be required anywhere else.

I think that code with traits and if constexpr or std::enable_if may be simpler than the one with some other kind of template magic. However, I am likely wrong, since I haven't seen the code for any of those variants.

Anyway, I shall try to implement my idea with traits and if you don't like it I'll humbly ask for points at the solution you'd prefer me to implement.

How should the types for which tuple_size > 2 be processed? Should they be treated as (full) properties, i.e. key-value pair, or as a list of flag properties, i.e. key-only properties? Obviously, get<0> and get<1> work for such types.

The risk of supporting everything is to make it counterintuitive. I'd probably reject them.

Reject like in silently ignore or static_assert?

BTW, what about multi-annotations returning multiple properties? As I mentioned, they are useful for defining concepts. Currently, I expect multi-annotation to return a tuple of properties. As long as only key-value pairs are allowed to define properties everything is fine and dandy: a tuple of pairs is a list of properties, a tuple of not (only) pairs is not a property list meaning that the entity returning it is not a multi-annotation. But with the addition of key-only (flag?) properties, this logic will no longer be correct, because single values are allowed to define a property. A possible workaround is to only allow such property lists to be returned by multi-annotation and not allowed to be passed directly to the meta_factory::data function. This is a bit limiting, but should not be a great problem - any time the user wants to pass a list of properties (i.e. a tuple consisting of both key-value pairs and keys) it is possible to wrap this list into a function with a meaningful name.

I cannot imagine the final API nor a proper use cases to be honest. Can you help me in this sense?

I see it this way:
auto name_annotation(entt::hashed_string const& i_name) {
    return std::make_pair ("name"_hs, std::string{i_name.data()});
}

auto json_serialized_annotation(entt::hashed_string const& i_name) {
    return std::make_tuple(
		name_annotation(i_name), // Name for JSON attribute
		"serialize_json"_hs);   // Flag (value-only) property
}

// Multi-annotation is useful for defining interdependent properties
struct int_value_range_annotation {
	int min = INT_MIN;
	int max = INT_MAX;

	auto operator()(entt::hashed_string const&) {
		return std::make_tuple(
			std::make_pair("min", min),
			std::make_pair("max", max));
	}
};

// Application-specific concept
auto randomized_attribute_buff_annotation (entt::hashed_string const& i_name) {
	return std::tuple_cat (
		json_serialized_annotation(i_name),         // < Reuse annotations
		int_value_range_annotation{10, 30}(i_name), // <-/
		std::make_tuple(                      // Additional properties, not
			std::make_pair("duration"_hs, 5), // defined by other annotations.
			"debuffable"_hs));
}

entt::reflect<blessing>("blessing"_hs)
	.data("health_buff",
		  &randomized_attribute_buff_annotation,           // Use concept
		  std::make_pair("heals_crippled_limbs"_hs, true), // Add k-v property
		  "dispellable"_hs)                                // Add flag property
	.data("speed_buff",
		  &randomized_attribute_buff_annotation,
		  std::make_tuple(  // << static_assert here, because property lists are not allowed in this context
			  std::make_pair("fixes_broken_shoes"_hs, false),
			  "nondispellable"_hs));

I did not implement anything for key-only properties yet. Their detection should be simple: they are not key-value properties and are not property lists. I don't think that tuple-valued key-only properties are useful. If they are needed then their concepts most likely can be named which means they should be named types.

I've managed to implement my idea with annotations, returning multiple properties. For the sake of simplicity, annotations are required to return a tuple of properties, even if there is only one property to return. Without this limitation, it would be impossible to distinguish between key-only properties and key-value properties.
Passing a key-only property will result in static assertion because this feature is not supported yet. There is another static assertion in case something is terribly wrong and the property is neither key-value nor key-only.
Property traits are still there and are used in the implementation. They are greatly simplified by if constexpr and the idea of annotations returning tuples of properties.
What would be the best way of implementing key-only properties? Setting the property key is straight forward, but what about the value?

Updated sketch of API use:
I see it this way:
auto name_annotation(entt::hashed_string const& i_name) {
    return std::make_tuple(
        std::make_pair ("name"_hs, std::string{i_name.data()}));
}

auto json_serialized_annotation(entt::hashed_string const& i_name) {
    return std::make_tuple(
        name_annotation(i_name), // Name for JSON attribute
        "serialize_json"_hs);   // Flag (value-only) property
}

// Multi-annotation is useful for defining interdependent properties
struct int_value_range_annotation {
    int min = INT_MIN;
    int max = INT_MAX;

    auto operator()(entt::hashed_string const&) {
        return std::make_tuple(
            std::make_pair("min", min),
            std::make_pair("max", max));
    }
};

// Application-specific concept
auto randomized_attribute_buff_annotation (entt::hashed_string const& i_name) {
    return std::tuple_cat (
        json_serialized_annotation(i_name),         // < Reuse annotations
        int_value_range_annotation{10, 30}(i_name), // <-/
        std::make_tuple(                      // Additional properties, not
            std::make_pair("duration"_hs, 5), // defined by other annotations.
            "debuffable"_hs));
}

entt::reflect<blessing>("blessing"_hs)
    .data<&blessing::health_buff>("health_buff",
          &randomized_attribute_buff_annotation,           // Use concept
          std::make_pair("heals_crippled_limbs"_hs, true), // Add k-v property
          "dispellable"_hs)                                // Add flag property
    .data<&blessing::speed_buff>("speed_buff",
          &randomized_attribute_buff_annotation,
          std::make_tuple(  // << static_assert here, because property lists are not allowed in this context
              std::make_pair("fixes_broken_shoes"_hs, false),
              "nondispellable"_hs));

static_assert is not implemented yet. Firstly, because I've forgotten about it. Secondly, Because it seems like it should be possible to support this kind of use because with property traits it is possible to distinguish between singular properties and property lists. However, I'm not so sure that it is a good idea: the problem is property lists of two key-only properties, that would be identified as a key-value property. For this reason, I think it will be better to just strictly prohibit passing property lists.

Static assertion on tuples with size other than 2 lives. Just like before all my gibberish about annotations pairs are treated as key-value properties.

Apparently, there is a real use case that could be improved (at least partially) with annotations.

Meanwhile, nested annotations are also possible. In the example above, instead of
auto randomized_attribute_buff_annotation (entt::hashed_string const& i_name) {
    return std::tuple_cat (
        json_serialized_annotation(i_name),
        int_value_range_annotation{10, 30}(i_name),
        std::make_tuple(
            std::make_pair("duration"_hs, 5),
            "debuffable"_hs));
}

it should be possible to do
auto randomized_attribute_buff_annotation (entt::hashed_string const& i_name) {
    return std::tuple_cat (
        &json_serialized_annotation,             // < Pass annotation directly, without invoking it
        int_value_range_annotation{10, 30}, // <-/
        std::make_tuple(
            std::make_pair("duration"_hs, 5),
            "debuffable"_hs));
}

if(auto p = my_type.prop(property::type); p && p.value<type>() == type::foobar) { ... }

I'm not sure about this variant, TBH. The problem I see is that one may want to set hashed_string-based property, like "serialized"_hs it may be a bit inconvenient to query the presence of the arbitrary property. With hashed_string in the example above it would only be possible to have one property of this type which may be a bit restrictive.

if(my_type.prop(property::foobar)) { ... }

This version seems to be better than the previous one. The only thing bothering me is using an invalid meta_any as a value of such property. I understand why this should be this way and even agree with it. It's just my constant fear of someone misusing the thing.

Key-only properties (only for data, as before) live now. They are implemented as having an invalid meta_any now. How do you think, would it be meaningful to have true as a value?

May I ask you to create a branch in your fork where you squash all the changes or a PR here to use as inspiration for this POC? I'll close it when done but this way I can have all the diffs at once without troubles.

@skypjack
I squashed implementation into a single commit, rebased it onto master and placed it in separate branch. Would you like me to create PR for convenience?

That's fine this way. Thank you very much. :+1:

So, the first review of the meta part is over. Let's try to close also this one now.
Right now, these are the types of properties supported:

Key only.
Key/Value.
std::get<1>()-table.

First of all, we could add a fourth option: invocable properties (as in std::is_invocable).
This type of property is invoked and we use the result as an actual property. The result must be one of the options listed above or another invocable properties.
With these bricks available, we can finally introduce composable properties and therefore annotations.
The idea is that of splitting the std::get<1>()-table property in two parts: std::pair based properties and std::tuple. The former is a property, nothing less and nothing more. The latter will be treated as a list of properties. It can contains all the ones above mentioned as well as another tuple if needed. This way, we can compose properties the way we prefer.
What do you think about? Does it sound like a good compromise?
The nice part of it is that it would fit nicely with the current implementation and it will get the job.

🤔

A thought from the top of my head, I didn't try it or something: if the property is invocable (without arguments, I suppose) then it should be possible to take the result and use std::apply() to pass the unpacked result into the props function. Of course, the invocable property should return a list of properties in the form of std::tuple for this to work.
The "not so fun" task is separating flies from cutlets, i.e. std::tuple from std::pair. I had some insane property traits for this to work in the original POC implementation. The problem at that time was that I worked with the idea that a two-element tuple is a property too. If this limitation is relaxed and only pairs can be used to define separate properties then it boils down to a check like std::is_same_v<std::pair<decltype(std::get<0>(property)), decltype(std::get<1>(property))>, property >

if the property is invocable (without arguments, I suppose) then it should be possible to take the result and use std::apply() to pass the unpacked result into the props function.

This is incredibly smart actually.

The "not so fun" task is separating flies from cutlets, i.e. std::tuple from std::pair.

Let me amaze you without using any trait class. :wink:

Have something that kinda works. I'll add tests to see how broken is it in reality.

I've some changes to push. I hope they won't break your stuff.

Don't worry, I'll fix everything. Also, as long as prop and unpack are not drastically changed I've nothing to worry about)

I've looked at what you've done. After I make everything work properly with my version I'll push it the way it is for you to watch and then port it to your version.

Ok, I must leave now. I've just pushed also the support for invocable properties. Afaik all was discusses by this issue is now supported but let me know if I'm missing something. We have annotations and we can compose them, we have key-only properties and also support for tuple. What else?

I'm sorry to say this but there is a bug in the current implementation of the prop. Trying to attach to properties for which both key and value have the same type results in duplicate assertion fail due to both properties using the same local static variables.
There is some failure in the latest wip build, I'll look into it.

Sorry, the failure in the wip build was some error in results interpretation by some of the GitHub internals - everything is fine.

C'mon, GH, show corrent information. The failure is there, I've just looked at the wrong green light.

I see. Apparently clang interprets the code differently from GCC/MSVC.
I thinks it's a bug of the older clang because locally (latest) I've no problems.
Let me know if you find the source of the problem.
Otherwise I'll try to reproduce it later and to write a workaround that works also with clang 6.
Fortunately we are in the wip branch. :wink:

The problem is with Clang only, yes. I'm installig it right now.
The problem with duplicate properties is supposedly everywhere. I've only tested MSVC right now but will also test Clang.

The problem with duplicate properties is supposedly everywhere.

This is trivial though. Don't worry.
The other one seems more annoying.

I've puched my version of property tuples and annotations a.k.a. invocable properties to a new branch. It is not based on your latest commits because you've dtractically changed unpack and implemented essentially the same feature.

At a first glance, in your implementation you've the problem that a callable that returns a tuple that contains a callable doesn't work as expected, because unpack treats the second callable as a property rather than as something to invoke. Am I wrong?

I have the following annotations in tests and they seem to work. Unpack checks if the received object is an std::pair before deciding whether to further it is a key-value property or a list of properties to pass to the props function.
auto nested_annotation() {
    return std::pair{"nested"_hs, 123};
}

auto nesting_annotation() {
    return
        std::tuple{
		    std::pair{"nesting"_hs, true},
			&nested_annotation};
}

I've "fixed" the tests so that they now run properly:

Commented out the test assertions for those properties that are not added as a workaround for the duplicated key-value types pairs problem.

Fixed the lambda-annotation so that it does not require entt::hashed_string any more.

Changed the type of the name property value - using char[] that is the type of the "i" caused error from within meta. It was something about instance being nullptr when it should not.

I have a crazy idea about how to fix the duplicate problem:

Add some kind of parameter pack as a tag to the function that stores the property and the node.

Check if the property and node were initialised by the current invocation. I think it should be possible. If thee were initialised - return.

If the current invocation did not initialise property and node then perform a recursive call to this very function with all the same arguments but with the tag parameter pack expanded by one new value/type.

The idea is to build a list of functions with parameter packs of different length.

The idea is great but doesn't work because things are not exactly constexpr.

I came up with the following horrible solution:
    template<typename Key, typename... Value>
    void unpack(char, Key &&pkey, Value &&... pvalue) {
		gogogo (
			std::make_index_sequence<25>{},
			std::forward<Key>(pkey),
			std::forward<Value>(pvalue)...);
    }

    template<
		typename Key, typename... Value, std::size_t TagHead, std::size_t... TagTail>
    void gogogo(
		std::index_sequence<TagHead, TagTail...>, Key &&pkey, Value &&... pvalue) {
        static auto property{
			std::make_tuple(
				std::forward<Key>(pkey),
				std::forward<Value>(pvalue)...)};
		static bool node_used = false;

        static internal::meta_prop_node node{
            *curr,
            []() -> meta_any {
                return std::get<0>(property);
            },
            []() -> meta_any {
                if constexpr(sizeof...(Value) == 0) {
                    return {};
                } else {
                    return std::get<1>(property);
                }
            }
        };

		if (node_used) {
			gogogo (
			    std::index_sequence<TagTail...>{},
				std::forward<Key>(pkey),
				std::forward<Value>(pvalue)...);
		}
		else {
			ENTT_ASSERT(!duplicate(node.key(), *curr));
			node_used = true;
			*curr = &node;
		}
    }

    template<typename Key, typename... Value>
    void gogogo(
		std::index_sequence<>, Key &&pkey, Value &&... pvalue) {
        static auto property{
			std::make_tuple(
				std::forward<Key>(pkey),
				std::forward<Value>(pvalue)...)};

        static internal::meta_prop_node node{
            *curr,
            []() -> meta_any {
                return std::get<0>(property);
            },
            []() -> meta_any {
                if constexpr(sizeof...(Value) == 0) {
                    return {};
                } else {
                    return std::get<1>(property);
                }
            }
        };

		ENTT_ASSERT(!duplicate(node.key(), *curr));
		*curr = &node;
    }

It has everything we love: needless recursion, code bloat and code duplication.

Ok, so... I like it, uh... Especially the index sequence having length 95, you know... So... What about deleting the branch that contains it? :smile:

Put the jokes aside, to maintain a library like this one we must be able to say - stop.
I wouldn't introduce fancy code that is hard to maintain only to face corner cases that are unlikely to happen in 95% of cases.
So, what are the feature that make the property part richer and without which we cannot live?
The current version on wip (once the couple of smalle issues are solved and it will be in a few hours probably) is really flexible imho and it allows to do property composition, that is a great idea to further reduce the amount of code required to reflect types.

First of all, it's not 95 - just 25)
This code above is nothing more than an attempt (obviously, a failed one) to fix the duplicate bug.
As for the actual implementation in the new-meta-annotations branch - it seems simpler than the one on wip to me. The only problem with it comes from the duplicate bug. However, if functionally they are the same then using the one from the wip is just fine with me.

I'm from mobile at the momyso forgive me if I've not read it right but it seems to me that it doesn't support tuples yet and it suffers from this problem of callable properties that return callable properties, because the detection is too early in the chain and the second callable isn't tested and is used directly as a non-invocable property. Am I wrong?

I'll retest it a bit later - after new failed attempt to fix the duplicate bug. But previous testing showed that it works just fine.

Trying to attach to properties for which both key and value have the same type results in duplicate assertion fail due to both properties using the same local static variables.

Is this true also on wip? I cannot reproduce it. Can you give me a hint in this sense?

 I need this fix to properly test my implementation of annotations and property tuples.
I used the following reflection for test:
        entt::meta<annotated_data_type>()
                .type("annotated_data"_hs)
                .data<&annotated_data_type::i, entt::as_alias_t>("i"_hs)
                    .prop (name_annotation{ std::string{"i"} })
                    .props (
                        int_value_range_annotation{-5, 5},
                        [](){
                            return std::pair{ "from_lambda"_hs, true};
                        },
                        std::pair{"int_prop"_hs, 42},
                        std::pair{"double_prop"_hs, 3.141592653},
                        "key_only"_hs,
                        std::tuple{1,2,3,4})
                    .prop (
                        std::tuple{
                            std::pair{"tup_1"_hs, 1},
                            & nesting_annotation,
                            std::pair{"tup_2"_hs, 2},
                            std::pair{"tup_3"_hs, 3} });

Annotations:

name_annotation - an object of a callable type returning a property (std::pair);
int_value_range_annotation - an object of a callable type returning a list of properties (std::tuple<std::pair>);
a lambda as an annotation;
nesting_annotation - an annotation returning a mixed list of properties and annotations, where one of the returned annotations returns a single property.

Direct use of a list of properties (std::tuple{1,2,3,4}) is present. Another instance of passing a list of properties in the form of a tuple is also present.
All tests are green.

Trying to attach to properties for which both key and value have the same type results in duplicate assertion fail due to both properties using the same local static variables.

Is this true also on wip? I cannot reproduce it. Can you give me a hint in this sense?

Yes, it is on wip. Here's how you can reproduce in:
         entt::meta<properties>()
                 .data<properties::prop_bool>("prop_bool"_hs)
                     .prop(properties::prop_int, 0)
+                    .prop(properties::prop_bool, 0)
                 .data<properties::prop_int>("prop_int"_hs)
                     .prop(std::make_tuple(std::make_pair(properties::prop_bool, true), std::make_pair(properties::prop_int, 0)))

Ok, wip contains a version that shouldn't suffer anymore from this problem. Let me know if I'm wrong.

I think it's done now


Set up continuous integration and add more tests

add Travis CI
add tox
move tests to own directory
migrate to pytest
100% coverage
no lint errors from flake8

@kpfleming can you please set this up on Travis?

@alexchamberlain ready for review


Remove need to call decodeTx in balanceTx

This should reduce balanceTx's dependency on the wallet, and marginally improve performance (judging from a local profile, around 1%, possibly 20% with PParam conversion costs excluded).
Comments
Issue Number
ADP-2978

bors r+


Bug or confusing behavior with Python API getGlobalFunctions

Hi folks,
not sure if this is a user error on my side, but at least I find it confusing. Here's a short snippet running on a disassembled x64 "grep" executable.

print(currentProgram.getFunctionManager().getFunctionAt(address))
print(currentProgram.getFunctionManager().getFunctionAt(address).getParentNamespace())
print(getGlobalFunctions("malloc"))

Prints:

malloc
Global
[]

I would have expected getGlobalFunctions("malloc") to return a Function object for the "malloc" function at the given address. What do you think?

Yes, there looks to be an inconsistency here.  getGlobalFunctions() doesn't find it because that API call sees it as <EXTERNAL> rather than Global.  What are your thoughts @ghidra1?

This method (Listing.getGlobalFunctions) only considers functions contained within the Global namespace.  Unfortunately, external functions are contained within a Library namespace which can complicate the lookup of external functions by name.  I hope this will be improved someday.  You could try the method SymbolTable.getExternalSymbol which will return the first external function with a given name (e.g., program.getSymbolTable().getExternalFunction("malloc")`).

Thank you for the feedback, folks. There are 2 functions/symbols called "malloc", the first being the a small function to set up the external call and one being external symbol.
(1)
                             **************************************************************
                             *                       THUNK FUNCTION                       *
                             **************************************************************
                             thunk void * malloc(size_t __size)
                               Thunked-Function: malloc
             void *            x0:8           <RETURN>
             size_t            x0:8           __size
                             malloc                                          XREF[20]:    0020e374(c), 0020e460(c),
                                                                                0020e68c(c),
        001a08b0 70 37 00 90     adrp       x16,0x88c000
        001a08b4 11 86 46 f9     ldr        x17,[x16, #0xd08]=>->malloc                      = 01588100
        001a08b8 10 22 34 91     add        x16,x16,#0xd08
        001a08bc 20 02 1f d6     br         x17=>malloc                                      void * malloc(size_t __size)
                             -- Flow Override: CALL_RETURN (COMPUTED_CALL_TERMINATOR)

(2)
                             **************************************************************
                             *                       THUNK FUNCTION                       *
                             **************************************************************
                             thunk void * malloc(size_t __size)
                               Thunked-Function: <EXTERNAL>::malloc
             void *            x0:8           <RETURN>
             size_t            x0:8           __size
                             malloc                                          XREF[2]:     malloc:001a08b0(T),
                                                                                malloc:001a08bc(c), 0088cd08(*)
        01588100                 ??         ??
        01588101                 ??         ??
        01588102                 ??         ??
        01588103                 ??         ??
        01588104                 ??         ??
        01588105                 ??         ??
        01588106                 ??         ??
        01588107                 ??         ??

I would have expected the first function to be returned by getGlobalFunctions.
What ultimately worked for me was the following code, inspired by one of the examples shipped with Ghidra:
        symbol = currentProgram.symbolTable.getExternalSymbol(functionName)
        if symbol and symbol.symbolType == SymbolType.FUNCTION:
            addresses = symbol.object.functionThunkAddresses
            if len(addresses) == 1:
                address = addresses[0]

Thunk function generally reside in the symbol table and its index with no name.  They thunk function symbol simply mirrors the name of the function it is thunking.  In this case that is an external function.  Hopefully we can improve upon the lookup of external functions by name.

Closing issue.  Expected behavior.


Add MPR installation instructions

Hi! I've recently added mprocs to the MPR, which is an AUR-like platform for Debian and Ubuntu based systems. It's a platform I've created, but it's seen quite a bit of adoption and growth in popularity, and I think it could be beneficial to potential users of mprocs who are on Debian/Ubuntu systems.
Would there be any interest to get it listed in the README as an installation option?

I've also added mprocs to the Prebuilt-MPR if there's any interest for that - it's like the MPR, but it provides mprocs as a prebuilt package (the MPR serves source packages that are built by the end user).

Nice project! Thanks for adding mprocs. Sure, I'd be happy to have MPR as an option in README.

Thanks! Should I just create a PR for it?

That would be nice.

Alright, sounds great! I won't be home until Friday night but I'll try to get something going then.


Compiling Godot Master "ar.exe" error

Tested versions
Godot master-branch 4.4
System information
Window 7 x64 Bit
Issue description

I Use Mingw64 13.2.0 To Compile Godot I Installed From WinLabs: https://winlibs.com
When Run : scons platform=windows target=template_release arch=x86_64 use_mingw=yes use_llvm=yes
At First Give Me Warning : WARNING: Couldn't parse version of ar.
Then Cruch.

When I Selecte Branch 4.3 And Compile It I Don,t See Previews Errors

Steps to reproduce
A first-level heading
Try Change "ar.exe" Argument
Minimal reproduction project (MRP)
Godot Source Code

See:

https://github.com/godotengine/godot/pull/96407#issuecomment-2380594553

In the meantime you can update mingw as this is seemingly a bug in mingw that has been solved in recent versions


Add v-bind example to components

There's no example of using v-bind for multiple props in the guide, only in the API references. This PR adds a quick example in the Components section.

Thanks! I tweaked it slightly, but I think this is a great place for a comment like this. 🙂 👍


Refactor layer indices and coords

Description
This PR refactors the indices and coordinates on each of the layers to reduce code duplication across layers (by putting common functionality on the base layer) and reducing the use of the layer.viewer property so that it will be easier to remove the viewer property completely from the individual layers in the future. The viewer property is now only used on the BaseLayer.
This PR accomplishes the following

Removes all references to viewer.dims.indices from the individual layers. Instead there is now a layer.indices property on the BaseLayer that gets set in the viewer when the dims change. The layer.ndim property is used to ensure that the right number of dims are being sent to each layer

Consolidates all the transforms relating to the scaling transformations from screen coordinates to image coordinates into a layer.rescale property, a layer.cursor_position, and a layer.coordinates all on the BaseLayer. This reduces duplicate code between the layers and was flagged in #193.

Consolidates the _refresh and update methods onto the BaseLayer as they were almost identical across layers. The critical method that now differs across layers and gets called during that process is set_view_slice. update, refresh, set_view_slice might be able to be consolidated even further amongst themselves? Maybe @kne42 has ideas there.

The PR adds no new functionality. Although it is complete and ready for review now, this PR should probably wait until after #246 is merged. They are mostly independent, but there is one line that will have to change in this PR after that one goes in or visa-versa.

Type of change

[x] Bug-fix (non-breaking change which fixes an issue)

How has this been tested?

[x] run examples

Final checklist:

[x] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works

The checks for this PR are currently failing for the labels-2d.py example, but when I run python examples/labels-2d.py everything looks fine. If I run pytest . and test all the examples locally that specific test also fails. Any idea @kne42  what could cause a difference between the pytest . and the python examples/labels-2d.py?

it fails on shapes_to_labels, not labels-2d, and it does so for both python and pytest on my machine

@jni - i'm about to go through your comments, but just want to be crystal clear on the coordinate spaces as I really have 4 different ones that I can think of.
If I have a 3-D dataset then I have the following 4 coordinates
(x, y) -> (x', y') -> (z, y', x') -> (z, y'', x'')
where (x, y) are integer valued in the space of my screen, (x', y') are floats in the 2D space of the raw data that is visible, (z, y', x') is now a tuple that refers to an actual point in the raw data volume and x'' = int(round(x')), y'' = int(round(y')) are integer valued also in the space of the raw data, now refering to an actual pixel.
In this framing (x, y) = event.pos is not saved on the layer, but is the input to the setter of the cursor_position.  (x', y') = layer.cursor_position, (z, y', x') = layer.coordinates, and (z, y'', x'') doesn't have a name.
The setter of this is used to do the layer.cursor_position is used to do the transformation from (x, y) -> (x', y'), but layer.cursor_position is only used inside layer.coordinates and never used on its own. It strikes me that layer.cursor_position could easily be dropped in favor of just using the setter of coordinates itself. Is it strange that coordinates is not integer valued? Do we then want another property that is the corresponding pixel values integer_coordinates = np.round(coordinates).astype(int), but if so what should it be called.
How do these concepts map onto screen space, canvas (real) space, image (pixel) space that you mentioned above?

Hello @sofroniewn! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file napari/layers/_base_layer/model.py:

Line 129:28: E222 multiple spaces after operator

@jni I have removed the cursor_position property, now there is just the coordinates property. I also now only talk about two different coordinate systems - there is screen coordinates which are (x, y) tuples representing points on my screen (I guess now that I think about it, maybe we should call these canvas, as (0,0) is not the top left of my entire screen, but it is the top left of the vispy canvas, which is the same as the top left of the QtWidget that corresponds to the canvas - I can change this to canvas if you want) - and there are image coordinates, which represent points (not necessarily pixel valued) in the coordinates of the raw data. These can be n-D and are ordered according to our napari ordering conventions.
I've tried to make this more clear / improve the doc strings - let me know if you have further requests for changes

@sofroniewn I don't think we have the same definitions of screen coordinates. =) canvas is right if (0, 0) refers to the top left corner of the vispy canvas. If (0, 1) does not correspond to "1 monitor pixel right of (0, 0) on your screen", then it is not screen coordinates, it is canvas coordinates.
From what I can tell, we are not dealing with screen coordinates at all.
One possible point of confusion is that currently our canvas coordinate spacing is the same as the pixels in the image. But as I recall we had a chat about having the canvas coordinates represent "real" space, in the sense that if the image has metadata specifying a scale, then we draw it taking that scale into account, and canvas coordinates would now be e.g. microns. In the status bar, we probably want to include both pixel and real space coordinates, or have a very easy toggle to switch between them (it is annoying in Fiji that this is not always easy to do).
I'm not super-clear on how transposition fits into this scheme. That can be very confusing, because you don't want to transpose things arbitrarily. I recall a horror story about doctors getting the side of a surgery wrong because of a bug in the volumetric image display software.

Yikes! Yes - we're not dealing with screen coordinates at all. I have now replaced all mentions of screen coordinates with canvas coordinates. In my terminology though the size of a pixel in canvas coordinates is the same as the size of a pixel in screen coordinates though and is fixed, regardless of the zoom on the vispy camera. The transformation to image coordinates then is really about the conversion through the zoom and position of the vispy camera. I havn't made any consideration yet of "real" coordinates like microns as we havn't done anything with any metadata there yet, but I'd suggest that we locate that conversion to a single place, that lives elsewhere on the base layer and is not part of this PR

Hmm, ok, the terminology needs refinement then. Let's add another coordinate space!
Screen > Viewport > Canvas > Array
Viewport is the thing you describe and it is related to screen coordinates only in translation of the origin. (And/or inversion of an axis and/or transposition, not sure?)
Now, from what you're telling me, currently you're assuming Array and Canvas are the same thing and that conversion isn't happening anywhere, right?

Hmm @jni, looking through the vispy scene docs they use a term viewbox but that refers to something not in screen / viewport coordinate as how you use them above. I'm not sure about the term viewport, we just have so many viewer / view etc being used.
I will note though that in the vispy docs they refer to the event.pos on the mouse event property as follows
pos : (int, int)
    The position of the mouse (in screen coordinates).

This is the input to the layer.coordinates setter - but I will note that the (0, 0) is not in the top left of the screen, but the top left of what you call the viewport see the screenshot

We could say in the coordinates of the "Canvas widget" as we do refer the that thing as the canvas on the QtViewer.
You seem to use the word canvas to be after the transformation back to what I call "image", I also find that confusing, but that is the space that the layer.coordinates are in right now. For the "array" there is also a rounding and clipping that occurs in the image / labels layers, and I guess I havn't been giving that thing a special name yet, though it is the coord output of the get_value function
We might need to talk about this on thursday to avoid going around in circles!!

We might need to talk about this on thursday to avoid going around in circles!!

This is a great idea! :joy: A diagram would probably also be super useful — I'll see if I can produce one in time.

For tomorrow:

The main source of confusion, I think, is that there's three coordinate systems that share the same origin. (?):

the event.pos coordinates, which are pixels on the monitor. Depending on the zoom and pan state, event.pos will point to different bits of the data. (Or is this origin at the top left corner of the black rectangle? I can't tell where the mouse cursor is in your screenshot.)
the data pixels. Are these axes transposed with respect to event.pos?
a "real" coordinate space. We haven't yet used this, but we will have to because of e.g. wanting to show registered layers one on top of the other. This means that images will not be just images but images + transforms, and so we cannot always count on the image pixels being aligned with the screen coordinate space.

The transformation between real coordinates and data pixel coordinates remains the same regardless of what we do the view (zoom/pan/rotate, whatever). In most cases, it will be a simple scaling.

@jni here's a screenshot defining things how I see it, and making it clear what's in event.pos

@jni if you can suggest changes to the doc strings based on the figure I posted above I will make them and then this should be ready to merge. Thanks!

So the PR as it is now refers to "canvas coordinates" that are (x, y) tuples relative to the top left pixel of the canvas on the screen in units of the screen. After the transform the PR refers to "image coordinates" which are in the space of the image and have the length as the same number of dimensions as the layer and in the ordering of the layer. They aren't necessarily integer valued or clipped.
I think this is clear for now, and I'm going to ask @kne42 to give it one more look over so we can merge and move on with the refactor. If @jni wants the naming further clarified we can make follow up PRs modifying the doc strings

I have fixed the remaining requests from @kne42 and will merge once the tests pass


[1.12.2] Network Tool GUI does not work

RFTools 7.12
Network tools GUI flashes briefly then disappears when wacked on some energy conduits carrying RF.  If wacked on to the ground or some block, the GUI will appear but no useful information can be seen of course.  Holding the item will show energy network, which I guess is part of the new behavior.

I cannot reproduce this. Are you using sneak-right click to open the GUI?

No, I just hold the tool in my hand then wack the cable.  If the tool is held in the hand, I see an outline of all RF consumers.  Whacking a cable will make the GUI briefly appears then disappears.

What if you use sneak-right click?
That's how you're supposed to open the gui for it

Hm I just did that, sneak-right click.  GUI flashes then disappears.

Same as the block protector issue.  Single player works fine, only happens in multiplayer.

Why did you close this? Is it fixed for you now?

Same comment as #1448

This fixed the problem
https://github.com/SpongePowered/SpongeForge/commit/a684cccd0355d1387a30a7fee08d23fa308273c9


Fix #94 - Replace requests to httpx. Change to_json service to return bytes

Related issue:

#94

Hey @lorddaedra,
Thank you for this pull request.
Out of curiosity, what is value of httpx compared to the current request implementation?

Thank you, that makes sense. Let's go then :)


Removal of redundant code

Two lines in create.sh, lines 23 & 24, are no longer required - please remove.

These lines are upon investigation still required - closing issue


Can't be installed on this machine

I tried downloading the plugin, however I got the above message and another message saying that it is not a valid custom action. Is this plugin compatible with Macs? I'm thinking that could be the issue

It says it's a Windows commandline plugin so definitely not going to work on Mac 😅

@aczekajski is correct, this plugin is Windows only.


bundle always has inline source maps even if inlineSources and inlineSourceMap are false

import { bundle } from<EMAIL_ADDRESS>const result = await bundle("./src/worker.ts", {
	compilerOptions: {
		inlineSourceMap: false,
		inlineSources: false,
		sourceMap: true
	}
})

console.log(result.code)
console.log("SOURCE MAP")
console.log(result.map)

Always generates a base64 sourcemap inline URL and the map property is undefined. I've tried all sorts of combinations of these settings with the same result.

Should be fixed with https://github.com/denoland/deno_emit/pull/63


Fix how we detect that the user has denied a transaction

@turbocrime it looks like the error we get when the user denies a transaction is now just a string, rather than an instance of ConnectError. Is that intentional? (If not, we probably shouldn't merge this PR.)

Superseded by #742


Urgent: Change Material to Use - Dropdown into Textbox with label - PTC user

Change Material to Use - Dropdown into Textbox with label - PTC user

text area is functional in update reservation PTC user..


Paha ipinfo helper context

Background
Knowledge of the delay in log parsing for critical events such as logins is helpful for rapidly reconstructing events. Some log sources, such as Gsuite, can have very long delays (several hours).
Knowledge of a user's login history can help a human user determine whether the new location is truly anomalous, or merely the result of random fluctuations in a user's IP address on the public internet (and it's corresponding geolocation). Until there is a general-purpose improbable geolocation rule, the history information helps a human make that determination.
Changes

Added a parsing delay statement to the alert title
Added the alert_context function

Testing

Live system

Have another thought, though this would require another burn-in: adding the ip address to the tuple in the kv-table. It seems ipinfo.io has some inaccuracies, but they often quickly update their database. It would help to understand whether or not a single IP address, or something within a /24 - /22, originally returned one geo, but later returned a different one. This could help with mobile IP exit nodes, for example.


Proxy container lose its config when oom killed inside the kong pod with an ingress controller setup

Summary

Kong version 2.4.1
Ingress Controller 1.3.1

As the proxy container could have limits (ram), it could be oom killed by kubernetes. When this occurs, only the proxy container is restarted inside the kong pod (as expected), and ingress controller is still alive. At this state, the proxy lose its configuration but accept the traffic. (at least with default readiness configuration in values.yaml from helm charts)
If the entire pod is deleted and recreated, everything works fine, the ingress controller POST the ingress configuration to the proxy.
We encounter the issue when we defined default "proposed" limits from the helm charts (256Mi), and this is very low according to the sizing guide, a small load test revealed the behaviour.
Of course, we resized this, but it could still happen if we define a memory limit.
Not sure if it's proxy or ingress controller role to ensure this when proxy container is restarted but it seems while debugging that it could be improved in this kind of setup.
Thx for your help
Steps To Reproduce
It's easy to reproduce as killing the proxy container intentionnaly
1.Deploy kong proxy with ingress controller with at least one ingress with the kong class
2.Kill the proxy container of at least 1 pod, if you have N replicas of kong, you should see the config lost by alternance due to load balancing on kong proxy kubectl exec <kong-pod> -c proxy -n <namespace> -- killall nginx
Additional Details & Logs

Kubernetes 1.19.3

Setup is simple : ingress controller + proxy in kubernetes native mode (dbless), 1 ingress for 1 route, no plugins or advanced configurations.
status is enabled with liveness/readiness configured like the example : https://github.com/Kong/charts/blob/main/charts/kong/values.yaml

I think dbless nodes do keep the previous config they received, but I am not sure why it fails in this case.

after reproducing the steps, you should be able to see like this :
* targeted pod below is pod where you killed the proxy container to reproduce the behaviour

at least 1 restart count on the proxy container  kubectl describe <kong-pod> -n <namespace>
port-forwarding on the pod  kubectl port-forward <kong-pod> -n <namespace> 8444:8444
curl -ks https://localhost:8444/config | jq .

and so, after this occurs, proxy "config" is empty while we expect to see ingress configuration "posted" by the ingress controller
it's coherent in the sense that the container is ephemeral and so, the config of the proxy disappears, but maybe a mechanism could allow to avoid that by making sure that the proxy container is able to recover its configuration that the ingress controller has provided it or should not go in traffic in this state.
by example, in this state of the proxy, if you edit the concerned ingress kubernetes object and make a change kubectl edit ing <ingress> , everything come back to normal, ingress controller see the ingress change, and push it to the proxy

I think dbless nodes do keep the previous config they received, but I am not sure why it fails in this case.

Through what mechanism? AFAIK we don't store it anywhere on disk, so if PID 1 goes all its memory goes along with it.
In hybrid mode DP nodes do store a config.cache.json.gz under KONG_PREFIX, and I believe they load this at start while awaiting their first CP contact. Standalone DB-less nodes don't have the same, however. If we could enable the same cache mechanism for them, it should solve this issue, as the temporary volume we use to hold KONG_PREFIX is bound to the Pod, not the containers: if a container does restart, its replacement will see files its predecessor left behind, and would be able to load the previous cached config.
Adding a more meangingful readiness endpoint (i.e. some endpoint to indicate if an instance has successfully loaded configuration for DB-less) to the status listen could also help here, though it'd be less useful. Kubernetes would take some time to recognize this state and the instance wouldn't recover on its own, so that's probably only of interest as an add-on to loading from disk cache, to disable instances that, for whatever reason, cannot load config cache.

This bug report was very useful for us and we have what seems to be the same issue. This issue is extremely problematic as it means that once in a while our applications with a Kong Ingress controller in front "suddenly" stops working - and we have to restart the Kong Ingress controller manually.
I believe that detecting this problem in a health check can be a correct first approach. It is a valid (and wanted) design to not accept traffic to pods that doesn't work (readiness) and kill them if they don't recover (liveness).
I'd say that finding a way to solve this problem ought to get priority as the Kong Ingress Controller (helm chart) isn't really production ready until this problem has been solved.

It looks like it is an option to use the reverse sync flag to make sure the Kong config is updated after a Kong restart. I assume the challenge with this workaround is that the config will be pushed frequently also when there is no need to do so. Taking a performance hit might still be better than running the proxy with a broken/missing configuration.

	// disable optimization if reverse sync is enabled
	if !reverseSync {
		// use the previous SHA to determine whether or not to perform an update
		if equalSHA(oldSHA, newSHA) {
			if !hasSHAUpdateAlreadyBeenReported(newSHA) {
				log.Debugf("sha %s has been reported", hex.EncodeToString(newSHA))
			}
			log.Debug("no configuration change, skipping sync to kong")
			return oldSHA, nil
		}
	}

I didn't see this one until now. This issue was also reported as a problem https://github.com/Kong/kubernetes-ingress-controller/issues/861 in September 2020.
The suggested solution is to set CONTROLLER_ENABLE_REVERSE_SYNC to true (as we've done). But I also see that this generates some error logs that I don't like. It has still bee working for us, so might be those errors can be ignored.
What we get is:

2022/03/30 16:50:25 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/counter.lua:33: 4096 lua_max_running_timers are not enough
2022/03/30 16:50:26 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/counter.lua:33: 4096 lua_max_running_timers are not enough
2022/03/30 16:50:27 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/counter.lua:33: 4096 lua_max_running_timers are not enough
<IP_ADDRESS> - - [30/Mar/2022:16:50:27 +0000] "POST /config?check_hash=1 HTTP/1.1" 429 54 "-" "Go-http-client/1.1"
2022/03/30 16:50:28 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/counter.lua:33: 4096 lua_max_running_timers are not enough
2022/03/30 16:50:29 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/counter.lua:33: 4096 lua_max_running_timers are not enough
2022/03/30 16:50:30 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/timer.lua:59: 4096 lua_max_running_timers are not enough
2022/03/30 16:50:30 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/timer.lua:59: 4096 lua_max_running_timers are not enough
2022/03/30 16:50:30 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/timer.lua:59: 4096 lua_max_running_timers are not enough
2022/03/30 16:50:30 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/timer.lua:59: 4096 lua_max_running_timers are not enough
2022/03/30 16:50:30 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/timer.lua:59: 4096 lua_max_running_timers are not enough
2022/03/30 16:50:30 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/timer.lua:59: 4096 lua_max_running_timers are not enough
2022/03/30 16:50:30 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/timer.lua:59: 4096 lua_max_running_timers are not enough
2022/03/30 16:50:30 [alert] 1117#0: lua failed to run timer with function defined at @/usr/local/share/lua/5.1/resty/timer.lua:59: 4096 lua_max_running_timers are not enough

It seems this problem has been solved by the latest Kong Ingress Controller release, ref. https://github.com/Kong/kubernetes-ingress-controller/blob/main/CHANGELOG.md#230. I've applied and slightly tested the updated Kong Ingress Controller in one cluster, and it seems the problem has been solved.
There is a problem with a livenessprobe with the new Helm chart, but that problem is luckily easy to work around - https://github.com/Kong/kubernetes-ingress-controller/issues/2435.


chore: use Ecto.Type.type to determine db type

Context
ecto release v1.12.1 introduced a change to the way mappings were return for Ecto.Enum.mappings/2.
We were relying on this mapping to convert Ecto.Enum to :string when creating the database columns.
See https://github.com/elixir-ecto/ecto/commit/21c6068c9c829df13f4cb577cbd53263b4950262#diff-025069044568b480ef6f86f025cb46a7064695e6df1e7008ede689e09a9c7836L317-R318
Decision
To make this more future proof, use Ecto.Type.type/1 to handle schema type to database type conversions.

chore: fix single-quoted warning
Context
warning: single-quoted strings represent charlists. Use ~c"" if you indeed want a charlist or use "" instead
     │
 256 │   defp insert_all_value(_), do: '?'
     │                                 ~
     │
     └─ lib/snowflex/ecto/connection.ex:256:33

     warning: single-quoted strings represent charlists. Use ~c"" if you indeed want a charlist or use "" instead
     │
 601 │     '?'
     │     ~
     │
     └─ lib/snowflex/ecto/connection.ex:601:5

Very nice! I like it.
I wasn't sure if we would want a version bump in the mix.exs but it looks like Ecto.Type.type has been in since at least 3.0.0.


[BUG] Loosing connection with ATEM TVS HD after running >1h

We have an issue with Companion loosing connection with our ATEM TVS HD after running for a while, typically ~1,5h. We are currently on build 3645 (i.e. not yet on latest bleeding edge build but will update as soon as possible).
Everything looks OK in the GUI when this happens and I can't  see any issues in the logs. The quick fix is to disable and enable the ATEM instance that gets everything up and running again. Normally, we only have Companion, an Arduino with Tally SW and a PC or a MAC running ATEM SW Control with connections to the ATEM TVS HD. We have been running the same setup for over a year and this issue seems to have starting to show up since the upgrade to build 3645. The last build we used before that was 3575.

In today's ~3h session, we lost ability to communicate with the ATEM TVS HD twice. Both times it was solved by doing disable/enable of the ATEM instance (through a separate stream deck button). The issue seems to be triggered by doing some ATEM actions in ATEM SW Control on a Mac which gives me some hope to try to find a specific sequence that triggers the issue. BTW, Companion is not running on the Mac but on a separate PC.

I don't know if it will help but I have had this sequence happen twice to me in the last couple months due to a loos AC power cord. For obvious reasons I don't want to experiment to try to verify the experience. Maybe this can help you investigate:
a. Power is very quicky lost and restored to the ATEM TVS HD
b. RPi can (maybe?) still communicate with the ATEM, but the ATEM software does not
c. Intentionally reboot the ATEM
d. RPi cannot communicate with the ATEM, ATEM software is fine
e. Repeat c-d numerous times, no change
f. Reboot RPi, no change
g.

This issue may be related: https://github.com/bitfocus/companion-module-ptzoptics-visca/issues/20

Any update on this issue?  Running the latest stable 2.4.1 and losing connection to the ATEM TV STUDIO HD every so often.   Disable and reenable doesnt fix.  Have to disconnect ethernet and reconnect.

I am hoping this is no longer an issue


scripts: elf_helper: Remove undefined var ref. in ArrayType.repr()

self.num_members doesn't exist. This commit just removes the reference,
because I didn't want to guess a proper fix.
zephyrproject-rtos/ci-tools#37 (just to link)

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@f4631d5). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master   #14761   +/-   ##
=========================================
  Coverage          ?    52.5%
=========================================
  Files             ?      309
  Lines             ?    45047
  Branches          ?    10418
=========================================
  Hits              ?    23654
  Misses            ?    16586
  Partials          ?     4807

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 f4631d5...18761b6. Read the comment docs.


CHORE: Address fast-xml-parser vulnerability

@williamfalconeruk no, typically npm package vulnerabilities are fixed by pinning a more recent version in the lock file -- they're often indirect dependencies so this is sufficient.

Closed in favour of Dependabot PR #794


kubectl get -w has no output

Expected Behavior
Please describe the behavior you are expecting
Current Behavior
$ kubecolor get po -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP              NODE    NOMINATED NODE   READINESS GATES
web-0   1/1     Running   0          3h    <IP_ADDRESS>   node1   <none>           <none>
web-1   1/1     Running   0          61m   <IP_ADDRESS>   node1   <none>           <none>
web-2   1/1     Running   0          3h    <IP_ADDRESS>   node1   <none>           <none>

$ kubecolor get po -o wide -w
^C

Introduced in #29.
Context
Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.

Operating System:
kubectl version:
kubecolor version:

Hello 张祖建! Thanks for the great issue.
Will work on a fix as soon as I am back from vacation.


There is an issue with the cache-manager option is expected to be an object, but the type hint in the library indicates it should be a number.

Describe the bug
There is an issue with the cache-manager option is expected to be an object, but the type hint in the library indicates it should be a number.
How To Reproduce (best to provide workable code or tests!)
Please provide code or unit test example that will reproduce the error. If you can't provide code, please provide a detailed description of how to reproduce the error.

Use the cache-manager library in a TypeScript project
Attempt to set a cache value with a ttl option as an object.
Observe the type error that occurs.

Example:

**Additional Information

"cache-manager": "^5.3.2"
"cache-manager-redis-store": "^2.0.0"
"@nestjs/cache-manager": "^2.1.1"
"@types/cache-manager-redis-store": "^2.0.4"

Thanks for sending this in and in typescript there is an issue as we force a custom type on the ttl. One thing you can do is use the export type Milliseconds = number; reference if you want to cast it and that should fix the issue. In future releases we are planning to make this simpler on the casting so a number should flow through. It should most of the time but sometimes has issues.


Upgrade wakeonlan to 1.1.6

Description:
Changelog: https://github.com/remcohaszing/pywakeonlan/releases
Example entry for configuration.yaml (if applicable):
wake_on_lan:

Service data:
{
   "mac":"00:30:18:cf:0f:80"
}

2018-09-09 10:12:11 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=wake_on_lan, service=send_magic_packet, service_data=mac=00:30:18:cf:0f:80>
2018-09-09 10:12:11 INFO (MainThread) [homeassistant.components.wake_on_lan] Send magic packet to mac 00:30:18:cf:0f:80 (broadcast: None)
2018-09-09 10:12:11 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_executed[L]>

Traffic dump:

Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass

If the code communicates with devices, web services, or third-party tools:

[x] New dependencies have been added to the REQUIREMENTS variable ([example][ex-requir]).
[x] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.

Need a rebase


Legal: Add CLA

As discussed in the Discord server, it should be good to add a CLA to make sure permission is granted by the package authors to distribute their work under the dirigenants name and copyright, with the MIT licence.
Accompanies https://github.com/dirigeants/klasa-pieces/pull/121

There is an explicit CLA given by Github TOS that all contributions to a repository are licensed under the same license of which the repository is licensed for, unless there is an agreement that supersedes it.

closing as resolved


[youtube] Support for timestamp bookmarks

Checklist

[x] I'm reporting a site feature request
[x] I've verified that I'm running youtube-dl version 2020.03.24
[x] I've searched the bugtracker for similar site feature requests including closed ones

Description

YouTube added last year a new functionality where if the description contains a list of timestamps, these are represented in the progress bar, as if it were a playlist within the video: https://www.coywolf.news/seo/google-video-segments/
Sample video: https://www.youtube.com/watch?v=RLWcYADoV84
Whereas it is possible to download the full video, the bookmarks information is lost. It would be great to have the possibility to download the segments as separate files as if it were downloading a playlist of separate files, maybe appending to the destination file name the description in the bookmark.
This may depend on https://github.com/ytdl-org/youtube-dl/issues/622

--add-metadata.

That's very interesting, thanks! It doesn't split the video, but in VLC I can see the bookmarks and descriptions.
I guess if anyone is interested in splitting the segments into separate files they could do it with some postprocessing using ffmpeg.


Upgrade videojs to latest version

There's a few breaking changes and new issues to work through

The chromecast and the airplay plugins now both have an open PR to replace the expired extend function. Let's revisit this next week.


Update kubernetes to v1.9.0.

Update kubernetes to v1.9.0.
Signed-off-by: Lantao Liu<EMAIL_ADDRESS>

Apply LGTM based on https://github.com/kubernetes-incubator/cri-containerd/pull/508#pullrequestreview-83956724


[API] Series banners fail to load since 2.3.17

Series banners fail to load on the WebUI since version 2.3.17
HTML code for flexget-2.3.16:

HTML code for flexget-2.3.17 up to  flexget-2.3.28:

The error for this URL is:
{
    "code": 500,
    "message": "Error: 13"
}

Update: It can be reproduce from the API test/doc page : http://flexget:5050/api/
Additional information:

Flexget Version: Started in flexget-2.3.17

Hmm that's an OS error, should be returned better though. Git logs or crash
logs?
On Sat, Sep 17, 2016, 10:19 Mirgolth<EMAIL_ADDRESS>wrote:

Series banners fail to load on the WebUI since version 2.3.17
HTML code for flexget-2.3.16:

HTML code for flexget-2.3.17 up to flexget-2.3.28:

The error for this URL is:
{
"code": 500,
"message": "Error: 13"
}
Additional information:

Flexget Version: Started in flexget-2.3.17

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Flexget/Flexget/issues/1410, or mute the thread
https://github.com/notifications/unsubscribe-auth/AELANe072Vg6-_CxJX3ElNwa0xn1cOiZks5qq5RjgaJpZM4J_iDq
.

logs:
2016-09-17 09:28 ERROR    flexget.api                   Exception on /cached/ [GET]
Traceback (most recent call last):
  File "/usr/local/flexget/env/lib/python2.7/site-packages/flask/app.py", line 1639, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/flexget/env/lib/python2.7/site-packages/flask/app.py", line 1625, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/local/flexget/env/lib/python2.7/site-packages/flask_restful/__init__.py", line 477, in wrapper
    resp = resource(*args, **kwargs)
  File "/usr/local/flexget/env/lib/python2.7/site-packages/flask/views.py", line 84, in view
    return self.dispatch_request(*args, **kwargs)
  File "/usr/local/flexget/env/lib/python2.7/site-packages/flask_restplus/resource.py", line 42, in dispatch_request
    resp = meth(*args, **kwargs)
  File "/usr/local/flexget/env/lib/python2.7/site-packages/flexget/utils/database.py", line 34, in wrapper
    return func(*args, **kwargs)
  File<EMAIL_ADDRESS>line 33, in get
    raise ApiError('Error: {}'.format(e.args[0]))
ApiError

Ok, the issue is that you have no permission to write to the default cache dir. I'll improve the error handling and add fallback logic for these errors.
In the meanwhile, the cache dir name is cached_resources under your flexget execution path.

I reset the flexget:users ownership to all files and restart but the dir is still not created automatically.
I tried to manually create a  cached_resources dir both under /usr/local/flexget/ and /usr/local/flexget/env/bin/ but error persists.
Any clue ?

Not really, I'll add more informative logs to this soon

After next release, please try again. API responses should be more helpful.

{
    "code": 500,
    "message": "Error: [Errno 13] Permission denied: '/cached_resources'"
}

Is it trying to write to the root folder ?

root folder being working dir

@liiight I don't think it should use the working dir for cache. Probably under config dir is better?

@gazpachoking I agree.
In my case the working dir was in fact / as the deamon is launched as a service by the system. I was going to propose to use log directory  which is the same as conf for many of us I guess.

yeah, my bad :-)
i'll fix this


WIP: Add policy reports RFC

This is the initial work to settle on the User Stories about the "Policy Reports" feature.
After we agree on the User Stories, we can work on being specific about the implementation on the RFC section that is specific to that.

For me, the use cases are OK. I would suggest to change/rephrase some of the use-cases in order to make it clear what's the goal (i.e. what is the whole stack?).
And while there's no impact in terms of requests handling when we are in monitor mode, it still (might) impact the requests/cluster performances (as discussed during the last meeting).

I would suggest to change/rephrase some of the use-cases

Done.

And while there's no impact in terms of requests handling when we are in monitor mode, it still (might) impact the requests/cluster performances (as discussed during the last meeting).

I think we can discuss this on the implementation side. I would suggest that we also update the report on protect mode (both in monitor and protect mode). This way, numbers are always up to date and can give you certain ideas on third-party integrators that might use this information to cross data or show a dashbard to the user. It really depends on how the implementation is driven, I think we can pull an implementation that won't impact Kubewarden's performance -- at some cost, slightly increased memory usage --. But I think we can discuss that later on if that's fine.

Do we want to expand the users stories to allow searching by resource/CRUD operation (in addition of searching by policy/set of policies)?

I think this is entirely up to the consumer of the reports. They are free to list/watch the reports custom resource and build their own indexes etc...

If you are all fine with it, I propose to merge this RFC as is, and work on top of it later on.


Release-please aborted due to untagged, merged release PRs

TL;DR
"‼ There are untagged, merged release PRs outstanding - aborting" is the last line of release-please output in GitHub Actions log. Happens in RPA v3 but not in v2.
I kind of understand what an untagged release PR is... but I can't find any such PRs.
And how can I fix the issue? And avoid it happening again?
It has happened for several repos when moving from v2 to v3 of Release-Please-Action, leaving those repos in a less than desired state when it comes to CI workflows.
Expected behavior

I expect a release PR to be created, based on the commit messages I've used since last release was done.
I expect the log output from RPA to reflect the config I use in the Action YAML file.
I expect the PR title pattern to be taken from the config in the Action YAML rather than from elsewhere

Observed behavior

RPA runs but eventually aborts with "‼ There are untagged, merged release PRs outstanding - aborting"
The logs indicate that some other pull request title pattern is used. Note: I do have a RPA manifest file in the repo (from previous tests with using manifest files), but with "release-type: simple" that manifest file should not be used by RPA.
The log complains TWICE about pullRequesttitlePattern not being correct. But I am not even specifying this in the Action YAML config.

Action YAML
Note: steps.extract_sp.outputs.servicepack is set in previous step.
If the branch name triggering the action to run is "dev/sp3", servicepack will be "sp3".
-------------------------

      - name: Run Release-Please
        uses: google-github-actions/release-please-action@v3
        id: release
        with:
          release-type: simple
          package-name: TEST_${{ steps.extract_sp.outputs.servicepack }}
          default-branch: dev/${{ steps.extract_sp.outputs.servicepack }}
          monorepo-tags: false
          changelog-types: '[{"type":"feat","section":"Features","hidden":false},{"type":"fix","section":"Bug Fixes","hidden":false},{"type":"docs","section":"Documentation","hidden":false},{"type":"refactor","section":"Refactored","hidden":false},{"type":"doc","section":"Documentation","hidden":false},{"type":"chore","section":"Miscellaneous","hidden":false},{"type":"ci","section":"CI/CD","hidden":false}]'
          fork: false
          clean: true

Log output
Run google-github-actions/release-please-action@v3
  with:
    release-type: simple
    package-name: TEST_sp5
    default-branch: dev/sp5
    monorepo-tags: false
    changelog-types: [{"type":"feat","section":"Features","hidden":false},{"type":"fix","section":"Bug Fixes","hidden":false},{"type":"docs","section":"Documentation","hidden":false},{"type":"refactor","section":"Refactored","hidden":false},{"type":"doc","section":"Documentation","hidden":false},{"type":"chore","section":"Miscellaneous","hidden":false},{"type":"ci","section":"CI/CD","hidden":false}]
    fork: false
    clean: true
    token: ***
    bump-minor-pre-major: false
    bump-patch-for-minor-pre-major: false
    draft: false
    draft-pull-request: false
  env:
    GITHUB_REF: refs/heads/dev/sp5
    GITHUB_EVENT_NAME: push
√ Looking for latest release on branch: dev/sp5 with prefix:
‼ Could not find releases.
√ Building releases
√ Building strategies by path
√ Looking at files touched by path
√ Building release for path: .
‼ pullRequestTitlePattern miss the part of '${scope}'
‼ pullRequestTitlePattern miss the part of '${component}'
‼ pullRequestTitlePattern miss the part of '${version}'
× Bad pull request title: 'Pending UAT release : 🔖 sp5 release TEST_sp5 3.0.1'
√ Looking at files touched by path
‼ pullRequestTitlePattern miss the part of '${scope}'
√ Building release for path: .
‼ pullRequestTitlePattern miss the part of '${component}'
‼ pullRequestTitlePattern miss the part of '${version}'
× Bad pull request title: 'Pending UAT release (dev/sp5): 🔖 sp5 release TEST_sp5 2.2.0'

√ Looking for latest release on branch: dev/sp5 with prefix:
‼  Could not find releases.
‼ Expected 1 releases, only found 0
‼ Missing 1 paths: .
‼ No version for path .
‼ Expected 1 releases, only found 0
√ Collecting commits since all latest releases
√ Splitting 500 commits by path
√ Building candidate release pull request for path: .
‼ No latest release pull request found.
√ Considering: 49 commits
‼ There are untagged, merged release PRs outstanding - aborting

Additional information
I've battled this for some time now, trying to use manifests and finally now also deleted all previous tags and releases.
Which makes the scan through the repo to take quite some time, which is reflected in the log output above.

@mountaindude sorry for this nuisance, I've bumped into this myself recently I believe.
Could I bother you to open a ticket on the main release-please repository?

The upstream issue is fixed. Closing?

I am also getting this issue in my github action, but am unsure how to fix it?
I have tried the same steps as mentioned above.
I am alittle unsure if it could be caused by my .release-please-manifest or the release-please-config
They look like this:
.release-please-manifest:
{
  "backend": "1.1.0",
  "frontend": "1.1.0"
}

release-please-config:

{
  "packages": {
    "backend": {
      "changelog-path": "CHANGELOG.md",
      "bump-minor-pre-major": false,
      "bump-patch-for-minor-pre-major": false,
      "draft": false,
      "release-type": "node",
      "prerelease": false,
      "package-name": "package.json"
    },
    "frontend": {
      "changelog-path": "CHANGELOG.md",
      "bump-minor-pre-major": false,
      "bump-patch-for-minor-pre-major": false,
      "draft": false,
      "release-type": "node",
      "prerelease": false,
      "package-name": "package.json"
    }
  }
}

Any help would be much appreciated.


Publish JARs to Maven Central

Publish to Maven Central to allow downloading the JAR when resolving the Gradle Artifactory plugin dependencies.
Resolves https://github.com/jfrog/build-info/issues/522

Any estimate on when this might be merged?


The dependency target "Arduino_Drv_I2cDriver" of target   "BaremetalReference_Top" does not exist while running fprime-util generate

@capsulecorplab
This is because my PR for the I2C driver hasn't been merged yet. You can either switch to my fprime-arduino branch or manually add the I2C driver to your project.
https://github.com/ethancheez/fprime-arduino.git
My main branch should be updated.

Yup, adding your fprime-arduino library was able to generate the build cache! Ran into an undefined symbol error while attempting to build though

Yup, adding your fprime-arduino library was able to generate the build cache! Ran into an undefined symbol error while attempting to build though

I was unable to reproduce this error. Could you check your project if lib/fprime-baremetal/Svc/TlmLinearChan is included?

Yup, adding your fprime-arduino library was able to generate the build cache! Ran into an undefined symbol error while attempting to build though

I was unable to reproduce this error. Could you check your project if lib/fprime-baremetal/Svc/TlmLinearChan is included?

Yup, lib/fprime-baremetal/Svc/TlmLinearChan is there

This was my attempt to reproduce the error:
git clone --recurse-submodules  https://github.com/fprime-community/fprime-baremetal-reference.git
cd fprime-baremetal-reference/
fprime-util generate
fprime-util build -j4

The build succeeded, generating binaries for all deployments: BaremetalReference, RadioPassthrough, and BaseDeployment. My only theory on why the undefined symbol error occurs is if the fprime-baremetal/Svc/TlmLinearChan/TlmLinearChan.fpp file is not included.
If you navigate directly into the lib/fprime-baremetal/Svc/TlmLinearChan directory and run fprime-util build, does it build?

The settings.ini file should include:
library_locations:  ./lib/arduino/fprime-arduino:./lib/fprime-baremetal

Ah, that could be the issue. I commented that line out and replaced it with just a path to your fork of fprime-arduino

Let me fix that...

I reverted any changes to settings.ini and set the head commit in lib/arduino/fprime-arduino to your fork and that fixed the build!

Now I just need to wait for my Teensy 4.1 to arrive in the mail to actually flash/test it :upside_down_face:

Now I just need to wait for my Teensy 4.1 to arrive in the mail to actually flash/test it :upside_down_face:

The baremetal reference uses the RFM69 radio to communicate. You would also need two RFM69 breakout boards and two Teensy 4.1 boards.
Or you can get two Feather M0s

The baremetal reference uses the RFM69 radio to communicate. You would also need two RFM69 breakout boards and two Teensy 4.1 boards.
Or you can get two Feather M0s

Cool! Any advantage to getting two Feather M0s over two RFM69 breakout boards? What would the 2nd Teensy be for?

The baremetal reference uses the RFM69 radio to communicate. You would also need two RFM69 breakout boards and two Teensy 4.1 boards.

Or you can get two Feather M0s

Cool! Any advantage to getting two Feather M0s over two RFM69 breakout boards? What would the 2nd Teensy be for?

There are two separate deployments that communicate to each other via the radio: BaremetalReference and RadioPassthrough.
One Teensy would have the BaremetalReference deployment, and the other Teensy would have the RadioPassthrough deployment. Your GDS would connect to the RadioPassthrough deployment to wirelessly command the BaremetalReference deployment.

Ordered a couple of the radio breakout boards + an extra teensy - might as well test with all the platforms :slightly_smiling_face:

I guess I'll go ahead and close this issue and open any new issues that may arise when attempting to connect and test with hardware. Thanks for all the help @ethancheez !

I also just noticed there's a 433MHz option that's license-free (which means I don't have to renew my ham license). Would this work as well?

I also just noticed there's a 433MHz option that's license-free (which means I don't have to renew my ham license). Would this work as well?

Yes, I believe both the 433 MHz and 915 MHz bands do not require a HAM Radio License. As long as both of your radios operate at the same frequency, you should be fine!

Re-opening this issue, as the fprime-arduino submodule doesn't contain @ethancheez's i2c drivers yet


Settings don't work

Hello,
today I recognized a new design for the settings. It's Version 2.20.0.
I can open the setting tabs on the arrows but smart rss doesn't react to setting changes in any way. I also cannot export or import any of my feeds anymore.
I'm using windows 7 64-bit and the newest version of vivaldi.
Best regards

Sorry for trouble, this issue will be fixed in the next release, depending on Chrome Web Store approval should be available in few hours up to few days

Sorry for trouble, this issue will be fixed in the next release, depending on Chrome Web Store approval should be available in few hours up to few days


X, previously known as Twitter in the footer and on blogs

Originally this PR was to handle issue #3647, but then I realized submodules needed updated to get the new logo (@fortawesome/fontawesome-free had to be updated in google/docsy and then the cncf/docsys fork had to be updated)
Instead of this PR handling any of those dependencies, this change was put on hold until those updates took place (which they now have).
See #3665 which broke up the "Twitter-to-X updates" and this handles one part of that issue.

This PR simply changes the Twitter logo in the footer to the X logo.
It also updates one blog post which happened after the X name change, which was the preference from @svrnm in discussions below.

@nmummau thanks for raising this PR and I appreciate the effort, but note that blog posts are historical and should be kept as they are as far as possible. Also twitter was renamed to X July 23th, so all blog posts before that should remain untouched by this change for that reason as well. I am OK with updating blog posts post re-name, but not before.
Having the logo changed on the website with the fontawesome updated is a change we can apply.

@svrnm I applied your suggested changes. In my mind updating the hyperlinks on old blog posts doesn't change the content of the blog post itself, which was my though process on my initial update.
Something to consider is that the links on the old blog posts may break if Elon ever decides to stop resolving Twitter.com.

@svrnm I applied your suggested changes.

Thank you!

Something to consider is that the links on the old blog posts may break if Elon ever decides to stop resolving Twitter.com.

Most links to twitter link to profiles of individuals or hashtags, so I wouldn't be worried to much about them, since they might be not-active anymore already. The only tweet referenced is the one by Yuri around jaeger sunsetting their clients in favor of OpenTelemetry, which ultimately links to a github issue (which we should have linked to begin with, but same here, let's keep it that way)

we could also wait another year for when the site gets rebranded to twitter, who knows. 😛
On Dec 5, 2023 at 7:51 PM -0500, Patrice Chalin @.***>, wrote:

@chalin commented on this pull request.
In hugo.yaml:

@@ -57,7 +57,7 @@ params:
collector services to capture distributed traces and metrics from your
application. You can analyze them using Prometheus, Jaeger, and other
observability tools.

font_awesome_version: 5.8.1

font_awesome_version: 6.5.1
Ohhh, that line shouldn't be there anymore! I'm glad that this PR allowed us to pinpoint that. See:

• #3653
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because your review was requested.Message ID: @.***>

Here's the update of Docsy (and FA):

#3666

Once it lands, rebase and feel free to clean up this PR to include only the changes that we've agreed to and that @svrnm mentioned. Thanks!

https://github.com/open-telemetry/opentelemetry.io/pull/3666 is merged.
@nmummau please double check if all things are working now and then I am happy to merge.

@svrnm All set!

/fix:format

🎉  thank you @nmummau


Missing scripts

Hi,
I recently came across your very interesting and insightful publication and followed through to get further insights by learning from the scripts used to conduct this study.
However, I am a bit confused as it seems that the bash and matlab scripts mentioned in the repository's readme file (e.g. scripts_assoc_clinical.m) are not available on the git repository.
Could you please help me in finding these files?
Many thanks,
Sina

Hi Sina,
Thank you for your interest! These files experienced some delay and will be updated asap. They should be available in 1~2 days.
Best,
Yongbin


Icon color

What if we want to change color of icons ?

There are two attributes that can be used to change the color of icons. You can look at the wiki page for Styling the dialog which explains how to use them. The two attributes are:

icdIconColor: Icon color when not selected. Default is ?android:attr/textColorSecondary.
icdSelectedIconColor: Icon color when selected. Default is ?attr/colorAccent.

I want to use icon in my ImageView and change the icon color when some change happens or when i click a button.

You can set a color filter on the ImageView like this:
Icon icon = IconHelper.getInstance(context).getIcon(232);  // Get an icon
imageView.setImageDrawable(icon.getDrawable(context));     // Set the icon on the image view
imageView.setColorFilter(color, PorterDuff.Mode.SRC_IN);   // Change the icon color

Alternatively, you can tint the drawable directly with icon.getDrawable(context).setColorFilter(color, PorterDuff.Mode.SRC_IN).
Is that what you needed?


fix: Use commit SHA from the event CY-4321

If the event is a pull request, the GITHUB_SHA will have a different commit UUID (the id of a merge commit):
https://help.github.com/en/actions/reference/events-that-trigger-workflows
We need to fetch the correct SHA from the event details that GitHub provides.
Tested with https://github.com/troubleshoot-codacy/eslint-test-prod/pull/5 (that relies on a fork of the action with this changes)

We solved this in another level in the coverage reporter. It is the coverage reporter itself that defaults to the correct commit uuid without any extra logic in the action side. @franciscodua knows well everything since he did it.
I think we can merge this PR, but also open an investigation task to see if it's worth to extract the provider logic in a library consumed by coverage-reporter and analysis-cli.

Yes, we already have a special case for the coverage reporter in Github. You can find it here

So that would be a direction that we want the CLI to move? Even if we do it in the future, we should do it here as well:

We are calling the CLI, and the CLI can receive the commit-uuid as a param, if the action already knows the correct one, can already pass it
We need to find the correct UUID on this side either way, as there are things that are not done on the CLI, like sending results for the GoSec that does not go through it, and sending the final notification.

That said, we can move on that direction, like you guys mention, but that does not invalidate this PR, correct? It is something that we still need to merge, right? @franciscodua @lolgab

That said, we can move on that direction, like you guys mention, but that does not invalidate this PR, correct?

Correct!


LS: Initialize tracing in E2E tests

Stack:

#5474
#5525 ⬅
#5531

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.


jacobi3d-gauss

Original author: Nikhil Jain
Original issue: https://charm.cs.illinois.edu/redmine/issues/610

No body.

Original author: Lukasz Wesolowski
Original date: 2015-02-08 09:31:13

The test relies on OpenMP and CkLoop, so it is probably not something we would want to run on every platform when testing. Further, it appears that CkLoop does not get built by default.
The question is whether to remove it or place it in a target for testing CkLoop. Perhaps Harshitha, who may be familiar with testing procedures for CkLoop, or Yanhua, who has worked on this code before, can weigh in.

Original date: 2015-03-19 20:50:22

any progress on this?
At the very least, the test could be configured to run if CkLoop has been enabled in the build.  That should be easy to test.  If it isn't, then it not being easy to test is itself a problem.

Original date: 2015-03-27 17:33:20

We're making moves toward enabling CkLoop to build by default, per #636. Once that's the case, we won't need to conditionalize this.

Original author: Harshitha Menon
Original date: 2015-08-17 20:24:11

Should I change the test to test ckloop part conditionally or we wait for ckloop to be built by default? Ckloop now builds on windows and solaris (https://charm.cs.illinois.edu/redmine/issues/701), so should we just build ckloop by default?

Original author: Harshitha Menon
Original date: 2015-10-26 20:45:35

CkLoop builds by default. So I have modified the test to run by default and also changed the Makefile to pass the right arguments.

Original date: 2016-10-13 20:59:17

Fix was here
~~https://charm.cs.illinois.edu/gerrit/810~~ https://github.com/UIUC-PPL/charm/commit/948abde7b7c4fb8d9da96239536d91ac42544ae5
(cross-linking for ease of future reference)


Caused By: org.redisson.client.RedisTimeoutException: Unable to acquire subscription lock after 14500ms. Try to increase 'timeout', 'subscriptionsPerConnection', 'subscriptionConnectionPoolSize' parameters.

Hi Team,
After increasing subscription value, issue still comes same times with same redis load. We flashed redis in every run without restarting redis.  Following are the details:
Redisson Version : 3.20.0
subscriptionsPerConnection=50
timeout=10000
subscriptionConnectionPoolSize =1200
Exception:
Caused By: org.redisson.client.RedisTimeoutException: Unable to acquire subscription lock after 14500ms. Try to increase 'timeout', 'subscriptionsPerConnection', 'subscriptionConnectionPoolSize' parameters.
at org.redisson.pubsub.PublishSubscribeService.lambda$subscribe$5(PublishSubscribeService.java:219)
at io.netty.util.HashedWheelTimer$HashedWheelTimeout.run(HashedWheelTimer.java:715)
at io.netty.util.concurrent.ImmediateExecutor.execute(ImmediateExecutor.java:34)
at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:703)
at io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:790)
Please suggest solution.
Regards
Ratna Shanker Mishra

What is the use case?

Hi Nikita,
We are storing non-transactional DB data into redis in the from of key-value pair at the time of system startup.
There is no change in the volume of data in every run. We are flushing redis cache before every run without restarting  redis.
We are using Sentinel redis setup and issue is coming frequently.
Please suggest some solution.
Regards
Ratna Shanker Mishra

Sorry, I mean which Redisson objects do you use.

Hi Nikita,
We are using below Redisson libraries for mentioned usecase :

RLocalCachedMap
RBatch
RMapAsync
RScoredSortedSetAsync
RFuture

Regards
Ratna Shanker Mishra

do you use RLocalCachedMap as a singleton per unique name?

Yes Nikita, we are creating unique  RLocalCachedMap  object based on key there is no duplicate RLocalCachedMap  creation call for same key. Following is the code.
redisson.getLocalCachedMap(getCacheName(),codec, options)
Here getCacheName() return unique key and above code will not call for same key inside same JVM.
One point that we have multi node application setup, Each node is creating 135 unique cache through above call.
Please refer attached diagram.

Is there any Redis connections amount limit?


Optimise pin icons/add pinned variant/improve metadata

An alternative way of showing the toggled state of pin vs pinned. The thinking here is that it might be more appropriate to appear as being pinned to a vertical surface…

If we didn’t necessarily want to add a simply rotated pin-horizontal variant, I suppose we could just add pinned like this instead:

I chose this one. The design is odd to me. This is a bit weird way of showing something is "pinned". I think from UX point of view it's better to use color or a "fill" to indicate something is "pinned".


chore(ci): Bump Mattermost server version

Test failure by this change (from changelog)

Removed the ability to change the type of a channel using the PUT /channels/{channel_id} API endpoint. The new PUT /channels/{channel_id}/privacy endpoint should be used for that purpose.


Missing script gpu_metrics_collector.py

def start_gpu_metrics_collector(interval=10, log_file='gpu_metrics_log.csv'):
    command = f"python gpu_metrics_collector.py --interval {interval} --log_file {log_file}"
    process = subprocess.Popen(command, shell=True)
    return process

This method refers to gpu_metrics_collector.py that doesn't exist in the project

This method refers to gpu_metrics_collector.py that doesn't exist in the project

Thanks. That shouldn't be referenced anymore. GPU metrics are collected at the same time/as part of the same data as inference/training now.
I'll remove this shortly.


Add router.add_get (#986)

What do these changes do?

Are there changes in behavior for the user?

Related issue number

Checklist

[ ] I think the code is well written
[ ] Unit tests for the changes exist
[ ] Documentation reflects the changes

Coverage decreased (-2.2%) to 95.765% when pulling f1160c0ce42132a541e79ff6f597f6354f4830cc on benmohta:master into 328bb368cc08240ef8c995bcc36ba0b694fe79ca on KeepSafe:master.

That's good but please add shortcuts to other methods.
Documentation is also need to be updated.

Coverage decreased (-2.09%) to 95.89% when pulling b9fd1ab3f44799c59eb008428cccb164ce93276e on benmohta:master into 328bb368cc08240ef8c995bcc36ba0b694fe79ca on KeepSafe:master.

Fixed by #989


"Body already consumed, and was too big to cache."

Could someone explain what this actually means?  I'm having trouble understanding it.
This seems to imply it's possible to not have an error on too-big request body by not consuming it - is that actually possible?
Currently to bypass this I've set the cache to be 1MB. This seems like a wrong fix. Is there a correct way of handling large requests? I noticed #116 & #135 mentioned configuration to disable request caching entirely, but from what I can tell that config no longer exists in 3.1.0? I only see a requestCacheSize on the config object (and it's no longer a setter method, just a variable).

Could someone explain what this actually means? I'm having trouble understanding it.

You're reading the request body more than once. This usually happens if you try to log the request body, or if you forget to store the body in a local variable.

This seems to imply it's possible to not have an error on too-big request body by not consuming it - is that actually possible?

I'm not sure if I'm following. If you don't read it twice, there won't be any problem. You can handle any size request bodies.

This seems like a wrong fix. Is there a correct way of handling large requests?

If you want to read it twice, it has to be cached, so either you have to increase the cache size, or only read the body once.

Ohhh, I didn't understand what was meant by "consuming" it (I assumed the consuming was being done automatically in some step as the request was received). Didn't realize that my logging of the request was reading the body (obvious in retrospect..), so I'll make the appropriate changes and store it in a variable now. Thank you!

No problem!