Quest: Drop mixins

ember-simple-auth has been heavily leveraging mixins form the beginning. Using mixins is what allowed ESA to be integrated easily be developers into their applications since the only thing that they'd need to do was to mix-in these mixins into some of the routes of the application and ESA would just work. However, with native JavaScript classes, mixins aren't really well supported and you have to fall back to constructs like
export default class ProtectedRoute extends Route.extend(AuthenticatedRouteMixin) {
}

which mixes native classes and Ember's old object model and thus results in unintuitive and harder-to-understand-than-necessary code. Also, eventually mixins will likely be removed from Ember altogether and they already trigger linter warnings which means installing ESA into an app will trigger new linter warnings which isn't a great and particularly reassuring experience obviously.
For those reasons, ESA should drop its mixins and adopt a new approach. There are a few key attributes we're looking for in a new solution:

Ease of use: as explained above, mixins made ESA super easy to use for everyone and we don't want to give that up when switching to a new mechanism. Ideally, integrating ESA into an app would still only require a few steps with little complexity to understand.
Customizability: another advantage of mixins is that everything they add to the respective classes can be overridden again and thus customized. That gives developers an easy way to modify particular aspects of ESA's behavior so it perfectly fits their needs without having to go through lots of complexity. In fact, we even extracted and designed some of the methods on the ESA mixins specifically with extensibility and customizability in mind, e.g. https://github.com/simplabs/ember-simple-auth/blob/master/addon/mixins/authenticated-route-mixin.js#L118
Sustainability: obviously we don't want to change the main mechanism for integrating ESA into an app frequently so we're looking for something that will be stable for the foreseeable future. That means obviously we cannot use anything that is already deprecated in Ember 3.x but should also be watching for what might be coming in Ember and/or JS in the future and be sure the mixin replacement we choose now will continue to work.

Status Quo
ESA currently provides 5 mixins:

ApplicationRouteMixin: This is an optional mixin that when used, maps certain events of the session to methods on the application route (by overriding init) that it provides default implementations of.
AuthenticatedRouteMixin: This is mixed in to route classes that are to expect the session to be authenticated in order to be accessed. The mixin adds a custom beforeModel method that will call the original one (if present) if the session is authenticated or call triggerAuthentication otherwise that it provides a default implementation of which redirects to a configurable login route
UnauthenticatedRouteMixin: This is the opposite of the AuthenticatedRouteMixin and works in the same way by adding a default implementation of beforeModel that checks whether the session is not authenticated and redirects otherwise (without a dedicated method for that)
OAuth2ImplicitGrantCallbackRouteMixin is used in combination with the OAuth2ImplicitGrantAuthenticator and triggers authentication of the session via that authenticator when the route is visited (by overriding activate)
DataAdapterMixin is used with Ember Data adapters and overrides the handleResponse method so that it automatically invalidates the session on 401 error responses

Options
There are several options that might be worth looking into more deeply:

Decorators: This seems to be the obvious choice for replacing mixins. Instead of the above example, one would simply write

import { authenticated } from 'ember-simple-auth/decorators/routes';

@authenticated
export default class ProtectedRoute extends Route {
}

The advantage of decorators is they would still allow integrating ESA super easily but the disadvantage is the uncertainty around the decorators proposal and the fact that we might not be able to do everything we need to do with the final version of the proposal

Custom mixin mechanism: Using a mechanism for mixins that does not rely on the Ember Object model but works with native JavaScript classes would be another option that minimises the changes in terms of how ESA is integrated into an application. The above example could look something like this with an approach like that:

import { Protected } from 'ember-simple-auth/mixins/routes';

export default class ProtectedRoute extends Protected(Route) {
}

More information on the approach can be found here. The disadvantage of this is that it is fairly exotic and while technically ESA could still be adopted in a way that is very similar to the current mixins-based mechanism, it would result in substantially increased complexity as it'd be unclear to many devs what they are doing exactly and how the mechanism works.

Providing individual methods: Instead of providing ESA's functionality via mixins it would be possible of course to export the individual methods instead so that those would be called manually be the dev in the appropriate places instead of automatically via the mixins. The above example would look something like this with the approach:

import { requireAuthentication } from 'ember-simple-auth/helpers/routes';

export default class ProtectedRoute extends Route {
  async beforeModel() {
    await requireAuthentication();
    …
  }
}

While this has the advantage of being fairly simple and straight-forward, the disadvantage is that it requires the dev to follow more steps when adapting ESA in an application which leads to more complexity simply as the amount of glue code that integrates ESA and the application is higer.
Prior Art
@mike-north did some work some time ago to split the ESA codebase apart into exports of individual methods that could be imported and called directly as a replacement for mixins. Unfortunately nobody ever found the time to implement it and the effort didn't lead anywhere…

it would result in substantially increased complexity as it'd be unclear to many devs what they are doing exactly and how the mechanism works.

I think understanding "how the mechanism works" is significantly more complicated for decorators than it is for the "mixin pattern", which is essentially just a factory function that produces a subclass of the passed in class 😅

Hm, maybe – I think the difference is decorators are (or will be) something that people know and is familiar to them while methods like the above might not be.

function mixinFoo(ParentClass) {
  return class extends ParentClass {
    foo() { /* ... */ }
  };
}

I honestly don't understand what's so hard to understand about such a factory function 🤔

I personally feel like the class decorator approach would be easier to integrate than importing functions and then creating your own base-classes. At least in the first steps of a project.
It feels significantly more "magical" than the individual methods- and "custom-mixin"-approach though and I don't see the benefit over a mixin conceptionally as it's basically just a mixin applied by a decorator, right?
Additional questions regarding this approach: Can people override methods mixed in that way? Can class-decorators be combined?
The "custom mixin"-approach feels like a good middle way as it's pretty easy to understand what's happening, very explicit and doesn't come with any integration headaches for people that just want to get started and don't want to dive deeper into the things that ESA is doing internally.

Additional questions regarding this approach: Can people override methods mixed in that way? Can class-decorators be combined?

Yes, both are possible.

I think option 3 could be valuable both in the short term as a bridging solution (giving the team more time to work on the design of a higher-level API) and in the long term as a set of primitives for those who need a more granular API.
The uncertainty around decorators is a risk, for sure, but I have to say I love how it reads! There’s something pleasingly intention-revealing about the decorator form.

I agree with @jgwhite: option 3 is great to have, because it can co-exist with other options focused on the class itself. To me, it's basically deciding between 1 and 2.

A couple thoughts:

Decorators are pretty, but they also basically reintroduce not only the convenience but also the problems of mixins/multiple inheritance, in that behavior is far away from the implementation and can be stomped accidentally by other decorators in ways that are very difficult to identify. This doesn’t mean we should never reach for them, but it does mean that the tradeoffs for them are heavily biased toward writing code over reading and especially over maintaining code.
In part because of the state of flux around the decorator spec, insofar as types are useful to consumers of the app, decorators are a non-starter, whereas both options 2 and 3 are perfectly amenable to typing not only usefully but indeed correctly.
Related, understanding how decorators modify a class is rather more involved than either of the other methods. A “manual mixin” is a little strange, but lots of folks have experience with factory methods and many fewer have any idea what’s going on with descriptors. When someone inevitably hits a bug or wants to extend behavior or just wants to learn how things work under the hood, option 3 is easily the most discoverable and option 2 still worlds ahead of decorators.

My very strong recommendation is to build option 3 and see what people's real world use of that primitive plays out as. It’s perfectly safe to then add option 2 as a convenience on top of it, itself implemented exactly in terms of those primitives. This is the ideal toward which Ember itself is working in most major API designs these days, and it’s a good one: if a user for some reason needs the control afforded by the lower-level primitive, for whatever reason including because they’re experimenting with new router ideas or similar, they can have it. And you may find that the little bit of “boilerplate” is in practice not that bad after all… or that it is and you ship option 2! But starting with the primitives gives you flexibility later and forward motion now.

My feelings on decorators in general

Why not support both a factory function, and class decorators? Under the hood they are basically the same.

I thought about suggesting that! At this point I think that decision can be deferred, but also there are at least two good reasons not to:

impact on bundle size: if both were bundled it would fairly substantially increase the cost of including ESA. Hopefully Embroider will begin to make that a non-issue for apps later this year but for now it has to be a consideration.
the goal of shared solutions: as a community, we tend to value converting on a Standards way of solving any given problem. Shipping both of those would substantially muddy the waters here. Which one is *recommended *? Is there a time when one is better than the other? How do I pick between them for my app? For this spot in my app?

And the other upside if shipping primitives first is that it lets users experiment with life without either as well as with solutions built on top of them without committing to that sugar as a public API.

FWIW we already ship the primitives and the mixins are mostly just the glue code that connects those primitives to the built-in constructs in Ember.
to be honest, I have doubts that extracting mid-level primitives between the already-shipped low-level primitives and the high-level mixins will actually result in any significant advantages.

