Allow the location of the Gradle cache to be specified independent of the user configuration files

Original issue: https://issues.gradle.org/browse/GRADLE-2608
Current behavior
It is possible to configure the location of the gradle user home directory by providing it on the command-line (via -g or --gradle-user-home), by providing it as a system property (gradle.user.home), or by setting an environment variable (GRADLE_USER_HOME), via the default (usually "USER_HOME/.gradle").
Of the items that are placed under this directory, some are user-provided configuration files, like gradle.properties, init.gradle, any files under init.d, and any files a user might create for those to use.
Other items are cache directories, such as caches, native, and wrapper. These typically contain caches of information that may be re-acquired later if need be, and which can grow quite large over time.
And finally, there are job management items such as those under daemon.
Of these items, all except the user configuration files have problems in the presence of a shared filesystem for the user's home directory. The most obvious and severe is that not all shared filesystems have the same sort of locking behavior as local filesystems, resulting in very strange results when the user attempts to use daemons on more than one machine at a time. However, the caches also cause problems, since large shared filesystems often have quotas that limit the amount of storage users have in their shared space. As a result, a user may wish to place large replacable caches on local disk, away from their home directory.
At the moment, there is no way to configure where these caches and host-specific pieces live separately from where the user configuration files live. All are found under GRADLE_USER_HOME. As a result, users have a few options to work around things:

They can use symbolic links from their GRADLE_USER_HOME directory to directories elsewhere, so that the configuration files live under USER_HOME, but the caches are found by following the symlinks to a location under /var/tmp or the like. This also requires the user to have their login scripts ensure that the directories under /var/tmp exist after each login, in case they are clobbered (or in case the user logs into a machine that they have not previously used.)
They can use the GRADLE_USER_HOME environment variable to locate their entire directory (including user config files and caches both) at some location on the local filesystem, for example under /var/tmp. This also requires the user to have their login scripts ensure that this directory exists and that the user's per-user configuration files are copied into it.

Desired behavior
Optimally, it should be possible to provide alternate locations for all of these caches directories. It's fine if they continue to be located under GRADLE_USER_HOME by default, but the ability to relocate all of the caches at once (perhaps with GRADLE_USER_CACHE which defaults to GRADLE_USER_HOME and will create the target directory if it does not exist) or the individual cache directories for each subdirectory of GRADLE_USER_HOME (so you could locate wrapper, native, daemon, and caches in different places—perhaps locating wrapper, native, and caches on a shared volume that is larger than the user's home directory, and daemon on a local volume to avoid lock and process problems.)
Since this would allow the cache location to be configured separately from the user configuration location, the user configuration might be usable to specify the cache configuration. For example, the user's gradle.properties file might specify either a new base cache dir or new individual cache dirs.
Context
As stated in the comment I added in support of the original ticket:

This is important for me—my organization makes use of a distributed filesystem for home directories, with fairly restrictive quotas. This means that before people can build things with gradle, they have to set up a gradle user home on local disk, or symlinks from their gradle user home to some location on local disk.
Explaining to users how to do this is... much more difficult than it ought to be.
It also doesn't do much good for the pitch: "Hey, try this awesome build tool!...

Making this easier to configure either with an environment variable or a gradle property means being able to say "add this line to your .profile" or "add this line to your .gradle/gradle.properties", instead of "run this long chunk of code in your login script that creates several directories and symlinks to them or everything will explode".

Can we rename to replace "user home dir" in the title with "user configuration files" to better reflect the use case?

This would seem to be blocked by #1338. I imagine we'd tackle these 2 stories in the same stream.

