fix: resolve modules if folder contains a package.json file

getMappedPath resolves files by trying a number of different file extensions and filtering out those that aren't a file. This does not work when a TSConfig path alias resolves to a directory containing built assets, and described by a package.json, e.g. @foo/bar -> node_modules/foo/bar/dist.
If the tsconfig path is mapped to a folder that doesn't contain an index.${ext} file, then getMappedPath returns undefined as the folder itself is not a file. However, in some cases it is ok for this to resolve to the directory as the package.json contains a typings entry that references a .d.ts file, which is correctly handled by enhanced-resolve.
https://github.com/import-js/eslint-import-resolver-typescript/issues/188

@scott-ut Thanks for your contribution!


remove the Enumerable sig from Array#+

Motivation

Array#+, at least in Ruby 2.7, requires its arg to be an array.  Even if it does permit the more general form in Ruby (we'd have to check), the Enumerable sig should come second as the more general case.
Test plan

See included automated tests.

I am dumb, because I missed the implicit to_ary conversion in rb_ary_plus.  Silly implicit conversions.


Zombienet test for coretime

Check if KAGOME can work with Coretime feature enabled: https://github.com/paritytech/polkadot-sdk/pull/2867

Will be implemented as part of #1950


Enhancement: replace validation with optionsets

As we've extended CLI with support for optionsets (#2998), we can proceed and replace the validation of option sets in all commands with optionset definitions. We should also replace the obsolete validation tests with ones that check that correct optionsets have been defined in each command.
Following commands need updating:

[x] aad app add
[x] aad app get
[x] aad app remove
[x] aad app role add
[x] aad app role list
[x] aad app role remove
[x] aad app set
[x] aad approleassignment add
[x] aad approleassignment list
[x] aad approleassignment remove
[x] aad groupsettingtemplate get
[x] aad o365group conversation post list
[x] aad o365group teamify
[x] aad o365group user add
[x] aad o365group user remove
[x] aad o365group user set
[x] aad sp add
[x] aad sp get
[x] aad user get
[x] aad user set
~adaptivecard send~ // while the command expects either card or title it also allows both options so this validation can't be replaced by an option set which defines one of options but doesn't allow both
[x] outlook message list
[x] outlook message move
[x] pa app get
[x] planner bucket add
[x] planner bucket list
[x] planner plan add
[x] planner plan details get
[x] planner plan get
[x] planner plan list
[x] planner task add
~planner task list~ // options in the set are optional and can't be validated with an option set
~planner task set~ // options in the set are optional and can't be validated with an option set
[x] pp managementapp add
[x] spo app deploy
[x] spo app get
[x] spo contenttype get
[x] spo contenttype remove
[x] spo field get
[x] spo field remove
[x] spo field set
[x] spo file checkin
[x] spo file checkout
[x] spo file get
[x] spo file remove
[x] spo file sharinginfo get
[x] spo group get
[x] spo group remove
[x] spo group user add
[x] spo group user list
[x] spo group user remove
[x] spo list contenttype add
[x] spo list contenttype default set
[x] spo list contenttype list
[x] spo list contenttype remove
[x] spo list get
[x] spo list label get
[x] spo list label set
[x] spo list remove
[x] spo list sitescript get
[x] spo list view field add
[x] spo list view field remove
[x] spo list view field set
[x] spo list view get
[x] spo list view list
[x] spo list view remove
[x] spo list view set
[x] spo list webhook add
[x] spo list webhook get
~[ ] spo list webhook list~ // options in the set are optional and can't be validated with an option set
[x] spo list webhook remove
[x] spo list webhook set
[x] spo listitem add
[x] spo listitem attachment list
[x] spo listitem get
[x] spo listitem isrecord
[x] spo listitem list
[x] spo listitem record declare
[x] spo listitem record undeclare
[x] spo listitem remove
[x] spo listitem set
[x] spo site apppermission add
~[ ] spo site apppermission list~ // options in the set are optional and can't be validated with a set
[x] spo site apppermission remove
[x] spo site apppermission set
[x] spo term add
[x] spo term get
[x] spo term group get
[ ] spo term list
[ ] spo term set add
[ ] spo term set get
[ ] spo term set list
[ ] spo user get
[ ] spo user remove
[ ] teams app install
[ ] teams app list
[ ] teams app update
[ ] teams channel add
[ ] teams channel get
[ ] teams channel list
[ ] teams channel member set
[ ] teams channel membership list
[ ] teams channel remove
[ ] teams chat get
[ ] teams chat message send
[ ] teams conversationmember add
[ ] teams conversationmember list
[ ] teams tab add
[ ] teams tab get
[ ] teams team get
[ ] teams user app list
[ ] todo list remove
[ ] todo list set
[ ] todo task add
[ ] todo task list
[ ] todo task remove
[ ] todo task set
[ ] yammer user get

I think teams channel member set is missing. Also, teams channel membership list is being renamed. Won't this cause merge conflicts?

It's a new command so it could very well be that I missed it. Thank you!

Hey folks, while working on this, I'm having a second guess about how we implement validation in the CLI and if perhaps we shouldn't refactor it. This is also related to #3081.
Right now, we divide the validation logic between the CLI runtime and the command. Checks like unknown options, required options and now also option sets are validated in the CLI runtime, whereas command-specific validations are executed in the command. This allows us to keep the command-specific code clean, with just the things that are specific to command, but splits validation responsibility between the command and the CLI runtime. As a result, we've got no single place to point to and validate options end-to-end. In the command we implicitly assume that the CLI runtime will check some of the things that the command expects (required options specified, at least one option from each set specified, no unknown options when not supported, etc.). If we ever removed or changed some of the CLI validation logic, commands would be none the wiser but would likely break on runtime with unhandled exceptions.
In #3081, I suggested, that we implement validating output value (if specified) in the base Command class' validate method and then update the command-specific implementation so that it calls the base, eg:
  public validate(args: CommandArgs): boolean | string {
    const parentValidate = await super.validate(args);
    if (parentValidate !== true) {
      return parentValidate;
    }

   // ... command specific validation goes here
  }

This got me thinking: shouldn't we move all of the validation logic to the base command class? It would allow us to have everything in one place and calling command.validate(args) would always check everything, rather than just the specific checks for the command. The downside is, that each instance of the validate method would have to be adjusted to call its parent (in the above example first 4 lines). This is repetitive and verbose, and something that we'd also need to enforce with a custom eslint rule to be sure that all commands do indeed call the base checks.
An alternative would be for each command to define an array of functions to run in the validation phase. We'd refactor the validate method to iterate over this array and call each function, breaking the iteration as soon as one of them fails. In the base command class we'd initialize the validation array with the basic checks (unknown, required, option sets) and each command would have the ability to add its specific checks to it. This approach would allow us to avoid repetition in each command, while having the ability to test validation end-to-end.
What do you think @pnp/cli-for-microsoft-365-maintainers?

so if I understand this correctly in the base validation method you were thinking to have checks for

unknown,
required,
what we have now in option set
etc.. other kind of universal for each inherited command
and in the command itself just the specific like 🤔... hmmm.. is webUrl valid? or Id is number as well?

as for the array approach seems also interesting. I wonder won't it be more user friendly if we would do all checks and show all error messages instead of breaking after first one 🤔. But I am just thinking out loud here 😋

Correct: we'd add generic checks centrally and specific checks in the command so that we can avoid repetition and yet have an end-to-end ability to test the assumptions that the command makes on its options.
You brought up an interesting idea, @Adam-it about running all checks rather than just failing after the first one. Once we have an array of checks, we could choose if we want to use all checks that we currently have in the command's validate method in a single check function or break each check into a separate function. The tradeoff here is validation simplicity: if we define an option as required, we check for that first and in the whole command assume it's set. If we run all checks, rather than failing on the first one, then we'd need to consider the option's value as optional which would add some verbosity to our code.

That's true, but it was just a random idea I had about it. We could add this as CLI co configuration property like "shouldValidateAll" as maybe not everybody would like this kind of behavior and probably most is already used to what we have now, which is first fail, first message. But this could be a separate discussion, sorry for the confusion.
Anyway, going back on the topic, I feel more like the first option (generic checks in base class, and specific in command implementation) is the one I would pick to implement, rather than the array one. But as always, I am opened for a different opinion 😉

That's true, but it was just a random idea I had about it. We could add this as CLI co configuration property like "shouldValidateAll" as maybe not everybody would like this kind of behavior and probably most is already used to what we have now, which is first fail, first message. But this could be a separate discussion, sorry for the confusion.

All good and always good to get new ideas and perspectives. The challenge with such switch is that it changes the behavior of the code and assumption, so it would add a lot of extra code throughout the command to take into account both possible behaviors.

I feel more like the first option (generic checks in base class, and specific in command implementation) is the one I would pick to implement, rather than the array one

How do you feel about having to have:
    const parentValidate = await super.validate(args);
    if (parentValidate !== true) {
      return parentValidate;
    }

in each validate method and then probably also a custom eslint rule so that we can ensure that it's not missing somewhere and missing a part of our validation process?

hmm.. thats true.. I don't feel like repeating that code in every place 😊

Hey @milanholemans, @Jwaegebaert, I'd appreciate your feedback on https://github.com/pnp/cli-microsoft365/issues/3218#issuecomment-1147464081 😊

An alternative would be for each command to define an array of functions to run in the validation phase. We'd refactor the validate method to iterate over this array and call each function, breaking the iteration as soon as one of them fails. In the base command class we'd initialize the validation array with the basic checks (unknown, required, option sets) and each command would have the ability to add its specific checks to it. This approach would allow us to avoid repetition in each command, while having the ability to test validation end-to-end.

I like this option; sounds like a great way to abstract some of the repetitive stuff to a central location. So that would have my vote.

If we ever removed or changed some of the CLI validation logic, commands would be none the wiser but would likely break on runtime with unhandled exceptions.

