Hystrix does never open circle when there is Retry Filter

Hystrix does never open circle when there is Retry Filter but fallback works properly.
Otherwise, Hystrix works as expected
Example of configuration:
server:
  port: 7000
spring:
  application:
    name: gateway-service
  cloud:
    gateway:
      routes:
        - id: test-rout
          uri: http://<IP_ADDRESS>:9004
          predicates:
            - Path=/test-service/**
          filters:
            - name: Hystrix
              args:
                name: test
                fallbackUri: forward:/fallback
            - name: Retry
              args:
                retries: 3
                series:
                  - SERVER_ERROR
                methods:
                  - GET
                  - POST

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 15000
hystrix.command.test.execution.isolation.thread.timeoutInMilliseconds: 3000

management:
  endpoints:
    web:
      exposure:
        include: hystrix.stream
      base-path: /

data:{"type":"HystrixCommand","name":"test","group":"HystrixGatewayFilterFactory","currentTime":1590584239645,"isCircuitBreakerOpen":false,"errorPercentage":100,"errorCount":15,"requestCount":15,"rollingCountBadRequests":0,"rollingCountCollapsedRequests":0,"rollingCountEmit":0,"rollingCountExceptionsThrown":0,"rollingCountFailure":15,"rollingCountFallbackEmit":0,"rollingCountFallbackFailure":0,"rollingCountFallbackMissing":0,"rollingCountFallbackRejection":0,"rollingCountFallbackSuccess":15,"rollingCountResponsesFromCache":0,"rollingCountSemaphoreRejected":0,"rollingCountShortCircuited":0,"rollingCountSuccess":0,"rollingCountThreadPoolRejected":0,"rollingCountTimeout":0,"currentConcurrentExecutionCount":3,"rollingMaxConcurrentExecutionCount":3,"latencyExecute_mean":1727,"latencyExecute":{"0":963,"25":1484,"50":1501,"75":2008,"90":2016,"95":2018,"99":2025,"99.5":2025,"100":2027},"latencyTotal_mean":1727,"latencyTotal":{"0":963,"25":1484,"50":1501,"75":2008,"90":2016,"95":2019,"99":2025,"99.5":2025,"100":2027},"propertyValue_circuitBreakerRequestVolumeThreshold":20,"propertyValue_circuitBreakerSleepWindowInMilliseconds":5000,"propertyValue_circuitBreakerErrorThresholdPercentage":50,"propertyValue_circuitBreakerForceOpen":false,"propertyValue_circuitBreakerForceClosed":false,"propertyValue_circuitBreakerEnabled":true,"propertyValue_executionIsolationStrategy":"SEMAPHORE","propertyValue_executionIsolationThreadTimeoutInMilliseconds":3000,"propertyValue_executionTimeoutInMilliseconds":3000,"propertyValue_executionIsolationThreadInterruptOnTimeout":true,"propertyValue_executionIsolationThreadPoolKeyOverride":null,"propertyValue_executionIsolationSemaphoreMaxConcurrentRequests":10,"propertyValue_fallbackIsolationSemaphoreMaxConcurrentRequests":10,"propertyValue_metricsRollingStatisticalWindowInMilliseconds":10000,"propertyValue_requestCacheEnabled":true,"propertyValue_requestLogEnabled":true,"reportingHosts":1,"threadPool":"HystrixGatewayFilterFactory"}

pom is attached
pom.txt
logs for retrying:
: RouteToRequestUrlFilter start
2020-05-27 17:12:01.916 DEBUG 24756 --- [ctor-http-nio-2] r.n.resources.PooledConnectionProvider   : [id: 0x12fbd12c] Created a new pooled channel, now 3 active connections and 0 inactive connections
2020-05-27 17:12:01.917 DEBUG 24756 --- [ctor-http-nio-2] reactor.netty.channel.BootstrapHandlers  : [id: 0x12fbd12c] Initialized pipeline DefaultChannelPipeline{(BootstrapHandlers$BootstrapInitializerHandler#0 = reactor.netty.channel.BootstrapHandlers$BootstrapInitializerHandler), (PooledConnectionProvider$PooledConnectionAllocator$PooledConnectionInitializer#0 = reactor.netty.resources.PooledConnectionProvider$PooledConnectionAllocator$PooledConnectionInitializer), (reactor.left.httpCodec = io.netty.handler.codec.http.HttpClientCodec), (reactor.right.reactiveBridge = reactor.netty.channel.ChannelOperationsHandler)}
2020-05-27 17:12:02.129 TRACE 24756 --- [ctor-http-nio-3] o.s.c.g.f.f.RetryGatewayFilterFactory    : setting new iteration in attr 1
2020-05-27 17:12:02.129 TRACE 24756 --- [ctor-http-nio-3] o.s.c.g.f.f.RetryGatewayFilterFactory    : exceedsMaxIterations false, iteration 1, configured retries 3
2020-05-27 17:12:02.129 TRACE 24756 --- [ctor-http-nio-3] o.s.c.g.f.f.RetryGatewayFilterFactory    : exception or its cause is retryable io.netty.channel.AbstractChannel$AnnotatedConnectException{cause=java.net.ConnectException}, configured exceptions [class java.io.IOException, class org.springframework.cloud.gateway.support.TimeoutException]
2020-05-27 17:12:02.129 TRACE 24756 --- [ctor-http-nio-3] o.s.c.g.f.f.RetryGatewayFilterFactory    : retryableMethod: true, httpMethod GET, configured methods [GET, POST]
2020-05-27 17:12:02.129 DEBUG 24756 --- [ctor-http-nio-3] reactor.retry.DefaultRetry               : Scheduling retry attempt, retry context: iteration=2 exception=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information: /<IP_ADDRESS>:9004 backoff={0ms}
2020-05-27 17:12:02.129 TRACE 24756 --- [ctor-http-nio-3] o.s.c.g.filter.RouteToRequestUrlFilter   : RouteToRequestUrlFilter start
2020-05-27 17:12:02.130 DEBUG 24756 --- [ctor-http-nio-3] r.n.resources.PooledConnectionProvider   : [id: 0xe6d800f2] Created a new pooled channel, now 3 active connections and 0 inactive connections
2020-05-27 17:12:02.130 DEBUG 24756 --- [ctor-http-nio-3] reactor.netty.channel.BootstrapHandlers  : [id: 0xe6d800f2] Initialized pipeline DefaultChannelPipeline{(BootstrapHandlers$BootstrapInitializerHandler#0 = reactor.netty.channel.BootstrapHandlers$BootstrapInitializerHandler), (PooledConnectionProvider$PooledConnectionAllocator$PooledConnectionInitializer#0 = reactor.netty.resources.PooledConnectionProvider$PooledConnectionAllocator$PooledConnectionInitializer), (reactor.left.httpCodec = io.netty.handler.codec.http.HttpClientCodec), (reactor.right.reactiveBridge = reactor.netty.channel.ChannelOperationsHandler)}
2020-05-27 17:12:02.889 TRACE 24756 --- [ HystrixTimer-3] o.s.b.f.s.DefaultListableBeanFactory     : Returning cached instance of singleton bean 'fallbackController'
2020-05-27 17:12:02.889 DEBUG 24756 --- [ HystrixTimer-3] s.w.r.r.m.a.RequestMappingHandlerMapping : [b9131aca-591] Mapped to com.nice.mcr.gateway.controller.FallbackController#fallback(ServerWebExchange)
2020-05-27 17:12:02.889 DEBUG 24756 --- [ HystrixTimer-3] o.s.w.r.r.m.a.ResponseBodyResultHandler  : Using 'text/plain;charset=UTF-8' given [*/*] and supported [text/plain;charset=UTF-8, text/event-stream, text/plain;charset=UTF-8, */*]
2020-05-27 17:12:02.889 DEBUG 24756 --- [ HystrixTimer-3] o.s.w.r.r.m.a.ResponseBodyResultHandler  : [b9131aca-591] 0..1 [java.lang.String]
2020-05-27 17:12:02.889 TRACE 24756 --- [ HystrixTimer-3] o.s.core.codec.CharSequenceEncoder       : [b9131aca-591] Writing "xxx"

issue was in
statuses:
- OK

The issue happened during negative case when downstream service is stopped because of exception:
``
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information: /<IP_ADDRESS>:9004
Caused by: java.net.ConnectException: Connection refused: no further information
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.8.0_211]
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) ~[na:1.8.0_211]
at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:330) ~[netty-transport-4.1.49.Final.jar:4.1.49.Final]
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:334) ~[netty-transport-4.1.49.Final.jar:4.1.49.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:702) ~[netty-transport-4.1.49.Final.jar:4.1.49.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650) ~[netty-transport-4.1.49.Final.jar:4.1.49.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576) ~[netty-transport-4.1.49.Final.jar:4.1.49.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) ~[netty-transport-4.1.49.Final.jar:4.1.49.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) ~[netty-common-4.1.49.Final.jar:4.1.49.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.49.Final.jar:4.1.49.Final]
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.49.Final.jar:4.1.49.Final]
at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_211]
**RetryConfig has defaults exceptions  to retry**
public static class RetryConfig implements HasRouteId {
...
private List<Class<? extends Throwable>> exceptions = toList(IOException.class,
TimeoutException.class);
}
``
java.net.ConnectException is transitive subclass of IOException

it works properly when Retry filter has right configuration

You can customize that list, have you tried that?

You can customize that list, have you tried that?

@spencergibb thanks, I did. it works perfect


Fix bug where we don't store a follow Response if the Accept fails

When we send an AP Accept activity in response to a Follow and it fails, eg returns HTTP 401, we don't create a Response entity, since that happens afterward in send_webmentions. Should fix that.
https://github.com/snarfed/bridgy-fed/blob/cfb6653d77e0b1c0c507eae18e4a333b4164e6cc/activitypub.py#L223-L229

fixed by #512, #529, etc


Add the capability to create reports for our license dependencies in backend

Add the capability to create reports for our license dependencies
addresses https://ucsc-cgl.atlassian.net/browse/SEAB-490

(on build success)


macOS support

This PR is a draft for initial macOS support using users as sandboxes. This PR contains:

A new macos_sandbox.ml implementation which generates a new user and executes commands as the user, note at this time obuilder only expects a single user to be run at a time.
A new rsync storage backend -- this is for easier testing (especially on macOS where ZFS is only available using kernel extensions)

This PR is a re-branding of this branch that was proving to difficult to rebase and also the commit history was a bit wonky. To get in this "working" state I had a lot of help from @kit-ty-kate and @talex5, thanks!
Questions

The rsync backend is almost a complete copy of the btrfs backend which has a result and result-tmp directory and can quickly copy from one to the other with snapshotting. ZFS (due to limitations) builds directly in the result directory. I'm wondering if rsync should do the same which should make it significantly faster.
We should probably sandbox-exec everything, not sure how nicely that plays when nested (when opam invokes it).
Originally, we were going to choose the sandboxing environment at build time by choosing an implementation based on the OS but given the Docker backend could in theory run on Linux, Windows and macOS (with a bit of tweaking) I'm not sure if we still want to go with this approach ?
The User_temp.ml could probably just be removed now, everything can use the "Docker fetcher" or would it be good to support a file-path based fetch (not limited to /Users) just some tar:/path/to/tar, it can be useful on macOS for testing but not strictly necessary ?

TODOs

[ ] Test this newer branch more thoroughly by submitting jobs to it.
[ ] Work out the docker image story.
[ ] Add the todos from https://github.com/ocurrent/opam-repo-ci/pull/116 -- these are somewhat implemented in https://github.com/patricoferris/obuilder/pull/5 but it requires changing the ZFS directory during the build which means moving the log elsewhere which breaks btrfs' model of RO snapshots (see the Docker backend work). So we need an approach to solve this for both.
[ ] Investigate ZFS issues on Linux and macOS -- recently the Github actions seem a bit flaky (see https://github.com/ocurrent/obuilder/pull/85). I noticed problems on macOS to and resulted to forcefully unmounting datasets in the original branch, but it would be good to actually fix the problem rather than do that.

Do we really need to investigate if the rsync backend works fine or is zfs still used even with rsync?

I was going to try and show using the Github runner that it is quite a bit slower but looks like it ran out of memory or something and I can't cancel the job :( Anyway, that's the main problem, rsync is slow. I used WSL to check the linux version worked and the stress test there says:
Ran 100 jobs (max 10 at once). 0 failures. Took 227.5 s (0.4 jobs/s)

I can't imagine that's all WSL/virtualisation's fault :/
When I get a chance I'll see if I can port the stress test to macOS and then do a head to head with ZFS maybe.

We should probably sandbox-exec everything, not sure how nicely that plays when nested (when opam invokes it).

Nested sandbox-exec is not permitted. When tried it returns:
sandbox-exec: sandbox_apply: Operation not permitted

It could be a good idea to enable sandboxing by default and to have some kind of parameter to disable it, e.g.
(run (sandbox disabled) (shell "opam install pkg")) # disabled for opam (allows us to test the opam sandbox)
(run (shell "dune build -p pkg")) # enabled by default for all other programs

https://github.com/ocurrent/ocluster/pull/152 is now in opam-repo-ci as mac-cat-2 to start testing this PR more thoroughly (note we're still using the User_temp fetcher and not Docker for the moment).

Just adding an update here that this PR now uses "a static home directory", this is needed to avoid relocation errors (the OCaml compiler is not relocatable, nor are quite a few packages). This comes at the expense of 2 additional copies from and to the static home directory. A typical build step is now:

Store clone: /<store>/result/<hash> -> /<store>/result-tmp/<new-hash>
Delete contents of /Users/<static-home-dir-unique-to-uid>
Rsync: /<store>/result-tmp/<new-hash>/ -> /Users/<static-home-dir-unique-to-uid>
Build using /Users/<static-home-dir-unique-to-uid>
Rsync: /Users/<static-home-dir-unique-to-uid>/ -> /<store>/result-tmp/<new-hash>
Store snapshot

The extra copies do slow down each build step. An alternative solution that could be explored would be to bindfs the static home directory to the store. Obuilderfs is largely based on bindfs, except it also has the added cost of checking the calling uid and redirecting based on that via the "scoreboard", which we don't need for this particular redirection. It would add yet another fuse filesystem though, so it's a tradeoff between the speed of copying vs. the speed of having all FS actions go through userspace.


Add .mcfunction output option

Adds options that allows users to compile to a list of a commands (can be pasted into a .mcfunction file) instead of summoning a command block minecart

PR is picking up unrelated changes because I neglected to make a separate branch. Let me know if you're interested in getting the change merged and I can split it into a separate branch and create a new PR


unable to get a custom attribute on $state

I found a problem about routing verification :
$stateProvider.state('main',{
        requiresLogin: true,
        url: "/main",
        templateUrl : "./view/main.html",
        controller: "mainCtr",
})

.run(['$rootScope','$state', function($rootScope,$state){
     $rootScope.$on('$stateChangeStart',function(){
        console.log($state.current.requiresLogin);
         if($state.current.requiresLogin){
               // Verify the login or check TokenExpired
          }
     });
}]);

But $state.current.requiresLogin is undefine

You need to check the event parameters for the toState.  .current isn't updated until AFTER the transition to the new state is complete.
     $rootScope.$on('$stateChangeStart',function(evt, toState, toParams){
        console.log(toState.requiresLogin);
         if(toState.requiresLogin){
               // Verify the login or check TokenExpired
          }
     });

Please also read about migrating to ui-router 1.0, which is nearly complete: https://ui-router.github.io/guide/ng1/migrate-to-1_0
There's a section in there about how $stateChange* are now deprecated and removed


Updating yarn script with Unity remote config

I have a dream of creating new dialogue as my users progress through the game.
Unity's Remote Config lets me update a string variable, where I can store the text of my yarn script and change it from unity dashboard.
How do I update/recompile my yarn dialogue with this new string at runtime?

See issue #43 ... as I mentioned there, the current design of Yarn Spinner v2.0 is about precompiling in Unity Editor and avoiding runtime compilation.
If you want to use v1.2.7 instead, then I believe runtime compilation is possible with DialogueRunner.AddScript() and you'd just need code to connect your Unity Remote Config to Yarn Spinner
Good luck!

See issue #43 ... as I mentioned there, the current design of Yarn Spinner v2.0 is about precompiling in Unity Editor and avoiding runtime compilation.
If you want to use v1.2.7 instead, then I believe runtime compilation is possible with DialogueRunner.AddScript() and you'd just need code to connect your Unity Remote Config to Yarn Spinner
Good luck!

Closing this issue as a duplicate of #43.


Bump auth version

Bumps auth version.
A new release on crates.io is required to publish the changes of #150.

@yoshidan is it possible to publish the crate?


Broadcast a bit less

TODO:

[x] If this PR is a new feature, reference an issue where a consensus about the design was reached (not necessary for small changes)
[x] Make sure all of the significant new logic is covered by tests
[x] Rebase your changes on master so that they can be merged easily
[x] Make sure all tests and linter rules pass
[ ] Update CHANGELOG.md with your change
[x] Add your name and email to the AUTHORS file (optional)
[x] If this was a change that affects the external API, update the docs and post a link to the PR in the discussion

(Could be understated, I bet this will broadcast a lot less :] )

Looks great!


Setup pioneer project

This is setup, just couple of things that need to be done from now, updates every week and updating the main project page whenever we have time and have a clear idea what to write there.


Sync eng/common directory with azure-sdk-tools for PR 1517

Sync eng/common directory with azure-sdk-tools for PR https://github.com/Azure/azure-sdk-tools/pull/1517  See eng/common workflow

/check-enforcer override


Train ego_pred on DoTA dataset.

Hi, I would like to train the ego prediction using on DoTA dataset. Do you have suggestions on how to do that? Thanks.

Hi@varunjammula, the only way to get ego motion data from DoTA I can come up with immediately is to use a visual odometry. FYI, I have used ORB-SLAM2 for A3D data, but have not tried DoTA

Ok, thanks. Will try and update the issue.

Hi @varunjammula Can you please close this issue if problem is solved? Thanks!


getReactively executes on every collection change

Hi,
I have one specific problem with getReactively. Having this code:
  this.someField = '12121';
  this.helpers({
    someCollection: () => {
      console.log('test');
      return SomeCollection.find({ someField: this.getReactively('someField') })
    }
  });

And it's ok - someCollection is filled, if anything added to it it updates, and test appears only once.
Bad things happen when this.someField changes or when I make:
  $timeout(() => { this.someField = '12121' }, 100);
  this.helpers({
    someCollection: () => {
      console.log('test');
      return SomeCollection.find({ someField: this.getReactively('someField') })
    }
  });

First of all test prints on every change to SomeCollection (even if query does not match!). What is even worse - adding another helper:
  $timeout(() => { this.someField = '12121' }, 100);
  this.helpers({
    someCollection: () => {
      console.log('test');
      return SomeCollection.find({ someField: this.getReactively('someField') })
    },
    otherCollection: () => {
      return OtherCollection.find();
    }
  });

will print test on every change to SomeCollection and to OtherCollection. This is causing big performance issues.

I believe that this issue is related to #1108. We are going to release the new version tomorrow with a fix. Hopefully, it will help you.

@ozsay I'm not sure if that's the case or that it is just a question about how Helpers work.
@gooor the helper will re-run on every change of the Collection and also on every change of reactive vars inside it, like any parameter using getReactively. that how helpers work and how reactivity work in Meteor.
If you don't want the helper to change when this.someField changes, you should use it directly without using getReactively.
But maybe I missunderstood your question so please elaborate.
Thanks

@Urigo I think there are 2 things here:

The find on someCollection is re-executed when an element of the someCollection changes. E.g. each time an object is added to the collection, the whole query is re-run (and since minimongo doesn't have indexes, this can be very expensive on larger collections). However, I think that's indeed just how Meteor works, but it could be done much, much more efficient.

I think in his last example someCollection shouldn't be re-run if nothing changes to it. @gooor sees the find on someCollection being re-run, if only things change to OtherCollection. That shouldn't happen I believe.

@gooor , is what @sebakerckhof suggests true?  I would like to see a reproduction with the new<EMAIL_ADDRESS>to examine it.
The helper re-runs, but inside we do smart nested diff that changes only the things that had really changed - https://github.com/Urigo/angular-meteor/blob/master/packages/angular-meteor-data/modules/reactive.js#L148-L167

I'm throwing together a repro, since I've also been seeing some similar stuff.

awesome!

@Urigo Here's a quick and dirty repro that tests some stuff:
https://github.com/sebakerckhof/angular-meteor-data-repro
The bad news is: the problems described by @gooor are true
The good news is: the problems seem to be solved in 1.3.6-beta.1 (the version in the repo uses that, you can switch back to 1.3.5 to see what @gooor describes).
There is however one thing left that bothers me even with 1.3.6-beta.1.
As you can see I set the selected property on an element when I select it. Selecting the element will open it in the details view which subscribes to new data. While the only new data is a description field, the entire object gets replaced. You can see it by the quick red flash when selecting an element.
Of course it's up for discussion what the correct behavior should be.

that's great @sebakerckhof ! I will have a look in a few hours

@sebakerckhof
Your current setup is deprecated. Our best practice setting foo as a reactive variable is with autorun (not with helpers. The right way to set foo as a reactive variable is:
...
    controller:['$scope','$reactive',function($scope,$reactive){
          $reactive(this).attach($scope);

          this.$onInit = function() {
            this.subscribe('foo',()=>[this.getReactively('fooId')]);
          };

          this.autorun(() => {
              console.log('calling foo');
              this.foo  = Foos.findOne({ _id: this.getReactively('fooId') });
          });
...

This basically will do the same, and it will replace foo whenever the autorun will run.
You can do this differently in order to avoid the replacement:
...
    controller:['$scope','$reactive',function($scope,$reactive){
          $reactive(this).attach($scope);

          this.foo = {};

          this.$onInit = function() {
            this.subscribe('foo',()=>[this.getReactively('fooId')]);
          };

          this.autorun(() => {
              console.log('calling foo');
              var tempFoo  = Foos.findOne({ _id: this.getReactively('fooId') });

              angular.extend(this.foo, tempFoo);
          });
...

@Urigo 1.3.6-beta.1 fixed the problem of re-executing the helper on every change in any collection :)
There's one thing that bothers me. As @ozsay wrote, best practice is to use autorun not helper, and if I do replace
  this.helpers({
    foos: () => {
      console.log('calling');
      return Foos.find({field: this.getReacively('field')});
    }
  });

(which now works fine on 1.3.6) with
    this.autorun(() => {
      console.log('calling');
      this.foos = Foos.find({field: this.getReacively('field')});
    });

It again executes on every change to Foos, while this.field remains unchanged o_O

@gooor the best practice is to use helpers only for Meteor Cursors.
Your last example use a Meteor Cursor so you should use a helper

@Urigo thanks for explanation :) - but there's still a problem as autorun is called even if this.field is unchanged

@gooor this is how Meteor's autorun works.  it executes on every change on any reactive thing inside it and a Meteor cursor is a reactive object.
If you want to re-run something only when field is changing you can use Angular's $watch:
$scope.$watch('field', function(){
  console.log('calling');
  this.foos = Foos.find({field: this.field});
});

@Urigo ok now I understand (I think) :)

1.3.6 was released.


test: split fixtures for browser test

Description
Base branch: https://github.com/vitest-dev/vitest/pull/4867 (new change is only the last commit)
Testing to see if splitting the custom base test would affect test failure on CI.
I also rewrote an assertion to be based on stdout/stderr, so it might be easier to debug.
I'll retry CI for a few times by force-pushing the same commit.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
[ ] Ideally, include a test that fails without this PR but passes with it.
[x] Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

[ ] Run the tests with pnpm test:ci.

Documentation

[ ] If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

[x] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

Closing this in favor of the other one

https://github.com/vitest-dev/vitest/pull/4879


test: update win32 test serializer to work on any win32 machine

This Pr fixes snapshot testing on windows machines that are not CI
ideally we would want to fix this issue upstream in jest-serializer-path, but this page seem to be no longer maintained
https://github.com/fi3ework/vite-plugin-checker/pull/327#issuecomment-2198006009

if you want we could just replace jest-serializer-path with simpler serializer

If we could makes it work with a simple, promising script, we definitely could remove jest-serializer-path.

do you want me to update this PR, or submit it as separate one?

updating this PR is fine.

Looksike something like this is going to work, as a bonus Ubuntu 18 tests are passing now

Thank you! I'm AFK now, will take a look into the code when back later today.


[INFINITY-2306] Correct closing brace in cassandra mustache (#1497)

@elezar, nope. Looking at the test history, the test has a success rate of 88%. Which bears investigation.

Especially given that it failed in both the PRs into this branch.


3.0.0 Switched to hashmap with performance improvements

Switched to a hashmap trie. With significantly faster insertion rates, creating a new instance is slower, albeit that is likely to be done substantially less than modification of the map. There is potential to improve performance, especially around create. Let me know what you think.
2.4.0 is 38.76 X faster on create an increase of 3775.95%
3.0.0 is 1.76 X faster on singleSet an increase of 76.11%
3.0.0 is 2.16 X faster on singleSet 20 an increase of 116.21%
3.0.0 is 1.91 X faster on singleReplace an increase of 90.53%
3.0.0 is 1.44 X faster on setAfter 1,024 an increase of 44.02%
3.0.0 is 1.91 X faster on set 20 After 1,024 an increase of 90.84%
3.0.0 is 3.25 X faster on setAfter 131'072 an increase of 225.36%
3.0.0 is 3.70 X faster on set 20 After 131'072 an increase of 270.20%

I appreciate your hard work and the fact that you submit it to the project, but I'll be honest with you. This project was created several years prior to the introductions and standarization of the JavaScript Map. Since this, I think there's little reason to use this over the native one. I'm not putting time into this except for very quick fixes.
I'm sure your implementation is fast but I don't want to go thru merging, testing, iterating, fixing a bug here and there.
Since you partially rewrote it and you seem very content with it, I'd suggest you publish it to NPM as an alternative. Then you get to maintain it, give support and all the good stuff. Whoever likes yours, will use it.

But people are using it, and the problem is its top of the list and not doing what it claims. This new impl is faster than the basic map function, because that's what is underpinning the original. More importantly it is a hashmap, which has very specific performance guarantees, which the original is claiming but can't deliver, as it is not and never was a hasmap.
I was trying to give back to the community, not create unnecessary competition.

Of course it does what it claims, I understand you care about that but it's the first time someone complains in the 7-8 years it exists. People needed a map that indexes something other than numbers and strings and got it.
Again, feel free to publish your version to NPM. I definitely don't care about part of the code being reused and the license definitely allows it.
Have a nice weekend

Dude I know what I am talking about here. It is 100% not a hashmap, it is a map with strings as keys, but not a hashmap. Popularity or lack of complaints does not mean I am wrong. I am trying to help you here, get a second opinion, willing to offer £500 to your £100 if I am wrong, I could do with the cash. Also you are indexing by string, there is a promise in your notes that you don't stringify the objects, but that is exactly what you do, you are just adding card image graphemes to the front for uniqueness, which btw has holes in the approach. And you are right a map will do a better job. But a properly segregated hashmap will be faster. I think you should be honest at least in your documentation.


[gui] ArrayTableWidget

This PR adds a widget  to view multi-dimensional numpy arrays as stacks of 2D arrays. The 2D array corresponding to the last two dimensions of the array is displayed in a QTableView. The indices of the other dimensions can be set by moving sliders, by typing text in a line edit or by using buttons/icons to browse the data.

4D array of shape (4, 5, 1000, 1000)
Currently the widget is almost identical to the one in PyMca5, with only minor refactoring.
To be discussed:

module name: silx.gui.array? directly in silx.gui to reduce the number of folders?
widget name: ArrayWidget? ArrayTableWidget? NumpyArrayWidget? NumpyArrayTableWidget?
should we provide a way to display frames with any perspective (not only frames whose axes are the last two dimensions of the array)? This is already implemented for 3D array, and could be generalized to higher dimensions.
possibility to add a color to the cell's background depending on its value, to make a gigantic pixelized image?

Todo list:

[x] generalize perspective to n-dimensional case, to be able to see any  2D slice in any array
[x] tests
[x] documentation
[x] tutorial
optional colormap (difficult and potentially not very readable)

It seems that "array" as a package name will cause issues on some configurations:
$ python setup.py $BUILD_COMMAND

Traceback (most recent call last):

  File "setup.py", line 322, in <module>

    config = configuration()

  File "setup.py", line 318, in configuration

    config.add_subpackage(PROJECT)

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/numpy/distutils/misc_util.py", line 1000, in add_subpackage

    caller_level = 2)

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/numpy/distutils/misc_util.py", line 969, in get_subpackage

    caller_level = caller_level + 1)

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/numpy/distutils/misc_util.py", line 906, in _get_configuration_from_setup_py

    config = setup_module.configuration(*args)

  File "silx/setup.py", line 35, in configuration

    config.add_subpackage('gui')

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/numpy/distutils/misc_util.py", line 1000, in add_subpackage

    caller_level = 2)

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/numpy/distutils/misc_util.py", line 969, in get_subpackage

    caller_level = caller_level + 1)

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/numpy/distutils/misc_util.py", line 906, in _get_configuration_from_setup_py

    config = setup_module.configuration(*args)

  File "silx/gui/setup.py", line 35, in configuration

    config.add_subpackage('plot')

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/numpy/distutils/misc_util.py", line 1000, in add_subpackage

    caller_level = 2)

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/numpy/distutils/misc_util.py", line 969, in get_subpackage

    caller_level = caller_level + 1)

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/numpy/distutils/misc_util.py", line 906, in _get_configuration_from_setup_py

    config = setup_module.configuration(*args)

  File "silx/gui/plot/setup.py", line 35, in configuration

    config.add_subpackage('test')

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/numpy/distutils/misc_util.py", line 1013, in add_subpackage

    dist = self.get_distribution()

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/numpy/distutils/misc_util.py", line 848, in get_distribution

    from numpy.distutils.core import get_distribution

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/numpy/distutils/core.py", line 10, in <module>

    from setuptools.command import easy_install

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 52, in <module>

    from setuptools.package_index import (

  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/setuptools/package_index.py", line 15, in <module>

    from urllib2 import splituser

  File "/opt/python/2.7.9/lib/python2.7/urllib2.py", line 94, in <module>

    import httplib

  File "/opt/python/2.7.9/lib/python2.7/httplib.py", line 69, in <module>

    from array import array

ImportError: cannot import name array

@vallsv started to place 'general purpose' widgets in silx.gui.widgets.
I would go for a silx.gui.widgets.ArrayWidget...
It is would be nice to optionally use a colormap to color the array.
As for the setup issue, try to add import array at the beginning of the top level setup.py... This worked for a similar issue with the io package.

I moved the widget to silx.gui.widgets. I'm thinking of using this PR to also move console.py to silx.gui.widgets, unless anyone disagrees with this move.

Personally I consider better to have as much as possible a single class on a single file. Therefore the orginal split. Qt itself separates them too.  Our HDF5 widgets too. Also, the FramwBroser could be used, and it was was used, for other things than the table.

Again, unless you have clear reasons to change the name of a widget (i.e. widget name: ArrayWidget? ArrayTableWidget? NumpyArrayWidget? NumpyArrayTableWidget?) do not change it. It only asks for unnecessary work.

In my opinion the existing widgets needed very little refactoring and I think you are just asking for unnecessary work.

Concerning the colormap, I have seen it somewhere. Could it be on Oxidis?

I hope we do not keep silx.gui.array or any module "array"anywhere (https://docs.python.org/3/library/array.html)

I would keep console separated from other widgets as it has an extra dependancy on ipython...

Please, do not misunderstand me. If you have any valid reason to change the name of a module, do so. What I do not want is names changed without any reason. For instance you could argue "have a shorter name", "support of something else than numpy arrays", ... but not changing them without any justification.

The only reason was having a shorter name, but I don't really have a strong opinion on this subject, so I'm fine with changing it back.
OK to put one class per file, but than I think I should add a subpackage to widgets, and expose the main widget (NumpyArrayTableWidget) in widgets.__init__.py, for the sake of maintaining a readable structure in widgets. If FrameBrowser starts being used elsewhere, we can then expose it later.

If it supports other things than numpy arrays (for instance HDF5 datasets) then dropping "Numpy" from the name is fully justified. So, one thing to be checked.

Exposing all the widgets form package silx.gui.widgets into silx.gui.widgets.__init__ is, i think, not a good idea, while this package is supposed to contain a lot of widgets.

@vallsv suggested that we could move the model to a new package silx.gui.models. It is to be discussed, it could be a good idea in the future if we consider having multiple models that each serve multiple views.

What about making the cells editable and providing a getData method to return the updated array?
Would that be of any use to someone? It could be a low-level way to edit the data.

To expose all the widgets at a single place does not shock me (PyQt exposes most of them at a single place) but I do not have a clear opinion.

My opinion was to put 'simple' widgets (i.e., single file) into silx.gui.widgets and more complicated ones (e.g. plot, hdf5) or the one with extra dependencies (e.g., console) into their own package.
But this seems to need some discussion.

I created a separate issue for the colormap, this will not be implemented in this PR.
Regarding the icons of FrameBrowser, they should be changed with something more in line with the silx graphic charter, but that's not really my area of expertise.

Back to WIP, I need to sort the problem of 1D datasets being copied and document the API of FrameBrowser. Should be fixed before the end of the day.

ArrayTableWidget setArrayData method is doing a copy systematically and it should not. (Reminder numpy.array defaults the copy keyword to True)

Fixed. I don't really need the numpy.array, I just need to guess the shape and dtype.
I also changed the behavior of the model, to raise a TypeError if the user requests copy=False but the data must be copied (instead of just logging a warning and forcing the copy).

Late comment: with numpy.array copy=False makes a copy only if needed...
I personnally expect APIs taking an array-like object and a copy argument to behave the same way (so they might make a copy with copy=False).

I find the numpy behavior slightly dangerous. If someone use copy=False to get a memory view, because he wants to ensure that any change to the data will really modify the original data in memory, the hidden copy will cause a problem.
If we want this widget to be usable as an array editor, working directly on the original data without having to setData/getData at every modification, I suggest that we keep the new behavior (raise an exception if copy=False is requested but impossible).
However, if we decide that direct editing of numpy arrays and h5py datasets is unsafe and must be disabled anyway, then I agree that we could make copy=False work the same way as numpy.array.


[QUESTION] How to allow custom doctrine type with SoftDelete / Timestampable?

Hi,
I want to use a custom doctrine type for SoftDelete / Timestampable. It would still convert to and form DateTime, so that would not be an issue.
The main reason is that I want to add support for microseconds to some of my DateTime fields (especially the SoftDelete / Timestampable) fields.
I checked and both would be able to handle them. However, it is quite tricky to add those types to the listeners. For SoftDelete I could probably add it to the public static property \Gedmo\SoftDeleteable\Mapping\Validator::$validTypes. However that is not very elegant (especially in combination with using the Symfony bundle) and for Timestampable it is a protected property.
The solution would be to override the the corresponding driver but that means to change the namespace in the listener class which also means to override all other classes that are inside that namespace to be sure everything works correctly and also to override all three drivers if necessary,

Hi @AndreasA. Yes this is an unfortunate issue, handling custom types/values. Right now Extensions is pretty hard-coded for the types it supports.
Give #1946 a follow for progress on this issue. I'm going to look into looping DBAL into the extension so we don't need to manage this separately. It's requested often enough that I'm going to try getting it into 3.0.


Add shims to the OPAE RTL platform between the top-level PR boundary and the AFU

JSON configurable clock domains for CCI-P and local memory.
Platform-dependent auto-insertion of register stages to reduce timing pressure.

http://sw-pert.altera.com/pert/pert.php?test_run_id=2064142
This commit looks long, but the big part is mostly inclusion of some Qsys components for clock crossing.
This code affects ASE but not Quartus builds yet. Quartus builds will only be affected when they start using afu_platform_config and a new green_bs() that imports the generated configuration.
The most significant change here is the ability to select clocks in the AFU's JSON. It is now possible to map all DDR and CCI-P interfaces to a common clock without doing anything in the AFU other than connecting to the right clock.

Your top level comment was about waiting to release until it is all coordinated with the Quartus side of the release. Waiting would be a huge mess. Remember, there are multiple boards! I need a stable OPAE SDK and then to work with each board group to get this done.
The ASE version is already different! For example, it already accepts MCP syntax on DCP.
To make progress, I need to commit these intermediate changes and work with board and documentation groups.

I rewrote the comments you suggested. Thank you for the feedback.
The Quartus version problem is on my list for later commits.
Anything else?

I'v asked LeePing/Jake to look so they understand this change. If I don't hear any concerns by tomorrow afternoon, I'll approve it.

Also, can you verify my understanding of num-timing-reg-stages and num-auto-timing-reg-stages?
num-timing-reg-stages=2, num-auto-timing-reg-stages=null, no stages will be inserted
num-timing-reg-stages=2, num-auto-timing-reg-stages=auto, 2 stages will be inserted
num-timing-reg-stages=2, num-auto-timing-reg-stages=4, 4 stages will be inserted (override)
Is that the intent?

Your questions about num-auto-timing-reg-stages are good and, I think, are highlighting something I could do better. The problem I'm having is the inconsistency between CCI-P and Avalon MM. CCI-P requires the AFU add a register stage. Avalon MM doesn't, because it can't. (Actually green_bs has a register stage for Avalon MM, but it uses a bridge that implements the protocol.)
Right now, the behavior of num-auto-timing-reg-stages is inconsistent. For Avalon-MM, it behaves exactly as you said. When num-auto-timing-reg-stages is a number, that number of stages is added. When num-auto-timing-reg-stages is "auto", num-timing-reg-stages are added.
For CCI-P, it adds num-auto-timing-reg-stages - 1 stages, assuming that the AFU is responsible for a stage.
Would it be better if the fields were suggested-extra-timing-reg-stages and auto-add-extra-timing-reg-stages? I'd make suggested-extra 0 on MCP and 1 on DCP for CCI-P. auto-add-extra could take true/false (insert exactly the suggested-extra number) or a number (insert exactly that number).
Would that be better?

It's fine. You can keep the original naming. Perhaps add my example in the comments to better illustrate how it works. Otherwise, looks good.

Merge complete and tests pass:  http://sw-pert.altera.com/pert/pert.php?test_run_id=2067197


Checks for wagtail 6.3

This pull request includes updates to the supported Python versions and dependencies
Updates to supported Python versions:

.github/workflows/test.yml: Removed Python 3.8 from the matrix of supported versions. [1] [2]
README.md: Updated the list of supported Python versions to remove Python 3.8.
pyproject.toml: Removed Python 3.8 from the classifiers and updated the requires-python field to >=3.9.
tox.ini: Removed Python 3.8 from the envlist and basepython sections. [1] [2] [3]

Updates to dependencies:

tox.ini: Added support for Django 5.1 and Wagtail 6.3. [1] [2]

Questions:

Did you want me to add python 3.13 into the mix?

Thanks a lot @nickmoreton for your constant support!
Yes, it would be nice to have 3.13 in it too :pray:

Thanks @th3hamm0r I just updated this for python 3.13 👍


Remove unnecessary "sign_data" endpoint

This endpoint is doing nothing except forwarding the request to the blokchain endpoint with the same name. There seems to be nothing preventing clients from communicating with the blockchain directly, so this is just noise here.
Thoughts?
I'd also say that if this makes sense to you in principle, we should do the same to other forward-only endpoints.

New finding: I guess the same can be said about the /blockchain/txs endpoint as well. Apparently no need for it at all.

You're absolutely right. However what I would prefer is that we first switch anything that points to these endpoints to point to the blockchain endpoint directly, just to make sure that it would work (no reason for it not to, in reality). Then we remove these endpoints.
Users of these endpoints that I know of include:

ixo-webclient
ixo-apimodule
ixo-cellnode
Possibly the mobile app?


Unknown opcode: b010 when decompile wallet_v5r1 contracts

Unknown opcode: b010. Any assistance in resolving this issue or guidance on how to add support for new opcodes would be greatly appreciated. Thank you!

Thanks for reporting the issue. Does https://github.com/scaleton-labs/tvm-disassembler also throw an error?

If you'd like to help fixing it, you can take a look at a recent PR fixing an unknown opcode issue for division instructions: https://github.com/tact-lang/ton-opcode/pull/16


Implement ACK.

ACK = 0x04

ACK is added, but will stay in its own branch until we see a need to use it. This is because TCP basically has a buildt in ACK. So we dont se a reason to merge it with main until we have somewhere to use it.


Publish Flutter package

I think the title speaks for itself.

The plugin is not published on pub.dev, but I think Flutter developers can directly use the plugin from here itself: https://github.com/breez/breez-sdk-flutter by modifying their pubspec.yaml as follows:
dependencies:
  breez_sdk:
    git:
      url: https://github.com/breez/breez-sdk-flutter.git


Link Pages and Implement Two Page Layout

Tentatively finished although might not want to push due to issues with the test cafe stuff


Suspected miscompilation on IDF v4.2.3 (IDFGH-7570)

Environment

Development Kit:     TinyPico
Module or chip used:  ESP32-PICO-D4
IDF version: v4.2.3
Build System:         idf.py (inside MicroPython build)
Compiler version:
xtensa-esp32-elf-gcc (crosstool-NG esp-2020r3) 8.4.0
GNU assembler (crosstool-NG esp-2020r3) 2.31.1
Operating System:    Linux
Using an IDE?: No
Power Supply:  USB

Problem Description
I'm from the MicroPython project.
We noticed that one of our recent commits broke some basic parsing functionality with the way constant folding works in our compiler, but only on ESP32, and only with IDF v4.2 (works fine in 4.3 and 4.4). Any modifications (e.g. debugging, changing of inlining, etc) to this code caused the bug to go away.
The only diff for this function compiled on 4.2 vs 4.4 is:
  d3:   1aa1c2          movi    a12, 0x11a
  d6:   209770          or      a9, a7, a7
  d9:   178976          loop    a9, f4 <push_result_rule+0xf4>
  dc:   030190          rsr.lend        a9
  df:   130090          wsr.lbeg        a9
> e2:   a8c992          addi    a9, a9, -88   (4.2, broken)
> e5:   06d992          addmi   a9, a9, 0x600
< e2:   000091          l32r    a9, fffc00e4 <push_result_rule+0xfffc00e4>   (4.4, working)
< e5:   0020f0          nop
  e8:   130190          wsr.lend        a9
  eb:   002000          isync
  ee:   030290          rsr.lcount      a9
  f1:   01c992          addi    a9, a9, 1
  f4:   1494e7          bne     a4, a14, 10c <push_result_rule+0x10c>

The 4.4 version references the constant 18:   9c 06 00 00
Both IDF versions seem to use the same compiler version (8.4.0) and just substituting the gcc binary didn't solve the problem. However, substituting the assembler did. This led me to https://github.com/jcmvbkbc/binutils-gdb-xtensa/commit/403b0b61f6d4358aee8493cb1d11814e368942c9 @jcmvbkbc which was applied in binutils 2.33 (v4.2 has binutils 2.31, v4.4 has binutils 2.35).
We would like to move to v4.4 as our minimum supported IDF version, but that is not feasible right now as it causes other issues due to the differences in memory layout resulting in a smaller contiguous area available to create our garbage-collected heap. We are working on solving that with a split heat but that isn't ready yet.
Right now we have a "workaround" (by disabling inlining for a section of the relevant code) but this is fragile. I understand that v4.2 is maintained until mid 2023, so would you consider doing a new v4.2.x release with an updated binutils?
FYI, I did a search in our firmware image for other patterns of this addi/addmi code, and also found one other occurrence in llm_hci_cmd_handler_tab_reset. This appears to come from a binary blob (perhaps hasn't been recompiled with newer gcc/binutils?).
While investigating this I also came across https://github.com/espressif/esp-idf/commit/ee2f8b1a6236fcdcd57f8410d98119d96de40a3f -- which is not in v4.2. We do put a significant amount performance-sensitive code in IRAM, so although I don't have any evidence that we're being affected by this, it's still a bit concerning. Perhaps worth backporting to v4.2 also?
Also worth mentioning, I haven't checked IDF v4.1, but I suspect much of the above applies to v4.1 too.
Thanks! Please let me know if you need additional details.
cc @dpgeorge

If you decide to backport the commit https://github.com/jcmvbkbc/binutils-gdb-xtensa/commit/403b0b61f6d4358aee8493cb1d11814e368942c9 please note that the commit https://github.com/jcmvbkbc/binutils-gdb-xtensa/commit/548791769dc737f05cb12e5ee4190b7e853beac9 is related to this issue and should be backported as well.

This is some impressive investigation you did!

If you decide to backport the commit jcmvbkbc/binutils-gdb-xtensa@403b0b6 please note that the commit jcmvbkbc/binutils-gdb-xtensa@5487917 is related to this issue and should be backported as well.

CC @igrr

v4.2 branch is already EOL, this should be closed.

Indeed. We have moved to 5.0 (and soon 5.1) so this is no longer an issue for us.


service: Add support for incremental updates

[x] This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?
Currently, measurement services send outputs to the client when the measurement is complete, by returning a list/tuple of output values. This PR allows measurement services to send outputs to the client during the measurement, by yielding a list/tuple of output values.
When accessed via the ni.measurementlink.measurement.v1.MeasurementService interface, only the last update is sent to the client.
The final update may use either a yield or return statement, so that adding a yield statement to a previously working measurement service doesn't cause the return value to be ignored. This is why this code catches StopIteration: to inspect the return value stored in the exception's value field.
Also:

Update the ni-measurementlink-service version to 1.1.0a0
Add a long_running_measurement example based on @dixonjoel's .NET version

Why should this Pull Request be merged?
AB#2371309
What testing has been done?
Ran ni-python-styleguide, mypy, and pytest.
Manually tested long_running_measurement example with latest dev build of InstrumentStudio.

Screenshot:

You may want to test whether the STOP button also still works correctly to stop a measurement that is in the progress of returning incremental updates.

You may want to test whether the STOP button also still works correctly to stop a measurement that is in the progress of returning incremental updates.

I originally overlooked that. It did not work, so I fixed it in commit 4 and then implemented a slightly better fix in commit 5.

Does python support partial updates? If so, I think it would be useful to create an example that shows partial updates. Or modify this example to use partial updates.

Not yet.

We should consider renaming this example. LongRunningMeasurement isn't very descriptive, especially when I can make the measurement be as long or short as I want. Perhaps we should call it ContinuousUpdateMeasurement or ContinuouslyUpdatingMeasurement or something similar.


👷 switch the pros build ci to an external repository

Summary
This pull request changes the pros build ci to depend on an external repository rather than being written out directly.

Download the template for this pull request:

[!NOTE]
This is auto generated from Add Template to Pull Request

via manual download<EMAIL_ADDRESS>via PROS Integrated Terminal:

curl -o<EMAIL_ADDRESS>https://nightly.link/LemLib/LemLib/actions/artifacts/1590552409.zip;
pros c fetch<EMAIL_ADDRESS>pros c apply<EMAIL_ADDRESS>rm<EMAIL_ADDRESS>

@meisZWFLZ squash and merge please

Oh it's gonna fail because there isn't a lemlib folder

My vote would be to put this on pause until there is more work done on LemLib 0.6, and then once there's something in the repo to actually test, then we can merge this.

We could close this and move the changes to the v0.6-chassis-refactor branch since that's what's being worked on anyways

I did what you suggested, however the workflow is still failing due to the include directory not being present at all in the built template, even though it exists in code and is mentioned by the Makefile.
I have no idea what to do to solve this, help would be appreciated.

It’s not because of the include folder, it’s because include/lemlib doesn’t exist. You might need to push another commit to make it rerun

include/lemlib exists, but template/include and template/include/lemlib both don't get created by pros make template.

That's not gonna do anything. I think its an issue with the Makefile

@BattleCh1cken this still being worked on?

This should be ready to merge now I think. The issue I was having before was resolved.

LGTM


[Relay][TensorFlow] Add support for StopGradient

Add support for StopGradient in tensorflow frontend.

When executed in a graph, this op outputs its input tensor as-is.

@merrymercy @icemelon9 @yzhliu please take a look.

This node acts as identity for inference, but it is not the case for training. Do we know how to properly support it for training? Is this worth discussing?
If you need to get rid of this node, you can export the graph with remove_nodes(op=StopGradient) as a transform.

Thanks. So I guess we need a new operator?


Support Ctrl+Enter to run scripts

TextEditor takes a generic list of IActionDescriptors, and ScriptEditor provides one that runs the current script

Confirmed that it works. Looks good.

Yup, good catch to memoize the lists.