I understand everyone's reasons for preferring option 3. My only worry is that we would/might not be able to keep integrating ESA into an app as simple as it is now with that approach. It's just a difference in complexity and the amount/depth of concepts you have to understand when you have to invoke a particular method in a particular place etc. The simple integration mechanism has been the main focus of ESA from the beginning (and probably is the only thing about it that is still simple now). Another option of course could be to export the primitives and also export base classes that invoke the primitives in all the right places. I think the overhead in bundle size would be neglect-able.
However, some of the above mixins could likely be replaced with other approaches altogether. For example, what the AuthenticationRouteMixin does could be moved into an instance initializer or so, removing the need for that mixin altogether (you could then opt out of that via a config setting maybe). For the AuthenticatedRouteMixin/AuthenticatedRouteMixin an alternative approach could be adding something to the router DSL (torii has had that for some time).

I took a look at what I think could be a good approach here. The mixins do not necessarily translate to function exports 1:1 and we can get rid of some concepts completely.
ApplicationRouteMixin
Since the only thing this mixin does is map events on the session service to methods on the application route it could be dropped completely and be moved to an instance initializer, e.g.:
import sessionAuthenticated from 'ember-simple-auth/routing';

export default {
  name: 'ember-simple-auth',

  initialize(app) {
    let session = app.lookup('service:session');
    let applicationRoute = app.lookup('route:application');
    session.on('authenticationSucceeded', (...args) => applicationRoute.sessionAuthenticated ? applicationRoute.sessionAuthenticated(...args) : sessionAuthenticated(...args));
    // …other events
  }
};

If the mixin is deprecated of course that means
you can no longer call e.g. super.sessionAuthenticated() in the application route when overriding one of the methods. For that reason it might make sense to also
export the individual methods so extending the default implementation is still possible without having to copy the code, e.g.:
import { sessionAuthenticated } from 'ember-simple-auth/routing';

export default class ApplicationRoute extends Route {
  sessionAuthenticated() {
    console.log('session was authenticated!');
    sessionAuthenticated();
  }
}

AuthenticatedRouteMixin
The AuthenticatedRouteMixin adds its own implementation of beforeModel that check whether the session is authenticated and redirects to a configurable login route otherwise. If it intercepts a transition and in fact redirects, it also stores the target route of the intercepted transition in the session which is then read in the ApplicationRouteMixin's sessionAuthenticated method and retried so that when a user requests /protected, they are redirected to e.g. /login to authenticate and taken to /protected once that was successful. That creates a kind of implicit connection between the two mixins of course – this doesn't lead to any immediate consequences but should be kept in mind when designing the new API (and also is something that is not solved in a particularly great way by the current API).
A good approach for getting rid of the AuthenticatedRouteMixin would likely be exporting the functionality that ensures the session is authenticated as a separate method for the developer to invoke in the route they want it in – as several people recommend as their favorite option above:
import { requireAuthentication } from 'ember-simple-auth/routing';

export default class ProtectedRoute extends Route {
  async beforeModel() {
    let isAuthenticated = await requireAuthentication();
    if (isAuthenticated) {
      // do/load other things here
    }
  }
}

Showing how this could be made reusable so the above doesn't have to be repeated for every protected route in an application by e.g. extracting the logic into a custom base class route could probably be covered in the README.
The other thing that the AuthenticatedRouteMixin does is it defines a triggerAuthentication method (with a default implementation) that is invoked
whenever a protected route is accessed without the session being authenticated and the session needs to be authenticated. By default that method will
simply redirect to the authenticatedRoute. This method is useful to have so it can be overridden if the application is using a different authentication
mechanism (e.g. one that relies on a modal which doesn't have its own route or in an Electron or Cordova app where you'd maybe want to authenticate the user via something that is implemented natively outside of the Ember.js app). However, if we export the method for ensuring authentication for invocation by the developer directly, there is no clear alternative for the triggerAuthentication method unless we'd build some sort of callback mechanism, e.g.:
import { requireAuthentication, triggerAuthentication } from 'ember-simple-auth/routing';

export default class ProtectedRoute extends Route {
  async beforeModel() {
    let isAuthenticated = await requireAuthentication(() => {
      console.log('triggering authentication');
      triggerAuthentication(); // alternatively one could implement their own logic of course
    });
    if (isAuthenticated) {
      // do/load other things here
    }
  }
}

I don't think an API like that would be particularly great though – maybe it makes sense to introduce a new authenticationRequired event or so on the session service (similar to the existing events) that could then be mapped to a method on the application route via the initializer that replaces the ApplicationRouteMixin. That would streamline the API a bit since all of the methods that handle similar things (handling successful login, handling successful logout, triggering login) are handled in a similar way then via events and all of those events end up being handled on the application route. Like for the other methods on the application route, I'd still export the default implementations so those could be reused when implementing the methods on the application with the intention to only add to the default behavior:
import { triggerAuthentication } from 'ember-simple-auth/routing';

export default class ApplicationRoute extends Route {
  triggerAuthentication() {
    console.log('triggering authentication!');
    triggerAuthentication();
  }
}

Of course we'd lose the ability to easily trigger authentication in different ways on different routes which you can do with the current implementation of the AuthenticatedRouteMixin by overriding the method differently in different routes (although I doubt anyone relies on that and it'll still be possible to reintroduce something similar with this new approach).
UnauthenticatedRouteMixin
The UnauthenticatedRouteMixin could be replaced by essentially the same mechanism explained above for the AuthenticatedRouteMixin since both are doing essentially the same things just in opposite ways:
import { preventAuthentication } from 'ember-simple-auth/routing';

export default class OpenRoute extends Route {
  async beforeModel() {
    let isUnauthenticated = await preventAuthentication();
    if (isUnauthenticated) {
      // do/load other things here
    }
  }
}

In this case though an event on the session might not make sense to trigger the redirect as we don't really want to invalidate the session and thus change its state, we just want the route not to be accessible if the session is authenticated (which is useful for e.g. the login route – you'll want to redirect them elsewhere when they access that and the session is not authenticated already but you do not necessarily want to log them out). Probably passing in the route to redirect the user to in case the session is authenticated is better in this case (I could also not think of anything different anyone might like to do in this case and it has also never been possible to do anything but redirecting with ESA's current mixin mechanism):
import { preventAuthentication } from 'ember-simple-auth/routing';

export default class OpenRoute extends Route {
  async beforeModel() {
    let isUnauthenticated = await preventAuthentication('index');
    if (isUnauthenticated) {
      // do/load other things here
    }
  }
}

OAuth2ImplicitGrantCallbackRouteMixin
The OAuth2ImplicitGrantCallbackRouteMixin should be easily replaced by a single function and some documentation on where to invoke it as well:
import { handleOauth2ImplicitGrantCallback } from 'ember-simple-auth/routing';

export default class CallbackRoute extends Route {
  activate() {
    handleOauth2ImplicitGrantCallback(location);
  }
}

Since this something that's only used in one route in the entire application and does not apply for all kinds of routes, I'd be less worried about the cognitive overhead having to deal with the function directly introduces.
DataAdapterMixin
Regarding the DataAdapterMixin I'm not sure yet what a good approach would be. We currently both support adding headers via ajaxOptions as well as headersForRequest and I think ajaxOptions could probably go away but of course that depends on what versions of ember data we want to support etc. and that would require some additional research.
Overall solution
With the solution explained here we get rid of all of the mixins (DataAdapterMixin is tbd as explained above) and are left with 2 main methods only which are requireAuthentication which replaces the AuthenticatedRouteMixin and preventAuthentication which replaces the UnauthenticatedRouteMixin. The ApplicationRouteMixin is removed without a direct replacement and we're moving its logic into an instance initializer instead (which could be opt-in or opt-out even – tbd). We still keep the flexibility of customizing ESA's default handling of e.g. session invalidation etc. requireAuthentication and preventAuthentication could still be accompanied by authenticated and unauthenticated decorators respectively later on if we choose to or factory methods or whatever – however I'm not sure that's even necessary. I think my key point here is that if we reduce ESA's API (at least the part of if that most people would have to deal with most of the time) to only 2 methods, that does already simplify it quite a bit in which case the additional complexity of having to deal with the bare functions directly that I mentioned above as one of my worries, matters less.

it could be dropped completely and be moved to an instance initializer

using initializers has developed into an anti-pattern. they make it significantly harder to mock things in tests for example and they can make rendering tests slower than necessary.

Hm, what’s a good alternative for an adding to add some code to an app that auto-connects parts of the app in the way described above? Or is there no alternative?

My take at this point is that auto-connecting things like that is not worth the trivial convenience it adds. It is convenient, but taking a very short time to wire up something in your application route just isn't that big of a deal and does make everything both easier to test and easier to understand for someone new to the code.

Hm, what’s a good alternative for an adding to add some code to an app that auto-connects parts of the app in the way described above?

In this case, setting it up in the Route constructor?

Hm, I understand these points. The thing is we should not force people to copy/paste this into their application route:
import { triggerAuthentication, sessionAuthenticated, sessionInvalidation,  } from 'ember-simple-auth/routing';

export default class ApplicationRoute extends Route {
  @service session;

  constructor() {
    this.session.on('authenticationSucceeded', () => this.sessionAuthenticated());
    this.session.on('invalidationSucceeded', () => this.sessionInvalidated());
    this.session.on('requireAuthentication', () => this.triggerAuthentication());
  }

  sessionAuthenticated() {
    sessionAuthenticated();
  }

  sessionInvalidated() {
    sessionInvalidated();
  }

  triggerAuthentication() {
    triggerAuthentication();
  }
}

While this is arguably more explicit and less magical, it'd substantially increase the cognitive overhead when integrating ESA into a codebase.
An alternative to this could be just providing one function to be called in the constructor that would effectively set up the above (without actually adding the methods to the class of course):
import { setupAutoSessionRouting  } from 'ember-simple-auth/routing';

export default class ApplicationRoute extends Route {
  constructor() {
    setupAutoSessionRouting();
  }
}

how do you handle cleanup of these events then?

I assume willDestroy?

we should not force people to copy/paste this into their application route… While this is arguably more explicit and less magical, it'd substantially increase the cognitive overhead when integrating ESA into a codebase.

This is the fundamental point of disagreement about the design here. I think one-time extra cognitive load during setup more than pays for itself during the long lives of applications; more than that, I actually think it's helpful in teaching people what they addon is actually doing when they set it up.
I won't belabor the point further though, as I think I've made my perspective clear and I don't want to be that guy who's just arguing. 😉

I actually think it's helpful in teaching people what they addon is actually doing when they set it up.

Indeed we disagree here :) I think my short response is that if you're supposed to understand everything you're using you cannot actually do anything because there's no way you can ever live up to that expectation – I strongly believe that hiding details is one of ESA's strong points that many people appreciate and that only enabled its relatively wide adoption.
That said though, there's a difference between hiding details and magically adding or changing stuff in an app. With the mixin approach things were actually not so magical since we relied on a (more or less) well-understood mechanism in Ember. The fact that
export default Route.extend(ApplicationRouteMixin);