I wouldn't tie this to #1338. They are 2 very different use cases.
This issue (#1319) is about providing some way for a user to tell Gradle where to put the cached content it generates so that this cached content is separate from the user's configuration files.
The other issue (#1338) is about a user taking the cached content (where ever it happens to live and however the user asked Gradle to put it there) and moving this cached content to a new location and then expecting Gradle to be able to continue to use this cached content as if it were generated into that new location. Which I feel pretty strongly that we should not do. We should solve those use cases, which are important, in other ways.

Thanks for the info, Adam. I've gone ahead and unblocked this. Should we just close #1338 then?

We have very similar problems on our CI system.
We centrally place a $HOME/gradle.properties and $HOME/init.gradle on each runner, which configures the build for our Corporate CI environment (Proxy, Nexus credentials, ...). This prevents each project from having to define the CI configuration itself. (Which would be very tedious with about 200 projects.)
However, due to the "shared" cache, the builds are constantly being broken. And I have to intervene manually and delete the cache directories. At the moment I am experimenting with overload the $HOME/.gradle/cache directory with a temporary volume on each run. But this feels like a workaround for me 🤔

Wow this is a shame


New version: Tenpi.Waifu2xGUI version 0.5.1

Pull request has been created with komac v2.6.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

URL: https://github.com/Moebits/Waifu2x-GUI/releases/download/v0.5.1/Waifu2x-GUI-Setup-0.5.1.exe
Status Code: 200
(Automated message - build 896)


Check if the binary in the $PATH is the matching server version and if so not download

Check if the binary in the $PATH is the matching server version and if so not download

It's a lot faster to download the binary now since we added compression, so we're not going to do this for now.


multistream goes a bit nuts when sockets hangup while it is doing its thing

We really need to model swarm as a big state machine https://github.com/libp2p/js-libp2p-swarm/issues/24, otherwise finding the causes for these issues is like looking for needles in haystacks

I have seen this error previously and in my case, it occurred when the browser was closed. The error seems to be propagated through the pull-stream and I previously traced it back to the following:
https://github.com/spdy-http2/spdy-transport/blob/master/lib/spdy-transport/connection.js#L180
How I am handling it? I have a drain in my pull-stream which actually catches that error and will probably handle it there at some point.
What I think you're seeing is probably the lack of a drain or other error handler causing it to explode (Maybe?) I don't think this is particularly ms-select's fault here. I personally think the application or module at the end of the stream should catch this error and end the pull-stream.

Closing this as stale. This should no longer be an issue as of the 0.15 refactor.


Retry functionality

Implement retry functionality for the client to retry requests. Cases that this implementation should solve and objectives:

Client is throttled and needs to check retry header to see when retry is possible. Same as 429 rate limits.
500 error codes have different possibilties and the Microsoft Graph Api may have their own way of returning certain 500 error codes. Some 500 errors are used in concert with a Retry-After header so that should be looked at. The 500 Internal server error will depend on the situation and error occuring.
Whenever there is a retry after header then always use that to figure out when to retry.

Functionality:

Retry after throttle using header value of time to wait. If possible, this should just be a flip of the switch to turn on. Meaning no other inputs should be required to be given except that this should be enabled (such passing true or false for enabled).
Backoff or retry policy that provides

min time to retry
max time to retry,
max retries tried - we want to stop trying to send requests when we reach this

backoff strategy - exponential backoff, and the retry after throttle mentioned above (name to be decided by who works on this). These strategies use the above policy inputs (min time/max time, etc)

Any other important use cases and implementation notes? Feedback welcome.
Update:
Implementation should include the following 2 retry types at the minimum and more can be added or updated later on as well:

Throttle Retry: Handle retrying for when Microsoft throttles requests and sends back the 429 http error code and Retry-After header. The impl should check if the http code is a 429 and if it is then get the seconds from the Retry-After header, and wait the amount of seconds provided in the Retry-After header before retrying the request again. See https://learn.microsoft.com/en-us/graph/throttling#best-practices-to-handle-throttling
Exponential backoff: retries requests exponentially, increasing the waiting time between retries up to a maximum backoff time. Each retry will have a wait time of 2x the previous wait time.

There may be cases where these conflict with each other and we will need to come up with a way to deal with this such as not using any other retry except the throttle retry when a 429 response code is returned.

@DevLazio Created this for the retry feature we talked about.
I found a few interesting crates. The first is the backoff crate which looks promising and provides mechanisms for doing retries and has reqwest examples.
The next is reqwest-retry which is a wrapper around reqwest that provides retry functionality. I don't want to use this crate mainly because it wraps the reqwest Client and provides its own interface to do requests which means you lose any choice of setting reqwest version, or using any features that this crate hasnt adopted yet. But its something to look at with regards to how a retry implementation could be done or some functionality can be done.

This is the design document for retry handlers in Microsofts SDKs and I thinking following this specification will probably work out best. https://github.com/microsoftgraph/msgraph-sdk-design/blob/master/middleware/RetryHandler.md

I finally had a bit of time to look into this.
The backoff crate looks like the right choice for the task. The only pain point is using an async FnMut function so I had to do a bit of gymnastics around it.
Nothing is final, just looking for comment at this time.
Usage :
    let config = GraphClientConfiguration::new()
        .retries(true)
        .retries_config(RetriesConfig {
            initial_interval: Duration::from_millis(500),
            randomization_factor: 0.0,
            multiplier: 1.5,
            max_interval: Duration::from_secs(450),
            max_elapsed_time: Some(Duration::from_millis(450)),
        })
        .access_token(ACCESS_TOKEN);

    let client = Graph::from(config);

    for _i in 0..100 {
        let response = client
            .reports()
            .get_email_activity_counts_by_period("D180")
            .send()
            .await.unwrap();

        println!("Got response {}", response.status());
    }

It's not necessary to provide a RetriesConfig, there is already a default one with values that seems okay enough for GraphAPI imo.

I finally had a bit of time to look into this. The backoff crate looks like the right choice for the task. The only pain point is using an async FnMut function so I had to do a bit of gymnastics around it.
Nothing is final, just looking for comment at this time.
Usage :
    let config = GraphClientConfiguration::new()
        .retries(true)
        .retries_config(RetriesConfig {
            initial_interval: Duration::from_millis(500),
            randomization_factor: 0.0,
            multiplier: 1.5,
            max_interval: Duration::from_secs(450),
            max_elapsed_time: Some(Duration::from_millis(450)),
        })
        .access_token(ACCESS_TOKEN);

    let client = Graph::from(config);

    for _i in 0..100 {
        let response = client
            .reports()
            .get_email_activity_counts_by_period("D180")
            .send()
            .await.unwrap();

        println!("Got response {}", response.status());
    }

It's not necessary to provide a RetriesConfig, there is already a default one with values that seems okay enough for GraphAPI imo.

I guess I would say can you give me more information on how it would be used? Is the ranomization factor based off of the backoff crate? I guess whats confusing about that is typically exponential backoff increases the rate at which the backoff happens. And this is typically done at a 2x factor. For instance first retry happens at 2 then 4 then 8 then 16.  This is how its done in other graph sdks as well.
For retry functionality we should allow providing policies such as ExponentialBackoffPolicy where the user can set certain fields that change how the retry is done whereas fields like max retry time or max retries allowed will be set internally. The user can still set those but only if they don't go over the given limit. And that limit would be based off of other graph sdks to be consistent.

I guess I would say can you give me more information on how it would be used? Is the ranomization factor based off of the backoff crate? I didn't go too far into looking at the backoff crate about its use so I apologize. Whats confusing about that is typically exponential backoff increases the rate at which the backoff happens. And this is typically done at a 2x factor. For instance first retry happens at 2 then 4 then 8 then 16. This is how its done in other graph sdks as well.

The five parameters are from the backoff crate. At first I was thinking that we could provide a simpler configuration then I realised that at some point we would get a ticket to add such and such parameter and "re-exported" them all.

For retry functionality we should allow providing policies such as ExponentialBackoffPolicy where the user can set certain fields that change how the retry is done whereas fields like max retry time or max retries allowed will be set internally. The user can still set those but only if they don't go over the given limit. And that limit would be based off of other graph sdks to be consistent.

There is an open issue about adding a max retry count, but currently the backoff crate does not provide that functionnality. I guess we can compute it by modifying the time parameters, but it's not the same. If we do this we have to implement it ourselves.

The unoffical Rust Azure sdk is similar but with the possibility of adding a random delay: https://github.com/Azure/azure-sdk-for-rust/blob/main/sdk/core/src/policies/retry_policies/exponential_retry.rs - I wonder the randomization factor is for the same thing?
As I understand it, pretty much.

@DevLazio Yeah probably the best thing to do here is to provide a configuration model, a wrapper around the backoff config, that has those fields:

initial delay: cannot be greater than max delay and cannot be greater than the max delay that the crate sets by default
max retries: can be set by the user as long as it doesnt go over the max retries that the crate sets by default
max delay
max time elapsed: can be set by the user as long as it doesnt go over the max time ther crate sets by default

For the max retries, that is something that will have to be done on our side. A counter of some sort.
The configuration model will need to be done in such as a way as to allow other types of retry configuration models such as a throttle retry configuration. This can be done by providing a mechamism to allow multiple types or configurations such as an enum where each enum field is one of the configurations or by using a trait object and the GraphConfiguration storing a Box for those configurations.

struct ThrottleConfig;

#[derive(Clone, Debug)]
pub enum Retries {
    NoRetry,
    ExponentialBackoff(ExponentialBackoffConfig),
    Throttle(ThrottleConfig),
}

#[derive(Clone)]
struct ClientConfiguration {
    access_token: Option<String>,
    headers: HeaderMap,
    referer: bool,
    timeout: Option<Duration>,
    retries: Retries,
    connect_timeout: Option<Duration>,
    connection_verbose: bool,
    https_only: bool,
    min_tls_version: Version,
}

Something like that ?
For the max retries I can't find a way to implement an attempt counter, neither inside the closure nor outside. I think the only way is to implement it inside the ExponentialBackoff struct (see https://github.com/ihrwein/backoff/pull/60).
I'm curious, what would the Throttle retry do ?

@DevLazio I havent forgotten about this. Sorry for the delay. Just been super busy between work and other things. I have a design that I think will work for this and I can give a high level overview and we can discuss. Just give me a few more days and i'll reply back with that design information.

I'm curious, what would the Throttle retry do ?

The graph api throttles the amount of requests that can be sent to its servers based on a few factors but mainly too many requests being sent at one time. Here is a small excerpt from their docs:

When a throttling threshold is exceeded, Microsoft Graph limits any further requests from that client for a period of time. When throttling occurs, Microsoft Graph returns HTTP status code 429 (Too many requests), and the requests fail. A suggested wait time is returned in the response header of the failed request. Throttling behavior can depend on the type and number of requests. For example, if you have a high volume of requests, all requests types are throttled. Threshold limits vary based on the request type. Therefore, you could encounter a scenario where writes are throttled but reads are still permitted.

When requests are throttled, Microsoft sends the response with the 429 error code, which can be used to detect throttling, as well as a Retry-After header which provides the number of seconds to wait before retrying the request again. The throttle retry will wait those number of seconds and then retry the request. We can possibly add an option for doing these waits on another thread so its non-blocking as well but default would block.
You can read more about it here: https://learn.microsoft.com/en-us/graph/throttling#best-practices-to-handle-throttling

@DevLazio
I will have some more information on this soon but in general the implementation should follow that of a http pipeline using policies. That can be a little confusing given its such a broad term but a simple description is that a pipeline stores a list of policies, which are things like retry policies or telementry policies or specific use case policies, and these policies are called in a specific order on each request.
So Policies are not specific to retrying requests but the basics are:

Policies accept a request as input
Policies can modify the request. Some policies can bail out of the pipeline such as when the maximum retries have been met.
When the last policy is reached, usually called a transport policy, this policy calls the request and returns the response.

A pipeline:

Stores a list of policies, both user defined and sdk defined but for now user defined will come at a later point.
These policies can be updated and/or removed except where sdk defined policies are required (transport policy)
Ensures proper order of policies being executed on each request.

Retry policies will be included in this list of policies. So this means the retry policy will modify the request in such a way that the transport policy knows how to handle any retries (there are different implementations and ways of doing things but I am providing a simple example). The request that I am talking about may not be just the http Request object but will have other fields, and will have a field for the current actual http request that is required.
I will provide a general impl of this and the retry policies soon. It won't be too in depth but it will provide enough of it to understand what I have mentioned above or at least make it more clear.

I like your pipeline approach. Might be especially usefull when trying to follow the Microsoft RFC for retries and the user's needs.

The graph api throttles the amount of requests that can be sent to its servers based on a few factors but mainly too many requests being sent at one time.

I thought you meant another thing. The way I started experimenting with it, the "429 Too Many requests" and their Retry-After header has priority over the user-defined exponential backoff settings, which resemble your pipeline model. The exponential backoff was used when their was no Retry After header or another error append.
Having the Enum be {None, ExponentialBackoff, Throttle} feels weird to me because we kinda have to abide by GraphAPI limitations, (I discovered that for endpoints you can continue to try before the Retry-After period is up and will a bit of luck you can get a successfull response if your request reach another instance or something) so ExponentialBackoff should include Throttle.
That's why I think your pipeline model is quite elegant.
We must be carrefull while implementing this pipeline though, because each endpoint has his own throttle limits, so the client must not delay a request because a request to another endpoint got a 429 response.

Ive been quite busy so its taking me longer to get back to you. So I wanted to provide a quick example that follows what other msgraph sdks do as far as a really simple example can.
This is a small example of what typical sdks do. Note how the policies are taking in a list of policies and calling the next in the list of policies.
Not sure how much youve looked at http pipelines when it comes to azure or graph sdks but they typically take multiple types of policies and its basicaly a modification of the request and then calls the next policy to put it simply.
pub struct RequestContext {
    // ... request context fields
}
// request context impl somewhere

// Just here as an example. The actual struct/impl would be different.
pub struct SomePolicyResult;

pub trait HttpPipelinePolicy {
    // Modify the request.
    fn process_async(&self, context: &RequestContext, request: &mut http::Request<Value>, pipeline: &[Arc<dyn HttpPipelinePolicy>]) -> Result<SomePolicyResult, Box<dyn std::error::Error>>;

    fn process_next_async(&self, context: &RequestContext, request: &mut http::Request<Value>, pipeline: &[Arc<dyn HttpPipelinePolicy>]) -> Result<SomePolicyResult, Box<dyn std::error::Error>> {
        pipeline[0].process_async(context, request, &pipeline[1..])
    }
}

// Example only. Not exact at all.
pub struct ExponentialBackoffRetryPolicy {
    // ... retry fields
    pub min_retries: u32
}

impl HttpPipelinePolicy for ExponentialBackoffPolicy {
    fn process_async(&self, context: &RequestContext, request: &mut Request<Value>, pipeline: &[Arc<dyn HttpPipelinePolicy>]) -> Result<SomePolicyResult, Box<dyn Error>> {
        // modify request...

        Ok(SomePolicyResult)
    }
}

pub struct ThrottleRetryPolicy {
    // ... impl
}

impl HttpPipelinePolicy for ThrottlePolicy {
    fn process_async(&self, context: &RequestContext, request: &mut Request<Value>, pipeline: &[Arc<dyn HttpPipelinePolicy>]) -> Result<SomePolicyResult, Box<dyn Error>> {
        // modify request...

        Ok(SomePolicyResult)
    }
}

I was trying to implement the Http Pipeline and I encountered a few problems.
First of all, contrary to something like a tower middleware, I don't think it's possible to modify the Http request so that the Transport policy knows how to do retries. And even if we could, that would mean that most of the logic is handled by the Transport policy, leaving the others empty.
In the specific case of retries, each policy has it's own state and based on that the policy can :

delay the request (so it should probably be async)
forward the request to the next policy
check if the request was sucessful and if not, delay, forward again or give up and return the error

There is no need there to modify the request, these policies just need to be able to retry and the Transport policy would basically be the same as the current send() method. Incidentally, the return type of these policies should be the request response.
Do you have an example of some other policies you would want to implement, other than retries ?

I just pushed a commit to implement the HTTP Pipeline.
A lot of work is still needed (give user ability to customize pipeline policies, implementing max number of retries, RequestContext, cleanup of unwraps, etc) but the basic POC is there.
Let me know what you think of it.

I just pushed a commit to implement the HTTP Pipeline. A lot of work is still needed (give user ability to customize pipeline policies, implementing max number of retries, RequestContext, cleanup of unwraps, etc) but the basic POC is there. Let me know what you think of it.

Hey, apologies my work has been very busy lately and I havn't had time to look at this yet.
I will take a look soon.

@DevLazio
Ok so there is a good bit there and I think its a good start.  One was why there needed to be a struct specifically to clone a pipeline policy. But im sure you had a reason I just couldnt tell what was going on there.
On adding a policy to the pipeline I would say it would make more since to not require them to have it wrapped in an Arc beforehand and just require providing an impl of the trait but I didn't run the code myself so I don't know if there was a reason for that specifically.

    pub fn add_pipeline_policy(
        mut self,
        policy: Arc<dyn HttpPipelinePolicy + Send + Sync>,
    ) -> GraphClientConfiguration {
        self.config.pipeline.push(policy);
        self
    }

I think in general it looks good. I would say there probably is some areas of concern. Such as why does the pipline take a Client. My assumption is that the underlying owner of the pipeline array of policies is also the owner of the client itself and would provide that itself. Because if we provide a way to allow the user to create new policies, ecspecially ones where they may do some type of manipulation pre/post request then they would probably also be implementing the HttpPipelinePolicy trait and I don't know whether or not its a good idea to give them access to the client. Maybe it is im not sure. I will have to think about that one some more and some of the possible benefits/drawbacks.

@DevLazio  Im also interested to know if you have ever look at Tower and the middleware use cases that their library brings. Both Reqwest and several other clients have added integrations for Tower.
They have middleware integrations that allow doing a very similar thing to what I described with the Http Pipeline Policies. And they even have retrty policies baked in. Although you still would have to define more policies for this specific use case but there is benefit to using Tower over a custom built one.
If you get a chance take a look at their main crate docs below and just read the first couple of paragraphs to see what I mean. I have looked at it a little bit and have tested doing an integration but didn't get too far into it.
Tower main crate docs:
https://docs.rs/tower/latest/tower/index.html
Example doc of Tower Retry:
https://docs.rs/tower/latest/tower/retry/trait.Policy.html

Sorry It took me so long to reply, was in vacations.

Ok so there is a good bit there and I think its a good start.  One was why there needed to be a struct specifically to clone a pipeline policy. But im sure you had a reason I just couldnt tell what was going on there.

It was needed to clone a struct containing a Box : https://stackoverflow.com/questions/30353462/how-to-clone-a-struct-storing-a-boxed-trait-object
I've since iterated on the design and I don't think it's needed anymore, will remove it.

On adding a policy to the pipeline I would say it would make more since to not require them to have it wrapped in an Arc beforehand and just require providing an impl of the trait but I didn't run the code myself so I don't know if there was a reason for that specifically.

I started with your example but could not make it to compile without changing that.

I think in general it looks good. I would say there probably is some areas of concern. Such as why does the pipline take a Client. My assumption is that the underlying owner of the pipeline array of policies is also the owner of the client itself and would provide that itself. Because if we provide a way to allow the user to create new policies, ecspecially ones where they may do some type of manipulation pre/post request then they would probably also be implementing the HttpPipelinePolicy trait and I don't know whether or not its a good idea to give them access to the client. Maybe it is im not sure. I will have to think about that one some more and some of the possible benefits/drawbacks.

It boils down to ownership issues. Because I want to carry the request between pipelines I need to bring the client with it.

@DevLazio Im also interested to know if you have ever look at Tower and the middleware use cases that their library brings. Both Reqwest and several other clients have added integrations for Tower.
They have middleware integrations that allow doing a very similar thing to what I described with the Http Pipeline Policies. And they even have retrty policies baked in. Although you still would have to define more policies for this specific use case but there is benefit to using Tower over a custom built one.
If you get a chance take a look at their main crate docs below and just read the first couple of paragraphs to see what I mean. I have looked at it a little bit and have tested doing an integration but didn't get too far into it.
Tower main crate docs: https://docs.rs/tower/latest/tower/index.html
Example doc of Tower Retry: https://docs.rs/tower/latest/tower/retry/trait.Policy.html

That was actually one of the first thing I look when I started the implementation because I use Axum with a custom middleware for a project. I don't think it's possible to use a Tower Middleware as-is inside graph-rs. So I looked into the implementation and found it way too complicated for what we needed.

That was actually one of the first thing I look when I started the implementation because I use Axum with a custom middleware for a project. I don't think it's possible to use a Tower Middleware as-is inside graph-rs. So I looked into the implementation and found it way too complicated for what we needed.

What was the issue with Tower? I mean I get that things can get complicated and its not always necessary to implement more complex features.
I'll try to explain my reasoning for looking at Tower and possibly working with that crate.
In the future I would like to have the ability to use different http request crates such as hyper instead of reqwest and others. And the logic to implement http policies and a pipline would obviously have to take into account the different types of http clients that could be used. So instead of duplicating the code and rewriting each part for each new client it would be easier to have a system in place that can work for any client regardless. Tower does this pretty decently well as far as I can tell and Tower integrations are often provided for these clients.
Really its about having an abstraction in place to handle these two features, pipline policies and multi http client support, in a way that works well and doesn't require overly complex (possibly somewhat complex), and problematic code.
Now how this is done is really up to how we write the code. We could potentially come up with an abstraction that does this that is simpler than Tower - but how much simpler I don't know. So my thinking is if we can use something like Tower than it would be beneficial because it solves both problems of needing http retry policies and being able to use different http clients.
So I am really just wondering if there are issues that you ran into attempting to use Tower or if the complexity of it was just something that turned you away from it quickly. I understand either way. Just trying to gather more information.

I started with your example but could not make it to compile without changing that.

It was needed to clone a struct containing a Box : https://stackoverflow.com/questions/30353462/how-to-clone-a-struct-storing-a-boxed-trait-object
I've since iterated on the design and I don't think it's needed anymore, will remove it.

Yeah I mean I didn't run the code myself. I wrote it quickly to give an example.
I think the point of the Arc was for the cloning. Either way you said that was not needed anymore but just wanted to mention that based on the article you linked.

It boils down to ownership issues. Because I want to carry the request between pipelines I need to bring the client with it.

I am not understanding why that would be needed though? The client is needed when the request is sent. The manipulation or creation of a policy shouldn't need the client. The policy will of course be used by the client at a later point in time but that doesn't mean its needed within this context. Maybe im failing to understand what your saying though?

That was actually one of the first thing I look when I started the implementation because I use Axum with a custom middleware for a project. I don't think it's possible to use a Tower Middleware as-is inside graph-rs. So I looked into the implementation and found it way too complicated for what we needed.

What was the issue with Tower? I mean I get that things can get complicated and its not always necessary to implement more complex features.
I'll try to explain my reasoning for looking at Tower and possibly working with that crate.
In the future I would like to have the ability to use different http request crates such as hyper instead of reqwest and others. And the logic to implement http policies and a pipline would obviously have to take into account the different types of http clients that could be used. So instead of duplicating the code and rewriting each part for each new client it would be easier to have a system in place that can work for any client regardless. Tower does this pretty decently well as far as I can tell and Tower integrations are often provided for these clients.
Really its about having an abstraction in place to handle these two features, pipline policies and multi http client support, in a way that works well and doesn't require overly complex (possibly somewhat complex), and problematic code.
Now how this is done is really up to how we write the code. We could potentially come up with an abstraction that does this that is simpler than Tower - but how much simpler I don't know. So my thinking is if we can use something like Tower than it would be beneficial because it solves both problems of needing http retry policies and being able to use different http clients.
So I am really just wondering if there are issues that you ran into attempting to use Tower or if the complexity of it was just something that turned you away from it quickly. I understand either way. Just trying to gather more information.

I did not think you wanted to integrate tower that much. I don't have the full picture of Graph-rs but it sounds like a quite big refactoring.
I did turn away from Tower quite quickly because it felt unnecessary for a relatively simple problem.

I think the point of the Arc was for the cloning. Either way you said that was not needed anymore but just wanted to mention that based on the article you linked. Was that the reason the method required the trait impl be wrapped in Arc to add it?

No idea.

It boils down to ownership issues. Because I want to carry the request between pipelines I need to bring the client with it.

I am not understanding why that would be needed though? The client is needed when the request is sent. The manipulation or creation of a policy shouldn't need the client. The policy will of course be used by the client at a later point in time but that doesn't mean its needed within this context. Maybe im failing to understand what your saying though?

Ugh. I just tried to instanciate the client in the transport policy only and yeah, it works fine. Can't remember why I thought I needed to bring the Client along. I do remember being annoyed having to do that though...

I did not think you wanted to integrate tower that much. I don't have the full picture of Graph-rs but it sounds like a quite big refactoring. I did turn away from Tower quite quickly because it felt unnecessary for a relatively simple problem.

I don't necessarily. I would rather just now have to implement it all by hand.

Ugh. I just tried to instanciate the client in the transport policy only and yeah, it works fine. Can't remember why I thought I needed to bring the Client along. I do remember being annoyed having to do that though...

Gotcha

I just pushed a rewrite of the pipeline to use Tower and it's services.
2 retries strategies are implemented : by number of attemps and waiting for the delay specified in the "Retry-After" header.
@sreeise Let me know what you think of this and if this sounds good I'll see if I can go further.

I just pushed a rewrite of the pipeline to use Tower and it's services. 2 retries strategies are implemented : by number of attemps and waiting for the delay specified in the "Retry-After" header.
@sreeise Let me know what you think of this and if this sounds good I'll see if I can go further.

Im just now seeing this. Been busy with a bunch of different things lately. Im gonna look at this soon within a few days to a week. This sounds awesome though.

@DevLazio
This is looking good! Thanks for continuing to work on this. Do you want to write some examples of its use and put them in the examples folder?

Sure !
Added a few lines of documentation for the new settings and completed the "client_configuration" example. Usage of the new settings is rather straigthforward I believe.


Replace old PNG build badge with SVG version

We've released those a while back: http://shields.io/

:+1:


Update LackLusterLabs-13.1.ckan

update links

Can you explain the reasoning behind this? The download link you have put is a completely different version number of a different mod. LLL-Continued is not LackLusterLabs, it's a replacement..

@politas The download should not be changed. These are two different versions of two different mods. The download listed is the correct 13.1 version of LackLusterLabs that the file specifies as the version. It appears that @ghost wants the newest version of LLL to be installed as LackLusterLabs, but this should not be done. The way to do this would be to create a new .netkan file in the NetKAN repository with all of the metadata updated for the new version. However, CKAN policy is that any such "Redux" or "Continued" mods (forks of an original mod, with a permissive license, that are unaffiliated with the original author) must be indexed under a different identifier.
@ghost, if you want to get that version of LLL indexed, please read up on the CKAN documentation so you can get a feel for how things work. Then, you can submit a pull request to the KSP-CKAN/NetKAN repository with your new changes. 🙂


feat: Add support for symfony/event-dispatcher-contracts ^3.1

New version of symfony/event-dispatcher-contracts since 07/2021

👋 please update your branch to make sure all tests pass


Looped Pulse Animation Hack - is there a better approach?

I've created a pulsing circle svg element using react-motion. Basically I want a circle to scale larger and fade to nothing, and repeat indefinitely. React-motion spring tends to create the reverse animation as well which I'm trying to eliminate.
I can get it to repeat indefinitely by setting damping = 0 and I don't wan't the reverse animation to happen - that is is if the spring goes from 0 to 1, I don't want it to animate back from 1 to 0. So I've basically made a hack to invert the reverse interpolation so instead of transitioning like 0->1, 1->0, 0->1, 1->0 it does 0->1, 0->1, 0->1, 0->1. It just figures out if the spring is transitioning up or down, and if it's transitioning down it inverts it.
It feels a bit hacky. Is there a better way to approach this? Maybe spring and react-motion isn't the best solution for this type of animation?
import React from 'react';
import {Motion, spring} from 'react-motion';

class Node extends React.Component {

  constructor(props) {
    super(props);
  }

  render() {
    var springDirectionUp = true; //keep track if spring is going up or down
    return (
      <g>
        <circle cx={this.props.xPos} cy={this.props.yPos} r={this.props.radius} fill={#FFC700} />
          <Motion  defaultStyle={{s:0}} style={{s: spring(.5, {stiffness: 5, damping: 0})}}>
            {({s}) => {
              if (s <= 0.01) { // when reaches trough
                springDirectionUp = true;
              } else if (s >= .99) { // when reaches peak
                springDirectionUp = false;
              }
              let v = springDirectionUp ? s : (1-s); //go from 0->1 twice in a single cycle, ie. replaces the returning 1->0 with 0->1
              return (
                <circle className="pulse" cx={this.props.xPos} cy={this.props.yPos} r={this.props.radius+this.props.radius*v} fill={#FFC700} style={{opacity: 0.75-v*0.75}}/>
              );
            }}
          </Motion>
      </g>
    );
  }

}

export default Node;

making loop animations is something I've struggled I'd hope to see a better way to do it

you can use onRest to know when the animation is idle, adds a bit of state (demo).
class Node extends React.Component {
  constructor(props) {
    super(props)
    this.state = {
      isResting: false,
    }
    this.handleRest = this.handleRest.bind(this)
  }

  handleRest() {
    this.setState({
      isResting: true,
    }, () => {
      requestAnimationFrame(() => {
        this.setState({
          isResting: false,
        })
      })
    })
  }

  render() {
    return (
      <g>
        <circle
          cx={this.props.xPos}
          cy={this.props.yPos}
          r={this.props.radius}
          fill={"#FFC700"}
        />
        <ReactMotion.Motion
          defaultStyle={{ s: 0 }}
          style={{
            s: this.state.isResting ? 0 : ReactMotion.spring(1, {stiffness: 130, damping: 26})
          }}
          onRest={this.handleRest}
        >
          {({ s }) =>
              <circle
                className="pulse"
                cx={this.props.xPos}
                cy={this.props.yPos}
                r={this.props.radius + this.props.radius * s}
                fill={"#FFC700"}
                style={{
                  opacity: 0.75 - s * 0.75,
                }}
              />
          }
        </ReactMotion.Motion>
      </g>
    );
  }
}

ReactDOM.render(
  <svg width={400} height={400}>
    <Node
      xPos={200}
      yPos={200}
      radius={100}
    />
  </svg>,
  document.getElementById("App")
)

See this simple Motion wrapper to do Looping and Pulsing animations (check readme/examples)
https://www.npmjs.com/package/react-motion-loop


not keeping changes

i just want to know if it's me, or the app is not keeping balance and transfer changes after closing or updating browser. i can see changes when hitting the logout button, but if i reload the site it won't keep changes. is this normal behavior?

No, it's not meant to save any changes but it sounds like a great addition. This project isn't based on real accounts and everything is hardcoded, or any database for the accounts but of course, it is better to have a more realistic implementation.


is there workability between Sonoff RF Bridge and HA-bridge?

Hi
I'm trying to figure out if there is a way to get a flashed (or un-flashed) Sonoff RF Bridge and HA-bridge to work together? Has anybody achieved this?
Ideally the operation would be... RF door sensor triggers the Sonoff RF bridge, which would then (via wifi) send a command to HA-Bridge which would turn a light on.
Thanks

Try some homeautomation software like Homeseer, or some opensource. You can do then http requests to turn light on/off
Walter

Op 19 jun. 2020 om 18:59 heeft Matttribal<EMAIL_ADDRESS>het volgende geschreven:

Hi
I'm trying to figure out if there is a way to get a flashed (or un-flashed) Sonoff RF Bridge and HA-bridge to work together? Has anybody achieved this?
Ideally the operation would be... RF door sensor triggers the Sonoff RF bridge, which would then (via wifi) send a command to HA-Bridge which would turn a light on.
Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Thanks Walter, but im hoping not to run another software as i already run my home using ha-bridge so am hoping there is a way to integrate it into there.
I think a flashed Sonoff RF Bridge can send out MQTT payload. So maybe there is a way to directly trigger the lights on ha-bridge this way?

There are several protocols to do that in Ha-bridge. I’m using http Json for connecting with my Homeseer. Ha-bridge is flexible with that. You you can check which protocol sonoff is using in the docs.
Regards, Walter

Op 19 jun. 2020 om 19:36 heeft Matttribal<EMAIL_ADDRESS>het volgende geschreven:

Thanks Walter, but im hoping not to run another software as i already run my home using ha-bridge so am hoping there is a way to integrate it into there.
I think a flashed Sonoff RF Bridge can send out MQTT payload. So maybe there is a way to directly trigger the lights on ha-bridge this way?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

I need a way to trigger HA-bridge.
What would be the http command for a device to trigger something in HA-bridge?? I assume you trigger by ID?
Or does it have to be done with Json? If so how are you doing this?
Thanks

For Homeseer im using this:
Kitchenlight ON:
http://<IP_ADDRESS>:8083/JSON?request=controldevicebyvalue&ref=579&value=255
Kitchenlight OFF:
http://<IP_ADDRESS>:8083/JSON?request=controldevicebyvalue&ref=579&value=0

Thanks Walter, but that looks like commands that are sent FROM ha-bridge TO other devices.
That's not what I'm looking for.
I need a way to trigger HA-bridge.
@bwssytems
Does HA-bridge accept any simple commands that I can put into another device that will trigger certain IDs in HA-bridge? Or to be used in a GUI button press.
I'm hoping for a simple HTTP request, something like http://<IP_ADDRESS>:80/api/lights/101/state/true
If so, are there multiple ways? What is the easiest way?
Thank you

It requires a PUT, works just like Phillips Hue, see  here: https://github.com/bwssytems/ha-bridge#set-light-state

This is currently the only way to trigger an HA-Bridge device, as it emulated the Phillips Hue API.
Username can be anything you want, HA-Bridge configures all usernames automatically.  I use a single letter for simplicity.
Yes you can perform a PUT with a configured device in HA-Bridge to trigger another configured device, change the "Http Verb" to PUT.

Thanks!
I'm not sure I'm getting the full command correct as its not working.
I tried multiple things in the HTTP BODY but no job.
See attached, any pointers?

Thanks

@Matttribal Putting that into another ha-bridge device. I believe you are asking to put that request into the sonoff system, correct?

@bwssytems yes. But I’m guessing if an HTTP command does exist to trigger a HA-bridge device ID, that I can use it on the SONOFF or from within HA-Bridge (as per the the pic in my last post)?
Am I along the right lines with that command pictured in my last post?
Thanks.

As I mentioned, it is in the readme at https://github.com/bwssytems/ha-bridge#create-user

@audiofreak9 please could you let me know where I'm going wrong with this PUT command?
I have created a user as per @bwssytems last comments but it still doesn't work.
I have tried multiple things but I always get log issues
INFO Tracestate: Decode Json for url items: [{"item":"http://<IP_ADDRESS>/api/dea7635a59aa44e29be5b40afd9ecd90/lights/102/state/","type":"httpDevice","httpVerb":"PUT","httpBody":""on": true"}]
WARN HTTP response code was not an expected successful response of between 200 - 299, the code was: HTTP/1.1 404 Not Found with the content of <<<404 Not found>>>

on another note do you know if "Bridge Reinitialize" can be triggered from a PUT command?
Many thanks!!

@audiofreak9 please could you let me know where I'm going wrong with this PUT command?
I have created a user as per @bwssytems last comments but it still doesn't work.
I have tried multiple things but I always get log issues
INFO Tracestate: Decode Json for url items: [{"item":"http://<IP_ADDRESS>/api/dea7635a59aa44e29be5b40afd9ecd90/lights/102/state/","type":"httpDevice","httpVerb":"PUT","httpBody":""on": true"}]
WARN HTTP response code was not an expected successful response of between 200 - 299, the code was: HTTP/1.1 404 Not Found with the content of <<<404 Not found>>>

on another note do you know if "Bridge Reinitialize" can be triggered from a PUT command?
Many thanks!!

Looking quickly you need to set the Content Type, probably to multipart/form-data.

Looking quickly you need to set the Content Type, probably to multipart/form-data.

Thanks, but unfortunately not... unless I'm missing some sort of syntax. I'm beginning to think the PUT feature doesn't work

Thanks, but unfortunately not... unless I'm missing some sort of syntax. I'm beginning to think the PUT feature doesn't work


Dynamic User Snippect

I want to add user snippets in this way right from extension.ts
const launguages = ["python", "java", "node", "cpp", "bash"];

	let codePathsPromise = Promise.all(launguages.map(launguage => {
		return shellComand(`which ${launguage}`, {
			shell:"C:\\Program Files\\Git\\bin\\bash"
		});
	}));

	codePathsPromise.then((codePath) => {
		codePath.map((codePath, index) => {
			// insert a user snippet with prefix ${launguage[index]} and body ${codePath}
		});
	});

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.
Happy Coding!

as we have text snippets which are present in json file which can be triggered globally by a matching prefix
i just want to have that functionality to introduce variables  inside it
example
vscode.workspace.addSnippet(`{
  "prefix": "System Python Path",
 "body":[
    ${pythonPath} // which is computed by typescript
 ]
})`

Thanks for clarifying. This is to some extends https://github.com/microsoft/vscode/issues/10561 but also something that you achieve by implementing an extension

This is a duplicate. Unfortunately, I don't recall the exact issue number nor its title :flushed: Anyways, searching for issues with the same labels will likely help you :point_right:
https://github.com/microsoft/vscode/issues?utf8=✓&q=is%3Aopen+label%3Asnippets


Updated documentation with solution to tf error

Should this be included for all examples? Since all dockerfiles use the python image python:3.8.9 with unspecified platform, I suppose the error could occur there as well

No problem. I'm not sure if this could occur with pytorch.


Implementation of CWN

Initial commit of CWN implementation for the ICML 2023 Topological Deep Learning Challenge

@michaelschaub @ffl096 Hello! Thank you for an opportunity to take part in the Topological Deep Learning Challenge! Our team is implementing CWNLayer, and we would appreciate your help since we have been facing some difficulties.

The message passing scheme involves messages and aggregations in a general form and covers a broad range of functions. We are not sure what is the recommended way to implement them. In particular, should we allow users to pass the message and aggregation methods as arguments into CWNLayer?
What is the recommended way to deal with several kinds of messages in one layer? In your tutorials, it is handled by instantiating Conv class for each message. However, CWN involves general messages, so Conv class is not suitable for us. Exactly the same problem applies to the MessagePassing class — the API tells "This class should not be instantiated directly, but rather inherited through subclasses that effectively define a message passing function." It means that we can not instantiate this class inside our layer. At the same time, we can not inherit our CWNLayer from MessagePassing because it handles only one type of message.
More specifically, the message $m_{y \rightarrow {z} \rightarrow x}^{(r \rightarrow r' \rightarrow r)} = M_{\mathcal{L}\uparrow}(h_x^{t,(r)}, h_y^{t,(r)}, h_z^{t,(r')})$ has three inputs. But the forward method of MessagePassing takes only x_source and x_target. Hence, it is impossible to implement a more general type of message passing using the existing API. Could you change it somehow so that it provides more freedom in which functions it can model and what objects it can operate on? We are ready to take part in solving this problem.

Aggregation of multiple targets to a single source can be realized as a consecutive application of a merge nodes.
Suppose that you have a target signal x_t that you want to update given multiple neighborhood functions (matrices). The sources are specified using the matrix B1,...,Bk.  All matrices have target same as x_t and have source signals y_1,...,y_k respectively.
Now the usual message passing can be used to aggregate messages for each individual source y_l to x_t,
So now you have messages that can have been sent from y_l to x_t using the class https://github.com/pyt-team/TopoModelX/blob/dev/topomodelx/nn/message_passing.py  for every 0<l<=k.
The merge node (example implemented here : https://github.com/pyt-team/TopoModelX/blob/dev/topomodelx/nn/cxin_conv.py ) can be then use to aggregate messages obtained using different sources . Please let me know if that makes sense.

Aggregation of multiple targets to a single source can be realized as a consecutive application of a merge nodes.
Suppose that you have a target signal x_t that you want to update given multiple neighborhood functions (matrices). The sources are specified using the matrix B1,...,Bk. All matrices have target same as x_t and have source signals y_1,...,y_k respectively.
Now the usual message passing can be used to aggregate messages for each individual source y_l to x_t,
So now you have messages that can have been sent from y_l to x_t using the class https://github.com/pyt-team/TopoModelX/blob/dev/topomodelx/nn/message_passing.py for every 0<l<=k.
The merge node (example implemented here : https://github.com/pyt-team/TopoModelX/blob/dev/topomodelx/nn/cxin_conv.py ) can be then use to aggregate messages obtained using different sources . Please let me know if that makes sense.

merge nodes are introduced here :
https://arxiv.org/pdf/2206.00606.pdf
implementation in the special case is here :
https://github.com/pyt-team/TopoModelX/blob/dev/topomodelx/nn/cxin_conv.py
note that the above merge implementation can merge two targets to a single source, the general function you are looking for can be realized with this function :
https://github.com/pyt-team/TopoModelX/blob/4bb096c947d68c7e702a6675e366f5ceba3df038/topomodelx/nn/cxin_conv.py#L299

@mhajij Thanks for your response! As we understand, your comment refers to the problem of aggregating various messages from different sources into one target domain. However, none of our questions is related to this problem.

In fact, the first question is about a too general form of messages in CWN, so we are not sure if we should implement a particular variant of CWN (such as CIN, which has been proposed by the authors of CWN) or allow users to pass their custom message functions via arguments in the __init__ method of our class.

As for the second question, here we explain that, due to the aforementioned problem of too general messages, MessagePassing is the only class that is suitable for constructing the second message $m_{y \rightarrow x}^{(r'' \rightarrow r)} = M_{\mathcal{B}}(h_x^{t,(r)}, h_y^{t,(r'')})$ of CWN. However, the existing API says that this class should not be instantiated directly, so it is not clear how we should instantiate this type of message in our implementation. However, we have found a note on the site of challenge saying that in the case that {Name of model}Layer requires further manipulation of the computational primitives in topomodelx/base, a Pull Request may include modifications to the files in topomodelx/base or new files in topomodelx/base. This note should resolve our second question.

Finally, in the third question, we try to point at the problem that none of the message passing classes in the existing API supports the processing of intermediate representations h_z on a par with target representations h_x and source representations h_y, which is required in the first message $m_{y \rightarrow {z} \rightarrow x}^{(r \rightarrow r' \rightarrow r)} = M_{\mathcal{L}\uparrow}(h_x^{t,(r)}, h_y^{t,(r)}, h_z^{t,(r')})$ of CWN. However, this question also might be resolved for the same reason as the previous one, since we may inherit from MessagePassing in a distinct file and modify the message method of our class to make it more flexible.

Thus, our only question is the first one — who is responsible for the implementation of a particular message function? We may consider a solution when users properly define their message functions and pass them into the arguments of __init__ method, while we only use these functions in our implementation of message passing. Of course, we should create some default message functions (e.g., based on CIN) so that users can pass nothing to CWNLayer. Is this solution acceptable?

@mhajij Thanks for your response! As we understand, your comment refers to the problem of aggregating various messages from different sources into one target domain. However, none of our questions is related to this problem.

In fact, the first question is about a too general form of messages in CWN, so we are not sure if we should implement a particular variant of CWN (such as CIN, which has been proposed by the authors of CWN) or allow users to pass their custom message functions via arguments in the __init__ method of our class.

You are right, but in order to implement that, you do need my answer above. I tried to implement the merge node here 👍
https://github.com/pyt-team/TopoModelX/blob/dev/topomodelx/nn/merge.py
Effectively this the same as sending messages as CWN/CXN. See Theorem 6.2 :  https://arxiv.org/pdf/2206.00606.pdf
In summary : merge node can realize the general message passing paradigm.
You can think about a merge node as sending the node x_target receives messages from two different places x_source1 and x_source2. The way to send the message is via the maps G1 and G2 in the implementation above. The linear functions are needed in order to make the dimensionality match when concatenating the messages on the target.

As for the second question, here we explain that, due to the aforementioned problem of too general messages, MessagePassing is the only class that is suitable for constructing the second message my→x(r″→r)=MB(hxt,(r),hyt,(r″)) of CWN. However, the existing API says that this class should not be instantiated directly, so it is not clear how we should instantiate this type of message in our implementation. We have found a note on the site of challenge saying that in the case that {Name of model}Layer requires further manipulation of the computational primitives in topomodelx/base, a Pull Request may include modifications to the files in topomodelx/base or new files in topomodelx/base. This note should resolve our second question.

The MessagePassing class is still not the most general form that we need it to be. Feel free to adjust it in your implemenation as given in the instructions.

Finally, in the third question, we try to point at the problem that none of the message passing classes in the existing API supports the processing of intermediate representations h_z on a par with target representations h_x and source representations h_y, which is required in the first message my→z→x(r→r′→r)=ML↑(hxt,(r),hyt,(r),hzt,(r′)) of CWN. However, this question also might be resolved for the same reason as the previous one, since we may inherit from MessagePassing in a distinct file and modify the message method of our class to make it more flexible.

Sounds good.

Thus, our only question is the first one — who is responsible for the implementation of a particular message function? We may consider a solution when users properly define their message functions and pass them into the arguments of __init__ method, while we only use these functions in our implementation of message passing. Of course, we should create some default message functions (e.g., based on CIN) so that users can pass nothing to CWNLayer. Is this solution acceptable?

The only reason I pointed to CXIN implementation is to show you an example of how to merge signals from two different sources which is equivalent to message passing as described in CWN (in the special case of CIN).
The above merge class can be used along with the HigherORderMessagePassing to implement a general message passing function.
The merge node is in a sense the dual of a message passing as described in CWN : in the message passing paradim you think about the source x and other neighbors are sending thier signals to that source. This is an update rule.
In the merge node it is easier to think about it as a functional rule : start where you want to send the message from (the neighbors of the source x) say you have two targets : these targers send thier messages via two operators G1 and G2.  Please read 6.3 : https://arxiv.org/pdf/2206.00606.pdf

Hello @gvbazhenov  ! Thank you for your submission. As we near the end of the challenge, I am collecting participant info for the purpose of selecting and announcing winners. Please email me (or have one member of your team email me) at<EMAIL_ADDRESS>so I can share access to the voting form. In your email, please include:

your first and last name (as well as any other team members)
the title of the model you implemented
the domain of the model you implemented
your pull request number (#115)

Before July 13, make sure that your submission respects all Submission Requirements laid out on the challenge page. Any submission that fails to meet this criteria will be automatically disqualified.

@mhajij Thank you very much for this discussion! We have managed to implement the CWN layer and hopefully made it clear to use and flexible to extend for user needs. Our PR is now ready for review.


Swift 2.2 warning

When compiling in carthage, I am getting this warning message:
SkyFloatingLabelTextField/Sources/SkyFloatingLabelTextField.swift:271:38: warning: use '#selector' instead of explicitly constructing a 'Selector'

This is a 2.3/2.2 issue I believe? It will be fixed in the next version since #69 has been merged now.


Publish testkit for scala.js

At the moment there is no testkit for scala.js. As a temporary workaround I just copypasted classes from testkit project to my scala.js project, but it would be convenient to have testkit cross-published.

Thank you for reporting! This should be doable. Testkit uses some JVM specific code to download and unzip. However, it should be possible to move that to the jvm/ directory. Would you be interested in contributing this fix @LMnet ?

I can try, but I'm playing with scalameta only with my pet project in free time, so I can't promise anything.
About implementation: as far as I understand, AnyDiff, Observation, Phase, StructurallyEqual and SyntaxAnalysis could be cross-published. Corpus, CorpusFile, FileOps should be moved to the jvm-specific folder. Am I right?

That sounds about right @LMnet .

@olafurpg @LMnet Guys, is this ticket still relevant?

@xeno-by I'm not sure I will have time for this issue in the near future.
About relevance - in my project, I still have a copy-pasted testkit. I'm not sure how many scala.js projects uses scalameta, but overall it looks like this task is pretty useful.

This is a several minute effort to separate out the JVM-only parts in to the jvm/ directory so I propose we keep this issue and I will complete it once I have some time to kill


Use PR if direct commit is not allowed

If Update AL-Go System Files is running on a schedule, use a PR if PRs are mandatory due to branch rules.

Also name the PR with the templateSha, and check whether a PR with the same templateSha already exists.
If a PR exists, the workflow will issue a warning:

Fixes #1084

Not a big fan of the separate tasks as there will be a lot of overhead if all steps run (e.g. checking out AL-Go repo, checking for updates, etc.). I think CheckForUpdates action should handle it in one go.

Not sure I understand what you mean by overhead - there are three steps for running upgrade:

runs if the workflow is invoked manually
runs if the workflow is invoked by a schedule (same behavior as before this PR)
runs if the workflow is invoked by a schedule and 2. fails (instead of just failing really)

Not a big fan of the separate tasks as there will be a lot of overhead if all steps run (e.g. checking out AL-Go repo, checking for updates, etc.). I think CheckForUpdates action should handle it in one go.

Not sure I understand what you mean by overhead - there are three steps for running upgrade:

runs if the workflow is invoked manually
runs if the workflow is invoked by a schedule (same behavior as before this PR)
runs if the workflow is invoked by a schedule and 2. fails (instead of just failing really)

If step 2. fails then step 3. will have to determine again whether there are updates (download the template, read the settings, etc.), when everything is already there.
I understand Alexander also meant something like the following:
try {
    push
}
catch {
    # pushing failed, trying PR
    create branch
    create PR
}

I understand Alexander also meant something like the following:
try {
    push
}
catch {
    # pushing failed, trying PR
    create branch
    create PR
}

I will see if this can be done without any large refactoring


Feature to add auxiliary authorization header

We have auxiliary authorization header support for Java.
Azure/azure-libraries-for-java#884
Let's also add the support in JS to keep them consistent.

@xiangyan99 you can add policy instead of change the sdk. For example: client.pipeline.addPolicy.
The sdk is generated automatically, and we don't allow to change it manaully
thanks

Yes. This request is to achieve language consistency. Java already supports the feature and we also created requests for Python and .net.

@xiangyan99 Which version of sdk do you use? For previous sdk, we have deprecated it. For latest sdk, we don't allow manual change and I think there is a way to achieve the goal. About the PR to java sdk, I think it's previous java sdk, and the latest java sdk in https://github.com/Azure/azure-sdk-for-java. I don't think the change is included in latest java sdk. thanks

Took offline.

close it as being taken offline.

@qiaozha The issue is not solved yet. We took offline to clarify the ownership.

@xiangyan99 have you synced with @sarangan12 ? If yes, could you create a new issue in https://github.com/Azure/autorest.typescript/issues to track this feture request? Thanks

Yes. I have synched up with @xiangyan99. The gist of the conversation is:

We need to create a new Policy (name undecided yet) in the core-client package. This Policy will be very similar to the bearerTokenAuthenticationPolicy with some changes on the name of the header to use.
Once the Policy is created and a new core-client version is released, then we need to make some changes in the generator. i.e. we need to add the policy if we find packages that satisfy certain criteria (I hope we are going to add this policy for all management packages who have a need for this policy which should be determined with a new flag. @xiangyan99 Please correct me if I am wrong)

Next Steps:

@xiangyan99 will work with other SDKs who have already implemented this policy and provide us the details.
I will be creating the new policy in the core-client and release it.
Then, I will be opening an work item in SDK Generator repo.

For the core-client work, this issue will be used to track.
@dw511214992 I am moving this issue to my plate.

This is to track the work to add the policy and update code generator across languages.
We will start the work from other languages.

@sarangan12 how is the process for this issue ? Are you working on it already ? if no, we are glad to help to work on it. :)

@qiaozha No. I have not started working on it. Per discussion with @xiangyan99 he would coordinate with other languages (Python specifically) and once the work is completed there,we could do the same for JS.

@xiangyan99 any updates on other languages support ? when will we start the support in JS ?

Close as the pr is merged: https://github.com/Azure/azure-sdk-for-js/pull/25270


[Darwin] Enable taking assertion on MTRDeviceController

Added ability to take assertion on MTRDeviceController to keep it running until all assertions are removed
A request to shutdown will take place only if there are no assertions are present

Fast-tracking platform-specific fix with platform owner review.


nufraw: expose gimp plugin, remove ufraw

Motivation for this change
https://github.com/NixOS/nixpkgs/issues/97946
commit 4e4c61d46e25c44cd6fc6ba2fbf5676dd2e03705
Author: Florian Klink<EMAIL_ADDRESS>Date:   Mon Jan 11 02:04:20 2021 +0100

    ufraw: remove

    This is broken and unmaintained. nufraw seems to be a drop-in
    alternative.

    Closes https://github.com/NixOS/nixpkgs/issues/97946.

commit 07e6b3bdb3ae32ec9a82c728cb25dffd75cf1736
Author: Florian Klink<EMAIL_ADDRESS>Date:   Mon Jan 11 02:03:35 2021 +0100

    gimpPlugins.nufraw: expose, remove broken gimpPlugins.ufraw

commit f09dc88cc727a83016c81f243179ff06e7878785
Author: Florian Klink<EMAIL_ADDRESS>Date:   Mon Jan 11 02:02:55 2021 +0100

    nufraw: provide gimp plugin

    This introduces a new "gimpPlugin" output, similar to how it was done in
    ufraw.

I didn't run the nufraw plugin, but it builds fine.
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Tried this out, it fails to load several different RAW files (Canon, Nikon, Panasonic).
/nix/store/3mr77qcnyarp9439xz87jfx0v691f9i5-gimp-with-plugins-2.10.22/lib/gimp/2.0/plug-ins/nufraw-gimp: fatal error: Segmentation fault

Loading directly, outside of GIMP, also fails.
[nix-shell:~/Documents/]$ nufraw ~/Pictures/P1000252.RW2
Segmentation fault (core dumped)

GIMP will default to using darktable if that's installed (I had to comment it out temporarily in my configuration.nix to test nufraw), and darktable works flawlessly, so I wonder if it's even worth exposing nufraw as a GIMP plugin. I think RawTherapee will also be used by GIMP for RAW.

Tried this out, it fails to load several different RAW files (Canon, Nikon, Panasonic).
/nix/store/3mr77qcnyarp9439xz87jfx0v691f9i5-gimp-with-plugins-2.10.22/lib/gimp/2.0/plug-ins/nufraw-gimp: fatal error: Segmentation fault

Loading directly, outside of GIMP, also fails.
[nix-shell:~/Documents/]$ nufraw ~/Pictures/P1000252.RW2
Segmentation fault (core dumped)

GIMP will default to using darktable if that's installed (I had to comment it out temporarily in my configuration.nix to test nufraw), and darktable works flawlessly, so I wonder if it's even worth exposing nufraw as a GIMP plugin. I think RawTherapee will also be used by GIMP for RAW.

I guess you're right. The main functionality seems to fail. On only tested with:
nufraw-batch --size 10 --out-type=png --noexif --output=preview.png --embedded-image P1250767.RW2
That works unless you're removing that --embedded-image flag. I guess when it's processing the raw footage the segmentation fault occurs.

I guess you're right. The main functionality seems to fail. On only tested with:
nufraw-batch --size 10 --out-type=png --noexif --output=preview.png --embedded-image P1250767.RW2
That works unless you're removing that --embedded-image flag. I guess when it's processing the raw footage the segmentation fault occurs.

So nufraw is currently entirely broken too?
In that case, I could trim that PR down, not include any nufraw changes and direct users to darktable?

So nufraw is currently entirely broken too?
In that case, I could trim that PR down, not include any nufraw changes and direct users to darktable?

@flokli Yes I think you should not link anything against nufraw for now.

@flokli Yes I think you should not link anything against nufraw for now.

I could get rid of the segmentation fault by applying the archlinux patch: https://github.com/asbachb/nixpkgs/tree/bugfix/nufraw
nufraw-batch now does not crash with an segfault but it creates just black images.

I could get rid of the segmentation fault by applying the archlinux patch: https://github.com/asbachb/nixpkgs/tree/bugfix/nufraw
nufraw-batch now does not crash with an segfault but it creates just black images.

So lensfun seems somehow broken or incompatible. When adding flag --lensfun=none the preview is generated as expected.

So lensfun seems somehow broken or incompatible. When adding flag --lensfun=none the preview is generated as expected.

I pushed a new version, now recommending Darktable, and not adding the nufraw changes.
The commit message still links to this PR, so someone interested in getting nufraw to work can pick it up.

I pushed a new version, now recommending Darktable, and not adding the nufraw changes.
The commit message still links to this PR, so someone interested in getting nufraw to work can pick it up.

Result of nixpkgs-review pr 108993 run on x86_64-linux 1

Result of nixpkgs-review pr 108993 run on x86_64-linux 1


[WIP]Feat: arbitrum one integration

TODO:

[ ] Implementation:

[X] ArbWorldID

[X] receiveRoot()
[X] setRootHistoryExpiry()

[ ] ArbStateBridge

[X] propagateRoot()
[ ] transferOwnershipArb()
[X] setRootHistoryExpiry()

[ ] Tests:

[ ] Finish all ArbWorldID tests
[ ] Finish all ArbStateBridge tests

[ ] Misc:

[ ] Decide on setter functions
[ ] Clean natspec comments

Closing this as the roadmap seems about using storage proof to integrate other networks, but finish this for fun here: https://github.com/haythemsellami/world-id-state-arb-bridge


Remove the old publish funtionality

@cruhland @larioj We should remove the /package/publish and /package/storage/repo endpoint before releasing. This PR does that.

LGTM


Number of training steps

Thanks for your great work! Can you please specify the number of training steps in first and second stage training mentioned in the paper?

50k per phase.

Thanks! Could you also please tell the batchsize and number of objects in the dataset?

256, and the size of Objaverse.

Hi, I was wondering did you ever try training the model in single stage?

The generalization was worse in an experimental, unreleased version of the model. I am not 100% sure if this is the same case for the v1.2 architecture.

May I also know the SNR gamma you used for Min SNR strategy? Thanks again :pray:

It is the default or paper value, perhaps 5.0


Various minor bug fixes and improvements.

These commits fix minor bugs and add improvements to the Leap system.

Leap's code is setup to read certain manifest values, it doesn't however include them all. such "server_scripts" rather than "server_script". I wasn't sure if this was designed in this manner for a reason so rather than adding the additional entries hard defined, I added them into a configurable format. I'm also using it as a workaround for globbing not being detected.

server_script also includes server_scripts, probably below server_scripts actually gets converted to multiple server_script calls.
The only thing to remove to the pull request is the directories hardly set in the config, since they don't make too much sense after multi globbing is fixed

It would appear that the manifest issue stemmed from the globbing issue, which has now been resolved.

Ok strange, can i merge the pull request or you want to edit anything else?

Not to my knowledge, I'll open further pull requests if required.

now should be better, i will merge it when im at home


Add flag to not create a powershell window on Windows

When I use your package in Tauri.app. It automatically opens a powershell window to run the command.
So I added an option to prevent it from opening additional windows on Windows.
Can you help me check if this is possible?
Thank you!

Hi, I don't have Windows, but I'll try running this code through Github Actions and see if it breaks the tests.

Thanks you!

Hello, I just tested your crate to build a license system. But having a terminal window showing up a fraction of second will not reassure our users. Can we merge this pull request please ?
Thank you very much for your implementation of machine id crate !

Hello, I just tested your crate to build a license system. But having a terminal window showing up a fraction of second will not reassure our users. Can we merge this pull request please ?
Thank you very much for your implementation of machine id crate !

Hi, have you checked to see if this PR is working?
I just don't have a chance to test it as I use mac.

Hey ! Yep I tested it on Windows 11 and no powershell/terminal window poping-up. 👍
I'm using this branch right now.


Super Resolution Using cppflow 2

Hello,
First of all, I really appreciate your work that enables to use Tensorflow in C++ without bazel.
I am using cppflow 2 to use the pre-trained super resolution model and output the SR images.
Below is the code that I made for it:
`#include
#include
#include <opencv2/opencv.hpp>
#include
#include
#include "../../include/cppflow/cppflow.h"
int main() {
auto input = cppflow::decode_jpeg(cppflow::read_file(std::string("small.jpg")));
input = cppflow::cast(input, TF_UINT8, TF_FLOAT);
input = cppflow::expand_dims(input, 0);

auto shape = input.shape().get_data<int>(); //num_data, height, width, num_channel;
int num_row = shape[1];
int num_col = shape[2];

cppflow::model model("test_model");
auto output = model(input);
//output = cppflow::cast(output, TF_FLOAT, TF_UINT8);

auto data = output.get_data<float>();
std::cout << data.size() << std::endl;

std::vector<uint8_t> sr_img;
sr_img.assign(data.begin(), data.end());

std::cout << sr_img.size()*sizeof(uint8_t) << std::endl;

cv::Mat save = cv::Mat(num_row*4, num_col*4, CV_8UC3);

memcpy(save.data, sr_img.data(), sr_img.size()*sizeof(uint8_t));

//cv::cvtColor(save, save, cv::COLOR_RGB2BGR);
cv::imwrite("result.png", save);
//unsigned char* result = data.data();
//stbi_write_png("sky.png", shape[2]*4, shape[1]*4, shape[3], result, shape[2]*4 * shape[3]);

return 0;

}`
To load the input image, I used 'cppflow:decode_jpeg' function as in 'main.cpp' of efficientnet directory.
After that, I load the pretrained SR model which was generated by this link, and ran the super resolution.
The output from cppflow 2 was saved using opencv image write function (cv2::imwrite).
However, the output from python code and the one from cppflow 2 are different!
cppflow result
python3 result
I checked my SR model several times, but I don't think the model causes such inconsistency since it produces the same results in python.
Could anyone give me some guidance on why such difference happens?
Thanks in advance.

Can you print out the elements of input and output tensors and compare them with the python input and output?

As you suggested, I first checked whether the elements of input tensors are the same as those in python.
To cut straight to the conclusion, IT IS DIFFERENT.
Below is the input tensor created by "cppflow::decode_jpeg(cppflow::read_file(std::string("small.jpg")));"
(tensor: shape=[270 480 3], data=
[[[26 16 14]
[19 8 4]
[39 21 17]
...
[96 54 30]
[74 34 9]
[60 23 0]]
[[23 15 12]
[19 10 5]
[21 6 0]
...
[48 10 0]
[101 65 43]
[113 79 54]]
[[10 10 2]
[19 17 5]
[21 13 0]
...
[40 9 0]
[54 22 7]
[70 41 25]]
...
[[20 20 22]
[19 19 21]
[19 19 21]
...
[21 21 23]
[24 24 26]
[21 21 23]]
[[18 18 20]
[21 21 23]
[19 19 21]
...
[19 19 21]
[22 22 24]
[21 21 23]]
[[18 18 20]
[23 23 25]
[19 19 21]
...
[19 19 21]
[24 24 26]
[25 25 27]]])
And this time, it is the input tensor from python (and I also tested in opencv c++, and it produced the same result):
array([[[ 20,  21,  31],
[ 10,  12,  23],
[ 20,  22,  40],
...,
[ 32,  54,  96],
[ 12,  34,  76],
[  0,  22,  62]],
   [[ 17,  19,  27],
    [ 10,  12,  22],
    [  4,   9,  24],
    ...,
    [  0,   9,  50],
    [ 45,  64, 102],
    [ 57,  79, 115]],

   [[  7,  12,  13],
    [ 11,  20,  24],
    [  5,  15,  25],
    ...,
    [  0,   9,  42],
    [ 10,  23,  55],
    [ 30,  43,  75]],

   ...,

   [[ 23,  21,  21],
    [ 22,  20,  20],
    [ 21,  19,  19],
    ...,
    [ 24,  22,  22],
    [ 26,  24,  24],
    [ 23,  21,  21]],

   [[ 21,  19,  19],
    [ 24,  22,  22],
    [ 21,  19,  19],
    ...,
    [ 21,  19,  19],
    [ 25,  23,  23],
    [ 24,  22,  22]],

   [[ 21,  19,  19],
    [ 26,  24,  24],
    [ 22,  20,  20],
    ...,
    [ 22,  20,  20],
    [ 26,  24,  24],
    [ 27,  25,  25]]], dtype=uint8)

I figured out that "cppflow::decode_jpeg " function returns decoded image data in a different channel ordering (RGB) from opencv (BGR).
So I re-trained my SR model by feeding input image data read via matplotlib.pyplot.imread, which read images in RGB ordering, and ran SR model in cppflow.
Though the SR output looks much better, there still exists inconsistency in large number of pixel values.
cppflow
python
Revisiting the input tensor values by "cppflow::decode_jpeg ", the pixel values are different from those in python, regardless of opencv or matplotlib.
I guess such difference in input tensor values is causing the different output.
In this case, would there be a way that we just feed data into input tensor as in cppflow version 1?
Ex) input.set_data()
Thanks in advance.

Did you try https://www.tensorflow.org/api_docs/python/tf/io/decode_jpeg?
You can also construct a tensor by https://github.com/serizba/cppflow/blob/ff862943dc4167ee9a4bfb6ca5483cf0fbd201ce/include/cppflow/tensor.h#L35-L36

'decode_jpeg' function in tensorflow indeed produced different pixel values!
Every guidance you @ljn917 provided led me some new finding! I really appreciate it!
To get the same pixel values as those from cv2.imread or plt.imread, I had to set the attribute dct_method to 'INTEGER_ACCURATE'  as mentioned in link.
Below is the way to get the accurate pixel values:
auto input = cppflow::decode_jpeg(cppflow::read_file(std::string("../small.jpg")), 0, 1, true, false, 1.0, std::string("INTEGER_ACCURATE"));
And I will also try the way to construct a tensor suggested above.
Thanks so much!

Thanks for reporting back. It is also the first time I learn decode_jpeg produces different results than other implementation!

I didn't expect that, thanks for pointing it!
@barrelo89 , should we close the issue now that you figured out the origin of the different output?

Sure. I will close it.


Same Message Sending Error

Hi,
When we try to reply our friend with any message it shows following error:
The following error was found:
Oops! It seems that you have already sent the same message to prevent spam you can not send multiple same content.
According to my suggestion:
Any message with same repeated content should not show error....
because we send same message everyday to same friend and other friend as well.
For example: we want to send everyday only Hi massage to our friends in the morning.
Kindly resolve this Issue:

Most people with dating websites, just copy/paste messages to a bunch of profiles.
In order to prevent this kind of spam and keep the quality of your service high, the software doesn't allow duplicate messages from the same user.
However, you can manually disable this prevention.

Open your _protected/app/system/modules/mail/forms/processing/MailFormProcess.php file.
Remove the highlighted condition I mentioned
https://github.com/pH7Software/pH7-Social-Dating-CMS/blob/68ad351919352bd7b4bda08e12f2754f50d19d60/_protected/app/system/modules/mail/forms/processing/MailFormProcess.php#L50-L51

At the moment, it isn't possible to disable this anti-spam feature right in the admin panel, but I will do my best to add this setting in the Setting admin dashboard :)
Hope it helps!

Removed following code:
elseif (!$bIsAdmin && $oMailModel->isDuplicateContent($iSenderId, $sMessage)) {
\PFBC\Form::setError('form_compose_mail', Form::duplicateContentMsg());
}
Now I am not getting above given error so far......
Let me test more......
Thanks for prompt reply and support!!!


pkp/pkp-lib#9525 Include affiliation/ROR in Crossref deposit

@bozana, I've been investigating adding in support for pulling in the ROR even when the ROR plugin isn't installed (for example in the current main branch or 3.4), and I've run into an issue. By default, the Author object will only have properties that are part of its schema, so if the ROR plugin isn't present (or doesn't exist) to add the rorId author field to the author schema, then even if it's saved in the database, it will never be loaded into the application.
Do you think this is something that should be addressed now or is it best to add in the bare-bones support now so that when the ROR plugin is present, it will work. As of right now, with this approach, it will only work in 3.3.
Thanks!

@ewhanson, oh... Hmm... Yes, maybe we can prepare that part of the code, so that it is there once we have a solution for it (either updating the ROR plugin to 3.4 and 3.5, or integrating it into the core (which I think would be better)). It can then be that 3.4 will never work, but... :-
We can maybe speak about it tomorrow in the meeting... :-)
Thanks a lot!

Thanks, @bozana, that sounds good!

Hi @klausru,
@ewhanson is currently working on it -- it will be provided for the next release 3.3.1...

Hi @bozana, from the release archive it looks like 3.3.1 has to come...
We have OJS <IP_ADDRESS> and ROR plugin <IP_ADDRESS> and no affiliation (textual or ROR) is exported to crossref...
Do you know when 3.3.1 will be released or when affiliations will be included in data exported to crossref?
Best regards
Stefano

Hi @bolelligallevi, I don't know when release 3.3.1 would come. Most of the team members are currently away, at the developer sprint, but I will make a note for myself to ask them next week when they return back, and will then let you know...

Hi @bozana, thanks for your answer, it's ok to wait after the sprint. In the meanwhile, can you confirm that "affiliations included in data exported to crossref" is a featured planned for 3.3.1? It is already included in 3.4? Best regards

Hi @bolelligallevi, the changes (to include affiliation into the crossref export) will come with this issue: https://github.com/pkp/pkp-lib/issues/9525. So you can follow that issue, to see when the changes are merged for which release.
@ewhanson has started to work on it and it seems the work is pretty finished for OJS 3.3 and main branch, but for 3.4 and OPS the pull requests/changes are still to come.
I will maybe ping @ewhanson to ask if he could maybe continue to work on it -- it is not much left, I think. (And I still have to double check with the team about 3.3.1 release.)

Hi @bozana, thanks for your update, I met @ewhanson in Turin and I mentioned the affiliations in crossdref issue with him, so I hope he will continue to work on it.
I started following https://github.com/pkp/pkp-lib/issues/9525 and I think it could be usefull that @klausru would follow too, if he's not already doing.
Best regards
Stefano