Wouldn't it be better to make sure this scenario doesn't happen. That we just keep validating our required options, unknown options, options sets, etc at runtime. Then we simply retain the command specific validation within the command itself and don't need to do any speciale refactoring.
If I am not mistaken, this suggestion is mainly to get issue #2988 resolved. To apply validation for the default option --output, could we possibly apply this here so that it validates the option during runtime. https://github.com/pnp/cli-microsoft365/blob/3879fc921d0f8deea3ff525dc1e86533eb744d6e/src/cli/Cli.ts#L200-L203

hmm.. thats true.. I don't feel like repeating that code in every place 😊

Understandable, repeating code is never fun. On the other hand, we are already doing this today for other methods.
For example in the options function, we have to call the super class.
public options(): CommandOption[] {
   const options: CommandOption[] = [
     { option: '-u, --webUrl <webUrl>' }
   ];

   const parentOptions: CommandOption[] = super.options();
   return options.concat(parentOptions);
}

In the getTelemetryProperties function, we have to call the super class.
public getTelemetryProperties(args: CommandArgs): any {
   const telemetryProps: any = super.getTelemetryProperties(args);
   telemetryProps.listId = typeof args.options.listId !== 'undefined';
   return telemetryProps;
}

Because we are already calling the super class in other methods of course doesn't mean you get a free pass to use this even more.
But if I have to pick a side, I tend to take the one with the super class instead of the array of functions.
Actually, I kinda like it the way we are doing it now. All common checks are done in the CLI class, and specific checks are done in the command class. You say that if we ever remove or change something in the CLI validation, commands will break. This is also applies to the various util classes we have now. If we for example remove or change the Planner util class, Planner commands will fail. Sometimes a command just has to assume that something does what it promises.
But I understand that when the current logic does not meet the requirements, you have to look for another system.

If I am not mistaken, this suggestion is mainly to get issue https://github.com/pnp/cli-microsoft365/issues/2988 resolved. To apply validation for the default option --output, could we possibly apply this here so that it validates the option during runtime.

#2988 is just one of the things we need it for. #3218 (this issue) is another one, when due to refactoring I'm removing tests that originally belonged in the command in favor of a generic test in the runtime plus a check if the option sets have been defined (but not if they're used!). As I'm removing tests, that we'd need back if we were to move all of the validation into command, I thought it's the right time now to raise this issue 🙂

Understandable, repeating code is never fun. On the other hand, we are already doing this today for other methods.
For example in the options function, we have to call the super class.

Which are other examples of where we could apply this approach of how we compose objects. Imagine that in both cases we could do:
public init(): void {
  this.options.push([
     { option: '-u, --webUrl <webUrl>' }
   ]);

  this.telemetryProps.listId = typeof args.options.listId !== 'undefined';
}

wouldn't that be clearer? And we could always decide if we want to have everything in the init() method or rather break it down to specific methods (initTelemetry, initOptions) and have init call these methods.

Actually, I kinda like it the way we are doing it now. All common checks are done in the CLI class, and specific checks are done in the command class. You say that if we ever remove or change something in the CLI validation, commands will break. This is also applies to the various util classes we have now. If we for example remove or change the Planner util class, Planner commands will fail.

Not quite. If we change something about Planner classes, then command-specific tests should pick up on it and break because the end-to-end behavior won't be the same anymore. If that's not the case, then we should address this. By splitting validation and have some of it done in the CLI runtime and some in the command, we make it impossible to validate end-to-end behavior for commands.
I appreciate the discussion. Keep it coming ❤

wouldn't that be clearer? And we could always decide if we want to have everything in the init() method or rather break it down to specific methods (initTelemetry, initOptions) and have init call these methods.

I'm also fan of placing this logic within an init() method. When we have a command with several options, then the init method could become quite large. We could split them in more specific methods but that will cause it to be more verbose aswell. However we apply it, I like the init() method suggestion. 😄

This got me thinking: shouldn't we move all of the validation logic to the base command class?

In regards to your validation logic refactor. Personally, I would also opt for the first option. The generic checks within the base class and the command specific ones within the validate method.
const parentValidate = await super.validate(args);
if (parentValidate !== true) {
  return parentValidate;
}

Because if I'm not mistaken, that's how we do it now for the base options as well. It will indeed be a bit more verbose, but with a good eslint rule people won't forget to insert this new logic.

If we'd use the init approach, then we wouldn't need to call super because all validation functions would end up in an array and in the Command.validate() method we'd step through all of them. That would eliminate the need for overly verbose code and custom eslint rules 😄

Nice discussion, I'm joining in late. But better late than never!
I think it would make sense to move all the validation logic out of the runtime and into the Command base class.
But I'm not thinking about super calls, but the other way around: we could call the Command-specific validate functions from the base Command-class validate function. In that case you don't need the super functions. You'd basically just be able to use the validate function as it is now.
The only refactoring that should be done is from the CLI to the base Command class.
...or am I overlooking something here?

How would that work if we have a chain of classes that inherit from each other, like Command > SpoCommand > SpoWebGetCommand? How would command call both validation from SpoCommand and SpoWebGetCommand?

Well sure, that's something to think about. Because the validate functions override each other, only the outer one gets executed. If there is a validate function in the middle layer, it is ignored. I just did a quick check and saw such a validate function in the AppCommand base class. The SpoCommand base class doesn't seem to have it.
This might be a downside of my proposal, but we could work around it by adding a baseValidate function (or something like that) that can be overridden in this middle layer of command classes.
If it's not overridden it will just call the validate function directly.
✅ The big pro of this proposal is that the amount of refactoring can be greatly reduced. We can move the validation logic to the command class without having to touch every file that's out there.
I'm not saying that we should not move to an init function at some point. I'm thinking it would be a helpful way to configure all the specific things about a command, things like validation, but possibly also other things that are currently using class getters. But that can be done at a later stage as well.

Nice discussion, I'm joining in late. But better late than never!

What should I say then 😅. Needed some time to re-read this all ... like twice 😋. I feel like time goes twice as fast now then it used to 😅

wouldn't that be clearer? And we could always decide if we want to have everything in the init() method or rather break it down to specific methods (initTelemetry, initOptions) and have init call these methods.

+1 👍 here  😊 and with method separations to specific init methods. Doesn't it seem like a lot of refactoring 🤔?

I'm not saying that we should not move to an init function at some point. I'm thinking it would be a helpful way to configure all the specific things about a command, things like validation, but possibly also other things that are currently using class getters. But that can be done at a later stage as well.

I agree here as well. We could divide the refactoring into steps and split work

Great start @waldekmastykarz, I can see where you're going with this.
There is one part that I'd personally like to see different: it's the part about adding stuff to arrays in the commands init functions. (SpoWebGetCommand in your example) Adding stuff to arrays seems like 'the plumbing' to me. The plumbing should go in the cabinet where I don't see it instantly. 😉 eg: it should be done in the base class (Commmand).
I'd like the command classes to just return a configuration object to somewhere. Maybe using a super function. It can then be added to arrays in the base class. That would make it clearer what's expected of me without all the plumbing distracting me.
Do you see what I mean with this?

Love the design @waldekmastykarz! Initially I was a little confused with the use of the # char but your comment in the constructor makes it very clear. Definitely interesting to keep this comment block in the final code as well. Now I also see that it will indeed be convenient for all validation to occur in the Command class. This makes it much easier to get an overview of what a command does. 👍

There is one part that I'd personally like to see different

I agree with the suggestion of @martinlingstuyl. The part where we push items to the array looks quite verbose to repeat in every method.

Something like this:

class Command {
  constructor(configuration: IConfig) {
    // we break down configuration into separate functions for readability
    this.#initOptions(configuration);
    this.#initValidations(configuration);
    this.#initTelemetry(configuration);
  }
}

class SpoCommand extends Command {
  constructor(configuration: IConfig) {

    // We optionally add extra validation logic in intermediate layers
    configuration.validations.push((args) => {
      if (args.options.url) {
        return validation.isValidSharePointUrl(args.options.url);
      }

      return true;
    })

    super(configuration);
  }
}

class SpoSiteGetCommand extends SpoCommand {
  constructor() {

    // We build a configuration object
    const configuration: IConfig = {
        validations: [
          (args) => {
          if (args.options.url) {
            return validation.isValidSharePointUrl(args.options.url);
          }

          return true;
        }
      ],
      options: [
        { option: '--query [query]' },
        {
          option: '-o, --output [output]',
          autocomplete: ['csv', 'json', 'text']
        },
        { option: '--verbose' },
        { option: '--debug' }
      ],
      telemetry: (args, telemetryProperties) => {
        telemetryProperties.url = typeof args.options.url !== 'undefined';
        telemetryProperties.id = typeof args.options.id !== 'undefined';
      }
   }

    super(configuration);

  }
}

Love the design @waldekmastykarz! Initially I was a little confused with the use of the # char but your comment in the constructor makes it very clear.
I had the same impression 😅
@waldekmastykarz I like the idea and the example with arrays is quite solid and clear 👍. Just one question (sorry if it is a stupid one 😋) will it be possible to test each separate #init... method 🤔?
@martinlingstuyl I totally understand your point. TBH this configuration: IConfig could sometimes get quite big and in my experience usually when we create big, config kind of, objects to pass somewhere else we end up refactoring it to create local builders (factories) for parts of each object to make the initial object creation less big and more readable 😉. I am afraid it could be similar situation here 🤔, so we will end up having optionsBuilder, validationBuidler etc. to make the initial object creation clear.

TBH this configuration: IConfig could sometimes get quite big

You're probably right @Adam-it!

will it be possible to test each separate #init... method 🤔?

#init methods are there for readability and we won't need to test them. Instead, we'll test the behavior of the command, for example: does it fail as expected when a required option is missing, does it send correct telemetry, etc. How the command does it internally will become less relevant, which is a great way to ensure that our tests are not coupled to the implementation.

#init methods are there for readability and we won't need to test them. Instead, we'll test the behavior of the command, for example: does it fail as expected when a required option is missing, does it send correct telemetry, etc. How the command does it internally will become less relevant, which is a great way to ensure that our tests are not coupled to the implementation.

makes total sense 👍.. I like it 😍