adds methods to the route isn't surprising as that's what mixins do. I agree that
export default class ApplicationRoute extends Route {
  constructor() {
    setupAutoSessionRouting();
  }
}

adding kind of optional methods to the application route is not necessarily straight forward. So maybe there's a better solution. Maybe we could have something that would essentially do this:
import { triggerAuthentication, sessionAuthenticated, sessionInvalidation,  } from 'ember-simple-auth/routing';

session.on('authenticationSucceeded', () => sessionAuthenticated());
session.on('invalidationSucceeded', () => sessionInvalidated());
session.on('requireAuthentication', () => triggerAuthentication());

This would not add any of the event handlers to the application route or invoke methods on the application route if present. It would simply apply ESA's default handling of these events. If we don't want to use an initializer we could have something to add to the router or something:
import EmberRouter from '@ember/routing/router';
import ESARouter from 'ember-simple-auth/routing';

const Router = EmberRouter.extend);

Router.map(function() {
  …
});

export default ESARouter(Router);

If anyone wants to customize any of the default behavior, the way to do that would be the above and you'd have to copy/paste code into the application route and set up the event handlers yourself.
In general, my main goal would be to find an API that hides all of the details from anyone who isn't interested while at the same time not leaning heavily on things being added/changed magically but providing some level of customizability.

I won't belabor the point further though, as I think I've made my perspective clear and I don't want to be that guy who's just arguing. 😉

Don't worry – the input is highly appreciated!

@marcoow Could you elaborate why we would need the route hooks registered at all of they just contain default implementation? Consumer could still implement a custom function if needed. But until then directly binding event to default event handler should be fine. It reduces complexity and lines of code needed for integration. It would be still obvious how to replace or extend a default implementation.

Yes, that's basically what I'm suggesting here. We'd want an easy way to switch on the default implementation which could be this (for example):
import EmberRouter from '@ember/routing/router';
import ESARouter from 'ember-simple-auth/routing';

const Router = EmberRouter.extend);

Router.map(function() {
  …
});

export default ESARouter(Router);

An alternative would be an instance initializer but if that has downsides it's likely not a great alternative in particular as we're looking for a sustainable solution.
We'd also want a straight forward way to extend or customize the default behaviour which you'd usually want at the routing layer as it involves redirecting. That could be this:
import { triggerAuthentication, sessionAuthenticated, sessionInvalidation,  } from 'ember-simple-auth/routing';

export default class ApplicationRoute extends Route {
  @service session;

  constructor() {
    this.session.on('authenticationSucceeded', () => this.sessionAuthenticated());
    this.session.on('invalidationSucceeded', () => this.sessionInvalidated());
    this.session.on('requireAuthentication', () => this.triggerAuthentication());
  }

  sessionAuthenticated() {
    // custom behavior goes here potentially plus invoking the default behavior:
    sessionAuthenticated();
  }

  sessionInvalidated() {
    // custom behavior goes here potentially plus invoking the default behavior:
    sessionInvalidated();
  }

  triggerAuthentication() {
    // custom behavior goes here potentially plus invoking the default behavior:
    triggerAuthentication();
  }
}

