Voiding Payment

It seems that the DataService is not able to void a payment.
var dataService = new QuickBooksSharp.DataService("AccessToken", "RealmId", useSandbox: true);

// https://developer.intuit.com/app/developer/qbo/docs/api/accounting/most-commonly-used/payment#void-a-payment
// Use a sparse update operation with include=void to void an existing Payment object;
// include a minimum of Payment.Id and Payment.SyncToken.
// The transaction remains active but all amounts and quantities are zeroed
// and the string, Voided, is injected into Payment.PrivateNote, prepended to existing text if present.
// If funds for the payment have been deposited, you must delete the associated deposit object before voiding the payment object.
var payment = new Payment()
{
    Id = paymentId,
    SyncToken = syncToken,
    status = EntityStatusEnum.Voided,
    sparse = true,
    PrivateNote = "Voided by QuickBooksSharp"
};

var result = await dataService.PostAsync(payment);

Any idea if we can actually do this?

@clement911 I've created a PR that fixes this problem. Please check it out.

Merged.

Published in 1.8.1


Organise output of search response in demo site

The demo site (see #21 ) set up here already has an axios request implemented to query the API and display results, but the results have still not been organised or styled.
Note: This project is built with Gatsby and uses Tailwind utility classes in order to give a consistent look to the site.

@C-Zekeri Is this ticket still something we should work on?

Closing this ticket since it's outdated.


Refactor math::nq module

WIP - DO NOT MERGE. This pull request is now only for code review and discussion
about changes.

Can you please box the array? I had some bad experiences with stack sizes recently.

If it needed to be boxed type then Vec  would be fine, but IMHO there is no need for either.

Well, Vec is fine. There is no gain in using an fixed size array. It only saves one allocation. Point is, that the struct is now 2kb big.

I've brought Vec back, but changed syntax in new.

(y) the WIP still holds?

Still holds as I want to see if I can refactor sort and search. Probably some methods change their name.

Looks good!
@hauleth The new io has some dependency issues and we might want to wait until those get fixed to check if it works.

@hauleth @nwin Can we merge this now?

I have no idea for now. Maybe later I find way to cleanup it more (or even extract it to another crate).

Nice!


Istio Virtual Service CorsPolicy

/kind feature
Describe the solution you'd like
It would be great to be able to set the CorsPolicy on the VirtualService which is automatically deployed by KFServing.
Anything else you would like to add:
This seems like a relatively simple feature to add and one that I would be happy to attempt to implement. However, I am uncertain whether the CorsPolicy should be a global KFServing setting in the inference-service ConfigMap or if it should be set on a per InferenceService basis. Obviously, this would mean a bit more work as it would mean adding to the InferenceService CRD (or perhaps the EndpointSpec?) Alternatively, is this viewed as something the underlying model servers should deal with?
Please, do let me know what your thoughts are.

Hi @yuzisun
I am able to curl the inference service I set up using curl. However I'm not able to access it from my frontend development due to CORS error.
from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Usually the setting will be in Istios Virtual Service Setting using corsPolicy: allowOrigins. In this case, how do I allow access from localhost or other host?
Thank you.

It's still not implemented right? So for any browser based front end this will be an issue. @yuzisun I can implement this, with enable cors as a global configuration for predictor/explainer, is that ok?

Hi @pugangxa
What is the progress on this issue? I am really looking forward to have this :)

We'd like to have this feature as well, seems very important.. Having a single istio config rather than injecting the headers in fastapi would be way better.


Authenticating to docker using gcloud isn't working after this action

TL;DR
Authenticating to docker using gcloud isn't working, despite what looks like a successful login.
Expected behavior
Docker to be successfully authenticated.
Observed behavior
Docker authentication doesn't seem to be working in combination with this actions output?
Action YAML
      - name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@v0'
        with:
          credentials_json: '${{ secrets.GOOGLE_CLOUD_TOKEN }}'

      - name: 'Set up Cloud SDK'
        uses: 'google-github-actions/setup-gcloud@v0'

      - name: Docker Login
        run: "gcloud auth configure-docker --quiet us-central1-docker.pkg.dev"

      - uses: actions/checkout@v2

      - name: Build Docker Image
        run: "docker build ."

Log output
Getting:

ERROR: (gcloud.auth.docker-helper) Failed to load credential file: [/home/runner/work/api/api/39c413352e4b4825126e788d].  File /home/runner/work/api/api/39c413352e4b4825126e788d was not found.

Even though:
    CLOUDSDK_AUTH_CREDENTIAL_FILE_OVERRIDE: /home/runner/work/api/api/39c413352e4b4825126e788d
    GOOGLE_APPLICATION_CREDENTIALS: /home/runner/work/api/api/39c413352e4b4825126e788d
    GOOGLE_GHA_CREDS_PATH: /home/runner/work/api/api/39c413352e4b4825126e788d

checkout should be the first step before doing anything else. This is documented in the readme.
If you move actions/checkout@v2 to before auth, that will fix your issue.

Apologies, it might be worthwhile to reorganize the readme into essential sections at the top and then break out the individual flows away from that.  A lot of it is all blended together, so I took a hunt-and-peck approach while reading it :chicken:
:wink:


using the libuv for proxy on windows, the last client can send the first messages to the server.

void on_client_tcp_read_done(uv_stream_t *handle, ssize_t nread,
const uv_buf_t *buf) {
if (nread == 0) { // EAGAIN || EWOULDBLOCK
return;
}
Session *sess = (Session *)handle->data;
if (sess == NULL || sess->state == S5_CLOSING) {
return;
}
// stop reading so the buf can be reused and not overrun
uv_read_stop(handle);
if (nread < 0) {
	if (nread != UV_EOF) {
		LOG_E("client read failed: %s", uv_strerror(nread));
	}
	printf("close %X\n", sess);
	printf("377 tcp rd\n");
	close_session(sess);
	return;
}

if (sess->state == S5_METHOD_IDENTIFICATION) {
       // the fun of handle_socks5_request finishs  the connection of server and change the state for
          // sS5_STREAMING, and then excutes client_tcp_read_start and upstream_tcp_read_start.
         // client_tcp  for the proxy server ,upstream_tcp for the proxy client
	handle_socks5_request(handle, nread, buf, sess);
}
else {
	if (sess->state == S5_STREAMING) {
            upstream_tcp_write_start((uv_stream_t *)((TCPSession *)sess)->upstream_tcp,
				((uv_buf_t*)buf));
	}
	else {
		// unreachable code
		LOG_W("unepxected state: %d", sess->state);
		close_session(sess);
	}
}

}

I don't follow.  Can you elaborate if you are reporting a bug in libuv or move it to the help repo if you are looking for help with your code?


Extract stats into separate server

What does this implement/fix? Explain your changes.
Extracted stats from server backend and transferred to its own server.
Does this reference any currently open issues?
…
Types of changes
What types of changes does your code introduce?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. This is simply a reminder of what we are going to look for before merging your code.

[x] I have linted my code and I have run tests locally that pass
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have added necessary documentation

Any other comments?
…

I just tested /players/:player and /teams/:team and both are working on the extracted server

Note there are more dependencies in package.json than actually needed to run. The dependencies match package.json as of 4/20.


Contrib separation & ftl::Trampoline

Please find the initial implementation of Trampoline, along with a hypothetical split from the mainline ftl library.
This is not intended to be merged in this form, but I wanted to initiate discussion on this implementation approach.

Frankly, I'm not really a big fan of this interface. The code itself looks perfectly fine for what it does, though I haven't been terribly thorough.
My comments in no particular order:

Forcing a bump up to c++17 for the functionality achievable with std::function doesn't seem worth it to me.  I understand that the std::invoke stuff is really nice, but I really can't justify to myself why it is truly necessary.
I understand that the purpose of having the Trampoline type is to allow you to control the scope as you wish, but I think this is just making things unnecessarily complicated. The whole purpose of interface is to make things as simple as possible, and i can't see the benefit of all the machinery you have to do with this (construct a trampoline, bind arguments, deal with the future etc.).
I personally think that the best interface would be very similar to a std::async call and how I designed my prototype interface:template<class F, class... Args>
future<rettype> TaskScheduler::AddTask(F& function, Args&&... args);

Obviously you need to add the other arguments in there, but you get the general point. All the nasty stuff can be handled internally, and you are allowed arbitrary functions to be called (including member functions as long as you delegate off to std::bind).
Because there is a vector of all the current BoundTrampolines you have to hold a mutex in order to modify it. This seems counterproductive over the alternative is just calling off to malloc/new/user provided allocator. The function that gets called can do the deletion. Holding mutexes within a fiber isn't good, and as of right now, ftl::Futex doesn't allow non-fiber threads to hold it.
Adding an addTask to AtomicCounter seems to be violating separation of concerns. There isn't a convincing reason why it should be there. There can be an overload of addTask or an additional member function that also blocks on the AtomicCounter.
FTL_CONTRIB_CHANGES really should be specific about what it is enabling. If we want things to be able to be compile time enabled and disabled (which I agree with), each optional feature should have its own descriptive macro on what it is enabling and disabling. While contrib is accurate, all the file names should be descriptive of what they are and what part they are tied to.

All in all, I think the code is fine, but the interface isn't as friendly as I hoped, and there is a lot of excess machinery that I don't think is needed.

Hey, thanks for the comments! No worries, I knew that this is a controversial proposal ;). Your comments were reasonable, so I went ahead and took most of the changes you found questionable.
I avoided making this change, because I felt it would be too invasive, since it would require all users of the TS to be aware of *Trampoline, but I agree that this would be a better interface.
template<class F, class... Args> future<rettype> TaskScheduler::AddTask(F& function, Args&&... args);

Overall, it's looking very nice.
With the recent changes pulling it back down to C++11, my first question is: do we really need a contrib folder / #ifdef? In my opinion, just put trampoline.h in with all the other files. And get rid of the #ifdef for the tests, and always call them.

I think trampoline was just chosen because that's what the internal stuff is called in std::thread. If we do end up going with the TaskScheduler::AddTask(F& function, Args&&... args) style interface, all this would be hidden from the user anyhow.

Are we still planning on going with that interface? I somehow got the impression that this would be the interface itself.

I think the AddTasks() interface is cleaner, and helps to prevent potential memory issues. For example, when the user uses Trampoline directly, they must not use the same function returned from make_trampoline in more than one Task. Otherwise you'll get a double free. With the AddTasks(), this is all hidden from the user, so they don't need to worry about it.
What are your thoughts? Pros? Cons?