So do we agree that we proceed with what I suggested in https://github.com/pnp/cli-microsoft365/issues/3218#issuecomment-1154815279? @pnp/cli-for-microsoft-365-maintainers

I am all in 👍

So action plan:

I'll create a new issue for the refactoring based on what we agreed
I'll reset this issue and put it on hold until the refactoring is done. When the refactoring is done, we can restart the work here to implement the missing option sets for the relevant commands.

Once again, thank you all for your feedback and ideas 🤗

Since the refactoring in #3409 is merged, I'll pick up working on this issue.


KeyError: 'loss_cls'

when i run the command：python tools/train.py configs/visdrone_step1_base.py
it got an error：
11/17 14:19:53 - mmengine - INFO - Iter(train) [  450/80000]  lr: 8.9990e-03  eta: 17:22:39  time: 0.7945  data_time: 0.0204  memory: 17784  loss: 0.9282  sup_loss_rpn_cls: 0.2866  sup_loss_rpn_bbox: 0.0894  sup_loss_cls: 0.3180  sup_acc: 95.3125  sup_loss_bbox: 0.1006  unsup_loss_rpn_cls: 0.0831  unsup_loss_rpn_bbox: 0.0000  unsup_loss_cls: 0.0505  unsup_acc: 100.0000  unsup_loss_bbox: 0.0000
File "tools/train.py", line 122, in
main()
File "tools/train.py", line 118, in main
runner.train()
File "/home/zwh/.conda/envs/castdet/lib/python3.8/site-packages/mmengine/runner/runner.py", line 1777, in train
model = self.train_loop.run()  # type: ignore
File "/home/zwh/.conda/envs/castdet/lib/python3.8/site-packages/mmengine/runner/loops.py", line 289, in run
self.run_iter(data_batch)
File "/home/zwh/.conda/envs/castdet/lib/python3.8/site-packages/mmengine/runner/loops.py", line 313, in run_iter
outputs = self.runner.model.train_step(
File "/home/zwh/.conda/envs/castdet/lib/python3.8/site-packages/mmengine/model/base_model/base_model.py", line 114, in train_step
losses = self._run_forward(data, mode='loss')  # type: ignore
File "/home/zwh/.conda/envs/castdet/lib/python3.8/site-packages/mmengine/model/base_model/base_model.py", line 361, in _run_forward
results = self(**data, mode=mode)
File "/home/zwh/.conda/envs/castdet/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
return forward_call(*input, **kwargs)
File "/home/zwh/.conda/envs/castdet/lib/python3.8/site-packages/mmdet/models/detectors/base.py", line 92, in forward
return self.loss(inputs, data_samples)
File "/home/zwh/.conda/envs/castdet/lib/python3.8/site-packages/mmdet/models/detectors/semi_base.py", line 87, in loss
losses.update(**self.loss_by_pseudo_instances(
File "/home/zwh/.conda/envs/castdet/lib/python3.8/site-packages/mmdet/models/detectors/soft_teacher.py", line 78, in loss_by_pseudo_instances
losses.update(**self.rcnn_cls_loss_by_pseudo_instances(
File "/home/zwh/.conda/envs/castdet/lib/python3.8/site-packages/mmdet/models/detectors/soft_teacher.py", line 255, in rcnn_cls_loss_by_pseudo_instances
losses['loss_cls'] = losses['loss_cls'] * len(
KeyError: 'loss_cls'
Can you solve this problem？Thanks！

You can modify the learning rate to make it smaller, but it will affect the detection accuracy later on. It is recommended to continue training with the original configuration.


Introducing asv to the JKU provider

Summary
Fixed Qiskit JKU Provider and introduced asv for benchmarking.
Details and comments

fixed mandatory coupling field
added alternative to build
fixed deprecated access to qubit
added asv config and benchmarks

@atilag @mtreinish Could you review our changes?

 All committers have signed the CLA.


view doesn't load on Android Kitkat after update to v1.4.5

After the update vis v1.4.4 -> v1.4.5, one of my display devices was unable to load the view anymore. It remained on the white screen with the spinning wheel indefinitly.
Reverting to vis v1.4.4 on the server and reloading the view on the device cleared up the issue immediatly.
The affected device is an older Android phone running Android v4.4.4/Kitkat.
Did v1.4.5 introduce new compatibility requirements that weren't necessary for v1.4.4?

The same problem with an old iPad and the ioBroker App.

Same for me: an old iPad and the ioBroker App does not work with 1.4.5 anymore.

Can someone please look into this?
This issue is keeping me from updating the adapter, which in turn keeps me from updating any other component on my ioBroker installation. Not a good situation. :-(

v1.4.65 is also not working?

Correct, as described in my initial post: The problem occured after updating vis v1.4.4 -> v1.4.5. Going back to v1.4.4 resolved the issue.

OI think the reason for this is ... https://github.com/ioBroker/ioBroker.vis/commit/ab82b1d2efc5c2c21954cd525e6634dbe5467575#diff-dc1ba6228bdc7ca8f354b8baf72deb978cb8a3d60942af60123ac35aa991b800R3042 ... template strings are not supported by androdi 4.4.4 https://caniuse.com/template-literals (and some other places, e.g. https://github.com/ioBroker/ioBroker.vis/commit/3f287815b04f7fb9d1dc8fcdba99cbde2b47bdb4#diff-dc1ba6228bdc7ca8f354b8baf72deb978cb8a3d60942af60123ac35aa991b800R3128)
@GermanBluefox ?? Change that back? Or should we start using some kind of bundler that transforms the code regardless what we do?

Can someone please do something about this? I've not been able to upgrade my system for three months now, even though there are some desirable fixes in other adapters. But I can't update them because they require a new admin adapter, which vis v1.4.4 doesn't work with any more. Even js-controller itself can't be upgraded, since one of the steps of the process is to upgrade all of the other adapters - which, again, I cannot do because of the problem with vis v1.4.5.

Vis has no dependency to Admin ... So what do you mean?

Good question. I believe I inferred this dependency from reading through some version history file, but going back to them now I can't find anything in either the admin history, nor the vis history, nor the web history. Not quite sure how I arrived at that conclusion now... ;-)

I removed some ES6 code in 1.4.9. Please try

Thanks! 1.4.12 works with my old iPad as well! 👍


METRON-259 Using 'any' for Snort's HOME_NETWORK

In some cases, Ansible is not yet aware of the 'tap0' interface when the Snort deployment begins.  This causes the deployment to fail with this error.
ERROR! ERROR! 'dict object' has no attribute u'ansible_tap0

It is not really necessary to set the HOME_NETWORK of Snort to the IP address of the sniff interface.  This needs to be customized for Snort on a case-by-case basis for production deployments based on the target environment.  For demo and development purposes, any works just fine and is much simpler.

I don't agree that using "any" works fine for either general or demonstration/development purposes.  If we don't sniff the same interface with all the sensors, we get events that are uncorrelated with the rest of the sensor stack. Additionally, we'll see events that have no pcap backup.
Kind of related - there is a a production use case for the tap0 interface. You can direct all interfaces of interest to to the tap interface and sniff that.
Is there any reason to not investigate making this work using the sniff interface before falling back to "any"?

AFAIK, the HOME_NETWORK is used primarily to designate which traffic should be validated against the rule set.  If Snort sees traffic where the source or destination is NOT associated with the HOME_NETWORK then it will not alert.
For replaying raw pcap in our demo environment, I want all traffic to be run against the rule set.  Setting HOME_NETWORK to 'any' achieves this.  What do you think?

The current code base is trying to set the HOME_NETWORK to the IP of the sniff interface.  I can't really think of any conditions under which you would want the HOME_NETWORK set to the IP of the sniff interface.  Maybe I'm wrong though.

Ah, that's a good clarification- I guess what we need is two things:

HOME_NETWORK to any (which you have done).
Configure the snort IFACE to be the sniff_interface.

So I had the corrective action wrong in METRON-247. If I'm not mistaken, after this PR, Snort will still listen on the first interface by default, so we won't see the traffic we expect in many situations. Having looked closer, I think the above 2 would have been the actual fix.
Thoughts?

+1

@dlyle65535 the code already configures Snort to listen on the sniff_interface. See bottom of metron-deployment/roles/snort/snort.yml

@nickwallen - so it does. Good deal. I'm +1.
Thanks!


Update windows CI to python 3.9

Codecov Report

Merging #129 (a5a4243) into master (80eb771) will decrease coverage by 0.99%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #129      +/-   ##
==========================================
- Coverage   85.89%   84.90%   -1.00%
==========================================
  Files          17       17
  Lines        3028     3028
==========================================
- Hits         2601     2571      -30
- Misses        427      457      +30

Impacted Files
Coverage Δ

geofileops/util/_general_util.py
66.94% <0.00%> (-17.36%)
:arrow_down:

geofileops/util/_io_util.py
75.00% <0.00%> (-6.67%)
:arrow_down:

geofileops/util/_geoops_gpd.py
86.60% <0.00%> (-0.74%)
:arrow_down:

geofileops/util/_ogr_util.py
81.51% <0.00%> (-0.48%)
:arrow_down:

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 80eb771...a5a4243. Read the comment docs.


[VS Code] [Audio] Request startOrJoinCall failed unexpectedly without providing any details.

Error:
Request startOrJoinCall failed unexpectedly without providing any details.
Steps to Reproduce:
1.
2.

Version Data

extensionName
VSLS-Audio

extensionVersion
0.1.91

applicationName
VSCode

applicationVersion
1.55.0

platformName
MacOS

platformVersion
20.3.0

Closing as a duplicate of #4076 . Feel free to join the conversation there! Please try running the command Live Share: repair audio installation.


Add dark mode

Changes

Add dark mode support via toggle button in top right corner of UI

Future improvements:

Auto detect if to enable dark mode based on users OS setting
Prettier button (maybe we can use a component library (https://cloudscape.design/components/ ;) )

Added ThemeContext to handle dark mode + persistence as @vishnukool suggested, also did some refactoring to use ant.design button component and make css colors easier to manage

Also sorry, I merged one more feature and so there's some conflicts, if you can rebase for the next revision

I will close this, since no updates have been made. Feel free to reopen after above are fixed and rebased


[Mini PRFC] EntitiesSearchFilter type refactor

The current EntitiesSearchFilter's matchValueExists field is a bit confusing - it's not immediately clear the nuances of its behavior until you closely examine the implementation in NextEntitiesCatalog. By splitting the filter into to distinct types (one for key and another for key + value) as well as renaming the fields, I think this expresses the intent of the filters more cleanly. This also allows filtering by negation for key + value filters, which is not possible with the current implementation).

@Joonpark13 how does this one interplay with https://github.com/backstage/backstage/pull/7843 ? Are both desired still?

@Joonpark13 how does this one interplay with #7843 ? Are both desired still?

I'd say so - I think this can follow pretty smoothly after #7843 if we go ahead with this API change.

just add a bit of a guide for how to migrate code that uses the previous type to use this new one.

Can do - where would be the best place for this?

From sync: Perhaps allOf, anyOf, not in the filter nesting instead of negate?

From sync: Perhaps allOf, anyOf, not in the filter nesting instead of negate?

I've been thinking about this a bit more, and I think it encourages simpler query structure if we ask for negation through a field instead of a separate nested level. This means that we are essentially asking for multiple, individual NOT statements (which I think are easier to understand), instead of negating a possibly complex compound statement. What do you think?

Not sure about that. Would you have not: true, allOf: [...], not: true, anyOf: [...], etc too then?
From a query structure perspective it feels like inversion is always a unary operator on a subtree. So whatever expression parsing we may end up making, will want to emit a unary not and recurse, no?

Not sure about that. Would you have { not: true, allOf: [...] }, { not: true, anyOf: [...] }, etc too then?
From a query structure perspective it feels like inversion is always a unary operator on a subtree. So whatever expression parsing we may end up making, will want to emit a unary not and recurse, no?

I was thinking that it would be a field only on EntitySearchFilter (the leaf), not any EntityFilter type. But your statement about inversion always being an unary operator on a subtree is correct as far as I understand it. I think this does give more choice in structure, which I now realize can be good if people have some large complex existing query that they want to negate.

Yeah if we're going to do the general expressions then we might as well.
Otherwise it'd be hard or impossible to express some things, like, you could try to express not(a or b) as not(a) and not(b) etc but it'd be awkward and some thing might not pan out at all if I'm not thinking all wrong.

The commit to add negation by nesting has been pushed up, please take another look!
@Rugvip happy to try to add a few words to help migration, not sure where the best place for that would be though?


not an actual api for clash royale

Somewhere in the readme it should be mentioned that this is not an actual api for clash royale.
I just spent 30 mins installing this, but only just found out that it does not connect to the clash royale servers.
There are a few mentions in the closed tickets, but a more obvious message in the readme would be nice.

30 minutes for installation?
Anyway this issue is invalid, read this:

This content is not affiliated with, endorsed, sponsored, or specifically approved by Supercell and Supercell is not responsible for it. For more information see Supercell’s Fan Content Policy.

30 minutes was because this was my first node+mongo installation. After figuring out how to install those two, the installation was as easy as described in the readme.
I didn't mean to disrespect your project, its a great api for a lot of purposes.
Its just that the name, and readme never mention that it doesn't pull live data from the game.
The disclaimer is just a legal copy/paste that absolves supercell's responsibility.
Projects that connect to the actual supercell servers also carry this statement. For example at the bottom of https://royaleapi.com/. Since there is no official api, they have probably reverse engineered the protocol of the app, and are using that to power their website.
A lot of developers, including me, have been looking on github for a project that connects to the actual servers, but haven't found any.
https://github.com/martincarrera/clash-royale-api/issues/80
https://github.com/martincarrera/clash-royale-api/issues/39
https://github.com/martincarrera/clash-royale-api/issues/38
https://github.com/martincarrera/clash-royale-api/issues/37
https://github.com/martincarrera/clash-royale-api/issues/30
Just a small message like this in the readme would prevent some confusion: This api doesn't pull live data from the supercell servers, therefor it cannot provide live player statistics, or live clan information.

Then we'll wait for @martincarrera @MaherFa

I'm facing the exact same problem. The only diff, I tried the endpoint before installing. Lost only 5 minutes. but it could be important to mention it. I found this API helpful for a lot of things, except the one I came here for.

Hey! this IS a clash royale API. It is an API and it is about clash royale.
The problem is that this only serve static information and you need live information, I'm sorry that it took 30 minutes for you to install the API and get it running locally and then realize that it was not useful for your needs.

I didn't mean it's not a clash royale api. I meant that it doesn't pull live data from the clash royale servers.
A small message in the readme that explains this difference would be nice.

You said that:

this is not an actual api for clash royale.

Anyway, I think there's no point in discussing this issue as @martincarrera labeled it wontfix.
You could try making a pull for this but again, I don't think it's worth it.

I think @Jimbolino just don't have the right words, but the problem still exact. With the name being Clash Royale API, it can lead to the thinking that it serve live data. Just a little note could help ppl understanding the type of project this is all about.
I do understand that the way it was told "This is not a clash royale api" it can be frustrating, but the message is clear.... the OP feel like someone lies to him. So there's a need for clarification.

Maybe a note about not providing live data can help few people.
But when I searched about Clash Royale API and found this project, after looking at the endpoints, I realized this is not a live data API.

@AmirSavand i'm with you on that, As I said, I tested the endpoint and realized fast that it was not live data, but there's a lot of hobbyist around who will not test and check, they just assume it do what they need because it exists online ;)


OpenAPI (Swagger) schema shouldn't provide choices for Status references

Environment

Nautobot version (Docker tag too if applicable): all

Steps to Reproduce
Currently the OpenAPI schema generated by Nautobot will list a specific enum of permissible options for references to Status objects, e.g.
    Circuit:
      ...
      properties:
        ...
        status:
          type: object
          properties:
            value:
              type: string
              enum:
              - active
              - decommissioned
              - deprovisioning
              - offline
              - planned
              - provisioning
            label:
              type: string
              enum:
              - Active
              - Decommissioned
              - Deprovisioning
              - Offline
              - Planned
              - Provisioning

The problem, of course, is that this is NOT actually a hard-coded list of choices, it's determined at schema generation time from whatever set of Status objects happen to be defined. The moment a user adds, deletes, or edits any Status record, this part of the schema becomes inaccurate.
Most likely, the best solution here (albeit probably a breaking, i.e. 2.0 change) will be to change the status API field serializers so that they use a nested serializer like any other foreign-key reference, i.e. instead of:
      "status": {
        "value": "active",
        "label": "Active"
      }

they instead use:
    {
      "id": "64864569-9d3f-4b17-bb00-47296d9ccd0e",
      "display": "Active",
      "url": "https://demo.nautobot.com/api/extras/statuses/64864569-9d3f-4b17-bb00-47296d9ccd0e/",
      "name": "Active",
      "slug": "active",
    },

Straightforward enough to implement, thanks to extensive use of mixin classes. The bigger challenge will be making it backwards-compatible with older API versions - there are a lot of models with Statuses, so that'll be a lot of versioned serializers.

Implemented for 2.0 in #3225.


fix: cannot create credentials directory

This commit fixes the following error:
2022-10-21T12:42:08.510+0200	error	sumologicextension@v0.57.2-sumo-1/extension.go:297	Unable to store collector credentials, they will be used now but won't be re-used on next run	{"kind": "extension", "name": "sumologic", "collector_name": "mstozek-mac-7e9e719a-5903-487c-8d35-eaa51811cad9", "collector_id": "0000000000355218", "error": "mkdir ~/.otelcol-credentials: no such file or directory"}
Apparently otelcol cannot resolve ~ to home directory properly.

How about $HOME/..sumologic-otel-collector instead? That will work if without the install script as well.

How about $HOME/.sumologic-otel-collector instead? That will work if without the install script as well.

Yeah, that might work as well because when run as systemd user we want to set HOME=/var/lib/otelcol-sumo anyway. But there is a problem 🤔
For systemd service user config (and home) dir is: /var/lib/otelcol-sumo - which is just $HOME/
For regular user config dir should be something like $HOME/.config/otelcol-sumo or just $HOME/.otelcol-sumo
How to make both compatible?

How about $HOME/.sumologic-otel-collector instead? That will work if without the install script as well.

Yeah, that might work as well because when run as systemd user we want to set HOME=/var/lib/otelcol-sumo anyway. But there is a problem 🤔
For systemd service user config (and home) dir is: /var/lib/otelcol-sumo - which is just $HOME/ For regular user config dir should be something like $HOME/.config/otelcol-sumo or just $HOME/.otelcol-sumo
How to make both compatible?

If we want to behave the same way as other system daemons, then I think your change is ok. If the user wants to use a different folder, they can modify the configuration.


Adjust vertex batching for modern-day use cases

From my experimentation, o!f almost never goes above 50 vertices per draw, and every single draw uses a new VBO. osu! is even lower at <30 vertices per draw. So 50 is a good value but I picked 100 vertices for a "safe" value.
I found that using 8 as the minimum amount of children resulted in a slightly reduced number of VBO binds:

old
new

The next step I believe is to implement mapped buffers which we can write to unsynchronised, and re-use the same VBO for subsequent Draw() calls.
This improves performance a tad (centipede is now mostly update limited for me), and reduces memory usage by at least 2x. Here's some comparisons:
Left = master, right = this branch

Here's a few more scenarios:


AnyScript

Changes proposed:

[x] Add

@melund I pushed an icon version that is compatible with our art guidelines to complete the PR.

Thanks, @JimiC. I have updated the files again. I see you modified the SVG. Cool. I made it originally with Inkscape. Is there any particular settings I could have used to get it right the first time around.

We prefer icons to be created by AI. Inkscape is also OK. We can then modify them to our art guidelines.

Fair. Thanks for all your help. @JimiC


"Angular support deprecation" Warning messages are displayed on the dashboard

This dashboard depends on Angular, which is deprecated and will stop working in future releases of Grafana.
Read our deprecation notice and migration advice.
Do you have any plan to solve it? Thank you!

OK, I followed the instruction to migrate the deprecated Angular plugin to React, so I closed this issue.


Enable firebase performance monitoring

By this ticket ,we will enable firebase performance monitoring .

https://github.com/Sambit650/Daily_News/pull/5

Merged with Main


Bring vecdot implementation in line with the one in array-api-compat

This fixes array_api_tests/test_linalg.py::test_vecdot that was failing.

This is failing with a different error in the tensordot test

This should be re-worked after #481 is in

This is failing for some edge cases for arrays of size 0 (tracked in #420), so I haven't re-enabled array API tests for this.


Allow directory recursion to happen on S3/MinIO (rather than locally)

Description
When recursing into multiple subdirectories on a locally-hosted MinIO server, I have experienced a lot of unreliability in terms of the number of files reported by ListFolderAsync().  After some investigation, I determined that there was an issue in the local recursion code, although I have not been able to identify the exact cause.  The problem seems to be here:
await Task.WhenAll(folders.Select(f => ListFolderAsync(container, f.FullPath, options, cancellationToken))).ConfigureAwait(false);
If I change this to:
foreach(var folder in folders)
{
    await ListFolderAsync(container, folder.FullPath, options, cancellationToken).ConfigureAwait(false)
}

or simply change the AsyncLimiter value from 10 down to 1, everything works reliably (but much more slowly!)
But there is also an option to have the recursion done on the S3 server itself.  In this case it just returns all the files names to the client using the NextContinuationToken mechanism.  In my tests, this also works reliably, and no more slowly than the local recursion method.
So, this PR adds additional properties to the ListOptions class, to allow the user to specify local or remote recursion, and also to control the number of parallel tasks used for local recursion.  The defaults remain as before.
--- UPDATE ---
Attached is a minimal reproduction solution.  Usage:
minio-repro <bucket name> <api key> <secret key> <s3 key> (<serviceUrl> | <region>)

<s3 key> is the s3 key of a folder inside the bucket containing test data

The code will query the folder 10 times in succession using Storage.ListFilesAsync() with recursion enabled and report the number of files returned on each query.
I want to request a follow up PR. Can we have the Remote recursion set as default for S3 and MinIO and all the places where it is natively supported? That would be great, thanks.

Hey nick, could you let me know how I can accomplish this? I can put in some time.

Robin
I've looked into this, and S3/MinIO appears to be the only provider for which this is configurable.  Azure/GCP/FTP always recurse remotely, and SFTP/Disk/ZIP always recurse locally.
I'll submit a PR to change the default in ListOptions from Local to Remote

Wonderful!


boards: arm: add toradex verdin imx8mm board

Add Toradex Verdin iMX8M Mini board based on NXP MIMX8MM EVK using the i.MX8MM SoC. This code is intented to be used with the Cortex-M4.

@danieldegrasse could you please take a look?

Hi @danieldegrasse, is there anything else I could do to help this PR moving forward? thanks

Hi guys, sorry to tag you @mmahadevan108, @dleach02, and @decsny, but could you please review this PR so we can move forward? Thanks.

Should there be a toradex board group in the MAINTAINER.yml?

Should there be a toradex board group in the MAINTAINER.yml?

If that's required, I can update the PR. Please let me know.

Should there be a toradex board group in the MAINTAINER.yml?

If that's required, I can update the PR. Please let me know.

I think the project is trying to deprecate the CODEOWNERS file

Should there be a toradex board group in the MAINTAINER.yml?

If that's required, I can update the PR. Please let me know.

I think the project is trying to deprecate the CODEOWNERS file

Added, thanks! Please let me know if that's correct or if something else is needed.

@kartben is the maintainers entry correct, and does it require any approval by TSC since it adds a maintainer?

Needs to be migrated to hwmv2

Hello, apologies for the delay. I believe I was able to update the PR to hwmv2. Please let me know.

@hiagofranco do you plan on returning to your PR and addressing the comments?

Hi @dleach02 I spoke to @hiagofranco and he has been moved to another role within Toradex which is why this has been stale for a while.  I'll try to take it up and move it forward and just consult with him directly.  We definitely want to see this support added in properly but I'm new to Zephyr so it may take some time.

No problem. Ping the PR if you need assistance and to keep the stale label cleared.

Please remove the stale label. This is still on my backlog.

@hiagofranco , any chance you plan to get back to this PR?

@hiagofranco , any chance you plan to get back to this PR?

It's now on my plate as @hiagofranco has been pulled into a different role.  I plan to get to but not sure when.

Hi all. I finally got around to spending some time on this.  I'm not sure the best way to take over this PR since it is based on @hiagofranco's fork.  I created a fork and added additional commits to address most of (I hope) the feedback above.  For now I have kept them as separate commits for ease of review but am happy to squash them when we get closer to approval.
Should I just create a new PR with fork/branch and continue the discussion there?

Should I just create a new PR with fork/branch and continue the discussion there?

Is it possible for you to push commits to his fork, if @hiagofranco sets up access permissions correctly? Otherwise, I do think we'd need to create an additional PR.

Should I just create a new PR with fork/branch and continue the discussion there?

Is it possible for you to push commits to his fork, if @hiagofranco sets up access permissions correctly? Otherwise, I do think we'd need to create an additional PR.

I was gonna suggest that too but then realized GitHub UI says "Maintainers are allowed to edit this pull request.", so not sure the branch would be writable by @drewmoseley -- but definitely worth trying!

Confirmed that I cannot (yet) write to @hiagofranco's fork.  I've pinged him directly to see if he can share it with me.

And just like that, I have push access.  Ready for further review.

Please take a look at the Compliance failures

Yes. At a minimum, looks like this needs a rebase.

commits need to be squashed

I will definitely do that once I get all the comments addressed.  Unless you prefer me to do it now; it's easier for me to keep track of what has been fixed and what is still open.

commits need to be squashed

I will definitely do that once I get all the comments addressed. Unless you prefer me to do it now; it's easier for me to keep track of what has been fixed and what is still open.

I'm not going to review a PR which has fixups after fixups after fixups, it needs to be squashed now for people to review it

OK.  Squashed and verified compliance test succeed locally.  Hopefully, I did not miss any review points.

Thanks @nordicjm your latest review comments have been included.

@hiagofranco you have a doc build problem with your boards doc page

@dleach02 can you clarify?  I don't understand what and how to test.

Thanks @kartben @dleach02.   Changes applied.

@hiagofranco and @holtmann many thanks for your patience and perseverance!

This is excellent.  Thanks to all for the help and patience.  I know our marketing team will be happy to hear this.  Now we  need to consider which other of our modules we should add.


No such file or directory when running read_splits

Hello. Thank you for your contribution.
I'm getting the following error after running the code:
>>> c = Corpus()
>>> train, valid, test = c.read_splits()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  ...
  File "/envs/torch/lib/python3.10/site-packages/pandas/io/common.py", line 856, in get_handle
    handle = open(
FileNotFoundError: [Errno 2] No such file or directory: 'splits/train.csv'

Am I right to assume I should just download these files from the essay repository and rename them to train.csv, dev.csv and test.csv here?
Thank you very much.

Hi Lucas.
I just updated the repository.
First of all, you need to build the corpus.
Corpus().build_corpus('extended_essay-br.csv')
This method is responsible to generate the splits.
Then, you can read the splits.
train, valid, test = Corpus().read_splits()
print(test.head())


Clipboard Integration -- Feedback from IT CPH University

Users are having bad experience in copy and paste stuff from their OS to Kali Linux.

[ ] In the haaukis home page we can add some important information of how to deal with the copy and paste scenario.

[ ] We might try to see if there is a better approach of how to copy and paste stuff

Yeah, sure, for quick solution, providing guideline how to deal with those situation could be nice. Basically, we can document them respect to documentation of guacalome regarding to copy/paste functionality.


[6.0] Remove Nexmo routing

After seeing https://github.com/laravel/framework/pull/29679 I noticed this was left over from when we removed the Nexmo notification channel from the core. After this change people will need to implement the routeNotificationForNexmo method themselves as they do for the Slack driver.
This is a breaking change for anyone using the Nexmo channel so this should be in the upgrade guide.
Updated the docs to highlight this new requirement as well: https://github.com/laravel/docs/pull/5387

Build is passing btw but Github had an outage so they didn't update the status.


JFoenix is too cool

this issue is of high importance and must be solved immediately.
ways of handling this:

convert code to haskell(immediate drop in stars)
close all issues and make repo private
allow issues like this to stay

Hello,
Feel free to add your own contribution to JFoenix :)
Regards,


Release Google.Cloud.Dataform.V1Beta1 version 1.0.0-beta03

Changes in this release:
Bug fixes

Rearrange several messages, thus changing field types (commit 9d2b3d8)

New features

Support for ReleaseConfigs (commit 9d2b3d8)
Support for WorkflowConfigs (commit 9d2b3d8)
Support new first-party repository methods for committing, listing/reading files, and fetching history (commit 9d2b3d8)
Support new ComputeRepositoryAccessTokenStatus repository method (commit 9d2b3d8)
Support SSH based git authentication configuration (commit 9d2b3d8)
Support workspace compilation override fields (commit 9d2b3d8)
Support NPMRC environment variables (commit 9d2b3d8)
Support labels on repositories (commit 9d2b3d8)
Support custom service account repository configuration (commit 9d2b3d8)

Documentation improvements

Several comments reformatted (commit 9d2b3d8)

Created release for Google.Cloud.Dataform.V1Beta1-1.0.0-beta03


[#552][DotNet] Adapt Test Scenarios pipeline to support the new CosmosDB Azure tests

Fixes # 552

Note: New optional SharedResourceGroup variable added to support the addition of the CosmosDb tests to use the resource. Default value is BFFN-Shared.

Description
This PR refactors the Test Scenarios pipeline internals to support the new Integration as well as the existing Functional tests.
The pipeline will be separated in two streams, Functional and Integration, each one will build its own project, configure and run their respective tests against the built project (.dll file).
Detailed Changes

Added common/getCosmosDbConnectionVariables.yml to gather the connection strings from the CosmosDb resource.
Added build.yml to build the desired DotNet project and publish it to Artifacts so other stages can consume it.
Added test.yml to gather the built .dll files from Artifacts, execute the tests and publish the generated .trx file, so it is available in the pipeline's Tests section.
Added the ability to choose the desired BotBuilder version and registry like in the Deploy pipeline to use it in the Integrations project.
Added functional.yml that will include all the configuration to build, configure and test the Functional project.
Added integration.yml that will include all the configuration to build and test the Integration project.
Moved and updated tagBotBuilderVersion.yml and evaluateDependenciesVariables.yml files to the common folder, updating all the references.
Updated runTestScenarios.yml by referencing the new functional.yml and integration.yml files.
Updated Test Scenarios pipeline documentation, adding the new variables and functionality.
Updated configureConsumers.yml to be supported by the new structure, replacing the Scenarios filter to use the bot names instead, and to expose securely the generated appSettings.json file with all the DirectLine secrets, so the test stage can use it.
Removed all Trait("TestCategory") used from the previous structure.
Removed the Publish Variables stage from the Deploy pipeline, since it's no longer required.
Removed runScenario.yml file that has been replaced by the new .yml files.

Testing
The following images show the Test Scenarios pipeline new look, how the Artifacts are published and the passing tests.

Promoted https://github.com/microsoft/BotFramework-FunctionalTests/pull/564


Build rotorS mavlink interface with PX4 mavlink

Describe problem solved by this pull request
Running PX4 and rotors_simulator with SITL/HITL has been painful due to the convoluted mavlink depdendency.
The problem can be described as the following.

PX4 has a mavlink c_library_v2 submodule that is generated by upstream mavlink. This is continuously updated with the PX4 Autopilot Firmware
When running in ROS, mavros / rotorS use a different mavlink which is distributed by the mavros maintainers called mavlink_gbp_release. The problem is that mavlink_gbp_release is only released every month(specifically, when the month and date numbers match - e.g. 4th of April) and mavros only updates whenever there is a new update on mavlink. Therefore, this mavlink for mavros is ALWAYS OUTDATED.
Since mavros does not have a HIL interface, a mavlink update on the firmware side will breaks on the HIL side. Since rotorS is assuming the correct mavlink version is what mavros is using, this failure occurs silently. When we realize that there is a breakage on HIL, it is very hard to backtrack when it has been broken since it is probably a few months prior. (couple hundred to thousand commits behind in PX4).

The result is a huge :exploding_head:
Describe your solution
This PR adds the rotors_simulator as a submodule of PX4, and build rotorS as part of the PX4 SITL toolchain.

This allows us to use the mavlink inside PX4 when building the rotorS mavlink_interface so that we can verify rotorS builds with the mavlink inside PX4 (up-to-date mavlink).
We still can't deal with the fact that mavros is using an outdated mavlink version, but we can at least detect it whenever it happens on the firmware side, and deal with it :smiley:
Test data / coverage
You can test the build with the following command
DONT_RUN=1 make px4_sitl rotors

Additional context

This PR depends on a change on the rotorS side: https://github.com/ethz-asl/rotors_simulator/pull/665
@david-rohr Since you are working with SITL on rotorS, I think we can try to unify our efforts here so we can make sure SITL always works with our flavour of PX4

Since there were no objections, merging


Consider to use testcontainer for collector test cases

We don't improve our collector test cases for a long time, most reasons are about env dependencies. And I found testcontainers-java by following @bsideup .
It looks like interesting to me, several simple lines of code, you could start up a container in Java test cases.
I think we could try to use this, at least in our ElasticSearch or H2 storage implementor. At least, write some POC codes first.
FYI @hanahmily @ascrutae @peng-yongsheng Let's find out would this be helpful?

Thanks @bsideup to write this interesting project.

Here is a list of similar uses:

https://github.com/bsideup/javaagent-boilerplate/tree/master/src/test/java
this is more or less how we were doing it in ZeroTurnaround
https://bsideup.gitbooks.io/spring-io-testcontainers-workshop/content/
this workshop has details about different scenarios of usage: JDBC containers, Singleton-like containers (where you want to share a single container between all tests) and JUnit rules (e.g. container per test)

@wu-sheng thanks for your warm words, but I must point out that the project was created and being leaded by @rnorth, he wrote it! 💪

Sorry. Thank both @rnorth and @bsideup

e2e and CI with IT tests have been set up by @kezhenxu94. No need to keep this open.
We keep working on e2e and IT tests.


Is there no way to get the pre-MTP dotnet test back with .NET SDK 8.0.404?

I'm trying to reproduce a problem with xUnit.net v3 for someone who is using dotnet test, but since installing .NET SDK 8.0.404 (dotnet test --version reporting <IP_ADDRESS>202) it appears that there's no way to disable its recognition and usage of Microsoft.Testing.Platform-compatible test projects, so I'm unable to run tests the same way as users do (that is, through xunit.runner.visualstudio and the TPv2 APIs).
Another way to say this is: <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> is no longer required, and in fact, trying to set the value to false does not turn off MTP support.
Is there any way for me to get the old behavior back, short of creating a VM and installing an older SDK in it?

This is actually about more than just me reproducing this one bug, though. Users will see dotnet test --help and virtually everything on that screen will be wrong because those command line options do not apply when running a Microsoft.Testing.Platform project. How is the user to know this will be the case? How can they get an accurate set of command line options for dotnet test now?

If it's useful information, we're currently linked against the 1.4.3 versions of the Microsoft Testing Platform libraries.

Okay, I'm even more confused now.
I tried installing 8.0.403 alongside 8.0.404 on Windows and I still see broken behavior even when sticking to 8.0.403:

However, on 8.0.403 on Ubuntu 24.04 (without 8.0.404) everything is working as expected:

It's not at all clear to me what's going on here.

Upgrading the Ubuntu box from 8.0.403 to 8.0.404 does not break dotnet test as I'd expected it to, so now I feel like my Windows machine is in a weird state with MTP always forced on. Is that possible?

Apparently there is something amiss in my stock test project that I use for reproducing issues. 🤦🏼
Starting over with dotnet new xunit3 and everything is working as expected, on 8.0.404 and 9.0.101:

I would still love to know how my project got into this "MTP is always enabled" mode. I can package it up if you want to try to figure it out, because I'm at a bit of a loss.

Repro project: vstest-10605-repro.zip
I was running dotnet test from the cs folder.

In the repro, you have <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> in cs.csproj. Is that intended?

I didn't know I'd put that there, and didn't even think to look there because I have everything like that stuffed into empty.proj. That's beyond embarrassing. 😂


Builds failing to upload

Seems to be related to https://github.com/actions/runner/issues/2033

closing in favour of #19


Improve manual rotation reliability

Manually requesting a device orientation change using MOD+r often fails.
Introducing a small delay dramatically improves reliability.

I cannot reproduce reliably. Currently, without that change, it always works… :confused:


MongoDB not working search for an object by its ObjectId

Here is the Deno discord threat of the problem:
https://discord.com/channels/684898665143206084/1054548873844105326
Here is the Stackoverflow description of the problem:
https://stackoverflow.com/q/74857334/8272938

I don;t see any problem here.
ObjectId is not an string. string is not an ObjectId
They are two different data types in bson and MongoDB. if some tools like mongoose let you to use an string instead of objectId, it's not the official driver feature


exception in GET - python branch

Hi,
I completed till module 5 of the workshop but my website doesn't stay good for longtime.
Very few seconds I see all of the mysfits from the dynamoDB table where I can even select and mark as favourite but most of the time the "View All Mysfits" call results in failure..line no: 547 in index.html..
...This is my fist project on AWS and even building a web app for first time....if anyone can suggest a way to fix this, that would be great help
I have pasted the log below.

Running on http://<IP_ADDRESS>:8080/ (Press CTRL+C to quit)
[2020-02-14 20:35:18,610] ERROR in app: Exception on / [GET]
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1982, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1614, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python2.7/dist-packages/flask_cors/extension.py", line 161, in wrapped_function
return cors_after_request(app.make_response(f(*args, **kwargs)))
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1517, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1612, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1598, in dispatch_request
return self.view_functionsrule.endpoint
File "mythicalMysfitsService.py", line 12, in healthCheckResponse
return jsonify(
{
"message": "Nothing here, used for health check. Try /mysfits instead."
}
)
File "/usr/local/lib/python2.7/dist-packages/flask/json.py", line 251, in jsonify
if current_app.config['JSONIFY_PRETTYPRINT_REGULAR'] and not request.is_xhr:
File "/usr/local/lib/python2.7/dist-packages/werkzeug/local.py", line 347, in getattr
return getattr(self._get_current_object(), name)
AttributeError: 'Request' object has no attribute 'is_xhr'
<IP_ADDRESS> - - [14/Feb/2020 20:35:18] "GET / HTTP/1.1" 500 -
[2020-02-14 20:35:18,640] ERROR in app: Exception on / [GET]
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1982, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1614, in full_dispatch_request

The problem is due to a breaking change in version 1.0 of the Werkzeug library, as described here:
https://stackoverflow.com/questions/60131900/weird-is-xhr-error-when-deploying-flask-app-to-heroku
I was able to work around the issue by adding the following to the requirements.txt file in the project:
werkzeug<1.0

The problem is due to a breaking change in version 1.0 of the Werkzeug library, as described here:
https://stackoverflow.com/questions/60131900/weird-is-xhr-error-when-deploying-flask-app-to-heroku
I was able to work around the issue by adding the following to the requirements.txt file in the project:
werkzeug<1.0

Than you, i had same issue now its working.


Adjust Email Formatting bug

When a user hits "send email" to open their email client, the formatting in the email doesn't have the right spacing (see screenshot)

Note, that when a user hits "copy email body" in the "create testimony" process, the formatting looks good. It's only an issue when the email loads via the "send email" button. See the difference between the two testimonies in the screenshot below

One of our users suggested the following slightly modified format for email drafts,

I [SUPPORT/OPPOSE] [BILL #], [BILL TITLE]
Chair [XYZ], and Members of the Joint Committee on [XYZ]:
[MY TESTIMONY]
Thank you for considering my testimony, submitted using MAPLE [Testimony URL].
[TESTIMONY AUTHOR NAME]

more info in #1403


[EventSourcing] Quality of life updates

Codecov Report
Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (7382e12) 65.86% compared to head (4fce060) 65.80%.

Additional details and impacted files
@@             Coverage Diff              @@
##               main     #108      +/-   ##
============================================
- Coverage     65.86%   65.80%   -0.06%
- Complexity      875      876       +1
============================================
  Files           142      142
  Lines          2285     2287       +2
============================================
  Hits           1505     1505
- Misses          780      782       +2

Files
Coverage Δ

...nent/EventSourcing/Aggregate/AbstractAggregate.php
72.09% <0.00%> (-3.52%)
:arrow_down:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


s4 fails to load libsystemd.so on Ubuntu 20

s4 fails to load libsystemd on Ubuntu 20
Reproduce
Here is the debug build output from commit eea1c02e8ccbe4b1204c6b6b4312ebe871642c05
$ ./target/debug/s4 /var/log/journal/a2d126cf2e9d4bdf91e336ee1cb904f8/user-1000.journal
    →main:
                                                                        →datetime_parse_from_str: (pattern "%Y-%m-%d %H:%M:%S %:z", has_tz true, tz_offset -02:46:39, data "2000-01-02 03:04:05 -07:00")
                                                                         datetime_parse_from_str: DateTime::parse_from_str("2000-01-02 03:04:05 -07:00", "%Y-%m-%d %H:%M:%S %:z") extrapolated DateTime 2000-01-02T03:04:05-07:00
                                                                        ←datetime_parse_from_str: return Some(2000-01-02T03:04:05-07:00)
                                                                 cli_process_tz_offset: datetime_parse_from_str_w_tz("2000-01-02 03:04:05 -07:00", "%Y-%m-%d %H:%M:%S %:z") returned Some(2000-01-02T03:04:05-07:00)
                                                                ←cli_process_tz_offset: return -07:00
                                                                            →datetime_parse_from_str: (pattern "%Y-%m-%d %H:%M:%S %:z", has_tz true, tz_offset -02:46:39, data "2000-01-02 03:04:05 -07:00")
                                                                             datetime_parse_from_str: DateTime::parse_from_str("2000-01-02 03:04:05 -07:00", "%Y-%m-%d %H:%M:%S %:z") extrapolated DateTime 2000-01-02T03:04:05-07:00
                                                                            ←datetime_parse_from_str: return Some(2000-01-02T03:04:05-07:00)
                                                                     cli_process_tz_offset: datetime_parse_from_str_w_tz("2000-01-02 03:04:05 -07:00", "%Y-%m-%d %H:%M:%S %:z") returned Some(2000-01-02T03:04:05-07:00)
                                                                    ←cli_process_tz_offset: return -07:00
         cli_process_args: args CLI_Args { paths: ["/var/log/journal/a2d126cf2e9d4bdf91e336ee1cb904f8/user-1000.journal"], dt_after: None, dt_before: None, tz_offset: -07:00, prepend_tz: None, prepend_utc: false, prepend_local: false, prepend_dt_format: None, prepend_filename: false, prepend_filepath: false, prepend_file_align: false, prepend_separator: ":", log_message_separator: "", journal_output: Short, color_choice: auto, blocksz: "65535", summary: false }
         cli_process_args: blocksz 65535
         cli_process_args: tz_offset -07:00
            →string_wdhms_to_duration: ("")
            ←string_wdhms_to_duration: REGEX_DUR_OFFSET.captures(…) None
            →string_wdhms_to_duration: ("")
            ←string_wdhms_to_duration: REGEX_DUR_OFFSET.captures(…) None
         cli_process_args: filter_dt_after None
         cli_process_args: filter_dt_before None
         cli_process_args: color_choice Auto
         cli_process_args: args.prepend_dt_format None
         cli_process_args: args.prepend_tz None
         cli_process_args: prepend_dt_format None
         cli_process_args: prepend_utc false
         cli_process_args: prepend_local false
         cli_process_args: cli_opt_prepend_offset -07:00
         cli_process_args: prepend_filename false
         cli_process_args: prepend_filepath false
         cli_process_args: prepend_file_align false
         cli_process_args: prepend_separator ":"
         cli_process_args: log_message_separator ""
         cli_process_args: journal_output Short
         cli_process_args: summary false
     main: path "/var/log/journal/a2d126cf2e9d4bdf91e336ee1cb904f8/user-1000.journal"
        →process_path: ("/var/log/journal/a2d126cf2e9d4bdf91e336ee1cb904f8/user-1000.journal")
            →path_to_filetype_mimeguess: ("/var/log/journal/a2d126cf2e9d4bdf91e336ee1cb904f8/user-1000.journal")
             mimeguess MimeGuess([])
             path_to_filetype_mimeguess: no mimeguess found, try again with removed file extension "/var/log/journal/a2d126cf2e9d4bdf91e336ee1cb904f8/user-1000"
             path_to_filetype_mimeguess: mimeguess MimeGuess([])
                →mimeguess_to_filetype: mimeguess_to_filetype(MimeGuess([]))
                ←mimeguess_to_filetype: mimeguess_to_filetype: return Unknown
             path_to_filetype_mimeguess: filetype 'Unknown' is not parseable
                →path_to_filetype: ("/var/log/journal/a2d126cf2e9d4bdf91e336ee1cb904f8/user-1000.journal")
                 file_name "user-1000.journal"
                 file_name_s "user-1000.journal"
                 file_prefix "user-1000"
                 file_suffix "journal"
                ←path_to_filetype: return Journal; JOURNAL_FILENAMES_EXT.contains("journal")
             path_to_filetype_mimeguess: filetype Journal
                ↔processable_filetype: (Journal)
            ←path_to_filetype_mimeguess: return (Journal, MimeGuess([]))
        ←process_path: ("/var/log/journal/a2d126cf2e9d4bdf91e336ee1cb904f8/user-1000.journal") [FileValid("/var/log/journal/a2d126cf2e9d4bdf91e336ee1cb904f8/user-1000.journal", MimeGuess([]), Journal)]
        →processing_loop: ([FileValid("/var/log/journal/a2d126cf2e9d4bdf91e336ee1cb904f8/user-1000.journal", MimeGuess([]), Journal)], 65535, None, None, Auto, -07:00, None, Short, false)
         processing_loop: match FileValid("/var/log/journal/a2d126cf2e9d4bdf91e336ee1cb904f8/user-1000.journal", MimeGuess([]), Journal)
         processing_loop: load_library_systemd()
            →load_library_systemd:
             load_library_systemd: Container::load("libsystemd.so")
             load_library_systemd: failed to load library: Could not obtain symbol from the library: /lib/x86_64-linux-gnu/libsystemd.so: undefined symbol: sd_journal_enumerate_available_data
             load_library_systemd: Container::load("libsystemd.so.0")
             load_library_systemd: failed to load library: Could not obtain symbol from the library: /lib/x86_64-linux-gnu/libsystemd.so.0: undefined symbol: sd_journal_enumerate_available_data
             load_library_systemd: Container::load("libsystemd.so.0.28.0")
             load_library_systemd: failed to load library: Could not obtain symbol from the library: /lib/x86_64-linux-gnu/libsystemd.so.0.28.0: undefined symbol: sd_journal_enumerate_available_data
             load_library_systemd: Container::load("libsystemd.so.0.32.0")
             load_library_systemd: failed to load library: Could not open library: libsystemd.so.0.32.0: cannot open shared object file: No such file or directory
             load_library_systemd: Container::load("libsystemd.so.0.36.0")
             load_library_systemd: failed to load library: Could not open library: libsystemd.so.0.36.0: cannot open shared object file: No such file or directory
             load_library_systemd: Container::load("/usr/lib64/libsystemd-journal.so")
             load_library_systemd: failed to load library: Could not open library: /usr/lib64/libsystemd-journal.so: cannot open shared object file: No such file or directory
             load_library_systemd: Container::load("/usr/lib64/libsystemd-journal.so.0")
             load_library_systemd: failed to load library: Could not open library: /usr/lib64/libsystemd-journal.so.0: cannot open shared object file: No such file or directory
            ←load_library_systemd: return Err(OpeningLibraryError(Custom { kind: Other, error: "/usr/lib64/libsystemd-journal.so.0: cannot open shared object file: No such file or directory" }))
ERROR: load_library_systemd() failed, library "libsystemd.so"; Could not open library: /usr/lib64/libsystemd-journal.so.0: cannot open shared object file: No such file or directory
         processing_loop: paths_invalid_results.push(FileErrLoadingLibrary) (LoadLibraryError::Err)
thread 'main' panicked at 'assertion failed: !map_pathid_received_fileinfo.is_empty()', src/bin/bin.rs:3031:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

API sd_journal_enumerate_available_data and libsystemd0 version
The culprit error is
failed to load library: Could not obtain symbol from the library: /lib/x86_64-linux-gnu/libsystemd.so: undefined symbol: sd_journal_enumerate_available_data
The version of libsystemd on Ubuntu 20 is 245.
$ ldconfig -v | grep libsystemd
        libsystemd.so.0 -> libsystemd.so.0.28.0

$ apt-file search /lib/x86_64-linux-gnu/libsystemd.so.0.28.0
libsystemd0: /lib/x86_64-linux-gnu/libsystemd.so.0.28.0

$ apt info libsystemd0
Package: libsystemd0
Version: 245.4-4ubuntu3.21
Priority: required
Section: libs
Source: systemd
Origin: Ubuntu
Maintainer: Ubuntu Developers<EMAIL_ADDRESS>Original-Maintainer: Debian systemd Maintainers<EMAIL_ADDRESS>Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 899 kB
Pre-Depends: libc6 (>= 2.30), libgcrypt20 (>= 1.8.0), liblz4-1 (>= 0.0~r122), liblzma5 (>= 5.1.1alpha+20120614)
Homepage: https://www.freedesktop.org/wiki/Software/systemd
Task: minimal
Download-Size: 268 kB
APT-Manual-Installed: no
APT-Sources: http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
Description: systemd utility library
 The libsystemd0 library provides interfaces to various systemd components.

From systemd NEWS file

CHANGES WITH 246:
    * The sd-journal.h API gained two new functions:
     sd_journal_enumerate_available_unique() and
     sd_journal_enumerate_available_data() that operate like their
     counterparts that lack the _available_ in the name, but skip items
     that cannot be read and processed by the local implementation
     (i.e. are compressed in an unsupported format or such),

    – Warsaw, 2020-07-30

So API sd_journal_enumerate_available_data was introduced in release 246.
Environment:

OS: Ubuntu 20
s4 version: eea1c02e8ccbe4b1204c6b6b4312ebe871642c05 (after release 0.6.64)

Closing.
Fixing this would require using an alternative API to sd_journal_enumerate_available_data. That would make the output modes verbose and export much more difficult to implement.


Remove reliance on jQuery

So it looks like people are viewing our reference docs on mobile devices! :grinning:  For our mobile device readers, I think we should make the mobile viewing experience as useful as possible.
I'm currently in the process of redoing the stylesheets (as part of https://github.com/thymeleaf/thymeleaf.github.com/issues/16) for articles/tutorials for a mobile-first focus.  The next thing that I think should happen is that we remove our reliance on jQuery: a massive 94KB download which is also heavy for a mobile browser engine to parse.
The only thing we use it for is to select items from the page, so I can alias $ to document.querySelector/All and get much the same benefit without the overhead of jQuery.

Bower isn't a part of the build process, so I should probably just include the code of https://github.com/ultraq/dumb-query-selector in the script.


Code refactoring - Remove unused codes

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 52
- Added 20

Complexity increasing per file
==============================
- platform-modules/batch-models/src/test/scala/org/ekstep/analytics/model/SparkFlatSpec.scala  4

Complexity decreasing per file
==============================
+ platform-modules/batch-models/src/main/scala/org/ekstep/analytics/job/JobFactory.scala  -85

See the complete overview on Codacy


Global style removed if another style is applied

I tried using this to change the font globally in my project which is built using typescript,
However it seems like my text aren't inheriting the fontFamily that i specified
so in my App.tsx I initialized with loading the text and used the text inside setCustomText.
useEffect(() => {
    Font.loadAsync({
      Montserrat: require("./assets/font/Montserrat-Medium.otf")
    });
    setCustomText(styles.text);
  }, []);

const styles = StyleSheet.create({
  text: {
    fontFamily: "Montserrat"
  }
});

am I doing it wrong?
Can someone advise on how I can tackle this issue?

It seems like it wasnt an issue from this library.
The replaced fonts are the fonts that is bold and react native cant just increase the weight of the fontFamily.
I needed to manually set another font for bold.
Closing this issue


feat(pnpm): nodePackages.pnpm: 7.29.1 -> 8.1.1

Temporary until https://github.com/NixOS/nixpkgs/pull/224851 or a PR with equivalent intention is merged

This was an accidental PR intended for a fork. Apologies!


fix(e2e): ensure we check if there are deployments incase pods are no…

/test openshift

/test openshift

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
ffa211dbcad26fe5175d74b6171a73c1334f0ffb
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
ffa211dbcad26fe5175d74b6171a73c1334f0ffb
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test openshift

/test openshift

/test openshift

/test openshift

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
56a31e74b3274e5de5ec966a0708d2a8e70a1b0c
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
56a31e74b3274e5de5ec966a0708d2a8e70a1b0c
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test openshift

/test openshift

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
03d5b115789b90eabe0532f9dc2c3af94f3f6782
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
03d5b115789b90eabe0532f9dc2c3af94f3f6782
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

/retest

/test openshift

/test openshift

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
4cddb5c00097777805d110ff35d4cb6078404c4a
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
4cddb5c00097777805d110ff35d4cb6078404c4a
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test openshift

/test openshift

/test openshift

/test openshift

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
24145ec66096c785bccc2917ca1893cca1c035d2
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
24145ec66096c785bccc2917ca1893cca1c035d2
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test openshift

/test openshift

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
2dfc972168a9d9d5f39cdbcd3601bbcb307060ac
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
2dfc972168a9d9d5f39cdbcd3601bbcb307060ac
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test openshift

/test openshift

/test openshift

/test openshift

/test openshift

/test openshift

/test openshift

/test openshift

/retest

/retest

/test openshift

/test openshift

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
dc1a71cede20c58ec3efac169ccc0bd6cf4c7bd4
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aslakknutsen: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

e2e-tests-openshift
dc1a71cede20c58ec3efac169ccc0bd6cf4c7bd4
link
/test openshift

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test openshift

/test openshift


silent grep stderr. closes #862

Heh, troll.

:smile: opening a PR is just a habit

Oh thats fine, I meant the fix.
Note: I'd like to continue working through PRs. Helps everyone get familiar with whats going on/raise objections before it goes into master. Plus, it makes doing releases easier; I only need to look at the "merge pull request" commits to see what should go in the changelog :)

That was option 1 :smile:


read config drive secret from provider spec

A "config drive" Secret will be present in the cluster, and it will contain data that the BareMetalHost needs in order to configure a provisioned host. We will assume that something will write the name and namespace of the secret into each Machine's provider spec.
This task is to define those fields in the provider spec and ensure the actuator writes the values to corresponding fields on the BareMetalHost.
As an example, currently in openshift the secret that contains worker config data is showing up with this identity:
  name: worker-user-data
  namespace: openshift-machine-api

https://github.com/metalkube/metalkube-docs/blob/master/design/worker-config-drive.md has some additional details


CES-898: Created an API to get message by id along with the disclaimer text

Description

Jira Ticket

Implementation

We have created an API to get the message using the message id
Added Unit Test for the same API
Added sharedMessage, disclaimer & sid fields to the InboundMessage following V4Message structure on the agent

@symphony-thibault You are welcome!
I will create a PR against the release branch also.
Thank you for the quick response. 👍


Upgrade Docusaurus to latest version

Is this a BUG REPORT or FEATURE REQUEST?
FEATURE REQUEST
The latest version of Docusaurus is 1.13.0, but what we use for Litmus-docs is 1.0.12 which is far behind the latest one.
The latest version has got better features and it will resolve all the issue with the responsiveness of the docs website.

Also, it is better to remove node_modules from repo and commit only one of package-lock.json or yarn.lock


build error: Resource entry js_arcardemo_res_tesla_object_car is already defined.

Hi, I just cloned Viro and I have build problem with this current git version:

Hey @EVALIJANI,
This is an issue with React Native and Android, the way React Native bundles assets in Android release builds is that they copy the assets to the Android Resources directory. The issue with that is that the Android Resources directory doesn't preserve file extensions, so if you look at the two files you have tesla_object_car.obj and tesla_object_car.mtl, you'll notice that if you drop the file extension, they'll have the exact same Resource identifier. What you can do is simply rename tesla_object_car.obj to tesla_object_car_obj.obj and use that. Also, you'll want to do a ./gradlew clean because the first .obj file will have already be copied to the build directories.
Let us know if you have any other questions.

Closing this, since it's not a bug on the platform. @EVALIJANI let us know if you have more questions.


Add PyTorch backend.

Once https://github.com/google/TensorNetwork/pull/52 is submitted, it would be nice to add a pytorch backend.
TF eager and pytorch are very similar, so someone could use the TensorFlowBackend as an example.

Hi,
would be happy to take it up, as you said, should be quite similar to the tf-backend. Quite a busy July though, so might only finish it in Aug. Is this very urgent?

Not urgent at all! And we would love to have you as a contributor.
It should be fairly straightforward with the exception of some weird shape only functions, specifically prod and concat. I'll be sure document it better before you get started in August.
If you get stuck or need any help, feel free to email me<EMAIL_ADDRESS>

Just remembered PyTorch still does not have full support for complex numbers. Do we expect this to be blocking in the future?

There are still use cases for exclusively real valued tensors, especially in ML. I'd say it's still worth it.

We'd have to explicitly exclude some tests, but I don't think we have that many.

I added a first try / progress in PR #165 , if you have time, feel free to give comments.

We'll push 0.0.6 tonight with your Pytorch backend!

0.0.6 is live! Just do pip upgrade tensornetwork and you should be good to go


Added Georgian Talks

I added valuable georgian(Georgia - Country) talks. They're in georgian language,of course,but I think that repository is worthy to be in awesome lists.

I think this is better suited for something like https://github.com/sindresorhus/awesome/issues/153. Comment your list there and we'll make sure to include it when we do the local thing.

Okay,Thanks.


Using images with continues representation

Hey,
In the self_sup_tasks file in the patch_ex function it says the images should be of type uint8. Do you have an idea of how to change it to support images in the range of [0,1]?
The reason I am asking is that I have images with a higher dynamic range and the discretization to [0,255] hurts the contents of the images. Instead I would like to use a continues representation if possible.
Thanks,
Eliahu

Hi Eliahu,
Since the data I worked with was mostly 0-255 RGB values, I used methods from OpenCV in several places in self_sup_tasks, e.g. for seamless cloning (i.e. Poisson blending). As far as I know, OpenCV usually represents each color channel by 8 bits (i.e. 0-255) so you won't be able to pass inputs with a higher dynamic range to those methods.
To avoid having to discretize your data to 0-255, you could replace all the cv2 calls with other imaging libraries or your own implementation. I think there are several open-source implementations of Poisson blending out there that you could substitute. But note that these will probably be slower than when using just 8-bits.
After the synthetic anomalies are generated, the rest of the training pipeline works with float32 data, so representing a higher dynamic range there should not be a problem.