The reason why I suggest exporting the default behaviour here as well is so you do not need to copy that code (which might change over time of course so that you'd have to adapt the copied code) but can just implement custom logic in addition to also invoking the default behaviour.

Also to be clear: opting-in to the default behaviour via the router is arbitrary really – it could be using any mechanism that allows us to get a hold of an owner.

A special router, custom mixin, factory function and decorator is too much magic in my opinion. I think it's fine to ask the user to register three event handlers in application route (and remove them on destroy). It's not much more lines of code but directly teaches the building blocks and provides an obvious way how to customize. It would be still simple with being magic.

A special router, custom mixin, factory function and decorator is too much magic in my opinion

To be clear – nobody is suggesting a special router nor all of the above together. Decorators are mostly off the table for now as well. The easiest way would be to use an instance initializer to hook up the default functionality but as that doesn't seem to be a sustainable solution we'll have to look for alternatives.

we'll have to look for alternatives.

The alternative I'm arguing for would be like this:
import { triggerAuthentication, sessionAuthenticated, sessionInvalidation,  } from 'ember-simple-auth/routing';

export default class ApplicationRoute extends Route {
  @service session;

  constructor() {
    this.session.on('authenticationSucceeded', () => sessionAuthenticated);
    this.session.on('invalidationSucceeded', () => sessionInvalidated);
  }

  willDestory() {
    this.session.off('authenticationSucceeded', () => sessionAuthenticated);
    this.session.off('invalidationSucceeded', () => sessionInvalidated);
  }
}

I don't see any need for an additional layer of high-level API as this is already very simple integration.
I see this similar for other functionalities for ember-simple-auth. E.g. relying on the primitives exposed by session service might also be enough for authentication and unauthenticated route functionalities:
export default class ApplicationRoute extends Route {
  @service session;

  async beforeModel() {
    try {
      await this.session.requireAuthentication();
    catch (error) {
      // user is not authenticated
      return this.transitionTo('login');
    }
  }
}

I don't see any need for an additional layer of high-level API as this is already very simple integration.

It is relatively simple but I'd rather look for a way that is even simpler since the flexibility this provides is not needed by a large part of apps that just want to stick with the default implementation. Thus there is no real benefit forcing everyone to write this glue code themselves. Manually subscribing/unsubscribing to events should certainly be possible for everyone who wants it but I strongly believe there is value in not forcing a bunch glue code onto every user of the addon.

 The factories must only use public API and basically represent the guide on how to apply the smaller building blocks on their own by applying them automatically.
If you are happy with the defaults, use protected(Route), if not use the primitives.
It would be nice to have primitives for binding/removing the event listeners and so on.

Let me clarify a point here:

if you're supposed to understand everything you're using you cannot actually do anything because there's no way you can ever live up to that expectation

This isn't what I meant, and I don't think it's a reasonable characterization of my position, but I understand how what I wrote read this way. What I'm actually saying above is that the "boilerplate" here just teaches you what you're changing. It doesn't teach you all the mechanics or require you to understand them; it does teach you that you're modifying the behavior of various routes. If you later want (or need!) to understand all the mechanics, you have an obvious thread to tug on.
Folks may or may not find that persuasive—our disagreement appears to be deep-seated and intractable, and that just is what it is; taste does vary! I just wanted to clarify what I was and was not saying above. 😅

This isn't what I meant, and I don't think it's a reasonable characterization of my position

Sorry, didn't mean to mis-characterize your position. The input is greatly appreciated and I do understand where you're coming from and what you're saying. I just think ease of adoption is one of ESA's core strengths and we should all aim for a solution that

requires few changes/additions in the app
forces as little of the internals as possible on devs
…while not relying on any automagic mechanisms that modify the app in unexpected ways etc.
…and while still providing escape hatches if you want to have more control/customize things

Right now integrating ESA requires mixing in 2 or at most 3 mixins in some routes which I think checks all the above boxes – although comes with the downside of mixins of course.

I think the best option would be to expose all functionality via the session service. I put together a quick example here. The idea is to add a few new methods into the service that replace the existing mixins more or less 1:1:

AuthenticatedRouteMixin becomes:

import Route from '@ember/routing/route';
import { inject as service } from '@ember/service';

export default Route.extend({
  session: service(),

  beforeModel(transition) {
    this.session.requireAuthentication(transition, 'login');
  },

  model() {
    return this.get('store').findAll('post');
  }
});

UnauthenticatedRouteMixin becomes:

import Route from '@ember/routing/route';
import { inject as service } from '@ember/service';

export default Route.extend({
  session: service(),

  beforeModel(transition) {
    this.session.prohibitAuthentication(transition, 'index');
  },
});

ApplicationRouteMixin becomes:

import { inject as service } from '@ember/service';
import Route from '@ember/routing/route';

export default Route.extend({
  session: service(),
  sessionAccount: service('session-account'),

  init() {
    this._super(...arguments);
    this.session.on('authenticationSucceeded', () => this.sessionAuthenticated());
    this.session.on('invalidationSucceeded', () => this.session.handleInvalidation());
    this.session.on('authenticationRequested', () => this.session.triggerAuthentication('login'));
  },

  beforeModel() {
    return this._loadCurrentUser();
  },

  sessionAuthenticated() {
    this.session.handleAuthentication('index');
    this._loadCurrentUser();
  },

  _loadCurrentUser() {
    return this.get('sessionAccount').loadCurrentUser().catch(() => this.get('session').invalidate());
  }
});

In this example, the app adds custom logic to the handler for the authenticationSucceeded event. To make things easier for the standard integration path of ESA, we could provide a convenience method handleSessionEvents or so which would be a shortcut for setting up the session service's standard event handlers for its own events like this:
this.session.on('authenticationSucceeded', () => this.session.handleAuthentication('index'));
this.session.on('invalidationSucceeded', () => this.session.handleInvalidation('index'));
this.session.on('authenticationRequested', () => this.session.triggerAuthentication('login'));

I like that proposal. Maybe even the ApplicationRouteMixin could be replaced by methods on the session service? ESA would not be configured anymore on application route but by providing a custom session service, which extends from the base service?
// app/services/session.js
import BaseService from 'ember-simple-auth/services/session';
import { inject as service } from '@ember/service';

export default class SessionService extends BaseService {
  @service sessionAccount;

  sessionAuthenticated() {
    // call super to have default implementation
    super.sessionAuthenticated();

    // do some additional custom stuff
    this.get('sessionAccount').loadCurrentUser().catch(() => this.get('session').invalidate());
  }
}

Extending a service is not a very common way in ember to customize an addon but it would be similar to how adapters and serializers are customized. Similar to mixins it has the risk of name clashes but this could be reduced if the base service only exposes it's public API on that service and hides it's internal state and methods.

Yes, extending the service would work as well. In the above example, attaching the event handlers in the application route is kind of arbitrary and could be done elsewhere as well.
Note: All of this being wired up in the routes is mostly for historical reasons since there was no router service in earlier versions of Ember and you needed to have something on the route be called when the session's state changed so you could transition accordingly and the routes were really the only place where that was possible.
In fact, the events on the session service could be dropped altogether since they are no longer needed when extending the session service (and could easily be added in again in an extension of the session service) – see f03483ac707344081aa2fcbb04605a2f8b8cccbd (I don't know why the tests are failing 😞 )

There's a WIP PR now: #2198


ftnerr, eelpot (logical-conflict)

This pull request was generated by the 'mq' tool

/trunk merge


[BUG] Missing metadata fields caused by version upgrade

Purpose of the pull request
close #13897

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

(or)
If your pull request contain incompatible change, you should also add it to docs/docs/en/guide/upgrede/incompatible.md

PTAL @zhongjiajie

I check branch dev, and found column exception_type already exists in https://github.com/apache/dolphinscheduler/blob/8c43e71adf3d98ad1e63711abfdf1d125e262c76/dolphinscheduler-dao/src/main/resources/sql/upgrade/2.0.0_schema/mysql/dolphinscheduler_ddl.sql#L444 and https://github.com/apache/dolphinscheduler/blob/8c43e71adf3d98ad1e63711abfdf1d125e262c76/dolphinscheduler-dao/src/main/resources/sql/upgrade/2.0.0_schema/postgresql/dolphinscheduler_ddl.sql#L79
which mean some already fix in, and I deep into mysql ddl find we have fix in https://github.com/apache/dolphinscheduler/pull/11619

I check detail and found some error here.

in 2.0.8(latest version of 2.0.x): only postgresql update ddl have execution_type in 2.0.0_schema updating
in 3.0.5(latest version of 3.0.): both postgresql have execution_type in 2.0.0_schema updating, 3.0.x already EOF
in 3.1.5(latest version of 3.1.x): only postgresql update ddl have execution_type in 2.0.0_schema updating

This make a little complex, mean we should add this column adding in both branch 2.0.9-prepare and 3.1.6-prepare, but we should not add directly to dev branch, because it already have

@xinxingi you should add new directory named 3.1.6_schema in https://github.com/apache/dolphinscheduler/tree/ecfdebebaee6cae98156ae1140fcd4205fa55ad9/dolphinscheduler-dao/src/main/resources/sql/upgrade and move your code in PR into mysql/dolphinscheduler_ddl.sql to fix the further version of 3.1.x

I check detail and found some error here.

in 2.0.8(latest version of 2.0.x): only postgresql update ddl have execution_type in 2.0.0_schema updating
in 3.0.5(latest version of 3.0.): both postgresql have execution_type in 2.0.0_schema updating, 3.0.x already EOF
in 3.1.5(latest version of 3.1.x): only postgresql update ddl have execution_type in 2.0.0_schema updating

This make a little complex, mean we should add this column adding in both branch 2.0.9-prepare and 3.1.6-prepare, but we should not add directly to dev branch, because it already have #13901 (comment)

FYI @zhuangchong we should add this in 3.1.6-prepare after is merged

already fix in next version in 2.0.x in 7c73e3f

fix in next version in 3.1.x in ca10898, cc: @zhuangchong

I think maybe we should close this pr, due to dev branch already have

@zhongjiajie LGTM，But I have a question, if only the latest version is submitted, if the user uses a version before 3.1.6, won't this problem still occur?

@zhongjiajie LGTM，But I have a question, if only the latest version is submitted, if the user uses a version before 3.1.6, won't this problem still occur?

Will still have a bug, but the version before 3.1.6 is been already release, we should not change then anymore but can notice users to upgrade to 3.1.6 instead of version between 3.0.0 - 3.1.5


[WIP] Fix #2179: Update ACRA version and theme

Fixes #2179, ACRA reporting dialog looks old
Updated to ACRA version 5.13, applied a material theme.
Tests performed (required)
Tested the master branch on an emulator of a Pixel 2 with API level 28.
I forced an exception to test the new version and theme of ACRA.
Screenshots showing what changed (optional - for UI changes)
I couldn't fix the padding, but I found a reference which may be useful
A material warning icon may look nicer than the blank image that I used.

Seems to have issues with fr.free.nrw.commons.category.CategoryDaoTest. Not sure why.

Sorry for taking forever to get round to this.
Now it emails a blank body with a .stacktrace attachment which is a different format than we used to - it is as bit annoying to analyse (I'm not sure if there's a ACRA .stacktracer viewer?). Do you think you can see if there's anyway to report it in an email in a similar way as we used to?
For reference, this is what emails previously looked like:
USER_COMMENT=Testing PR #2219
ANDROID_VERSION=9
APP_VERSION_NAME=2.10.1-debug-master
BRAND=google
PHONE_MODEL=Android SDK built for x86
CUSTOM_DATA=
STACK_TRACE=java.lang.Error: Test ACRA error
at fr.free.nrw.commons.explore.categories.ExploreActivity.onCreate(ExploreActivity.java:73)
at android.app.Activity.performCreate(Activity.java:7136)
at android.app.Activity.performCreate(Activity.java:7127)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1271)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2893)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3048)
at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)
at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1808)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6669)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

Here's the sample report that this PR is generating:
ACRA-report.zip

Sorry for taking forever to get round to this.
Now it emails a blank body with a .stacktrace attachment which is a different format than we used to - it is as bit annoying to analyse (I'm not sure if there's a ACRA .stacktracer viewer?). Do you think you can see if there's anyway to report it in an email in a similar way as we used to?
For reference, this is what emails previously looked like:
USER_COMMENT=Testing PR #2219
ANDROID_VERSION=9
APP_VERSION_NAME=2.10.1-debug-master
BRAND=google
PHONE_MODEL=Android SDK built for x86
CUSTOM_DATA=
STACK_TRACE=java.lang.Error: Test ACRA error
at fr.free.nrw.commons.explore.categories.ExploreActivity.onCreate(ExploreActivity.java:73)
at android.app.Activity.performCreate(Activity.java:7136)
at android.app.Activity.performCreate(Activity.java:7127)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1271)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2893)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3048)
at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)
at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1808)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6669)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