I definitely agree wholeheartedly. I also really don't know what the advantage of something like this is versus just using std::bind/std::function. That's what I used in my implementation and it was something on the order of 20 loc for the whole thing.


Added infobox for unaggro calibration

I would prefer to have just the infobox for the uncalibrated message instead of an option between both the infobox and the overlay panel

@Adam- Alexsuperfly and ron had a discussion in the discord channel and said that having the infobox only, would still result in people asking why the plugin is not working. That's why I changed it to being optional. As you can see in my "added infobox for calibration" commit, it was exactly like you just said, the infobox only.

I think that it should work like this comment details https://github.com/runelite/runelite/pull/17109#issuecomment-1875960335. As long as you always show the uncalibrated infobox that seems like it would be ok.

So reverting back to my previous commit should be fine then?


Remote plan spec

Finally I have a UC for the multiple remotes undef one symlink plan:
As we would like to cover Tiers execution by this I would like to have something as follows for e.g. rsyslog:
/rsyslog:
    /Sanity:
        /local-messaging:
            description: test local messages delivery
            test: ./runtest.sh
            tag: Tier1
    /Multihost:
        /tcp:
            description: deliver messages via tcp connection
            test: ./runtest.sh
            tag: Tier1multi
    /plans:
        /Tier1single:
            provision:
                how: virtual
            discover:
                how: fmf
                filter: "tag:Tier1"
            execute:
                how: tmt
        /Tier1multi:
            provision:
              - name: client
                how: virtual
              - name: server
                how: virtual
            discover:
                how: fmf
                filter: "tag:Tier1multi"
            execute:
                how: tmt
        /Tier1:
            remote-plan:
              - name: /plans/Tier1single
              - name: /plans/Tier1multi

the tier master's plan would contain:
/Tier1:
    /rsyslog:
        remote_plan:
            url: https://github.com/RedHat-SP-Security/tests
            name: /rsyslog/plans/Tier1

As rsyslog uses both single host and multi host tests for Tier1 testing this could be a way how to export both plans as one entity for Tier masters to handle. They would refer just to one plan per component which is actually the goal here. We do not want to make them to refer to all the component specific stuff (multiple plans base on the component needs - there may various reasons for having more Tier1 plans for a component)
Thus, we need to also support:

nesting as we cannot prevent from referencing another reference
prefixes generation (the final plan name should be made of the symlink name together with the reference/remote name), in case of nested references, the name would hold all of the plan names. e.g. rsyslog/Tier1/Tier1single and rsyslog/Tier1/Tier1multi.

@sopos, thank you for providing the detailed example. I understand the use case but I'm afraid your proposal for multiple references under a single plan symlink substantially complicates the implementation. Also, one symlink pointing to multiple locations sounds a bit weird. But the most important point is that it would not be possible to even list names of available plans using tmt plan ls without fetching remote stuff which seems to me as an unquestionable requirement.

Btw, there is https://pypi.org/project/xunitmerge/ , maybe we could use it to merge individual xunit files from individual runs so that results can be reported together.

@sopos, thank you for providing the detailed example. I understand the use case but I'm afraid your proposal for multiple references under a single plan symlink substantially complicates the implementation. Also, one symlink pointing to multiple locations sounds a bit weird. But the most important point is that it would not be possible to even list names of available plans using tmt plan ls without fetching remote stuff which seems to me as an unquestionable requirement.

It may sound weird if we call it a test plan symlink. It does not if we call it a plan of plans.
If this plan symlink is just another feature, then it's ok. Definitely there are some use cases for it, e.g. system upgrades testing.
For the Tiers testing we would probably want to see the plan of plans.

Btw, there is https://pypi.org/project/xunitmerge/ , maybe we could use it to merge individual xunit files from individual runs so that results can be reported together.

Thanks for the pointer. This might be useful when handling results locally or for the tier use case. But the important point is that the remote plan support in tmt will enable referencing remote plans seamlessly even within CI without any change in the pipelines. Otherwise the results aggregation would have to be implemented/handled there.

It may sound weird if we call it a test plan symlink. It does not if we call it a plan of plans.

Understood, but the question is not about how we call it but how we implement it. And here I see a substantial difference: While plan symlink should be easy (just clone the repo and load the plan from there) the plan of plans brings much more complexity.

If this plan symlink is just another feature, then it's ok. Definitely there are some use cases for it, e.g. system upgrades testing. For the Tiers testing we would probably want to see the plan of plans.

Yes, we can consider this first step as a separate feature. It will allow us to enable integration testing and can be used for tiers as well although with a bit of discomfort:
/rsyslog:
    /singlehost:
        plan:
            url: https://github.com/RedHat-SP-Security/tests
            name: /rsyslog/plans/Tier1single
    /multihost:
        plan:
            url: https://github.com/RedHat-SP-Security/tests
            name: /rsyslog/plans/Tier1multi

Inheritance could slightly help here as well if needed:
/rsyslog:
    plan:
        url: https://github.com/RedHat-SP-Security/tests

    /singlehost:
        plan+:
            name: /rsyslog/plans/Tier1single
    /multihost:
        plan+:
            name: /rsyslog/plans/Tier1multi

For the first PoC I'd say it's not that user unfriendly approach.

if there will be applied inheritance in this case, and if it is allowed, or in case not, we should explicitly mention this, that it is not allowed.

Good point! At least for the start I'd explicitly state that no other keys besides plan are supported. Will update the spec.

Thanks much to all for patientce and providing valuable feedback!

Seems github got confused by my repush, the merged commit for reference: https://github.com/teemtee/tmt/commit/0eea512722f85859e01cc52e0410f09c66278aaf


Using SystemUiOverlayStyle App crashes

I am using 3 Lib ScreenUtil - Getx and Country Code Picker in my project
When I try to hide entire app bar or bottom nav bar  and show it again the app keeps on getting crash.
In Case 1.)
When I remove  CountryLocalizations.delegate the app runs perfectly fine .
localizationsDelegates: const [
CountryLocalizations.delegate, //   Removing this precent app getting crash
],
In Case 2 )
I removed screen Util and kept only Getx  and found out the app no longer crashes.
PubSpec

dependencies:

  flutter:
    sdk: flutter

  get: ^4.6.1
  get_it: ^7.2.0
  flutter_screenutil: ^5.5.2
  path_provider: ^2.0.10
  country_code_picker: ^2.0.2

dev_dependencies:
  json_serializable: ^6.2.0
  build_runner: ^2.1.10
  retrofit_generator: ^4.0.1

  flutter_test:
    sdk: flutter

  flutter_lints: ^2.0.1

 return GestureDetector(
      onTap: () => Get.focusScope?.unfocus(),
      child: MediaQuery(
        data: MediaQueryData.fromWindow(WidgetsBinding.instance.window),
        child: ScreenUtilInit(
          splitScreenMode: false,
          minTextAdapt: true,
          designSize: const Size(393, 851),
          builder: (_) => GetMaterialApp(
              title: "Test",
              defaultTransition: Transition.fade,
              opaqueRoute: Get.isOpaqueRouteDefault,
              popGesture: Get.isPopGestureEnable,
              transitionDuration: Get.defaultDialogTransitionDuration,
              debugShowCheckedModeBanner: false,
              locale: LocalizationService.locale,
              translations: LocalizationService(),
              supportedLocales: languageSupported,
              localizationsDelegates: const [
                CountryLocalizations.delegate,     / /  Removing this to prevent the app getting crash
              ],
              themeMode: ThemeMode.light,
              builder: (context, widget) {
                return MediaQuery(
                  data: MediaQuery.of(context).copyWith(textScaleFactor: 1.0),
                  child: widget!,
                );
              },
              routingCallback: (routing) => RoutingApp.routingCallback(routing),
              initialRoute: RoutingApp.ScreenARoute,
              enableLog: true,
              getPages: RoutingApp.getRoutingPages()),
        ),
      ),
    );

Please find the sample project link for the reference to generate the crash
https://github.com/parmarravi/ScreenUtil-CountryCodePickerBug

Hi @parmarravi , please try to use key in MaterialApp.
ex:
MaterialApp(
  key: const GlobalObjectKey('my-app'),
)

Note: Don't close this issue, we will remain it open until we came up with a solution.

Solution Worked!!

It worked Thank you for the solution


issue

<EMAIL_ADDRESS>C:\Program Files\nodejs\node_modules\npm
C:\Users\amitseal>npm --version
6.4.1
C:\Users\amitseal>node --version
v8.12.0
C:\Users\amitseal>npx create-react-app my-app
Creating a new React app in C:\Users\amitseal\my-app.
Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...
npm ERR! Unexpected end of JSON input while parsing near '..."^0.3.5","matcha":"^0'
npm ERR!      C:\Users\amitseal\AppData\Roaming\npm-cache_logs\2018-09-13T15_32_19_917Z-debug.log
Aborting installation.
npm install --save --save-exact --loglevel error react react-dom react-scripts has failed.
Deleting generated file... package.json
Deleting my-app / from C:\Users\amitseal
Done.

Please run npm cache clear --force and try again, it should work!

solved after installing yarn

That's an option as well. 😄


Rename hardware attribute into profile

Profile basically defines user-agent's capabilities and influences the
subset of tests visible in the application. |hardware| name was quite
confusing, as the capabilities depend on both device and software
running the MVT.
Additionally, merge old hardware configs into a single profiles.js

Blackduck scan failure details
Summary: 0 violations, 0 files pending approval, 2 files pending identification.

Protex Server Path: /home/blackduck/github/MVT/7/rdkcentral/MVT

Commit: 961fdb2d2c887c59cd1ef8fab3e83ae61a00ed30

Report detail: gist


bevy_reflect: Reflect remote types

Objective
The goal with this PR is to allow the use of types that don't implement Reflect within the reflection API.
Rust's orphan rule prevents implementing a trait on an external type when neither type nor trait are owned by the implementor. This means that if a crate, cool_rust_lib, defines a type, Foo, then a user cannot use it with reflection. What this means is that we have to ignore it most of the time:
#[derive(Reflect)]
struct SomeStruct {
  #[reflect(ignore)]
  data: cool_rust_lib::Foo
}

Obviously, it's impossible to implement Reflect on Foo. But does it have to be?
Most of reflection doesn't deal with concrete types— it's almost all using dyn Reflect. And being very metadata-driven, it should theoretically be possible. I mean, serde does it.
Solution
Taking a page out of serde's book, this PR adds the ability to easily use "remote types" with reflection. In this context, a "remote type" is the external type for which we have no ability to implement Reflect.
This adds the #[reflect_remote(...)] attribute macro, which is used to generate "remote type wrappers". All you have to do is define the wrapper exactly the same as the remote type's definition:
// Pretend this is our external crate
mod cool_rust_lib {
  #[derive(Default)]
  struct Foo {
    pub value: String
  }
}

#[reflect_remote(cool_rust_lib::Foo)]
struct FooWrapper {
  pub value: String
}

Note: All fields in the external type must be public. This could be addressed with a separate getter/setter attribute either in this PR or in another one.

The macro takes this user-defined item and transforms it into a newtype wrapper around the external type and marks it as #[repr(transparent)]. The fields/variants defined by the user are simply used to build out the reflection impls. Therefore, the output generated by the macro would look something like:
#[repr(transparent)]
struct FooWrapper(pub cool_rust_lib::Foo);

// reflection impls...
// these will acknowledge and make use of the `value` field

Internally, the reflection API will pass around the FooWrapper and transmute it where necessary. All we have to do is then tell Reflect to do that. So rather than ignoring the field, we tell Reflect to use our wrapper using the #[reflect(remote = "...")] field attribute:
#[derive(Reflect)]
struct SomeStruct {
  #[reflect(remote = "FooWrapper")]
  data: cool_rust_lib::Foo
}

Other Macros & Type Data
Because this macro consumes the defined item and generates a new one, we can't just put our macros anywhere. All macros that should be passed to the generated struct need to come below this macro. For example, to derive Default and register its associated type data:
// ✅ GOOD
#[reflect_remote(cool_rust_lib::Foo)]
#[derive(Default)]
#[reflect(Default)]
struct FooWrapper {
  pub value: String
}

// ❌ BAD
#[derive(Default)]
#[reflect_remote(cool_rust_lib::Foo)]
#[reflect(Default)]
struct FooWrapper {
  pub value: String
}

FromReflect
FromReflect is unique in that it is also a very common reflection trait that is not automatically derived along with Reflect (see the FromReflect Ergonomics RFC). In fact, it's required for all fields within an enum.
In order to implement FromReflect, we simply add the FromReflect identifier to the end of the attribute's arguments:
#[reflect_remote(cool_rust_lib::Foo, FromReflect)]
struct FooWrapper {
  pub value: String
}

Note that this is the only trait that works like this.
Generics
Generics are forwarded to the generated struct as well. They should also be defined in the same order:
#[reflect_remote(RemoteGeneric<'a, T1, T2>)]
struct GenericWrapper<'a, T1, T2> {
  pub foo: &'a T1,
  pub bar: &'a T2,
}

Naming does not need to match the original definition's. Only order matters here.

Also note that the code above is just a demonstration and doesn't actually compile since we'd need to enforce certain bounds (e.g. T1: Reflect, 'a: 'static, etc.)

Nesting
And, yes, you can nest remote types:
#[reflect_remote(RemoteOuter)]
struct OuterWrapper {
  #[reflect(remote = "InnerWrapper")]
  pub inner: RemoteInner
}

#[reflect_remote(RemoteInner)]
struct InnerWrapper(usize);

Assertions
This macro will also generate some compile-time assertions to ensure that the correct types are used. It's important we catch this early so users don't have to wait for something to panic. And it also helps keep our unsafe a little safer.
For example, a wrapper definition that does not match its corresponding remote type will result in an error:
mod external_crate {
  pub struct TheirStruct(pub u32);
}

#[reflect_remote(external_crate::TheirStruct)]
struct MyStruct(pub String); // ERROR: expected type `String` but found `u32`

Note: Unfortunately, the expected/found terms have to be swapped in order to avoid additional complexity and code generation.

Generated Assertion
const _: () = {
  #[allow(non_snake_case)]
  fn assert_wrapper_definition_matches_remote_type(__remote__: external_crate::TheirStruct) {
    // ERROR: expected type `String` but found `u32`
    let _: String = __remote__.0;
  }
};

Additionally, using the incorrect type in a #[reflect(remote = "...")] attribute should result in an error:
mod external_crate {
  pub struct TheirFoo(pub u32);
  pub struct TheirBar(pub i32);
}

#[reflect_remote(external_crate::TheirFoo)]
struct MyFoo(pub u32);

#[reflect_remote(external_crate::TheirBar)]
struct MyBar(pub i32);

#[derive(Reflect)]
struct MyStruct {
  #[reflect(remote = "MyBar")] // ERROR: expected type `TheirFoo` but found struct `TheirBar`
  foo: external_crate::TheirFoo
}

Generated Assertion
const _: () = {
  struct RemoteFieldAssertions;

  impl RemoteFieldAssertions {
    fn assert__foo__is_valid_remote(foo: MyBar) {
      // ERROR: expected `external_crate::TheirFoo` but found `external_crate::TheirBar`
      let _: external_crate::TheirFoo = foo.0;
    }
  }
};

Discussion
There are a couple points that I think still need discussion or validation.

[ ] 1. Any shenanigans
If we wanted to downcast our remote type from a dyn Reflect, we'd have to first downcast to the wrapper then extract the inner type. This PR has a commit that addresses this by making all the Reflect::*any methods return the inner type rather than the wrapper type. This allows us to downcast directly to our remote type.
However, I'm not sure if this is something we want to do. For unknowing users, it could be confusing and seemingly inconsistent. Is it worth keeping? Or should this behavior be removed?

[ ] 2. Implementing Deref/DerefMut and From
We don't currently do this, but should we implement other traits on the generated transparent struct? We could implement Deref/DerefMut to easily access the inner type. And we could implement From for easier conversion between the two types (e.g. T: Into<Foo>).

[ ] 3. Should we define a getter/setter field attribute in this PR as well or leave it for a future one? I think this should be saved for a future PR

[ ] 4. Any foreseeable issues with this implementation?

Changelog

Added the #[reflect_remote(...)] attribute macro to allow Reflect to be used on remote types

This sounds really useful for any sort of editor or inspector in the future. Especially if a particular bevy plugin or non-bevy crate does not use the reflect types. I don't feel qualified to fully review this, as I don't know much about bevy's reflection stuff, but this PR is something that is needed!

I definitely need this for bevy_synthizer. Some of my types wrap theirs so I can use them as components. Unfortunately, for the moment I can't use any of these types in scenes, which is important since some of these components are audio-related properties that require specific tweaking per entity.

It appears that nesting remote reflect with FromReflect fails.
Example:
use bevy::reflect::reflect_remote;

mod remote {
    pub struct A;

    pub struct B {
        pub a: A,
    }
}

#[reflect_remote(remote::A, FromReflect)]
struct LocalA;

#[reflect_remote(remote::B, FromReflect)] // Error: the trait `FromReflect` is not implemented for `remote::A`
struct LocalB {
    #[reflect(remote = "LocalA")]
    pub a: remote::A,
}

Attributes on fields are lost when #[reflect_remote] is added.
mod remote {
    pub struct A {
        #[cfg(feature = "something")]
        pub a: i32,
    }
}

#[reflect_remote(remote::A)]
pub struct LocalA {
    #[cfg(feature = "something")]
    pub a: i32, // Error: no field `a` on type `remote::A`
}

@devil-ira The nesting issue should be resolved (as well as an issue with generics that I discovered while trying to fix it).
Unfortunately, I'm not sure how to go about fixing the attribute issue. It seems the best way to handle this (without adding complexity/specialized logic) would be to just add the attribute to the entire item:
mod remote {
    pub struct A {
        #[cfg(oof)]
        pub a: i32,
    }
}

#[cfg(not(oof))]
#[reflect_remote(remote::A)]
pub struct LocalA {}

#[cfg(oof)]
#[reflect_remote(remote::A)]
pub struct LocalA {
    pub a: i32,
}

I think if we want to fix this, it should probably happen in a followup PR.

@devil-ira The nesting issue should be resolved (as well as an issue with generics that I discovered while trying to fix it).
Unfortunately, I'm not sure how to go about fixing the attribute issue. It seems the best way to handle this (without adding complexity/specialized logic) would be to just add the attribute to the entire item:
mod remote {
    pub struct A {
        #[cfg(oof)]
        pub a: i32,
    }
}

#[cfg(not(oof))]
#[reflect_remote(remote::A)]
pub struct LocalA {}

#[cfg(oof)]
#[reflect_remote(remote::A)]
pub struct LocalA {
    pub a: i32,
}

I think if we want to fix this, it should probably happen in a followup PR.

This feature would be very useful for displaying more information in bevy-inspector-egui. Currently a lot of very simple structs can't be debugged, just because I don't own them...

Rebased onto main. Also improved the generated assertions to output for all Reflect derives rather than just for #[reflect_remote(...)] attributes. This ensures the correct type is used in any reflected struct/enum that uses a remote type.

Added another assertion that ensures wrapper definitions match their remote types (see PR description for details).

Rebased.
Also, added a commit that updates the assertion for reflect_remote so that we no longer display the types in "reverse" order (i.e. no longer expected IncorrectType, found CorrectType). It also now correctly attributes the assertion to the macro.
Let me know if I should revert this change. While it does make a bit more sense imo, it also makes the error output slightly more verbose (with some mangled hints).

Examples
Example 1
mod external_crate {
    #[derive(Debug, Default)]
    pub struct TheirType {
        pub value: String,
    }
}

#[reflect_remote(external_crate::TheirType)]
#[derive(Debug, Default)]
#[reflect(Debug, Default)]
struct MyType {
    pub value: Foo,
}

#[derive(Debug, Reflect)]
struct Foo;

Before
error[E0308]: mismatched types
    --> crates/bevy_reflect/src/lib.rs:1667:9
     |
1667 |         #[reflect_remote(external_crate::TheirType)]
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `Foo`, found `String`
...
1671 |             pub value: Foo,
     |                        --- expected due to this
     |
     = note: this error originates in the attribute macro `reflect_remote` (in Nightly builds, run with -Z macro-backtrace for more info)

After
error[E0308]: mismatched types
    --> crates/bevy_reflect/src/lib.rs:1671:24
     |