Here's the sample report that this PR is generating:
ACRA-report.zip

Sure, I will look into this

I got the reports to send as plain text, but the formatting is atrocious.
there are \n and \t escape sequences, but they aren't formatting the text within the email.

Do you have any ideas?
We can also change what content to include in the report. For now I copied the content of the old email.
https://github.com/ACRA/acra/wiki/ReportContent

I got the reports to send as plain text, but the formatting is atrocious.
there are \n and \t escape sequences, but they aren't formatting the text within the email.

Do you have any ideas?
We can also change what content to include in the report. For now I copied the content of the old email.
https://github.com/ACRA/acra/wiki/ReportContent

Nice! Thanks for getting to work on this so quickly. I'm not quite sure to be honest - that looks like JSON so maybe using the GSON library (that's already used elsewhere in the project) decoding it could allow us to pretty print it better?
If you push your changes to this branch and I could take a deeper look when I have the time.

Sorry I'm not sure how to commit changes to a specific branch. How would I go about doing that?
For now I'll show you the changes I made as a comment.
There are only 3 changes which are denoted by '>>>>'
import org.acra.ACRA;
import org.acra.annotation.*;
>>>>import static org.acra.ReportField.*;

import java.io.File;

import javax.inject.Inject;
import javax.inject.Named;

import fr.free.nrw.commons.auth.SessionManager;
import fr.free.nrw.commons.bookmarks.locations.BookmarkLocationsDao;
import fr.free.nrw.commons.bookmarks.pictures.BookmarkPicturesDao;
import fr.free.nrw.commons.category.CategoryDao;
import fr.free.nrw.commons.concurrency.BackgroundPoolExceptionHandler;
import fr.free.nrw.commons.concurrency.ThreadPoolService;
import fr.free.nrw.commons.contributions.ContributionDao;
import fr.free.nrw.commons.data.DBOpenHelper;
import fr.free.nrw.commons.di.ApplicationlessInjection;
import fr.free.nrw.commons.kvstore.JsonKvStore;
import fr.free.nrw.commons.kvstore.JsonKvStore;
import fr.free.nrw.commons.logging.FileLoggingTree;
import fr.free.nrw.commons.logging.LogUtils;
import fr.free.nrw.commons.modifications.ModifierSequenceDao;
import fr.free.nrw.commons.upload.FileUtils;
import fr.free.nrw.commons.utils.ConfigUtils;
import io.reactivex.android.schedulers.AndroidSchedulers;
import io.reactivex.schedulers.Schedulers;
import timber.log.Timber;

@AcraCore(
        buildConfigClass = BuildConfig.class,
        resReportSendSuccessToast = R.string.crash_dialog_ok_toast,
        >>>>reportContent = {USER_COMMENT, APP_VERSION_CODE, APP_VERSION_NAME, ANDROID_VERSION, PHONE_MODEL, CUSTOM_DATA, STACK_TRACE}
)

@AcraMailSender(
        mailTo =<EMAIL_ADDRESS>        >>>>reportAsFile = false
)

@AcraDialog(
        resTheme = R.style.Theme_AppCompat_Dialog,
        resText = R.string.crash_dialog_text,
        resTitle = R.string.crash_dialog_title,
        resCommentPrompt = R.string.crash_dialog_comment_prompt
)

Sorry I'm not sure how to commit changes to a specific branch. How would I go about doing that?

No problem - you've done it anyways (0236c4d18fb73fe81b0db494ba039b09c01d0d02). I just meant commit and push your changes to the branch that you had submitted this PR from, which in your case is your master branch.
I will try to have a look at this properly later.

Having read the migration guide, I think we should set the reportFormat in to StringFormat.KEY_VALUE_LIST in the @AcraCore config.
reportFormat = StringFormat.KEY_VALUE_LIST

Codecov Report

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

@@          Coverage Diff           @@
##           master   #2219   +/-   ##
======================================
  Coverage    2.75%   2.75%
======================================
  Files         260     260
  Lines       12438   12438
  Branches     1125    1125
======================================
  Hits          343     343
  Misses      12068   12068
  Partials       27      27

Impacted Files
Coverage Δ

...n/java/fr/free/nrw/commons/CommonsApplication.java
0% <ø> (ø)
:arrow_up:

...n/java/fr/free/nrw/commons/logging/LogsSender.java
0% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

There's still more styling work that could be done to make it feel more part of the commons application. However this at least gets us most of the way there, and future PRs can fix the exact styling.


Moving the cabal library definition of plutus-playground-usecases.

Intero (or possibly cabal) has problems if the library sections aren't
put before the executable ones, it seems.
You should open an upstream issue to fix intero, pretty sure cabal is fine with this :p


deps: run poetry update

Description
Run poetry update to update dependencies.

@Xaenalt we were too eager to add this, and this breaks the image. Gonna revert this for now.


Incorrect pmp NA4/NAPOT address matching

#875 seems to have introduced an issue with NA4/NAPOT address matching modes - the scenario is as follows.
In my test, csr_pmp_addr[3] is 0x8000_3f54 with its corresponding configuration bits csr_pmp_cfg[3] set to {0, PMP_MODE_NA4, 0, 1, 1}, and the core requests an instruction fetch from pmp_req_addr_i[0] = 0x8000_3f54. Note that since we are using NA4 mode, region_start_addr[3] = 0x8000_3f54 and region_addr_mask[3] = 0xffff_ffff. We are also using a granularity of 0.
With this setup, we should expect that the requested instruction fetch should match pmpaddr3 but then then fail due to a fetch error since the corresponding access bit is disabled.
However, region_match_low[0][3] goes high as expected since
pmp_req_addr_i[0][33:2] >= region_start_addr[3][33:2],
but region_match_high[0][3] stays low since the check
pmp_req_addr_i[0][33:2] < csr_pmp_addr[3][33:2] will fail due to lack of equality checking - this causes an altogether mismatch with this PMP region.
I think we still need to include equality checking to cover NA4 and NAPOT matching (as the error I describe above can also easily occur in NAPOT mode with any granularity), but these equality checks should only be enabled when we are in one of those two modes.

Thanks @udinator - I was trying to be (too) clever and avoid the extra equality matching by using address masking. I think this still works for NA4 if the mask is set up correctly. I'll push a proposed fix as a PR and hopefully you can run some testing on it to confirm.


Allow configuring session to use remote metastore and storage in python bindings

Summary
See https://github.com/GlareDB/cloud/issues/1611 for some rationale.
This should be configurable via arguments to connect, as well as through environment variables so that users don't need to configure anything when running inside a python compute engine.
Specifications

Rationale

Impact

Tasks

going to actually hold off on this one for now, I think there's still some additional refinement needed to figure out how exactly we plan on communicating between the python client & remote server.

Remote metastore/storage
The use case for this is being able to run glaredb locally, and connect it to
an instance running on glaredb cloud.
The ux might look something like this:

Start glaredb via glaredb local --cloud <cloud-instance-name> from the
command line or glaredb.connect(<cloud-instance-name>) from python.
Get prompted to log in, or us some authentication mechanism (api keys,
browser link, etc).
Be able to execute queries as you normally would with some of the execution
being routed to the cloud instance.

Execution break down

When connecting, the local instance of glaredb will download a copy of the
catalog.
All query planning will be done locally. It will be assumed that executing
scans against anything that's not a local data frame or file will be ran on
the remote instance.
The physical plan will be split into "local" and "remote" fragments. Remote
fragments will be executed on the cloud instance, and local fragements will be
executed locally.

Infrastructure needs
None of the communication between the remote/local instances will be going
through pgsrv as that's postgres protocol specific, and there's no overlap
between that and what we're trying to do here.
So this means we'll likely add in an additional service with the following
endpoints:

Retrieve catalog
Execute physical plan fragment

Both endpoints should be authenticated (unsure if we want to use the existing
username/password stuff, or just go with api keys).
I'm also unsure what we want the protocol/serialization to look like. GRPC is
likely for transport, and then either datafusion proto or substrait for physical
plan serialization.

@universalmind303 is researching around the planning and what's possible with DF. This one is a blocker for the initiative on Cloud, so we need to figure out what's possible first before continuing elsewhere too far.

we create a new datasource that wraps the existing file & object store datasources. Check if it's local/remote & delegate accordingly. The implementation should be pretty easy, but it'll likely have a pretty big cascading effect on the existing code.

implement new CloudExec for the various datasources we want to run in the cloud (cloudHttpExec, cloudS3Exec, ...). Or potentially a generic implementation instead.
implement new hybridExec that wraps the local & cloud ones & delegates accordingly.
replace calls to existing datasources with new hybrid compatible sources