1667 |         #[reflect_remote(external_crate::TheirType)]
     |         --------------------------------------------
     |         |
     |         expected due to the type of this binding
     |         in this procedural macro expansion
...
1671 |             pub value: Foo,
     |                        ^^^ expected `String`, found `Foo`
     |
     = note: this error originates in the attribute macro `reflect_remote` (in Nightly builds, run with -Z macro-backtrace for more info)

Example 2
mod external_crate {
    #[derive(Debug, Default)]
    pub struct TheirType {
        pub value: String,
    }
}

#[reflect_remote(external_crate::TheirType)]
#[derive(Debug, Default)]
#[reflect(Debug, Default)]
struct MyType {
    pub value: Foo,
}

#[derive(Debug, Reflect)]
struct Foo;

impl Into<String> for Foo {
    fn into(self) -> String {
        todo!()
    }
}

Before
error[E0308]: mismatched types
    --> crates/bevy_reflect/src/lib.rs:1667:9
     |
1667 |         #[reflect_remote(external_crate::TheirType)]
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `Foo`, found `String`
...
1671 |             pub value: Foo,
     |                        --- expected due to this
     |
     = note: this error originates in the attribute macro `reflect_remote` (in Nightly builds, run with -Z macro-backtrace for more info)

After
error[E0308]: mismatched types
    --> crates/bevy_reflect/src/lib.rs:1671:24
     |
1667 |         #[reflect_remote(external_crate::TheirType)]
     |         --------------------------------------------
     |         |
     |         expected due to the type of this binding
     |         in this procedural macro expansion
...
1671 |             pub value: Foo,
     |                        ^^^ expected `String`, found `Foo`
     |
     = note: this error originates in the attribute macro `reflect_remote` (in Nightly builds, run with -Z macro-backtrace for more info)
help: call `Into::into` on this expression to convert `tests::foo::Foo` into `std::string::String`
     |
1671 |             pub value: Foo.into(),
     |                           +++++++

Example 3
mod external_crate {
    #[derive(Debug, Default)]
    pub enum TheirType {
        #[default]
        Unit,
        Tuple(usize),
        Struct {
            value: String,
        },
    }
}

#[reflect_remote(external_crate::TheirType, FromReflect)]
#[derive(Debug)]
#[reflect(Debug)]
enum MyType {
    Unit,
    Tuple(i32),
    Struct { value: f32 },
}

Before
error[E0308]: mismatched types
    --> crates/bevy_reflect/src/lib.rs:1713:9
     |
1713 |         #[reflect_remote(external_crate::TheirType, FromReflect)]
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `i32`, found `usize`
...
1718 |             Tuple(i32),
     |                   --- expected due to this
     |
     = note: this error originates in the attribute macro `reflect_remote` (in Nightly builds, run with -Z macro-backtrace for more info)
help: you can convert a `usize` to an `i32` and panic if the converted value doesn't fit
     |
1713 |         #[reflect_remote(external_crate::TheirType, FromReflect)].try_into().unwrap()
     |                                                                  ++++++++++++++++++++

error[E0308]: mismatched types
    --> crates/bevy_reflect/src/lib.rs:1713:9
     |
1713 |         #[reflect_remote(external_crate::TheirType, FromReflect)]
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `f32`, found `String`
...
1719 |             Struct { value: f32 },
     |                             --- expected due to this
     |
     = note: this error originates in the attribute macro `reflect_remote` (in Nightly builds, run with -Z macro-backtrace for more info)

After
error[E0308]: mismatched types
    --> crates/bevy_reflect/src/lib.rs:1718:19
     |
1713 |           #[reflect_remote(external_crate::TheirType, FromReflect)]
     |           ---------------------------------------------------------
     |           |
     |  _________in this procedural macro expansion
     | |
1714 | |         #[derive(Debug)]
1715 | |         #[reflect(Debug)]
1716 | |         enum MyType {
1717 | |             Unit,
1718 | |             Tuple(i32),
     | |                   ^^-
     | |___________________|_|
     |                     | expected due to the type of this binding
     |                     expected `usize`, found `i32`
     |
     = note: this error originates in the attribute macro `reflect_remote` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
    --> crates/bevy_reflect/src/lib.rs:1719:29
     |
1713 |         #[reflect_remote(external_crate::TheirType, FromReflect)]
     |         --------------------------------------------------------- in this procedural macro expansion
...
1719 |             Struct { value: f32 },
     |                             ^^^- help: try using a conversion method: `.to_string()`
     |                             |
     |                             expected `String`, found `f32`
     |                             expected due to the type of this binding
     |
     = note: this error originates in the attribute macro `reflect_remote` (in Nightly builds, run with -Z macro-backtrace for more info)

Update: Added the unsafe ReflectRemote trait.
This trait is implemented automatically when using #[reflect_remote], and indicates that the implementor is safe to use as a remote wrapper. The trait is then used inside a compile-time assertion.
This should help prevent people from doing something like:
#[derive(Reflect, Debug)]
struct ContainerStruct {
  #[reflect(remote = "InvalidWrapper")]
  their_type: external_crate::TheirType,
}

#[derive(Reflect, Debug)]
struct InvalidWrapper(#[reflect(ignore)] external_crate::TheirType);

We could use the autoref specialization trick to print a custom error message indicating to the user to use #[reflect_remote]. However, since the error points back to ReflectRemote and the docs for it say to use #[reflect_remote], we probably don't need to do this.

Updated the PR to support Bevy 0.11.
This removes the need for the special FromReflect opt-in since now that FromReflect is derived by default.
I also updated ReflectRemote:

It no longer is unsafe to implement
It now defines methods related to remote and wrapper types (e.g. into_remote, into_wrapper, etc.).

The methods on ReflectRemote could likely have default implementations. However, I chose not to do this so as to make it harder for users to accidentally shoot themselves in the foot by doing something like:
#[derive(Reflect)]
struct NotSafeToMakeRemote {
  foo: i32
}

impl ReflectRemote for NotSafeToMakeRemote {
  type Remote = SomeRemoteType;
}

Implementing Deref/DerefMut and From

We don't currently do this, but should we implement other traits on the generated transparent struct? We could implement Deref/DerefMut to easily access the inner type. And we could implement From for easier conversion between the two types (e.g. T: Into).

I don't see why most of these would be useful, except maybe for FooWrapper::from(foo). From what I understand, the generated transparent struct is not meant to be used directly by users. The only place where it should be used is as the argument to #[reflect(remote =, and in the case described by (1) below. Otherwise, the user just sees the original struct everywhere else. Is my assumption incorrect?

Any shenanigans

If we wanted to downcast our remote type from a dyn Reflect, we'd have to first downcast to the wrapper then extract the inner type. This PR has a commit that addresses this by making all the Reflect::*any methods return the inner type rather than the wrapper type. This allows us to downcast directly to our remote type.
However, I'm not sure if this is something we want to do. For unknowing users, it could be confusing and seemingly inconsistent. Is it worth keeping? Or should this behavior be removed?

I don't think this is too confusing as long as the generated struct type doesn't implement Reflect, only ReflectRemote, similar to how serde differentiates them:

The code ultimately generated by these remote derives are not Serialize and Deserialize impls but associated functions with the same signature.

So the rule would be: Methods on a Reflect type return itself. Methods on ReflectRemote type return the inner type.
As far as converting between the two types, it seems to only go one way: you need to call FooWrapper(foo).as_any() (or FooWrapper::from(foo).as_any() or FooWrapper::wrap(foo).as_any()) but you never have a FooWrapper lying around that you need to get Foo out of (so you never need to call Foo::from(foo_wrapper)). Again, is my understanding of how this would be used correct? I quite possibly am forgetting about important use cases, not being deeply familiar with bevy_reflect.
Passing around FooWrapper rather than doing the conversion only when needed would probably be bad style, but there may be extreme cases where the user needs to do it anyway, though I can't think of any right now. And they would still be able to use .0, peel, or peel_mut (or whatever the equivalent would be for ReflectRemote if not using TransparentWrapper. This, btw, is a weak argument for using TransparentWrapper, not for its implementation, but for its well-understood and well-documented semantics.

This, btw, is a weak argument for using TransparentWrapper, not for its implementation, but for its well-understood and well-documented semantics.

Yeah, I'm thinking it may be worth looking into using TransparentWrapper directly. It doesn't really do anything we don't already do here, but it has better safety assertions/documentation.
We could also just copy+paste the specific parts we need (since we really only need these six methods).
Whether we decide to use bytemuck or not, I think it's best to explore that in a future PR so that this one isn't further blocked/delayed more than it already has been.

I once again marked ReflectRemote as unsafe because I noticed that bytemuck's TransparentWrapper is also marked as unsafe. Until we explore using TransparentWrapper directly in a future PR, it's probably best to at least align with it there.

TransparentWrapper is unsafe because it explicitly guarantees that every type implementing it is marked with #[repr(transparent)]. there's no way to prove that in the system, so it's unsafe because implementors must manually assert that the implementee has a valid #[repr(transparent)] annotation.
that's not needed for ReflectRemote. it would be perfectly sound to implement ReflectRemote in any and every way, excluding of course where the method bodies are unsound in isolation which isn't grounds for making the trait unsafe. there's nothing we need to manually assert for ReflectRemote and relevant systems to be sound, just that weird implementations might produce logic errors.
RemoteReflect is more like ref_cast::RefCast than bytemuck::TransparentWrapper

TransparentWrapper is unsafe because it explicitly guarantees that every type implementing it is marked with #[repr(transparent)]. there's no way to prove that in the system, so it's unsafe because implementors must manually assert that the implementee has a valid #[repr(transparent)] annotation.

Oh that's true. It would only be "unsafe" if we provided the methods with the transmutations. But since those are only generated along with repr(transparent), it should be perfectly fine.
Am I understanding that right?
If so, I can undo that last commit (again lol).

yep that's all correct!

I like the last minute reflect remote value addition! Let's get this merged :)

Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to https://github.com/bevyengine/bevy-website/issues/1674 if you'd like to help out.


Fix: rm desynchronized: true

Resolves #2831.

can you do the same for the progress canvas? the main canvas is not black anymore but anything in the progress canvas is


ENH: Keep netCDF files open

We have a bunch of functions in the image driver that operate on netCDF files, they all look something like this:
int
get_x_from_nc_file(char   *nc_name,
                   char   *var_name,
                   size_t *x)
{

    ...

    // open the netcdf file
    status = nc_open(nc_name, NC_NOWRITE, &nc_id);
    if (status != NC_NOERR) {
        log_err("Error opening %s", nc_name);
    }

    /* get NetCDF variable */
    status = nc_inq_varid(nc_id, var_name, &var_id);
    if (status != NC_NOERR) {
        log_err("Error getting variable id for %s in %s", var_name, nc_name);
    }

...

    // close the netcdf file
    status = nc_close(nc_id);
    if (status != NC_NOERR) {
        log_err("Error closing %s", nc_name);
    }

    return status;
}

We end up redundantly opening and closing the parameter, forcings, and domain files.  I think @wietsefranssen has already reported that keeping the forcing file open speeds up the image driver considerably, the next step would be to extend that to all netcdf files in the image driver, removing the open/close lines from many of these functions.  We will just need to create structures to store the file pointers (e.g. nc_id) and functions to open/close them at the beginning and end of a simulation.
@bartnijssen, am I missing anything here?

This was just implemented that way for expediency sake when doing the first implementation. We definitely want to keep the files open during the run, since the reopening of the files brings a lot of overhead for netcdf files. Similarly we'll want to keep the output files open for as long as we can.
Note though that you cannot necessarily keep the files open for the duration of the simulation since the files maybe organized by year. So you need to store the start and end time of a file and figure out whether you need to open a new file or can reuse the one that is already open.

A while ago I did a little test with keeping the files open and it indeed increased the running time a lot.
I am looking forward to the changes!

Me too!

Bumping this to 5.1. I think we already have a few ways of how we may want to implement this. Not sure how separate this is from #538 (seems mostly a duplicate to me, so we could potentially get rid of at least one of them).

Rather than using nc_open and nc_close every time we read a netcdf entry (field, dimension, variable, attribute, etc), we should nc_close only once (take it out of the read functions) and check whether the file is open before we call nc_open. For example, you could expand the use of nc_file_struct (https://github.com/UW-Hydro/VIC/blob/master/vic/drivers/shared_image/include/vic_driver_shared_image.h#L104-L142) and pass or perhaps something simpler instead of the filename to the functions that read fields. For example:
/******************************************************************************
 * @brief    Read double precision netCDF field from file.
 *****************************************************************************/
int
get_nc_field_double(char   *nc_name,
                    char   *var_name,
                    size_t *start,
                    size_t *count,
                    double *var)
{
    int nc_id;
    int status;
    int var_id;

    // open the netcdf file
    status = nc_open(nc_name, NC_NOWRITE, &nc_id);
    check_nc_status(status, "Error opening %s", nc_name);

could become
/******************************************************************************

@brief    Read double precision netCDF field from file.
*****************************************************************************/
int
get_nc_field_double(nc_file_struct   *nc_file,
char   *var_name,
size_t *start,
size_t *count,
double *var)
{
int nc_id;
int status;
int var_id;
// open the netcdf file
if (nc_file->open == FALSE) {
status = nc_open(nc_file->name, NC_NOWRITE, &nc_id);
check_nc_status(status, "Error opening %s", nc_file->name);
nc_file->open = TRUE
}

When you call `nc_close()` you would then also do `ncfile->open = FALSE`.

As said you will have to think a bit on how to implement this, but it will likely increase the initialization by a lot, because we open and close the files many times, which with netcdf invokes a lot of overhead. As said at the start of this issue: the current implementation was simply for expediency sake while implementing netcdf in VIC. It was never end as the production solution, so I'll leave it up to @yixinmao to implement the production version.

Closed per #684


update testing to improve coverage

Coverage increased (+2.1%) to 68.89% when pulling 52d8aba977cfaac9494b966899f4ca78cca91698 on update_testing_to_improve_coverage into 227cf202d6ec8da639d8cf3470edd971c2c67dad on master.


Minimap Icon

I have my options set to not show the minimap icon, but it won't go away.

I am having the same issue as ReclusiveSpyder as are all my friends who use the add on.  I set the mini map option to not display and it does.  When I try to move it out of the position it defaults to it always goes back to the original default position too.  It is getting really annoying now.

I really need more info on how to recreate this.  I’ve tested with both standard up and ElvUI and I can’t get this to happen.  If anything I have gotten the reverse where it doesn’t appear when it should.
TimothyLuke

On 11 Aug 2019, at 3:30 pm, kazleesi<EMAIL_ADDRESS>wrote:
I am having the same issue as ReclusiveSpyder as are all my friends who use the add on. I set the mini map option to not display and it does. When I try to move it out of the position it defaults to it always goes back to the original default position too. It is getting really annoying now.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Agree with @ReclusiveSpyder @kazleesi .
To me happens mostly when mouseover on minimap icon.
And of course, the minimap icon, dont go away, even repositioning it.
Hope this helps @TimothyLuke
Cheers.
Dump Error Info.txt

Ok Found the saving thing and fixed that
now working on the drag error


Does not work on Metal-less macOS

Describe the bug
Trying to run using the 0.3.1-alpha2 version will panic at orbtk_shell::platform::WindowBuilder<A>::build with Failed to create window "Unable to open Window" on Metal-less macOS
To Reproduce
Steps to reproduce the behavior:

Add orbtk = "0.3.1-alpha2" to your dependencies
Copy the minimal example
cargo run

Expected behavior
To work on any x64 macOS (don't panic!())
Desktop (please complete the following information):
macOS 10.13 (High Sierra), with no Metal
Additional context
Support for non-metal macOS is missing from minifb (see https://github.com/emoon/rust_minifb/issues/140), but since it worked in 0.2 and older mac machines are pretty popular (as they still run fast and the upgrade cost is pretty high), I'm posting here to raise awareness.
Also, if this is intentional, it should be at least advertised in the "Platforms" section of the README.

I’m working on an alternative backend. Could you check the pathfinder branch and run: cargo run — example widgets — features pathfinder and let me now if it run on your metalless macOS.

Very nice! It partially works (open and render widgets) with "Selected" incorrectly (?) over the list and 100% usage on one of my cores. I also cannot interact with anything, but its probably because its hanging the core.
Not sure if that's just the current state of the backend, but I can try to do some perf / flamegraph to identify the culprit.

Ok really nice, thank you. Yes it’s the current state. I will continue my work on the new backend soon.

@pheki could you also check the orbclient branch please? I have to check if it works also on metal less macOS.

Short answer: I think so.
Long answer:
It kind of works (takes very long to init and after that, when I move the mouse over it glitches), sometimes it hangs my CPU for seconds. I actually compiled on a newer macOS, in both debug and release mode (to try help with the CPU usage), while the hang seemed shorter on release the glitches are the same.

Metal-less screenshots

With Metal (also more recent macOS) screenshots

Could you recheck it please? It is now merged in develop.

There are many improvements now. I close this now. If there are still issues you can reopen it.

Sorry for the delay... It works!
Thanks a lot 😄

You're welcome.


Changing namespace to be a tuple.

Closes #290

Also can we update client/server example to show using namespace tuple


Accommodate trailing slash in repo override

@paetling Fixes #673. Will write a test and finish it when I have time, but think this'll do it.

Side note I hate HFS so much.

seems alright.

CI is busted probably from recent Mac rejiggering in the Jenkins cluster


Change TextFiled Type for Lateral Student

UPDATE:
keyboard input type number to text for username at Login Page because some alphabetic characters are required for lateral entry student.
e.g. my username is 2######D194 (# --> Integar Character)

Thanks, update will be published on play store.


Auto-complete should also complete namespaces and not only class/interface names

I would expect to be able to type "Progress." and get auto-complete suggestions.
If I do that in OEDT I get:

If I do that in VSCode I get:

That "using" code completion is very PDSOE-esque 😆

That "using" code completion is very PDSOE-esque 😆

I don't expect the LS to provide this kind of options. Is that a snippet in your environment?

And regarding the issue, yes, that will be improved

That "using" code completion is very PDSOE-esque 😆

I don't expect the LS to provide this kind of options. Is that a snippet in your environment?

No, none of the 3 presented options are snippets.

No, none of the 3 presented options are snippets.

Interesting because according to the icon, this should come from a snippet. Even funnier is that the exact same issue was reported by @PeterJudgeZA some time ago. With the same typo in routing-level on error ... in the description of routine-level.... As snippets can be provided by extension, I had a look at the other ABL extensions (not a very long list...), and found the snippet: https://github.com/kenherring/ablunit-test-runner/blob/prerelease-0.2.7/snippets/snippets-abl.json#L9
I opened PR kenherring/ablunit-test-runner#201 to fix this typo.

I didn't know snippets could be provided by an extension...
And in this case I would rather not have these presented (they seem a bit out of scope for an ABLUnit Test Runner extension in my opinion).
Is there a way to suppress or exclude these @kenherring ?

Will be included in 1.15.3

I lied, that's in 1.15.4 (currently on its way to the marketplace)


String algorithm

Best string algorithms:

[x] String Hashing

[x] Rabin-Karp for String Matching

[x] Prefix function - Knuth-Morris-Pratt

[x] Z-function

[x] Suffix Array

[ ] Aho-Corasick algorithm

Can  I work on string hashing and Rabin Karp algorithm in python

Thankyou @shaswatsingh19 for the issue. Sure. Assigning String hashing and Rabin Karp to you.
Please be sure that you place this in  python folder with the name "string algorithms". Thankyou :)

Can I work on the suffix array in Python @geekquad

Hi @geekquad ,
I can work on the Z-Algorithm and Knuth-Morris-Pratt
Can you assign those to me? ✌

Assigning Suffix Array to @sachincpu
Assigning Z-Algorithm and Knuth-Morris-Pratt to @malhotra-paritosh

Hello @geekquad, I would like to work on this issue :)
should I add levenshtein_distance and  naive match string algorithm?
Thank you :)

Hey @geekquad I would like to add another Pattern Searching Algorithm.
Can I work on Finite Automata algorithm for Pattern Searching?

I have completed rabin karp PR issue #84 please check

@hritik5102 @panda311 , We'll soon be adding another issue with more string and Pattern Searching related Algorithms. Till then, we still have Aho-corasick Algorithm, You guys can work on it. Happy Coding :)

I would like to work Aho-corasick using CPP.

@hritik5102 @panda311 , We'll soon be adding another issue with more string and Pattern Searching related Algorithms. Till then, we still have Aho-corasick Algorithm, You guys can work on it. Happy Coding :)

I would like to work Aho-corasick using CPP.

Assigning Aho-corasick  to @hritik5102.

@hritik5102 @panda311 , We'll soon be adding another issue with more string and Pattern Searching related Algorithms. Till then, we still have Aho-corasick Algorithm, You guys can work on it. Happy Coding :)

I would like to work in Aho-corasick algorithm using CPP.
@hritik5102 , since we haven't moved to any other language than python, so please try to stick to it for now. We'll soon be moving on to other languages as well.

@hritik5102 @panda311 , We'll soon be adding another issue with more string and Pattern Searching related Algorithms. Till then, we still have Aho-corasick Algorithm, You guys can work on it. Happy Coding :)

I would like to work in Aho-corasick algorithm using CPP.

@hritik5102 , since we haven't moved to any other language than python, so please try to stick to it for now. We'll soon be moving on to other languages as well.

Can I work on rabin karp algorithm in Python? I can do in Cpp as well.

Hey @anands97, sorry for the delay. It is up for grab for python as of now. Do let me know if you want to work on the issue.

@geekquad, can I work on Robin Karp algorithm in Python?

Assigning Rabin-Karp for String Matching to @srirupa19.

I can do string hashing in python as well as cpp. Please assign me

Assigning String Hashing to @aditkumar72. For cpp please go to the specific issue and ask for assignment there itself. Thankyou.

Added String Hashing Algorithm #409

Best string algorithms:

[x]  ~String Hashing~
[x]  ~Rabin-Karp for String Matching~
[x]  ~Prefix function - Knuth-Morris-Pratt~
[x]  ~Z-function~
[x]  ~Suffix Array~
[ ]  Aho-Corasick algorithm

Hello. I want to work on Aho-Corasick Algorithm

Assigning Aho-Corasick Algorithm to @manish2202.

Hi
Is the Aho-Corasick algorithm still available?
I would like to work on it

Hi,
Is the Aho- Corasick algorithm available to work on?
Can you please assign it to me?


build: use http_archive instead of git_repository

Description: This will hopefully allow for both faster and more reliable builds. http_archive contains built-in retry logic, and pulls down smaller artifacts (no history).
Risk Level: Low
Testing: Local and CI
Signed-off-by: Mike Schore<EMAIL_ADDRESS>

FWIW git_repository also doesn't pull down history https://github.com/bazelbuild/bazel/blob/49ea9589f0255b0250cb4438cab88eceb91be62d/tools/build_defs/repo/git_worker.bzl#L52 and there is 1 (mostly theoretical but has happened once before) risk with using http_archive. The problem is that GitHub's tars are generated as needed, so when you lock the sha, if they update their version of tar, the sha could change. This happened at one point when they did an OS update on their machines. But realistically it's probably fine to ignore this and fix it if that happens.

Good points. Even if we are avoiding pulling down history (though my read of that code is that we're maybe still pulling down some unless shallow_since is set really precisely?), the main win (hopefully) here will be the built-in retry logic in http_archive helping us around the connection flakiness we've seen in azure/github actions.
Good callout on the potential sha issue. Something to keep an eye out for.

We should be setting shallow_since because otherwise Bazel warns too. But I think this is safe to test!

Thank you @keith and @artem-zinnatullin!


Add RedirectToPage helper methods to Controller

We need to add RedirectToPage to controllers. This should go on Controller and include all of the needed variations for permanent/preservemethod

assigned @ryanbrandenburg - please go ahead and get this ready. You might run into https://github.com/aspnet/Mvc/issues/6140 or something similar.

Load balancing


Fix the line numbers for literalinclude.

removed line-height: normal from .highlight > pre, .linenodiv > pre
because only .highlight > pre gets changed.

Otherwise you get line numbers like this.

I think the lines can just be  removed

I will take a look Monday.

While this fixes the issue, I think a proper solution would be to replace those lines with:
pre
    line-height: normal

Can you confirm that this works for you? This should fix the issue and not change the spacing.

I'll check it tomorrow please verify my css file. I guess lines 21->23 should be removed before testing.

The real issue comes from: https://github.com/snide/wyrm/blob/fd41b56978f009e8c33cb26f384dd0dfaf430a7d/sass/wyrm_addons/pygments/_pygments.sass#L49 which is getting more priority than our css. So maybe this needs a !important.

Any idea when this fix will be published ?

We are trying to release an update of the the theme however, things have
been slow lately. I will try to get things moving again.
On Aug 27, 2017 3:59 AM, "Tony Flury"<EMAIL_ADDRESS>wrote:

Any idea when this fix will be published ?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/rtfd/sphinx_rtd_theme/pull/422#issuecomment-325188728,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOeua7nVDZe4WAACZQEORRHEYfI1Qwduks5scT4VgaJpZM4NhXvw
.

You can avoid !important by using more specificity in your selector.
This issue this is referencing is not clear to me, what is the problem this is solving?

Line numbers and lines were not aligned in code snippets.
Currently I am not able to reproduce the bug with the latest version.
Closing.

Current version on pypi is still 0.2.4 - (i.e. not the master) therefore the bug still exists in the current live version. When will the master being release to pypi ?


IGNITE- 22264 Fix startup instructions in Ignite examples

https://issues.apache.org/jira/browse/IGNITE-22264
Thank you for submitting the pull request.
To streamline the review process of the patch and ensure better code quality
we ask both an author and a reviewer to verify the following:
The Review Checklist

[ ] Formal criteria: TC status, codestyle, mandatory documentation. Also make sure to complete the following:
- There is a single JIRA ticket related to the pull request.
- The web-link to the pull request is attached to the JIRA ticket.
- The JIRA ticket has the Patch Available state.
- The description of the JIRA ticket explains WHAT was made, WHY and HOW.
- The pull request title is treated as the final commit message. The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
[ ] Design: new code conforms with the design principles of the components it is added to.
[ ] Patch quality: patch cannot be split into smaller pieces, its size must be reasonable.
[ ] Code quality: code is clean and readable, necessary developer documentation is added if needed.
[ ] Tests code quality: test set covers positive/negative scenarios, happy/edge cases. Tests are effective in terms of execution time and resources.

Notes

Apache Ignite Coding Guidelines

Closing to add Docker node startup instructions.


Introduced fuzzing by adding first fuzzer

This PR adds a fuzzer to Kingpin and raises the question to the Kingpin community if there is interest in fuzzing Kingpin.
The fuzzer can be run locally, or we can see if oss-fuzz will integrate Kingpin into their project to run this fuzzer and future fuzzers continuously.
If any of Kingpins users would like to introduce fuzzing to Kingpin and will look into the potential bugs that fuzzing finds, I will be happy to work more on fuzzing the library.

Hi Adam, I would say in lieu of someone picking up maintainership of Kingpin, that this is probably time better spent elsewhere. Thanks for the PR though.


======== Exception caught by animation library =====================================================

logs
======== Exception caught by animation library =====================================================
The following assertion was thrown while notifying listeners for AnimationController:
'package:flutter/src/rendering/object.dart': Failed assertion: line 1627 pos 12: '_debugCanPerformMutations': is not true.

Either the assertion indicates an error in the framework itself, or we should provide substantially more information in this error message to help you determine and fix the underlying cause.
In either case, please report this assertion by filing a bug on GitHub:
  https://github.com/flutter/flutter/issues/new?template=2_bug.md

When the exception was thrown, this was the stack:
#2      RenderObject.markNeedsLayout (package:flutter/src/rendering/object.dart:1627:12)
#3      RenderBox.markNeedsLayout (package:flutter/src/rendering/box.dart:2370:11)
#4      new RenderAnimatedSize.<anonymous closure> (package:flutter/src/rendering/animated_size.dart:99:9)
#5      AnimationLocalListenersMixin.notifyListeners (package:flutter/src/animation/listener_helpers.dart:155:19)
#6      AnimationController._animateToInternal (package:flutter/src/animation/animation_controller.dart:602:9)
#7      AnimationController.forward (package:flutter/src/animation/animation_controller.dart:461:12)
#8      RenderAnimatedSize._layoutStable (package:flutter/src/rendering/animated_size.dart:303:19)
#9      RenderAnimatedSize.performLayout (package:flutter/src/rendering/animated_size.dart:224:9)
#10     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
#11     RenderPositionedBox.performLayout (package:flutter/src/rendering/shifted_box.dart:437:14)
#12     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
#13     RenderProxyBoxMixin.performLayout (package:flutter/src/rendering/proxy_box.dart:116:14)
#14     _RenderCustomClip.performLayout (package:flutter/src/rendering/proxy_box.dart:1376:11)
#15     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
#16     RenderProxyBoxMixin.performLayout (package:flutter/src/rendering/proxy_box.dart:116:14)
#17     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
#18     RenderProxyBoxMixin.performLayout (package:flutter/src/rendering/proxy_box.dart:116:14)
#19     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
#20     RenderSliverList.performLayout (package:flutter/src/rendering/sliver_list.dart:213:28)
#21     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
#22     RenderSliverEdgeInsetsPadding.performLayout (package:flutter/src/rendering/sliver_padding.dart:137:12)
#23     RenderSliverPadding.performLayout (package:flutter/src/rendering/sliver_padding.dart:371:11)
#24     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
#25     RenderViewportBase.layoutChildSequence (package:flutter/src/rendering/viewport.dart:510:13)
#26     RenderViewport._attemptLayout (package:flutter/src/rendering/viewport.dart:1580:12)
#27     RenderViewport.performLayout (package:flutter/src/rendering/viewport.dart:1489:20)
#28     RenderObject._layoutWithoutResize (package:flutter/src/rendering/object.dart:1757:7)
#29     PipelineOwner.flushLayout (package:flutter/src/rendering/object.dart:887:18)
#30     RendererBinding.drawFrame (package:flutter/src/rendering/binding.dart:504:19)
#31     WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:892:13)
#32     RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:370:5)
#33     SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1146:15)
#34     SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1083:9)
#35     SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:997:5)
#39     _invoke (dart:ui/hooks.dart:151:10)
#40     PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:308:5)
#41     _drawFrame (dart:ui/hooks.dart:115:31)
(elided 5 frames from class _AssertionError and dart:async)
The AnimationController notifying listeners was: AnimationController#390e4(⏮ 1.000; paused)
====================================================================================================

======== Exception caught by animation library =====================================================
The following assertion was thrown while notifying listeners for AnimationController:
'package:flutter/src/rendering/object.dart': Failed assertion: line 1627 pos 12: '_debugCanPerformMutations': is not true.

app> flutter doctor -v
[√] Flutter (Channel stable, 3.0.5, on Microsoft Windows [Version 10.0.22000.856], locale en-US)
• Flutter version 3.0.5 at C:\src\flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision f1875d570e (9 weeks ago), 2022-07-13 11:24:16 -0700
• Engine revision e85ea0e79c
• Dart version 2.17.6
• DevTools version 2.12.2
[√] Android toolchain - develop for Android devices (Android SDK version 32.1.0-rc1)
• Android SDK at C:\Users\h\AppData\Local\Android\sdk
• Platform android-33, build-tools 32.1.0-rc1
• Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
• Java version OpenJDK Runtime Environment (build 11.0.12+7-b1504.28-7817840)
• All Android licenses accepted.
[√] Chrome - develop for the web
• Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe
[√] Visual Studio - develop for Windows (Visual Studio Community 2022 17.2.0)
• Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
• Visual Studio Community 2022 version 17.2.32505.173
• Windows 10 SDK version 10.0.19041.0
[√] Android Studio (version 2021.2)
• Android Studio at C:\Program Files\Android\Android Studio
• Flutter plugin can be installed from:
https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 11.0.12+7-b1504.28-7817840)
[√] VS Code (version 1.71.0)
• VS Code at C:\Users\h\AppData\Local\Programs\Microsoft VS Code
• Flutter extension version 3.48.0
[√] Connected device (3 available)
• Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.22000.856]
• Chrome (web)      • chrome  • web-javascript • Google Chrome 105.0.5195.102
• Edge (web)        • edge    • web-javascript • Microsoft Edge 105.0.1343.33
[√] HTTP Host Availability
• All required HTTP hosts are available
• No issues found!

flutter run --verbose
[  +48 ms] executing: [C:\src\flutter/] git -c log.showSignature=false log -n 1 --pretty=format:%H
[  +41 ms] Exit code 0 from: git -c log.showSignature=false log -n 1 --pretty=format:%H
[        ] f1875d570e39de09040c8f79aa13cc56baab8db1
[        ] executing: [C:\src\flutter/] git tag --points-at f1875d570e39de09040c8f79aa13cc56baab8db1
[  +30 ms] Exit code 0 from: git tag --points-at f1875d570e39de09040c8f79aa13cc56baab8db1
[        ] 3.0.5
[   +5 ms] executing: [C:\src\flutter/] git rev-parse --abbrev-ref --symbolic @{u}
[  +23 ms] Exit code 0 from: git rev-parse --abbrev-ref --symbolic @{u}
[        ] origin/stable
[        ] executing: [C:\src\flutter/] git ls-remote --get-url origin
[  +21 ms] Exit code 0 from: git ls-remote --get-url origin
[        ] https://github.com/flutter/flutter.git
[  +71 ms] executing: [C:\src\flutter/] git rev-parse --abbrev-ref HEAD
[  +24 ms] Exit code 0 from: git rev-parse --abbrev-ref HEAD
[        ] stable
[  +52 ms] Artifact Instance of 'AndroidGenSnapshotArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidInternalBuildArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterWebSdk' is not required, skipping update.
[   +2 ms] Artifact Instance of 'WindowsEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'WindowsUwpEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerDebugSymbols' is not required, skipping update.
[  +35 ms] executing: C:\Users\h\AppData\Local\Android\sdk\platform-tools\adb.exe devices -l
[  +33 ms] List of devices attached
[   +5 ms] Artifact Instance of 'AndroidGenSnapshotArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidInternalBuildArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IOSEngineArtifacts' is not required, skipping update.
[   +6 ms] Artifact Instance of 'WindowsUwpEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerDebugSymbols' is not required, skipping update.
[  +47 ms] No supported devices connected.
[  +20 ms] The following devices were found, but are not supported by this project:
Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.22000.856]
Chrome (web)      • chrome  • web-javascript • Google Chrome 105.0.5195.102
Edge (web)        • edge    • web-javascript • Microsoft Edge 105.0.1343.33
If you would like your app to run on web or windows, consider running flutter create . to generate projects for these platforms.
[   +6 ms] "flutter run" took 172ms.
[  +13 ms]
#0      throwToolExit (package:flutter_tools/src/base/common.dart:10:3)
#1      RunCommand.validateCommand (package:flutter_tools/src/commands/run.dart:484:7)

#2      FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:1298:5)

#3      FlutterCommand.run. (package:flutter_tools/src/runner/flutter_command.dart:1183:27)

#4      AppContext.run. (package:flutter_tools/src/base/context.dart:150:19)

#5      CommandRunner.runCommand (package:args/command_runner.dart:209:13)

#6      FlutterCommandRunner.runCommand. (package:flutter_tools/src/runner/flutter_command_runner.dart:281:9)

#7      AppContext.run. (package:flutter_tools/src/base/context.dart:150:19)

#8      FlutterCommandRunner.runCommand (package:flutter_tools/src/runner/flutter_command_runner.dart:229:5)

#9      run.. (package:flutter_tools/runner.dart:62:9)

#10     AppContext.run. (package:flutter_tools/src/base/context.dart:150:19)

#11     main (package:flutter_tools/executable.dart:94:3)

[ +259 ms] ensureAnalyticsSent: 257ms
[   +3 ms] Running shutdown hooks
[   +1 ms] Shutdown hooks complete
[   +1 ms] exiting with code 1

══╡ EXCEPTION CAUGHT BY ANIMATION LIBRARY ╞═════════════════════════════════════════════════════════
The following assertion was thrown while notifying listeners for AnimationController:
'package:flutter/src/rendering/object.dart': Failed assertion: line 1627 pos 12:
'_debugCanPerformMutations': is not true.
                Either the assertion indicates an error in the framework itself, or we should provide substantially
                more information in this error message to help you determine and fix the underlying cause.
                In either case, please report this assertion by filing a bug on GitHub:
                  https://github.com/flutter/flutter/issues/new?template=2_bug.md

                When the exception was thrown, this was the stack:
                #2      RenderObject.markNeedsLayout (package:flutter/src/rendering/object.dart:1627:12)
                #3      RenderBox.markNeedsLayout (package:flutter/src/rendering/box.dart:2370:11)
                #4      new RenderAnimatedSize.<anonymous closure> (package:flutter/src/rendering/animated_size.dart:99:9)
                #5      AnimationLocalListenersMixin.notifyListeners (package:flutter/src/animation/listener_helpers.dart:155:19)
                #6      AnimationController._animateToInternal (package:flutter/src/animation/animation_controller.dart:602:9)
                #7      AnimationController.forward (package:flutter/src/animation/animation_controller.dart:461:12)
                #8      RenderAnimatedSize._layoutStable (package:flutter/src/rendering/animated_size.dart:303:19)
                #9      RenderAnimatedSize.performLayout (package:flutter/src/rendering/animated_size.dart:224:9)
                #10     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
                #11     RenderPositionedBox.performLayout (package:flutter/src/rendering/shifted_box.dart:437:14)
                #12     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
                #13     RenderProxyBoxMixin.performLayout (package:flutter/src/rendering/proxy_box.dart:116:14)
                #14     _RenderCustomClip.performLayout (package:flutter/src/rendering/proxy_box.dart:1376:11)
                #15     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
                #16     RenderProxyBoxMixin.performLayout (package:flutter/src/rendering/proxy_box.dart:116:14)
                #17     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
                #18     RenderProxyBoxMixin.performLayout (package:flutter/src/rendering/proxy_box.dart:116:14)
                #19     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
                #20     RenderSliverList.performLayout.advance (package:flutter/src/rendering/sliver_list.dart:249:18)
                #21     RenderSliverList.performLayout (package:flutter/src/rendering/sliver_list.dart:281:12)
                #22     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
                #23     RenderSliverEdgeInsetsPadding.performLayout (package:flutter/src/rendering/sliver_padding.dart:137:12)
                #24     RenderSliverPadding.performLayout (package:flutter/src/rendering/sliver_padding.dart:371:11)
                #25     RenderObject.layout (package:flutter/src/rendering/object.dart:1915:7)
                #26     RenderViewportBase.layoutChildSequence (package:flutter/src/rendering/viewport.dart:510:13)
                #27     RenderViewport._attemptLayout (package:flutter/src/rendering/viewport.dart:1580:12)
                #28     RenderViewport.performLayout (package:flutter/src/rendering/viewport.dart:1489:20)
                #29     RenderObject._layoutWithoutResize (package:flutter/src/rendering/object.dart:1757:7)
                #30     PipelineOwner.flushLayout (package:flutter/src/rendering/object.dart:887:18)
                #31     RendererBinding.drawFrame (package:flutter/src/rendering/binding.dart:504:19)
                #32     WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:892:13)
                #33     RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:370:5)
                #34     SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1146:15)
                #35     SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1083:9)
                #36     SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:997:5)
                #40     _invoke (dart:ui/hooks.dart:151:10)
                #41     PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:308:5)
                #42     _drawFrame (dart:ui/hooks.dart:115:31)
                (elided 5 frames from class _AssertionError and dart:async)

                The AnimationController notifying listeners was:
                  AnimationController#d9803(⏮ 1.000; paused)
                ════════════════════════════════════════════════════════════════════════════════════════════════════

[  +19 ms]
Another exception was thrown: 'package:flutter/src/rendering/object.dart': Failed assertion: line 1627 pos 12: '_debugCanPerformMutations': is not
true.
[        ]
Another exception was thrown: 'package:flutter/src/rendering/object.dart': Failed assertion: line 1627 pos 12: '_debugCanPerformMutations': is not
true.
[        ]
Another exception was thrown: 'package:flutter/src/rendering/object.dart': Failed assertion: line 1627 pos 12: '_debugCanPerformMutations': is not
true.
[        ]
Another exception was thrown: 'package:flutter/src/rendering/object.dart': Failed assertion: line 1627 pos 12: '_debugCanPerformMutations': is not
true.
[        ]
Another exception was thrown: 'package:flutter/src/rendering/object.dart': Failed assertion: line 1627 pos 12: '_debugCanPerformMutations': is not
true.

Hi @ahad21,
A newer version of flutter was recently released. Can you upgrade to the latest version of flutter to see if you still experience this issue?
If you do, please provide the updated output of flutter doctor -v and a complete minimal reproducible code sample.
Thank you

I think the exact error is.
======== Exception caught by widgets library =======================================================
The following assertion was thrown while applying parent data.:
Incorrect use of ParentDataWidget.
The ParentDataWidget Expanded(flex: 1) wants to apply ParentData of type FlexParentData to a RenderObject, which has been set up to accept ParentData of incompatible type StackParentData.
Usually, this means that the Expanded widget has the wrong ancestor RenderObjectWidget. Typically, Expanded widgets are placed directly inside Flex widgets.
The offending Expanded is currently placed inside a Stack widget.
The ownership chain for the RenderObject that received the incompatible parent data was:
RepaintBoundary ← Lottie ← FutureBuilder ← LottieBuilder ← Expanded ← Visibility ← Stack ← Center ← Builder ← MediaQuery ← ⋯
When the exception was thrown, this was the stack:
#0      RenderObjectElement._updateParentData. (package:flutter/src/widgets/framework.dart:5960:11)
#1      RenderObjectElement._updateParentData (package:flutter/src/widgets/framework.dart:5977:6)
#2      RenderObjectElement.attachRenderObject (package:flutter/src/widgets/framework.dart:5999:7)

Hi @ahad21, the error you've posted above is different from the initial one you reported. The error you've posted above is because you've used an Expanded as a direct child of a Stack. Expanded is only meant to be used in Row, Column or Flex.


There is a bug in the jailbreak tool.

中国用户在苹果12系统14.6越狱后无法拨打电话。我希望这个错误能被修复。谢谢您。I hope you can get a reply.

Chinese users can't make calls after the jailbreak of Apple 12 system 14.6. I hope this bug can be fixed. Thank you.

Can you see this message?


SSAPI token refresh failed

Describe The Bug:
 Plug in stops function after several minutes. Home app reports no response from any Simplisafe device, and no camera feeds. Restart of Homebridge fixes the issue but only for several minutes, then it recurs.
To Reproduce:
just let it run..
Expected behavior:
 Connectivity should not timeout...
Logs:

For when Home completely loses SimpliSafe functionality (no response for any devices/cameras), I see:
[7/15/2020, 10:43:35] [Home Alarm] SSAPI token refresh failed, request blocked (rate limit?)
Paste Homebridge Logs here

Homebridge Config:

"bridge": {
"name": "Homebridge xxxx",
"username": "xxxx",
"port": 51083,
"pin": "xxxxxx"
},
"accessories": [],
"platforms": [
{
"name": "Config",
"port": 8581,
"auth": "form",
"theme": "auto",
"tempUnits": "f",
"lang": "auto",
"debug": true,
"platform": "config"
},
Paste the relevant section of your homebridge config.json here

{
"name": "Home Alarm",
"auth": {
"username": "xxxxx",
"password": "xxxxx"
},
"cameras": true,
"debug": true,
"sensorRefresh": 15,
"persistAccessories": false,
"resetSimpliSafeId": false,
"cameraOptions": {
"enableHwaccelRpi": true
},
"platform": "homebridge-simplisafe3.SimpliSafe 3"
Screenshots:

Environment:

Plugin version:  1.6.7
Node.js Version:  12.18.1
NPM Version:  6.14.5
Homebridge Version:  0.5.0 RC20
Operating System:  Raspbian

Hi @thrangster , how long have you been having this issue? You may be getting rare limited by SS which usually resolves after a matter of hours or a day, but the plugin should do its best to mitigate this by pinging SS less frequently. Can you please make sure you have the debug -D option enabled for homebridge and post a longer section of your logs (should have more info with that enabled)

Well, I rebooted as suggested, and the SSAPI token refresh failed, request blocked (rate limit?) error returned.
Does this happened every time one reboots the Homebridge? Or is there something else I need to look at?
Thanks

Did another reboot and good for two hours, then it recurs...
[7/15/2020, 15:57:37] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":359,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 15:58:02] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":360,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 15:58:26] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":361,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 15:58:47] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":362,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 15:59:12] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":363,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 15:59:36] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":364,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 15:59:56] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":365,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 16:00:22] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":366,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 16:00:47] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":367,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 16:01:07] [isy-nodejs] ZWave Front Porch - Glass Break Ala (ZW003_118): Command Luminance (LUMIN) triggered.
[7/15/2020, 16:01:08] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":372,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
**