The join nodes will be pretty tricky, we'll have to do some checking to make sure both sides can & should be done on client or server & potentially some other optimizations as well. More discovery will likely be needed on the join & union implementations.

Split up per data source (serializing each one)?

An initial pass for this might actually be skipping the plan serialization, exposing metastore, and having a more generic auth mechanism with Cloud. So instead of having to send plans over the network, we just execute everything locally.
The flow on startup may look something like this:

(SQL) Username/password provided in glaredb.connect
In-process glaredb connects to Cloud to retrieve a service account (using the username/password)
In-process glaredb also connects to metastore to retrieve the catalog (using the username/password)
Create local session using service account provided by Cloud for storage access, and an authenticate grpc connection to metastore.

Then once the session is created, we just resume execution as normal, and everything is executed locally.
This would also provide an opportunity to cleanup session initialization if we feel that's worthwhile.

https://github.com/GlareDB/glaredb/issues/1278 might necessitate the need to change how we create sessions. Python CE will need have needs like writing directly to storage.

Hybrid execution obviates this.


Fix a minor bug which was causing loading twice

I noticed that we are loading model twice when running again on a new dataset. We should not do that. My hunch is this was caused due to dask serializing the class it on workers and causing it to create a new id for it
This  PR changes that by caching the ID on initialization, which i tested and that works.

@GPUtester  okay to test

/okay to test


README

README
User Story
As a bootcamp student
I want the prework notes to be structured on a webpage
so that I can easily find and read information
Acceptance Criteria
GIVEN a prework project repository,
WHEN I view the README for the repository,
THEN I see a professional README that provides information on the project and how to use it.

Read me file updated


mv: failed to access '/data/bind/etc': Too many levels of symbolic links

I have a problem, after making modifications to my dns server, I need to copy the configs to another server and start the container with the same data I had modified before, I get an error like mv: failed to access '/data/bind/etc': Too many levels of symbolic links

@Shinigami2so please share the steps to reproduce the issue.

I am now also having this issue.
I setup the docker and on the initial run everything looked fine, I could get webUI and setup seemed proper.
I then had to reboot the docker host for other reasons and now if when the container will not launch anymore.
I am pushing the volume to an nfs mounted directory in the host. Which is accessible to the host prior to the container launching.
The view log, only says "mv: failed to access '/data/bind/etc': Too many levels of symbolic links" over and over every time it attempts to reboot the container.
Volume setup
/mnt/docker/dns:/data
The nfs mount on the host is
:/mnt/Store/docker-data:/mnt/docker
so the /mnt/docker is the base dir then the added "dns" sub directory is what is being used to attach the container's /data
from the host I can see the data from the original run
[rancher@rancher ~]$ cd /mnt/docker/dns/
[rancher@rancher dns]$ ls -l
total 8
drwxrwxr-x    3 105      106           4096 Feb  5 02:37 bind
drwxr-xr-x    2 root     root          4096 Feb  5 02:37 webmin
[rancher@rancher dns]$
I can also see the data on my nfs server
Let me know what other information you would liek and I will attempt to obtain it.
Strangly enough, if I modify anything any of the other directories in the mount path, it seems to let this docker load up properly.

Have the same issue. If I point the data volume at the local disk everything is fine. If I put data out on an NFS mount then I get the same error as the OP


ScreenToGif crashes when importing an animated GIF file into the Editor

Just opened the ScreenToGif's Editor, clicked on Load icon, picked up an animated GIF image downloaded from Google Images and then finally crashes.

Here, my log file: 17_03_11.txt

Apparently, the property "TemporaryFolder" was/is empty. Is this the first time that you open the app?
Could you just open and close the Recorder window? This setting is set to a default value if not present or empty when you open the recorder (screen, webcam or board recorder).
Anyway, thanks for the feedback. I fixed this by adding the same check to the initialization of the Editor.
#region Temporary folder

//If never configurated.
if (string.IsNullOrWhiteSpace(UserSettings.All.TemporaryFolder))
    UserSettings.All.TemporaryFolder = Path.GetTempPath();

#endregion

You can also pick a custom location to store the temporary files by opening Options > Temporary Files > Location Folder.


Test cases are missing copyright statements

There are no copyright statements on the test cases and on some of the scripts in the SmartRedis repository

Completed as part of the error handling PR


Add support for goto next and prev bookmark

Resolves #5
Adds basic support for goto next and previous bookmark in line number order within the currently active BookmarkList.
Basically works as Vim's 'find next/previous occurrence' (n/N) constrained within the active BookmarkList, which I assume was the wanted feature.
Thanks for the awesome plugin!

Hihi, thanks for your contribution

AI review
Overview
The changes add two new commands BookmarksGotoNext and BookmarksGotoPrev to navigate between bookmarks in line number order within the current file.
Positive Aspects

✅ Good documentation updates in README.md
✅ Consistent function naming with existing codebase
✅ Proper error handling by checking for selected bookmark before navigation
✅ Reuses existing Service.goto_bookmark and Sign.safe_refresh_signs functions
✅ Command descriptions are clear and consistent

Suggestions for Improvement

Code Duplication

-- The goto_next_bookmark and goto_prev_bookmark functions share very similar logic
-- Consider extracting common code into a helper function like:
local function find_nearest_bookmark(bookmarks, cur_lnr, compare_fn)
  local selected_bm
  for _, bookmark in ipairs(bookmarks) do
    if filepath == bookmark.location.path and compare_fn(bookmark.location.line, cur_lnr) then
      if not selected_bm or compare_fn(bookmark.location.line, selected_bm.location.line) then
        selected_bm = bookmark
      end
    end
  end
  return selected_bm
end

Error Feedback

Consider adding user feedback when no next/previous bookmark is found
Could use vim.notify to inform the user

Performance

The functions iterate through all bookmarks - consider adding an early return if a suitable bookmark is found

Security/Safety
No security concerns identified. The code properly uses Neovim API and existing helper functions.
Summary
The PR is well-implemented and adds useful navigation functionality. The main improvement would be reducing code duplication between the two new functions.

An addition to this feature could be to add wrap-around when traversing next/previous bookmarks.
I chose not to do this because I am not a fan of wrap-around for this feature. I'd like to be able to know start/end boundary when browsing bookmarks within a file.
A suggestion for follow up improvement:

Gather bookmarks for current file into list
Sort list by line order
Using current line number, round up to for next bookmark
Using current line number, round down for previous bookmark
Boundary check for wrap-around (add as option)

I took it upon myself to re-implement this to allow wrap-around, please have an additional look over the code.

perfect, thx~


ks

https://www.uni-gjilan.net/

@Edmond1997 I am sorry, I have to close the request without merging, because you made a mistake in a request and specifies an incorrect filepath. Please ensure that you are familiar with this repository rules located at the bottom of this page and make a new correct request. Thank you for the understanding!


Searchkit is not defined

Hey there,
First great gem, but when following the demo I'm getting the following errors:

Hey, thanks for trying out the gem. This gem is still in its very early versions so it helps to have some feedback! To start with what version of rails are you using? Can you confirm that the generator script you ran was able to add //= require searchkit to your application.js file?


Fix failing test #54

Resolves incompatibility with Ember 2.11 for https://github.com/danielspaniel/ember-data-change-tracker/issues/8. There are still 2 more failing tests that are unrelated to this fix, and I'm not sure what changed in Ember Data to cause the failures.
Error for tests that are still failing:
You should not call `create` on a model. Instead, call `store.createRecord` with the attributes you would like to set.

As I mentioned in #8:

It looks like the build() function is sideloading dummy data (via included) and creating the relationship records, instead of leaving it as an unloaded relationship.
Maybe something introduced in Ember Data to support nested resource creation for the JSON API spec? Idk enough about FactoryGuy to say, but I've recently seen discussions on that.

I fixed those 2 tests already @ezekg when I was looking at 2.11+ .. so don't worry about those ..

The sideload stuff is part of the way factory guy works with relationships.
I usually don't setup up async data like this,  so I have not come up with an api for that yet ..
but this might push me to do that in factory guy so you can say .. here is relationship but don't sideload it

Okay, good deal. I figured it was something to do with the factory guy. 👍
So everything's green again?

still failing for ed 2.11.3 .. will investigate

no wait ... take that back .. green .. thanks .. more shots for us! .. your hired again!  whoooo hooo

I am hoping that
let value = model.belongsTo(key).belongsToRelationship.inverseRecord;

this still works in future versions of ED ..  that was neat-o  .. hate to loose that

But yeah, same here. Took some digging to figure out how Ember checks relationships, so I just went with what they're doing internally for belongsTo(rel).id() and belongsTo(rel).value().

where do you find those gif's .. damn .. those are so funny

Haha! Your new best friend: http://giphy.com. Then attach it to a post with this Markdown:
![](gif direct link)


Flush cookies to disk and clear cookies in memory