[7/15/2020, 16:01:21] [Home Alarm] SSAPI token refresh failed, request blocked (rate limit?).

**
[7/15/2020, 16:01:33] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":373,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 16:01:57] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":374,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 16:02:18] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":375,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 16:02:39] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":376,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 16:03:04] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":377,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 16:03:27] [isy-nodejs] Received Heartbeat Signal from ISY: {"seqnum":378,"sid":"uuid:148","control":"_0","action":120,"node":"","eventInfo":""}
[7/15/2020, 16:03:34] [Ring] No snapshot cached for Front Door
[7/15/2020, 16:03:34] [Ring] Loading new snapshot into cache for Front Door
[7/15/2020, 16:03:35] [Ring] Snapshot cached for Front Door (0.788s)
[7/15/2020, 16:03:44] [Ring] Used cached snapshot for Front Door
Odd....

When I touched a SS camera during this No Response state, I saw this in the log if helpful
[7/15/2020, 16:06:26] [Home Alarm] Prepare stream with request: {
sessionID: 'c0d3a248-9818-469f-a2d8-febc21680bb',
targetAddress: '<IP_ADDRESS>',
addressVersion: 'ipv4',
video: {
port: 53335,
srtpCryptoSuite: 0,
srtp_key: <Buffer 20 9f 84 e4 d3 23 fb 5a ec fc 33 9f 57 b1 8e 3a>,
srtp_salt: <Buffer da fa 68 8c 02 9b 60 26 a7 15 0e 2b d1 37>
},
audio: {
port: 51236,
srtpCryptoSuite: 0,
srtp_key: <Buffer 69 fe d3 32 0a 77 78 7d d9 48 08 2a 8b 33 e8 01>,
srtp_salt: <Buffer 16 7b 6b 95 be 1c fd b5 f0 b4 d4 b6 dd 77>
}
}
[7/15/2020, 16:06:26] [Home Alarm] handleStreamRequest with request: {
sessionID: 'c0d3a248-9818-469f-a2d8-febc21680bb',
type: 'start',
video: {
profile: 2,
level: 2,
packetizationMode: 0,
cvoId: undefined,
width: 1280,
height: 720,
fps: 30,
pt: 99,
ssrc:<PHONE_NUMBER>,
max_bit_rate: 299,
rtcp_interval: 0.5,
mtu: 1378
},
audio: {
codec: 'AAC-eld',
channel: 1,
bit_rate: 0,
sample_rate: 16,
packet_time: 30,
pt: 110,
ssrc: 838977725,
max_bit_rate: 24,
rtcp_interval: 5,
comfort_pt: 13,
comfortNoiseEnabled: false
}
}
[7/15/2020, 16:06:26] [Home Alarm] Error: Camera stream request blocked (rate limited)
at SS3SimpliCam.handleStreamRequest (/usr/local/lib/node_modules/homebridge-simplisafe3/accessories/simplicam.js:341:21)
at RTPStreamManagement._handleStartStream (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/camera/RTPStreamManagement.ts:791:19)
at RTPStreamManagement._handleSelectedStreamConfigurationWrite (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/camera/RTPStreamManagement.ts:622:14)
at Characteristic.emit (events.js:315:20)
at Characteristic.EventEmitter.emit (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/EventEmitter.ts:42:22)
at Characteristic._this.setValue (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:651:12)
at /usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:1437:24
at Array.forEach ()
at Bridge.Accessory._this._handleSetCharacteristics (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:1279:10)
at HAPServer.emit (events.js:315:20)

Since the issue is not widespread I am confident its just because you've been messing around with the plugin and are intermittently getting blocked. One thing you can do when it happens is check if you can login to the SS website control panel (if youre blocked you shouldn't be able to). I suggest we it some time undisturbed (perhaps even with HB / the plugin disabled) and see how things shake out.

(I dont mean messing around in a pejorative way, just that you've been playing with getting it setup etc)

Lol - well, not too much messing around with the SS plug in at all, in fact when it stops working I'm not even logged into the Homebridge.
I have been adding lights to my ISY plug in, so there have been several HB restarts - not sure if global restarts impact this.
But good check - when it happens I will try and log into the site (I can tell you the app continues to work during this condition if that matters)
Thanks - and no pejorative taken...!

Yea restarting HB will re-login to SS so might play a role, its not just how many total logins its also how close together. For example if you set the sensor refresh time to something very short like 5s it can get you blocked (at least that was true last time I tried that).
If this happens again after a real period of things working and no playing around =) then please post logs with the -D option enabled and I'll take another look!

Thanks - yes I was adding small groups go lighting which required a restart each time, at least yesterday, so I'll keep and eye on it.
Thanks for your prompt and thorough help


forEachParallel lost input function name information

When forEachParallel expand task function from arguments array , it losts function name, even the task function has name. Please see vasync.js line 135.  It will be hard to debug.  Please kindly fix it in your convenience.

Yeah, this looks to be an artifact of the way we use parallel() to implement forEachParallel().


Notification bubble on the icon on dock not working (OSX Yosemite)

The notification bubble on the icon on the dock with a number in it that shows the number of new messages either blinks and dissapeares or doesn't show at all.

I also have this problem on 10.10.4 (14E46)

+1

Please try the new beta. See https://github.com/Aluxian/Facebook-Messenger-Desktop/issues/458
If it is still an issue, please open a new issue.


Listener transaction confirmation service

closes #99
Notifications for transactions now also include the transaction hashes

@d-velev will you still fix the broken tests?


VALIDATOR KEY COMMANDS - advanced - Grouping / Filtering

Taken out of #613, pushed back to a later version.
An additional functionality used to:
-) GROUP VALIDATOR KEY(s)
-) FILTER VALIDATOR KEY(s) BY NAME / PUBLIC KEY
this also must include a path to:

move / add to a group
remove keys from a group

FILTER   done.

@gbayasgalan & @MaxTheGeeek going to finish this up soon