Hi,
first of all, sorry for my bad english.
Just a few hours ago I ran into that issue when I was writing tests for my app. I use post request to login to some webpage. When I tested "Login failed" I was not able to simulate this behavior because easy handle in pool helds cookies in memory from previous (successful) login. And keep sending old cookies to server.
Don't know if this behavior is a future or a bug. In this pull request I propose solution for this issue.
Also I'm not sure if this fix should be in Typhoeus or in Ethon.

@mrazicz thanks for your work! Could you provide a few more tests so that it is obvious that it actually works?

Uff, here it is. Thanks God for that. I found out, that if I call reset before cookielist = "all", Easy will not send/set cookies at all in future requests.
Tests are little messy, sorry for that.

Seems to work, thank you very much for the solution !! :)

@mrazicz thank you very much for your work and the new tests!
@MrShoco thank you very much for giving it a try!


hash float arrays using primitive usigned integer type

Which issue does this PR close?

Closes #512.
Rationale for this change
Generate hash using u8 slices will be less efficient and breaks
sepcialization in ahash.
See https://github.com/tkaitchuck/aHash/issues/93 for more details.
What changes are included in this PR?
Convert u8 slices back to u32 or u64 when calculating hashes for f32 and f64.
Are there any user-facing changes?
no

Codecov Report

Merging #556 (0104e51) into master (d382854) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #556      +/-   ##
==========================================
+ Coverage   76.09%   76.10%   +0.01%
==========================================
  Files         156      156
  Lines       27047    27057      +10
==========================================
+ Hits        20581    20593      +12
+ Misses       6466     6464       -2

Impacted Files
Coverage Δ

datafusion/src/physical_plan/hash_join.rs
85.40% <100.00%> (+0.50%)
:arrow_up:

Continue to review full report at Codecov.

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

Thanks @houqp


webhooks/gitlab: Support both "Build Hook" and "Job Hook" events.

GitLab recently changed their event name for build notifications
from "Build Hook" to "Job Hook". Instead of just supporting the
latter, we should support both just in case people are running
older versions of GitLab.
@timabbott: Sorry, I didn't know GitLab was open source! :)

No worries!  These days, most of the Git hosting projects have this dual-deployment nature (GitHub Enterprise, Bitbucket, etc.).


[13.0.0] Add audit metadata for wasmtime-wmemcheck

Required to get the release automation working again

Addressing the failure here

I've pushed up a cherry-pick of the flaky test failure


[BUG] dial tcp [fe80::21b6:a3a0:d48e:76ca]:22: connectex: A socket operation was attempted to an unreachable network.

General information

OS: Windows 10 Pro
Hypervisor: Hyper-V
Did you run crc setup before starting it (Yes/No)? Yes
Running CRC on: Laptop

CRC version
# Put `crc version` output here
CodeReady Containers version: 1.25.0+0e5748c8
OpenShift version: 4.7.5 (embedded in executable)

## CRC status
```bash
# Put `crc status --log-level debug` output here
DEBU CodeReady Containers version: 1.25.0+0e5748c8
DEBU OpenShift version: 4.7.5 (embedded in executable)
DEBU Running 'crc status'
DEBU Checking file: C:\Users\WengJo1\.crc\machines\crc\.crc-exist
DEBU Checking file: C:\Users\WengJo1\.crc\machines\crc\.crc-exist
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM crc ).state
                   ] : Running
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM crc ).state
                   ] : Running
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive (( Hyper-V\Get-VM crc ).networkadapters[0]).ipaddresses[0]
DEBU [stdout =====>] :
DEBU [stderr =====>] :
Error getting ip: IP not found

## CRC config
```bash
# Put `crc config view` output here

consent-telemetry                     : no

Host Operating System
# Put the output of `cat /etc/os-release` in case of Linux
# put the output of `sw_vers` in case of Mac
# Put the output of `systeminfo` in case of Windows

Host Name:                 xxxxxxx
OS Name:                   Microsoft Windows 10 Pro
OS Version:                10.0.18363 N/A Build 18363
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Member Workstation
OS Build Type:             Multiprocessor Free
Registered Owner:          Desktop Management Services
Registered Organization:   Government of Ontario
Product ID:                00331-10000-00001-AA915
Original Install Date:     03/27/2021, 5:07:47 PM
System Boot Time:          04/29/2021, 7:13:25 AM
System Manufacturer:       LENOVO
System Model:              20S1S80400
System Type:               x64-based PC
Processor(s):              1 Processor(s) Installed.
                           [01]: Intel64 Family 6 Model 142 Stepping 12 GenuineIntel ~804 Mhz
BIOS Version:              LENOVO N2XET26W (1.16 ), 11/04/2020
Windows Directory:         C:\windows
System Directory:          C:\windows\system32
Boot Device:               \Device\HarddiskVolume1
System Locale:             en-ca;English (Canada)
Input Locale:              en-us;English (United States)
Time Zone:                 (UTC-05:00) Eastern Time (US & Canada)
Total Physical Memory:     16,135 MB
Available Physical Memory: 2,018 MB
Virtual Memory: Max Size:  30,983 MB
Virtual Memory: Available: 8,148 MB
Virtual Memory: In Use:    22,835 MB
Page File Location(s):     C:\pagefile.sys
Domain:                    cihs.ad.xx.xxx.xxx
Logon Server:              \\Mxxxxx
Hotfix(s):                 19 Hotfix(s) Installed.
                           [01]: KB4601056
                           [02]: KB4513661
                           [03]: KB4516115
                           [04]: KB4517245
                           [05]: KB4521863
                           [06]: KB4535680
                           [07]: KB4537759
                           [08]: KB4538674
                           [09]: KB4541338
                           [10]: KB4552152
                           [11]: KB4560959
                           [12]: KB4561600
                           [13]: KB4565554
                           [14]: KB4569073
                           [15]: KB4580325
                           [16]: KB4586863
                           [17]: KB5000908
                           [18]: KB5001406
                           [19]: KB5001337
Network Card(s):           7 NIC(s) Installed.
                           [01]: Intel(R) Ethernet Connection (10) I219-V
                                 Connection Name: Ethernet
                                 Status:          Media disconnected
                           [02]: Intel(R) Wi-Fi 6 AX201 160MHz
                                 Connection Name: Wi-Fi
                                 DHCP Enabled:    Yes
                                 DHCP Server:     <IP_ADDRESS>
                                 IP address(es)
                                 [01]: <IP_ADDRESS>
                           [03]: Bluetooth Device (Personal Area Network)
                                 Connection Name: Bluetooth Network Connection
                                 Status:          Media disconnected
                           [04]: Check Point Virtual Network Adapter For Endpoint VPN Client
                                 Connection Name: Local Area Connection* 3
                                 Status:          Media disconnected
                           [05]: Hyper-V Virtual Ethernet Adapter
                                 Connection Name: vEthernet (Default Switch)
                                 DHCP Enabled:    No
                                 IP address(es)
                                 [01]: <IP_ADDRESS>
                           [06]: Hyper-V Virtual Ethernet Adapter
                                 Connection Name: vEthernet (WSL)
                                 DHCP Enabled:    No
                                 IP address(es)
                                 [01]: <IP_ADDRESS>
                           [07]: VirtualBox Host-Only Ethernet Adapter
                                 Connection Name: VirtualBox Host-Only Network
                                 DHCP Enabled:    No
                                 IP address(es)
                                 [01]: <IP_ADDRESS>
Hyper-V Requirements:      A hypervisor has been detected. Features required for Hyper-V will not be displayed.

Steps to reproduce

crc delete -f
crc setup
successfully
crc start --log-level debug

Expected
crc up and running
Actual
error
Logs
DEBU CodeReady Containers version: 1.25.0+0e5748c8
DEBU OpenShift version: 4.7.5 (embedded in executable)
DEBU Running 'crc start'
DEBU Total memory of system is<PHONE_NUMBER>8 bytes
DEBU No new version available. The latest version is 1.25.0
INFO Checking if podman remote executable is cached
DEBU Currently podman remote is not supported
INFO Checking if admin-helper executable is cached
DEBU Running 'C:\Users\WengJo1\.crc\bin\admin-helper-windows.exe --version'
DEBU Found admin-helper-windows.exe version 0.0.3
DEBU admin-helper executable already cached
INFO Checking minimum RAM requirements
DEBU Total memory of system is<PHONE_NUMBER>8 bytes
INFO Checking if running in a shell with administrator rights
INFO Checking Windows 10 release
INFO Checking Windows edition
DEBU Running on Windows Professional edition
INFO Checking if Hyper-V is installed and operational
INFO Checking if user is a member of the Hyper-V Administrators group
INFO Checking if Hyper-V service is enabled
INFO Checking if the Hyper-V virtual switch exist
INFO Found Virtual Switch to use: Default Switch
DEBU Checking file: C:\Users\WengJo1\.crc\machines\crc\.crc-exist
DEBU Cannot load secret from configuration: empty path
DEBU Cannot load secret from keyring: secret not found in keyring
CodeReady Containers requires a pull secret to download content from Red Hat.
You can copy it from the Pull Secret section of https://cloud.redhat.com/openshift/create/local.
? Please enter the pull secret **********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
DEBU Copying 'C:\Users\WengJo1\.crc\cache\crc_hyperv_4.7.5\oc.exe' to 'C:\Users\WengJo1\.crc\bin\oc\oc.exe'
INFO Loading bundle: crc_hyperv_4.7.5.crcbundle ...
INFO Creating CodeReady Containers VM for OpenShift 4.7.5...
DEBU Running pre-create checks...
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive @(Get-Module -ListAvailable hyper-v).Name | Get-Unique
                   ] : Hyper-V
DEBU [stderr =====>] :                                                                                DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive @([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole(([System.Security.Principal.SecurityIdentifier]::new("S-1-5-32-578")))                                                                                True                                                                                DEBU [stderr =====>] :                                                                                DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive [Console]::OutputEncoding = [Text.Encoding]::UTF8; (Hyper-V\Get-VMSwitch).Name
DEBU [stdout =====>] : Default Switch

DEBU [stderr =====>] :
DEBU Creating machine...
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive [Console]::OutputEncoding = [Text.Encoding]::UTF8; (Hyper-V\Get-VMSwitch).Name
DEBU [stdout =====>] : Default Switch

DEBU [stderr =====>] :
DEBU Using switch "Default Switch"
DEBU Creating VM...
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive Hyper-V\New-VM crc -Path 'C:\Users\WengJo1\.crc\machines\crc' -MemoryStartupBytes 9216MB -SwitchName 'Default Switch'
DEBU [stdout =====>] :
Name State CPUUsage(%) MemoryAssigned(M) Uptime   Status             Version
---- ----- ----------- ----------------- ------   ------             -------
crc  Off   0           0                 00:00:00 Operating normally 9.0

DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive Hyper-V\Set-VMMemory -VMName crc -DynamicMemoryEnabled $false
DEBU [stdout =====>] :
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive Hyper-V\Set-VMProcessor crc -Count 4
DEBU [stdout =====>] :
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive Hyper-V\Add-VMHardDiskDrive -VMName crc -Path 'C:\Users\WengJo1\.crc\machines\crc\crc.vhdx'
DEBU [stdout =====>] :
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive Hyper-V\Start-VM crc
DEBU [stdout =====>] :
DEBU [stderr =====>] :
DEBU Waiting for host to start...
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM crc ).state
                   ] : Running
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive (( Hyper-V\Get-VM crc ).networkadapters[0]).ipaddresses[0]
DEBU [stdout =====>] :
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM crc ).state
                   ] : Running
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive (( Hyper-V\Get-VM crc ).networkadapters[0]).ipaddresses[0]
DEBU [stdout =====>] :
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM crc ).state
                   ] : Running
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive (( Hyper-V\Get-VM crc ).networkadapters[0]).ipaddresses[0]
DEBU [stdout =====>] :
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM crc ).state
                   ] : Running
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive (( Hyper-V\Get-VM crc ).networkadapters[0]).ipaddresses[0]
 EBU [stdout =====>] : fe80::b589:7028:83d0:152b
DEBU [stderr =====>] :
DEBU Waiting for machine to be running, this may take a few minutes...
DEBU retry loop: attempt 0
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM crc ).state
                   ] : Running
DEBU [stderr =====>] :
DEBU Machine is up and running!
DEBU Machine successfully created
DEBU Created C:\Users\WengJo1\.crc\machines\crc\.crc-exist
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM crc ).state
                   ] : Running
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM crc ).state
                   ] : Running
DEBU [stderr =====>] :
DEBU [executing ==>] : C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive (( Hyper-V\Get-VM crc ).networkadapters[0]).ipaddresses[0]
 EBU [stdout =====>] : fe80::b589:7028:83d0:152b
DEBU [stderr =====>] :
DEBU Waiting until ssh is available
DEBU retry loop: attempt 0
DEBU Running SSH command: exit 0
DEBU Using ssh private keys: [C:\Users\WengJo1\.crc\cache\crc_hyperv_4.7.5\id_ecdsa_crc]
DEBU SSH command results: err: dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network., output:
DEBU error: Temporary error: ssh command error:
command : exit 0
err     : dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network.\n - sleeping 1s
DEBU retry loop: attempt 1
DEBU Running SSH command: exit 0
DEBU Using ssh private keys: [C:\Users\WengJo1\.crc\cache\crc_hyperv_4.7.5\id_ecdsa_crc]
DEBU SSH command results: err: dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network., output:
DEBU error: Temporary error: ssh command error:
command : exit 0
err     : dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network.\n - sleeping 1s
DEBU retry loop: attempt 2
DEBU Running SSH command: exit 0
DEBU Using ssh private keys: [C:\Users\WengJo1\.crc\cache\crc_hyperv_4.7.5\id_ecdsa_crc]
DEBU SSH command results: err: dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network., output:
DEBU error: Temporary error: ssh command error:
command : exit 0
err     : dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network.\n - sleeping 1s
DEBU retry loop: attempt 3
DEBU Running SSH command: exit 0
DEBU Using ssh private keys: [C:\Users\WengJo1\.crc\cache\crc_hyperv_4.7.5\id_ecdsa_crc]
DEBU SSH command results: err: dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network., output:
DEBU error: Temporary error: ssh command error:
command : exit 0
err     : dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network.\n - sleeping 1s
DEBU retry loop: attempt 4
DEBU Running SSH command: exit 0
DEBU Using ssh private keys: [C:\Users\WengJo1\.crc\cache\crc_hyperv_4.7.5\id_ecdsa_crc]
DEBU SSH command results: err: dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network., output:
DEBU error: Temporary error: ssh command error:
command : exit 0
err     : dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network.\n - sleeping 1s
DEBU retry loop: attempt 5
DEBU Running SSH command: exit 0
DEBU Using ssh private keys: [C:\Users\WengJo1\.crc\cache\crc_hyperv_4.7.5\id_ecdsa_crc]
DEBU SSH command results: err: dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network., output:
DEBU error: Temporary error: ssh command error:
command : exit 0
err     : dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network.\n - sleeping 1s
DEBU retry loop: attempt 6
DEBU Running SSH command: exit 0
DEBU Using ssh private keys: [C:\Users\WengJo1\.crc\cache\crc_hyperv_4.7.5\id_ecdsa_crc]
DEBU SSH command results: err: dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network., output:
DEBU error: Temporary error: ssh command error:
command : exit 0
err     : dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network.\n - sleeping 1s
DEBU retry loop: attempt 7
DEBU Running SSH command: exit 0
DEBU Using ssh private keys: [C:\Users\WengJo1\.crc\cache\crc_hyperv_4.7.5\id_ecdsa_crc]
DEBU SSH command results: err: dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network., output:
DEBU error: Temporary error: ssh command error:
command : exit 0
err     : dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network.\n - sleeping 1s
DEBU retry loop: attempt 8
DEBU Running SSH command: exit 0
DEBU Using ssh private keys: [C:\Users\WengJo1\.crc\cache\crc_hyperv_4.7.5\id_ecdsa_crc]
DEBU SSH command results: err: dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network., output:
DEBU error: Temporary error: ssh command error:
command : exit 0
err     : dial tcp [fe80::b589:7028:83d0:152b]:22: connectex: A socket operation was attempted to an unreachable network.\n - sleeping 1s

Before gather the logs try following if that fix your issue
$ crc delete -f
$ crc cleanup
$ crc setup
$ crc start --log-level debug

Please consider posting the output of crc start --log-level debug  on http://gist.github.com/ and post the link in the issue.

There is no VPN connected.

@polaroffer Looks like the VM is getting an IPv6 address, which will not work, as a work around you can try to disable ipv6 addresses for the default switch by going to Network & sharing Settings > change adapter settings > vEthernet Default switch properties and uncheck the IPv6 option.


GUI: new egg chamber example dataset

This PR introduces the drosophile egg chamber data from LimeSeg Test Datasets(https://zenodo.org/record/1472859) as a new example dataset to Aydin Studio per @royerloic and @haesleinhuepf requested. Also this will enable aydin napari plugin to expose this data as an example data together with the plugin.

Hi @AhmetCanSolak ,
when reusing CC-BY licensensed materials, you should put a link to the CC-BY license in the documentation together with an acknowledgement of the authors. That's basically the only conditions CC-BY has.
https://creativecommons.org/licenses/by/4.0/
Best,
Robert

Hi @haesleinhuepf , I will be adding this in our new example datasets gallery in our documentation, thank you for the reminder!

you can follow on #236


ARTEMIS-3067 - track application properties in memory estimate and ch…

…eck for modification after potential filter execution

This fix seems a little indirect to me, but I did not see a better way. Am open to suggestions!

This fix seems a little indirect to me, but I did not see a better way. Am open to suggestions!