Remove clock option

Followup to https://github.com/davidkpiano/xstate/pull/1030#discussion_r384432402

We use clock heavily in our automated tests to avoid having to wait for delay transitions, is there a plan for its replacement?
I read the linked comment, it's a bit sparse on details.

@tivac could u use global fake timers such as https://jestjs.io/docs/en/timer-mocks.html ?

Not easily, we have other code using timers and being able to do a targeted override for just the statechart is really valuable.
We're also running our statechart code in puppeteer and using jest-puppeteer to connect to it, so that adds another fun layer of complicated.

Not easily, we have other code using timers and being able to do a targeted override for just the statechart is really valuable.

I would consider this an anti-pattern - IMHO you should only speed up execution for testing purposes, but you shouldnt do it selectively because you expose yourself to various scheduling bugs (your test environment differs quite significantly from the production one).

We're also running our statechart code in puppeteer and using jest-puppeteer to connect to it, so that adds another fun layer of complicated.

This shouldnt be a vastly different situation - you can, for example, use https://sinonjs.org/releases/v1.17.6/fake-timers/ .

Let's hold off on this - I want to introduce a clock as a default service so that switching out clocks can be done in the same way, rather than baked into the interpreter.
So it will be removed, but I'd like to replace it as well. If it's okay @Andarist, I'll continue on this branch to add the clock service.

I was just about to submit a PR with adding clock to the interpreter options in the docs when I found this issue... I got worried for a second, but adding a replaceable clock as a default service instead seems like a reasonable change.
For another use case to keep in mind, scheduling in media players and web audio apps often heavily relies on using service workers to prevent timer throttling in unfocused tabs. Quoting https://github.com/chrisguttandin/worker-timers:

For scripts that rely on WindowTimers like setInterval() or setTimeout() things get confusing when the site which the script is running on loses focus. Chrome, Firefox and maybe others throttle the frequency of firing those timers to a maximum of once per second in such a situation. However this is only true for the main thread and does not affect the behavior of Web Workers. Therefore it is possible to avoid the throttling by using a worker to do the actual scheduling. This is exactly what WorkerTimers do.

We've agreed with @davidkpiano that this can land as is (it's targeting the next branch that is not yet being published anywhere), but most likely we are going to think about some replacement for this.
The worker timers issue is a compelling argument - I also had to deal with this in the past. That being said it's a rare-ish use case and can be handled by creating a dedicated "worker timer" actor. That would force you to ditch using delay property on send objects though (which is convenient).
There are many tradeoffs here and things to consider, we'll try to deliver the best solution we can think of. We believe that you shouldn't use the custom "clock" (however the API would look like) for testing purposes - global fake timers are way better suited for that and should be preferred. We are also going to document using fake timers as the preferred solution for testing time-dependent machines.

That being said it's a rare-ish use case and can be handled by creating a dedicated "worker timer" actor. That would force you to ditch using delay property on send objects though (which is convenient).

Not just that, I use dynamic delays for state transitions that depend on rapidly changing context values (playback speed) to control the frequency of certain checks in my player. I assume having to deal with a separate actor that now also needs each of those updates would make the whole hierarchy a lot more cumbersome and "chatty" 😞

@haywirez Thanks for the concern, we're still debating the right direction to take this.
Currently, time is an event, so the way these delayed transitions/events are triggered will remain exactly the same.
The only difference (tentative) is that the clock won't be baked into the interpreter. Neither your code nor the "chattiness" of your services will change. It's an implementation detail of XState.

What is the impetus for removing it? It doesn't seem like a lot of code in xstate but it dramatically increases the end-user burden if they want to manipulate timers. Is there something I'm not aware of that makes it particularly burdensome to support?
Using something like @sinonjs/fake-timers means your tests now need to be responsible for every single timer in your app and ensuring they're firing, or giving up all control and letting time move forward on specific intervals. This is all a massive change from how our tests worked previously where we only needed to care about managing timers for the statechart (since it drives our overall app state other timers are less important when we're doing integration tests).
I strongly disagree with @Andarist's assertions around our current usage being an anti-pattern and am dreading updating our hundreds of tests one by one to account for this change.

Revert PR: https://github.com/davidkpiano/xstate/pull/1046


Improve documentation

I would suggest to organize the documentation differently.
Having everything in this one super massive readme can be really daunting for people not accustomed to straight.el
Then the package appears as being very complex when in reality, much of what's the readme, is not documentation per say. (comparisons with other package manager for example)
I've thought of this when I saw Denis Ogbe here (https://ogbe.net/emacs/emacs.html), detailing his (very interesting!) configuration for emacs.
I quote:
"There are alternatives to the built-in package.el, for example straight.el. It looks like a great project. But the manual is incredibly long, it seems like an incredibly "different" way to handle packages, and I am frankly intimidated by it's apparent complexity."
Which is a shame, since the guy seem clearly able to handle straight.el.
Maybe organize the documentation with several markdown documents? in a wiki?
Just a suggestion that could avoid turning people off because of the appearance the length of the documentation gives to the project.
Cheers!

Thanks for bringing this to our attention.
I agree we could simplify the README and move some of the other information to a secondary site or document(s). Will discuss with @raxod502

Thanks for bringing this to our attention.
I agree we could simplify the README and move some of the other information to a secondary site or document(s). Will discuss with @raxod502

You aren't the first person to point out this problem. I think you are correct that having multiple sub-pages is better than having one gigantic large page. I think it would be nice to keep the documentation in Markdown format in this repository, although we could certainly make it auto-publish to GitHub Pages for even easier accessibility.

You aren't the first person to point out this problem. I think you are correct that having multiple sub-pages is better than having one gigantic large page. I think it would be nice to keep the documentation in Markdown format in this repository, although we could certainly make it auto-publish to GitHub Pages for even easier accessibility.

I saw a post on reddit regarding this issue, and just wanted to say that the long format of @raxod502's READMEs is one of the reasons why I like to use his packages. Other Emacs packages make me search information all across the web (Github, reddit, EmacsWiki, Blog posts, etc.), but with packages like straight and selectrum I know that all the relevant information is right there in a single file.

https://github.com/raxod502/straight.el/issues/827#issue-953473692
Explicitly mention, provide example usage of :type nil.

I have tried :type nil to get automatic byte-compilation etc. for local mini-packages that I have in my large dotfiles repository. So they are not in their own package repository and I would prefer to leave them in the general dotfiles repository. As a workaround, I have tried the recipe (my-package :local-repo "my-package") which works as far as building is concerned but fails, for example, in the pull and freeze operations. I changed the recipe to (my-package :local-repo "my-package" :type nil) as I have seen recommended by @raxod502 for my use-case but I get No such VC backend ‘nil’. I have tried to look into it and there are not straight-vc-nil-* functions defined, so I don't see how it could work with the definition of straight-vc but I guess it should since this was mentioned in issues multiple times in the past 3 weeks. Can you tell me what my recipe should actually look like?

I follow the recommended by @raxod502 on gist.     gist :type nil.
(straight-use-package `(popup :local-repo ,(concat my-lisp-dir "popup") :type nil))

I still get the error: No such VC backend ‘nil’.

Debugger entered--Lisp error: (error "No such VC backend ‘nil’")
signal(error ("No such VC backend ‘nil’"))
error("No such VC backend `%S'" nil)
straight-vc(keywords nil)
straight-vc-keywords(nil)
straight--register-recipe((:local-repo "~/emacs/lisp/popup" :type nil :files ("popup.el" "popup-pkg.el") :flavor melpa :repo "auto-complete/popup-el" :host github :package "popup"))
straight-use-package((popup :local-repo "~/emacs/lisp/popup" :type nil :files ("popup.el" "popup-pkg.el") :flavor melpa :repo "auto-complete/popup-el" :host github))
(progn (defvar bootstrap-version) (straight-use-package (cons 'popup (cons ':local-repo (cons (concat eow-lisp-dir "popup") '(:type nil :files ("popup.el" "popup-pkg.el") :flavor melpa :repo "auto-complete/popup-el" :host github))))))
elisp--eval-last-sexp(nil)

Maybe  my local package name popup is same as the github's repoauto-complete/popup-el,
'(:type nil :files ("popup.el" "popup-pkg.el") :flavor melpa :repo "auto-complete/popup-el" :host github)) is appended to my recipe specified. Under this case,  how to ignore the remote package's recipe.

I try to fix the recipe via setting straight-recipe-overrides, but the remote recipe still be appended, when runnig straight-use-package

Confirmed with the following:
YODEL REPORT (2021-09-18 17:59:12):
(yodel
  :save t
  :user-dir "local-repo-test.straight"
  :formatter yodel-format-as-github-markdown
  :post*
  (yodel-file "./local-repo/local-repo.el"
    :save t
    :overwrite t
    :with*
    ";;;###autoload"
    (defun local-repo-test nil
      (message "PASS"))
    (provide "local-repo"))
  "Straight bootstrap code"
  (defvar bootstrap-version)
  (let
      ((bootstrap-file
        (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
       (bootstrap-version 5))
    (unless
        (file-exists-p bootstrap-file)
      (with-current-buffer
          (url-retrieve-synchronously
           (concat "https://raw.githubusercontent.com/" "raxod502/straight.el/develop/install.el")
           'silent 'inhibit-cookies)
        (goto-char
         (point-max))
        (eval-print-last-sexp)))
    (load bootstrap-file nil 'nomessage))
  (condition-case nil
      (message "Test run with version: %s"
               (straight-version))
    (error nil))
  "End bootstrap"
  (straight-use-package
   '(local-repo-test
     :local-repo "./local-repo"
     :type nil))
  (local-repo-test))

STDOUT:
Test run with version: prerelease (HEAD -> master, origin/master, origin/HEAD) 1e27b05 2021-06-13
Cloning ./local-repo (for local-repo-test)...

STDERR:
(error "No such VC backend ‘nil’")

Environment

emacs version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.4, Xaw3d scroll bars)
of 2021-09-16
system type: gnu/linux

I've never used a recipe in this way. Indeed it does look like specifying :type nil will fail during straight-vc.
It looks like this behavior would require implementing a VC backend called "nil" according to:
19c34fc96b3668d2b1266cf18fb8008903c5c98b
@raxod502: Is this a use case we want to support?

Sorry y'all, I didn't do so good of a job with the :type nil situation. I opened a belated pull request at https://github.com/raxod502/straight.el/pull/885 which should improve the support, though I'm not 100% sure it covers all the cases correctly. At the very least, it should make it clear what we are supposed to be doing, so later bugs can be patched easily.

@meziberry and @martenlienen: Have either of you had a chance to test this out since #855 was merged to the "develop" branch? If so, any issues?

@progfolio On my environment(Win11+Msys2+emacs-master), now it works correctly, when :type is nil.  Thank you for your work.

Also works for me. Thanks a lot!

https://github.com/radian-software/straight.el/issues/1024#issuecomment-1348500546


Fix broken CI/CD pipeline

Fix broken tests:

[x] a recent change used a Java 1.7+ API which results in broken tests when running on Java 1.6 or earlier:

:compileJava/home/runner/work/picocli/picocli/src/main/java/picocli/CommandLine.java:11634:
 <T>emptyEnumeration() is not public in java.util.Collections;
cannot be accessed from outside package

The solution is to use Collections.enumeration(Collections.emptyList()) instead.

[x] Broken tests using System.setSecurityManager on Java 18-ea -> does not manifest on Java GA, separate ticket #1932

[x] ManPageGeneratorTest has 3 failing tests (testEndOfOptionsWithoutOptions -  line 307, testNamelessCommand line 489 and testHiddenOptions line 242), likely related to https://github.com/remkop/picocli/pull/1896

[x] Java 10 on Ubuntu fails the build due to a problem in release-tasks.gradle:

> startup failed:
  script '/home/runner/work/picocli/picocli/gradle/release-tasks.gradle': 1:
  Can't have an abstract method in a non-abstract class.
  The class '_BuildScript_' must be declared abstract or the method
  'void init(java.lang.Object, org.gradle.internal.service.ServiceRegistry)' must be implemented.
   @ line 1, column 1.
     task bumpReadmeVersion {

This may be caused by this change in gradle/wrapper/gradle-wrapper.properties, which bumped Gradle from 7.4 to 7.6...
Temporary fix is to revert to Gradle 7.4.

[x] Flaky tests? Broken tests on Java 10 ubuntu:

picocli.HelpAnsiTest > testUsageMainCommand_ANSI FAILED
    org.junit.ComparisonFailure at HelpAnsiTest.java:442
stty: /dev/tty: No such device or address

picocli.HelpTest > testMapFieldHelp_with_unlimitedSplit FAILED
    org.junit.ComparisonFailure at HelpTest.java:2926

2327 tests completed, 2 failed, 27 skipped

Solution: skip non-LTS versions of Java

@remkop , In regards to the chanes made to ManPageGenerator from PR #1896, I'm currently looking at the three failed tests in ManPageGeneratorTest and I have a few questions/comments for you so that I can update the tests appropriately.
Test testEndOfOptionsWithoutOptions:
This test espects that if a command has no options, then the "options" section in the ascii doc will still get generated. Now that PR #1896 has been merged, do you still want an empty "options" section in the ascii docs to be generated, or would you like for the test to be updated to expect for that section to be missing?
For reference, here's a screenshot showing a diff of the expected ascii doc vs the ascii doc that got generated:

As a heads up, updating the test to simply expect a missing "options" section will be quick and easy as it will only require updating a resource file.
Tests testNamelessCommand and testHiddenOptions:
These tests are failing simply because of an extra white space in various locations or newline that gets added. Not sure if this behavior is acceptable, but I think this is harmeless, so I'll just update the test cases to accept the extra new lines and white spaces. Based on the updates in #1896, it's not immediately obvious to me why this is now happening. Here's a screenshot of the diffs for reference.
Diff from testNamelessCommand failed test outputs. This one is when compairing main_class.adoc:

Diff from testHiddenOptions failed test output:

To try and not hold you up, I've raised PR with updated test that just accept the whatever the newly generated stuff in the ascii docs. Please see PR #1940.

@wtfacoconut Thank you for the PR! Looks good and it is merged. Many thanks!


Feature suggestion: Automatic parameter lookup - allow list for lookups

Suggest adding an optional allowed_keys to the lookup_options parameters - when specified, this would prevent lookups for anything that does not match entries (either strings or regular expressions) in the list.
Automatic parameter lookup will (by default) look up any variables not found in the hierarchy. Even on relatively small sites, this can mean hundreds or thousands of queries against the KeyVault when using this feature.
As an example, instrumenting azure_key_vault::lookup with the following code:
open('/tmp/lookup_trace', 'a') do |f|
      f.puts "get_access_token called for: " + secret_name
    end

Shows that when generating a catalog for a puppet master running Puppet Enterprise v2019.8.5, this results in 776 lookups against Azure KeyVault.
Azure KeyVault service limits allow a maximum of 2,000 lookups every 10 seconds against a key vault: https://docs.microsoft.com/en-us/azure/key-vault/general/service-limits#secrets-managed-storage-account-keys-and-vault-transactions

Old module but example of what we are looking for
https://github.com/Accenture/hiera-aws-sm

https://github.com/petems/petems-hiera_vault

Hi, Do you know when this might be available for use? At the moment my lookups are generating 100's of calls to Keyvault with lookups that I being generated by variables that I am not interested in.

Hi, Do you know when this might be available for use? At the moment my lookups are generating 100's of calls to Keyvault with lookups that are being generated by variables outside hiera that I am not interested in.

Hey @adelany ,
I can take a stab at this next weekend and let you know how it goes.

Hey @adelany ,
Please give v2.0.0 a try with the new confine_to_keys hiera configuration option.  Let me know if you have any issues or questions.
Thanks!

Hi,
I am getting the following error (not sure I am doing something wrong or it's my setup)
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Function Call, 'azure_key_vault::lookup' expects (Variant[String, Numeric] secret_name, Struct[{'vault_name' => String, 'vault_api_version' => String, 'metadata_api_version' => String, 'confine_to_keys' => Array[Regexp], Optional['key_replacement_token'] => String}] options, Object[{name => 'Puppet::LookupContext', parent => Any, attributes => {'environment_name' => {type => String[1], kind => derived}, 'module_name' => Variant[String[1], Undef]}, functions => {'not_found' => Callable[[0, 0], Undef], 'explain' => Callable[[0, 0, Callable[0, 0]], Undef], 'interpolate' => Callable[1, 1], 'cache' => Callable[Optional[Scalar], Any], 'cache_all' => Callable[[Hash[Optional[Scalar], Any]], Undef], 'cache_has_key' => Callable[[Optional[Scalar]], Boolean], 'cached_value' => Callable[Optional[Scalar]], 'cached_entries' => Variant[Callable[[0, 0, Callable[1, 1]], Undef], Callable[[0, 0, Callable[2, 2]], Undef], Callable[[0, 0], Iterable[Tuple[Optional[Scalar], Any]]]], 'cached_file_data' => Callable[String, Optional[Callable[Array[Integer]]]]}}] context)
rejected: parameter 'options' entry 'confine_to_keys' index 0 expects a Regexp value, got String
rejected: parameter 'options' entry 'confine_to_keys' index 1 expects a Regexp value, got String
rejected: parameter 'options' entry 'confine_to_keys' index 2 expects a Regexp value, got String
rejected: parameter 'options' entry 'confine_to_keys' index 3 expects a Regexp value, got String
rejected: parameter 'options' entry 'confine_to_keys' index 4 expects a Regexp value, got String (file: /etc/puppetlabs/code/environments/its_azplatform_rt_dev/manifests/site.pp, line: 3, column: 1) on
Line in site.pp is
lookup('classes', {merge => unique}).include
hiera.yaml : -

version: 5
defaults:
datadir: data
data_hash: yaml_data
hierarchy:

name: 'Application Key Vault Secrets'
lookup_key: azure_key_vault::lookup
options:
vault_name: 'devartifactorykvne'
#vault_name: "%{facts.az_metadata.compute.tags.environment}%{facts.az_metadata.compute.tags.application}kvne"
vault_api_version: '2016-10-01'
metadata_api_version: '2018-04-02'
key_replacement_token: '-'
confine_to_keys:
- '^hiscox.'
- '^profile.'
- '^azure_.'
- '^._password$'
- '^password.*'
name: "Per-node data (eyaml version)"
globs:

"per_region/%{facts.az_metadata.compute.location}/%{facts.az_metadata.compute.tags.environment}/%{facts.az_metadata.compute.tags.application}/*.yaml"
"per_region/%{facts.az_metadata.compute.location}/%{facts.az_metadata.compute.tags.service}/%{facts.az_metadata.compute.tags.application}/*.yaml"
"secrets/%{facts.az_metadata.compute.tags.environment}/%{facts.az_metadata.compute.tags.application}/*.yaml"
"secrets/%{facts.az_metadata.compute.tags.environment}/*.yaml"
"secrets/*.yaml"
"per_environment/%{facts.az_metadata.compute.tags.environment}/%{facts.az_metadata.compute.tags.application}/*.yaml"
"per_environment/%{facts.az_metadata.compute.tags.environment}/%{facts.az_metadata.compute.tags.environment}.yaml"
"per_service/%{facts.az_metadata.compute.tags.service}/%{facts.az_metadata.compute.tags.application}/%{facts.az_metadata.compute.location}/%{facts.az_metadata.compute.tags.environment}.yaml"
"per_service/%{facts.az_metadata.compute.tags.service}/%{facts.az_metadata.compute.tags.application}/%{facts.az_metadata.compute.tags.environment}.yaml"
"per_service/%{facts.az_metadata.compute.tags.service}/%{facts.az_metadata.compute.tags.environment}.yaml"
"per_role/%{trusted.extensions.pp_role}.yaml"
"per_os/%{facts.os.name}.yaml"
lookup_key: eyaml_lookup_key
options:
pkcs7_private_key: /etc/puppetlabs/puppet/eyaml/its_azplatform/private_key.pkcs7.pem
pkcs7_public_key: /etc/puppetlabs/puppet/eyaml/its_azplatform/public_key.pkcs7.pem

name: common_data
glob: 'common/*.yaml'
lookup_key: eyaml_lookup_key
options:
pkcs7_private_key: /etc/puppetlabs/puppet/eyaml/its_azplatform/private_key.pkcs7.pem
pkcs7_public_key: /etc/puppetlabs/puppet/eyaml/its_azplatform/public_key.pkcs7.pem

Key's I am looking up from a dev.yaml file within hiera data
profile::artifactory_app::artifactory_storage_accname: "%{lookup('artifactory-storage-account')}"
profile::artifactory_app::artifactory_storage_acckey: "%{lookup('artifactory-storage-key')}"
profile::artifactory_app::artifactory_storage_accurl: "%{lookup('artifactory-storage-url')}"
profile::artifactory_app::artifactory_storage_container: "%{lookup('artifactory-storage-container')}"
Any ideas why this isn't working

Hey @adelany ,
I was hoping this wouldn't be an issue.  Can you change your confine keys to be like this and see if it works?
confine_to_keys:
- /^hiscox./
- /^profile./
- /^azure_./
- /^._password$/
- /^password.*/

Also, I'm on the puppet-community slack.  It would be great if you reached out to me on there so i can get this fixed for you quickly.

Hey @adelany ,
Please get 2.0.1 which resolves your issue.

Many thanks this resolved the issue now working perfectly.


Synthesize interview results into user research knowledge base and produce report

@edwardbarraza status: Plan to get started on this task once interviews complete later this week.

Edward provide Jordan with some slides for early user interview synthesis.

July Schedule Status: On track

First raw synthesis should be available by the end of the week (10+10)

Transcribing of the interview is fully done.
The research database is migrated into a atomic UX research database.
This will help to draw the conclusions from the collected user experiences.
The objective is to finalize the synthesis next Thursday.

Done. Summary report time!

@edwardbarraza status: all information has been added to atomic database, working on report now.

August Schedule Status: Delayed due to resources diverted early to #7. This delivery is a prototype and not linked to system I&T.

September Schedule Status: Delayed due to resources diverted early to #7. Delivery on schedule prior to I&T.

@edwardbarraza are we on track with this ticket ? Thanks.

Yes - I will be talking about the work tomorrow during our tag up.

Discussed at 10/22 Sprint Planning Meeting.
@edwardbarraza please attach slide deck when available

Draft - revisions pending
Uploading user study draft1.pdf…

@edwardbarraza the PDS above doesn't work?

Try again - looks like I submitted comment before it was uploaded. This was the draft, working revisions in before tomorrow.


Consider looking at Cabal default-extensions field

This troublesome Cabal field breaks most standalone Haskell tools, even GHCi. We could hack relentlessly to support it, though.
This depends on #24

Actually, now that I think of it I'm not sure that any GHC syntactic extensions actually break when combined. We might be able to just enable all of them. A little research is required.

It looks like OverloadedStrings and RebindableSyntax don't currently play well together: https://ghc.haskell.org/trac/ghc/ticket/14342

Luckily we only need to care about extensions that change the syntax, rather than the meaning. I think we can safely ignore both of those?
Thinking of extensions like LambdaCase and MultiWayIf and DoAndIfThenElse and KindSignatures


Added support for extra document types.

Added support for extra document types.
Also reordered case statements to make it more easy to spot the different types.
Unfortunately i don't have any example documents to use for unit tests.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: Krm1t sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Problem if sequences are less than 60 aa.

See in getDomainsFromHMMScanOrRpsAndTm.py
def formatSequence(sequence) function

Resolved.


Translated into Latin.

You translated the whole repo to Latin instead. You should fork the repository and translate it, after that you can open a PR with your contribution. I'll close this PR, feel free to open another one with the correct contribution.


NXStyle: Ignore alignments of block comments at right of code

NXstyle rightfully ignores single comments at right of code, for instance within a struct declaration.
But complaints about a block comment.
struct a_struct_s
{
   uint8_t f1; /* Long line in a single comment, OK. */
   uint8_t f2; /* Long line in a block comment,
                * nxstyle complains.
                */
};

The */ is normally not on a separate line on right hand comments.  Does this eliminte the problem?
struct a_struct_s
{
   uint8_t f1; /* Long line in a single comment, OK. */
   uint8_t f2; /* Long line in a block comment,
                * nxstyle complains.  */
};

Tried this as well. I got the same complaints.

Can you please generate a test case?  I created this file, junk.c:
/****************************************************************************
 * junk.c
 ****************************************************************************/

/****************************************************************************
 * Included Files
****************************************************************************/

#include <stdint.h>

/****************************************************************************
 * Private Types
 ****************************************************************************/

struct a_struct_s
{
  uint8_t f1; /* Long line in a single comment, OK. */
  uint8_t f2; /* Long line in a block comment,
               * nxstyle complains.
               */
};

/****************************************************************************
 * Public Functions
 ****************************************************************************/

But nxstyle is completely happy with that... no complaints at all.  Nor have I ever seen a problem in the past.  So I am thinking that this is context specific problem.  So I think to resolve it, you will need to provide a full test file that shows the failure in context.
Is there an existing file in the repository?

Looking back through the PR chekcs for I think I see the issue you are referring to: https://github.com/apache/incubator-nuttx/runs/562410318?check_suite_focus=true
The file is  arch/arm/src/imxrt/imxrt_enc.c and these errors were reported:
arch/arm/src/imxrt/imxrt_enc.c:266:78: error: Long line found
arch/arm/src/imxrt/imxrt_enc.c:269:78: error: Long line found
arch/arm/src/imxrt/imxrt_enc.c:272:82: error: Long line found
arch/arm/src/imxrt/imxrt_enc.c:273:80: error: Long line found
arch/arm/src/imxrt/imxrt_enc.c:296:78: error: Long line found

Looking at those, I see that these are not related to the right hand comments at all.  These are simply saying that the lines are too long.  I verfied each that this is the case.  The ARE too long.
When I run the current nxstyle against the current imxrt_enc.c I get:
$ tools/nxstyle.exe arch/arm/src/imxrt/imxrt_enc.c
arch/arm/src/imxrt/imxrt_enc.c:1037:81: error: Long line found
arch/arm/src/imxrt/imxrt_enc.c:1043:84: error: Long line found

To things to note:

The errors at liness 266-296 no longer appear.  That is a regression.
New long lines are reported at 1037 and 1043.  These are correct and appear not due to a recent fix to nxstyle.

So I am thinking that this Issue should be closed.  Please give your feeback before I close it.

Yes, the lines are too long.  But nxstyle ignores long lines when it's a comment at the right of struct field for instance.
This is used throughout the code base to comment struct fields, so the exception was added to nxstyle not too long ago.
The issue is, single line comments are ignored and no complaints is raised, however if it's a block (and long) comment, now nxstyle complains about the length.

Yes, the lines are too long. But nxstyle ignores long lines when it's a comment at the right of struct field for instance.

I does not, but it did not use too.  That is a different error recently introduced into nxstyle when the right hand comment alignment logic was added.  We lost the length check then.

This is used throughout the code base to comment struct fields, so the exception was added to nxstyle not too long ago.

It wasn't added intentionally.  It was an error that was introduced recently.  Now it turns out, I think it is a good behavior at least for now because there are two many long, right-hand comments, espectially int arch/ header definition header files.

The issue is, single line comments are ignored and no complaints is raised, however if it's a block (and long) comment, now nxstyle complains about the length.

Let me modify my junk.c to make the lines too long and try again.

Nope, no long line is reported. Here is the modified junk.c file:
/****************************************************************************
 * junk.c
 ****************************************************************************/

/****************************************************************************
 * Included Files
 ****************************************************************************/

#include <stdint.h>

/****************************************************************************
 * Private Types
 ****************************************************************************/

struct a_struct_s
{
  uint8_t f1; /* This is a very long line in a single right-hand comment, No error is reported OK. */
  uint8_t f2; /* This is a a very long line in a block comment.  In this case nxstyle complains
               * and an error is reported.
               */
};

/****************************************************************************
 * Public Functions
 ****************************************************************************/

But nxstyle does not complain about the long lines at all.  I am not sure that that is good.  It is good for now, but there is no exception in the coding standard for long right hand comments.  They are also a violation of the coding standard, we just do not want to deal with them now:
The long right hand comments in arch/arm/src/imxrt/imxrt_enc.c no longer generate errors either.  So I conclude that this issue as reported no longer exists.  I believe that there are still issues wtih long lines:  They should be reported.  But given the context of this issue, it can be closed now.

Let me modify my junk.c to make the lines too long and try again.
I did so too.  And I confirm that nxstyle is working as it should be!

Looking back through the PR chekcs for I think I see the issue you are referring to: https://github.com/apache/incubator-nuttx/runs/562410318?check_suite_focus=true
We can also see that some of the errors generated here no longer appear.  An example is line 272.


Trouble using blocks with jade

Greetings, I'm trying to use your jade-starter, but the blocks aren't being compiled properly. I'm not sure if this is an issue with hexo, or the way you provided the jade markup.

For example:
// base.jade

body
 section
  block content

// index.jade
extends base

block content
 h1 test

Doesn't work. Am I missing something here?

I've managed to make it work renaming layout.jade to _layout.jade


high deep value test line 465

if (np.nanmedian(BBPmf1[iDEEP]) > C_DEEP_BBP700_THRESH) & (len(BBPmf1[iDEEP]) >= C_N_of_ANOM_POINTS):
I think this part is not correct len(BBPmf1[iDEEP]) >= C_N_of_ANOM_POINTS, assuming that you are counting points deeper than the Pressure threshold and not anomalous points deeper than the Pressure threshold

Thanks for spotting this bug: I (think I) have now fixed it.

iDEEP = np.where(PRES > C_DEPTH_THRESH)[0] # find deep part of the profile
if np.nanmedian(BBPmf1[iDEEP]) > C_DEEP_BBP700_THRESH: # this is the test
    # find how many points fail the test
    iPointsBelow700dbar = len(iDEEP) # indices of points that fail test
    if iPointsBelow700dbar >= C_N_of_ANOM_POINTS: # check if we have enough points at depth
        ISBAD = np.where(BBPmf1)[0] # flag entire profile

into (not sure about python syntax and how to deal with nan values)
iDEEP = np.where(PRES > C_DEPTH_THRESH)[0] # find deep part of the profile
iPointsBelow700dbar = np.where(BBPmf1[iDEEP]) > C_DEEP_BBP700_THRESH)  # find how many deep points fail the test
if len(iPointsBelow700dbar) >= C_N_of_ANOM_POINTS: # check if we have enough points at depth
ISBAD = np.where(BBPmf1)[0] # flag entire profile
as BBPmf1 is already the median filtered value ?

I think the issue is in how the test was described in v1 of the manuscript. In fact the test checks if the median value of the median-filteredf BBP values below C_DEPTH_THRESH is > C_DEEP_BBP700_THRESH. But we should also check that we have enough points below C_DEPTH_THRESH.
So I have update the revised manuscript and the flow chart. Please let me know if you see other problems.


SConscript file error

SConscript file GPS_RMC_USING_EXAMPLE, rtconfig.h is GPS_RMC_USING_SAMPLE

Thank you very much. This bug has been fixed.


[v18 banner] adding a new banner request

Contribution type
Documentation
Contribution type (other)
we plan to add a new banner since 10/27 instead of the banner between10/12-10/26 at the same place and the same layout.
text：
Think Summit Japan 2021
IBM X-Onlineでオンデマンド配信中
CTA：
オンデマンドを視聴する
[url]
https://www.ibm.com/jp-ja/events/x-online?ondomainbanner=tsj2021_xonlinebanner
we hope the new banner can be show in below domain:
https://www.ibm.com/jp-ja/about
https://www.ibm.com/jp-ja/analytics
https://www.ibm.com/jp-ja/cloud
https://www.ibm.com/jp-ja/it-infrastructure
https://www.ibm.com/jp-ja/products
https://www.ibm.com/jp-ja/security
https://www.ibm.com/jp-ja/watson
https://www.ibm.com/think/jp-ja/business/
https://www.ibm.com/blogs/security/jp-ja/
https://www.ibm.com/blogs/systems/jp-ja/
https://www.ibm.com/blogs/think/jp-ja/
we hope the new banner will not been show in below page:
https://www.ibm.com/jp-ja/services
Intent
we plan to add a new banner since 10/27 instead of the banner between10/12-10/26 at the same place and the same layout.
Solution
we hope the new banner can be show in below domain:
https://www.ibm.com/jp-ja/about
https://www.ibm.com/jp-ja/analytics
https://www.ibm.com/jp-ja/cloud
https://www.ibm.com/jp-ja/it-infrastructure
https://www.ibm.com/jp-ja/products
https://www.ibm.com/jp-ja/security
https://www.ibm.com/jp-ja/watson
https://www.ibm.com/think/jp-ja/business/
https://www.ibm.com/blogs/security/jp-ja/
https://www.ibm.com/blogs/systems/jp-ja/
https://www.ibm.com/blogs/think/jp-ja/
we hope the new banner will not been show in below page:
https://www.ibm.com/jp-ja/services
IBM Organization or Company you are part of
I'm from MSC - Digital Specialist_Japan
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

The follow-on issue in sprint 21-23 is #7612 .  Closing this issue.


Requirements

Can't see the requirements.txt

me too. if you figured out how to solve the issue please make sure to leave a reply with solution. Thanks!

maybe cuz it doesn't use aything related to python nowadays

Can I get more clarity on this issue, I'd like to solve it

Can I get more clarity on this issue, I'd like to solve it

Some tutorials online require you to install the python requirements but it's now all written in Go so maybe that's why they're missing

Mosint no longer includes Python. requirements.txt is not needed.


[ML] Avoid using a temporary zip file during local job invocation

Description
This pull request refactors some local endpoint logic to avoid writing an intermediary zipfile to disk, which is immediately used to extract the contents and then subsequently deleted.
This seems to cause intermittent issues with our tests, specifically on Windows, where test_command_job_local will fail because the intermediary zipfile is "in use by another process".
https://dev.azure.com/azure-sdk/internal/_build/results?buildId=2771681&view=logs&j=11a651e3-713b-5092-386c-1f3b6f7ebbbd&t=6fbf28f9-d2de-5c6e-ba72-80f998604aaa&l=3445

All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

API change check
API changes are not detected in this pull request.


Add IPv6 support

Heavily based on #300 by @StephenKing

v2.10.0 has been released.
This release resolves #307, #300, #185, #16, #218, #21.
Huge kudos to @StephenKing @dekimsey @sc250024 @FernandoMiguel and @bcenker, who starting discussing and contributing to the implementation of IPv6 in this repository almost 2 years ago (see https://github.com/terraform-aws-modules/terraform-aws-vpc/pull/21) !

Thank you @antonbabenko for this PR! So much appreciated!


Suspicious, likely dead code in ec_wNAF_mul()

Cppcheck found this in ec_wNAF_mul()
        if (tmp_len <= max_len) {
            /*
             * One of the other wNAFs is at least as long as the wNAF
             * belonging to the generator, so wNAF splitting will not buy
             * us anything.
             */

            numblocks = 1;
            totalnum = num + 1; /* don't use wNAF splitting */
            wNAF[num] = tmp_wNAF;
            wNAF[num + 1] = NULL;
            wNAF_len[num] = tmp_len;
            if (tmp_len > max_len)
                max_len = tmp_len;

Note  if (tmp_len > max_len) neither max_len nor tmp_len have changed since outer  if (tmp_len <= max_len) { so the inner if condition will always be false and the dependent code will never run.

+1

I'm not sure what the +1 / reviewed means here, there doesn't seem to be a patch.

good point, it describes a patch to be made, isn't a pull request.

Actually I have no idea of how this should be fixed. That code was added for some purpose. What was the purpose?

@Dmitry-Me I could not find tmp_len in the ec2_mult.c

Hence can this issue be closed?

no, it's in ec_mult.c around line 323.

Is there a way one can find out who wrote that section, so we can ask them?

Post to openssl-dev might elicit and answer.  Or, since this is clearly dead code no matter the intent, a PR to remove it would work.

@richsalz what is the email address for openssl-dev?

You have to be a member to post; see https://mta.openssl.org

@nick599 FWIW I'm somewhat familiar with that code. I'm guessing it's just a leftover condition check from a copy/paste -- changed some variable names then tweaked the outer condition, then failing to remove the resulting inner dead code. Here's the commit that did it if you want to dig more:
https://github.com/openssl/openssl/commit/37c660ff9b22d6f0eb19a9881d3b663ca4f63449#diff-40a9b7f560ef4410b988fafff6e79928

Ok, it seems we need a pull request with the dead code removed.
It's been a while since I cloned a repo, edited applicable file, then make a pull request. I'm willing to do this or hand this over to someone who has more experience.


How do I record longer videos? Seems like it only records 2 seconds.

Im using it through recordRTC.

Can you give some code samples or anything? You can definitely record for longer than 2 seconds.
Demo, source.

I tried recordRTC too, seem this is an issue of recordRTC library, it forces to drop all the queued frames after end recording.


distributed tracing for armeria

Introduces distributed tracing capability to armeria clients/servers. This enables us to watch timing data among the whole armeria rpc chain.
This feature depends on brave distributed tracing library compatible with zipkin.
Setup client with brave
// Create a brave instance with service name, span collector, sampling rate.
Brave brave = new Brave.Builder("FibClientMain")
        .spanCollector(new ScribeSpanCollector("<IP_ADDRESS>", 9410))
        .traceSampler(Sampler.create(0.01f))
        .build();

FibService.Iface fibClient =
        new ClientBuilder("tbinary+http://<IP_ADDRESS>:8080/thrift/fib")
                .decorator(client -> HttpTracingClient.of(client, brave))
                .build(FibService.Iface.class);

Setup server with brave
// Create a brave instance with service name, span collector, sampling rate.
Brave brave = new Brave.Builder("FibServerMain")
        .spanCollector(new ScribeSpanCollector("<IP_ADDRESS>", 9410))
        .traceSampler(Sampler.create(0.01f))
        .build();

ServerBuilder builder = new ServerBuilder();

builder.port(8080, SessionProtocol.HTTP);

VirtualHost vh = new VirtualHostBuilder()
        .serviceAt("/thrift/fib",
                ThriftService.of(new FibServiceHandler(brave))
                             .decorate(service -> HttpTracingService.of(service, brave))
        )
        .build();

Add custom annotations using brave's API
// Add custom attribute to the span in service handler
brave.serverTracer().submitBinaryAnnotation("foo", "bar");

// Add custom timing tag in server handler
brave.serverTracer().submitAnnotation("somethinghappen");

w00t!

@trustin Please take a look

@synk First pass done. Please ping me for another pass.

@trustin Thanks. I'll ping you when I finished

@trustin I think I handled your comments. Please take a look again.

Please fix the Javadoc errors:
[ERROR] Exit code: 1 - /home/travis/build/line/armeria/src/main/java/com/linecorp/armeria/client/tracing/HttpTracingClient.java:28: error: self-closing element not allowed
[ERROR] *

[ERROR] ^
[ERROR] /home/travis/build/line/armeria/src/main/java/com/linecorp/armeria/client/tracing/TracingRemoteInvoker.java:44: error: self-closing element not allowed
[ERROR] *

[ERROR] ^
[ERROR] /home/travis/build/line/armeria/src/main/java/com/linecorp/armeria/server/tracing/TracingServiceInvocationHandler.java:41: error: self-closing element not allowed
[ERROR] *

[ERROR] ^

It seems like Javadoc does not like
 and
. (only
 is allowed for P tags)

@synk Looks good to me except for a few nits. Please squash for a merge.

@trustin I've squashed. Please merge if it's OK.

BOOM!


Update version on PyPI

Not a huge problem, but it would be nice; I'm having to pip install from GitHub, since the PyPI version doesn't have this fix.
Thanks for the plugin, by the way.

Sorry about that, 1.1 is now uploaded to pypi.

No problem; thanks for the quick fix.


rename policies

Changes:

rename policies and policy set to remove the volsync from name
rename cluster.open-cluster-management.io/volsync label to cluster.open-cluster-management.io/backup-hub-pvc
updated Readme

thank you for the review @dhaiducek !

@birsanv These review comments are unresolved:

https://github.com/open-cluster-management-io/policy-collection/pull/450/files#r1475217527
https://github.com/open-cluster-management-io/policy-collection/pull/450/files#r1475223994

Also please squash the commits into one commit and update the title of the commit message to something more descriptive, something like "Remove "volsync" from policy names".

@dhaiducek thanks ! I resolved the last 2 comments I missed

@dhaiducek thanks ! I resolved the last 2 comments I missed

Thanks! Also please squash the commits into one commit and update the title of the commit message to something more descriptive, something like "Remove "volsync" from policy names".

Replaced by:

https://github.com/open-cluster-management-io/policy-collection/pull/452


Provide an API to obtain public certificate of WSO2 keystore in .PEM format

Currently KeyStoreAdminService, does not have a method to retrieve public certificate in .PEM format.
The available workaround is to obtain the .CERT

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


[EDCK] Add new object type for EDCK

Furthermore, the example object is missing

@Markus1812 : I have incorporated all above review comments. However, I am stuck at the check Generated Json Schema differs from provided ones. I am not really sure how to resolve this error. I cannot find out from where I can download the generated JSON schema to perform the comparison with the provided JSON schema. Please help.

@Markus1812 : Thank you for helping out. I have incorporated the review comments. and deleted the .DS_Store file as well. Please approve.

In case you have missed it: One comment above is still unresolved. There was not only the z missing of zif... missing but also the exist has to be existence_check to be the same as the constant name.
https://github.com/SAP/abap-file-formats/pull/629#discussion_r1745227671

@Markus1812 : Constant name of the default value has been corrected as well. Let me know if further changes are required.

@wurzka : Requested changes are done.


missing domain for some properties

Are the following properties missing the rdfs:domain of mod:Ontology:

mod:metrics
mod:numberOfDataProperties
mod:numberOfObjectProperties

The descriptions of these properties indicate that they are for use with the Ontology e.g. "The total number of object properties in an ontology", so I suspect their missing rdfs:domain is just an oversight.

Hello. Good observation.
This has been fixed in MOD2 where each metrics properties have rdfs:domain =>  mod:SemanticArtefactDistribution.
https://github.com/sifrproject/MOD-Ontology/blob/master/mod-v2.0_profile.ttl#L2582


out of date documentation

In the documentation it states the following:
To obtain this stream you can use:
CancellationTokenSource cancellation = new CancellationTokenSource();
Stream stream = await client.Miscellaneous.MonitorEventsAsync(new ContainerEventsParameters(), cancellation.Token);
// Initialize a StreamReader...
However, the source code does not have this (Miscellaneous) class anymore. In case of getting the Container logs, MonitorStreamAsync is located in the StreamUtils class now used by GetContainerLogsAsync as part of the Container Operations set of methods. On the other hand, for using the MonitorEventsAsync, thats located now in the System class. The documentation should be updated stating that.

@s0ren1 - Want to PR up the changes?


Fix text inconsistency

Fix text to match what was said on the previous paragraph.
Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] All the files I changed are in the same world language, for example: only English changes, or only Chinese changes, etc.

Closes #XXXXX

I've only fixed the inconsistency to the previous paragraph. I'd suggest that for such an introductory lesson, listing the primitive data types instead of all the Language Types (https://tc39.es/ecma262/#sec-ecmascript-data-types-and-values) is less overwhelming.

@zbianca Thanks for catching seven vs. the correct eight.  Regarding your suggestion, you can create an issue on GitHub and present your ideas on changing the challenge description.

@raisedadead Seems to be stuck at the Travis build stage.

It looks like Travis completes the run and then doesn't report back to GitHub, but I have no idea why.  This is the original job, which GitHub thinks has stalled, but Travis is reporting as a success.
Also, it should be enough to press the 'restart job' button on Travis - force pushing feels like overkill.

Thanks for sorting this out @zbianca and congrats on your first merged PR!


UNICODE fixes (clipboard, window title, file dialogs, paths, font glyphs, ...)

Adds UNICODE support for CFFI related things on HXCPP and HashLink targets.

Hey @restorer, can you take a look at this one and tell us how it compares to #1391?

@joshtynjala Can you resolve the conflicts in ExternalInterface.cpp? It looks like you were both trying to solve the same problems but solved them in slightly different ways.

I'd like to discourage from using std::wcstombs even on Windows because the encoding of the resulting string is locale-dependent and while some more recent versions of Windows 10 (and newer) allow to set locale to UTF-8, it's probably never the default system locale. Windows API uses UTF-16 (UCS-2 before Windows 2000) for file names and it's quite possible to have files with names that cannot be translated to a narrow string using the default system locale.

. @joshtynjala Can you resolve the conflicts in ExternalInterface.cpp? It looks like you were both trying to solve the same problems but solved them in slightly different ways.

In order to resolve the conflicts some maintainer needs to decide which one of those two similar functions (hl_wstring_to_utf8_bytes() vs wstring_to_vbytes()) they wish to keep. Mine is locale-independent so I think it's better but I really wish for this PR to get merged so I go either way.

which one of those two similar functions (hl_wstring_to_utf8_bytes() vs wstring_to_vbytes()) they wish to keep

I've opened up a another PR #1665 to clean things up so hopefully we can avoid these conversions altogether.

Actually, it looks like there are a few other places where these conversions are still required, so might need to keep one of these functions around anyway, unless those wstrings can be avoided as well.

In order to resolve the conflicts some maintainer needs to decide which one of those two similar functions (hl_wstring_to_utf8_bytes() vs wstring_to_vbytes()) they wish to keep.

Would it be possible to decide on one of these so that these unicode issues can be fixed? Maybe @nixbody's one because it is locale independent?

I've forked and resolved the merge conflicts in a separate branch, preferring hl_wstring_to_utf8_bytes over wstring_to_vbytes:  https://github.com/tobil4sk/lime/tree/cffi-unicode-fixes
This is quite an important fix. If there are no objections, these changes can be pushed here and this could be merged? Then, once things are working finally, in future we can look at cleaning up the conversions in #1665.

I didn't have permission to push your branch from my machine, so I redid the changes in the web editor. Let me know if I got anything wrong.

I added a commit here to put it in sync with my branch.

There is a conflict now in src/lime/text/Font.hx because of #1742. I think it might be fine to keep that file as it currently is in develop, it seems to me that both changes deal with the same issue? @nixbody

I think I'd prefer the version here, without the unsafe cast.

I think I'd prefer the version here, without the unsafe cast.

You're right, looks like this is the preferred way to handle hl.NativeArray -> Array conversions with hashlink, e.g. in hlsdl:
https://github.com/HaxeFoundation/hashlink/blob/783cd2a785b2e6f38e6b01e1b3bf5bdc19fa1173/libs/sdl/sdl/Sdl.hx#L141-L144

Since all the conflicts and issues seem to be resolved here, is this something that could be merged soon? This is quite a useful fix.

I haven't moved towards merging this because I don't know how to test it. I can tell it doesn't break the RenderingText sample on Linux, but it also doesn't fix it.
 (I'm a fan of PRs being merged by whoever understands them best. Then if there's a problem it's clear who to contact.)

I can tell it doesn't break the TextRendering sample on Linux, but it also doesn't fix it.

I've mostly been dealing with the file dialog and file system fixes here, which I've tested and they work fine. I don't think these changes would be enough to get unicode text rendering working, I think a separate PR like #1391 is needed to deal with that.
I haven't myself run into the issues with the other parts of the api this PR fixes (particularly the font related bits). However, the changes are pretty regular and simple (ensuring that necessary string conversions are performed before passing to native apis). From what I know about hxcpp and hashlink string encoding, these changes look correct to me.
I'd prefer to just go ahead and merge this, but if you think it's better I could also try to create some test projects to test all these api calls, it don't know when I'll have time for this though.

However, the changes are pretty regular and simple (ensuring that necessary string conversions are performed before passing to native apis). From what I know about hxcpp and hashlink string encoding, these changes look correct to me.

That sounds like a good level of confidence. I think you can go ahead, then.


cordova build windows generates following error "Error: No valid MSBuild was detected for the selected target."

cordova platform list
Installed platforms: browser 5.0.3, ios 4.5.4, osx 4.0.1, windows 5.0.0
Available platforms: amazon-fireos, android, blackberry10, firefoxos, webos
cordova -v
5.4.0
I have tried this on Mac High Sierra as well as Windows 10

Uh - current cordova version is 8.0.0 and current cordova-windows is 6.0.0 - you should try updating both. (Instructions here for example: https://ionic.zone/cordova/update)

My temporary solution has been only to execute it in debug mode and not in release mode.
At the time of generating the compiled for the store does not happen, it works perfectly. I will continue to see the same log to see what is happening.

Essentially the MSBuild detection code does not work well with VS 2017. Duping this into #274


I've been using it in the form add widget since 98cd3c8f7e0c644ecf0263aabf83af03c3cb908b


Update runtimeclassname in docs/tests/webhook

This code depends on #903 and contains the e2e, doc and webhook changes to move us to use kata-remote as our peer pods runtime class in prep for switching to use the upstream operator to install the runtime payload.

To test this branch I manually built the runtime-payload changes to quay.io/stevenhorsman/pp-payload:latest then updated:
kind: CcRuntime
metadata:
  name: ccruntime-sample
  namespace: confidential-containers-system
spec:
  # Add fields here
  runtimeName: kata
  ccNodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker: ""
  config:
    installType: bundle
    payloadImage: quay.io/stevenhorsman/pp-payload:latest

to point to it.
I then installed peer pods in the currently documented way and it gave me the updated runtime class:
kubectl get runtimeclass
NAME          HANDLER       AGE
kata-remote   kata-remote   7m18s

I then ran the updated e2e tests which passed in that set-up:
Wait for the kata-remote runtimeclass be created
=== RUN   TestCreateSimplePod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created
time="2023-05-04T09:49:51-07:00" level=info msg="PodVM name: simple-peer-pod"
time="2023-05-04T09:49:51-07:00" level=debug msg="Instance number: 0, Instance id: 0797_4a7379a8-fd1c-43ae-8808-d545c15f6a47, Instance name: podvm-simple-peer-pod-7685ad9b"
--- PASS: TestCreateSimplePod (35.33s)
    --- PASS: TestCreateSimplePod/Simple_Peer_Pod (35.33s)
        --- PASS: TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created (0.16s)
=== RUN   TestCreatePodWithConfigMap
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data
time="2023-05-04T09:50:27-07:00" level=info msg="Data Inside Configmap: Hello, world"
time="2023-05-04T09:50:27-07:00" level=info msg="Deleting pod... configmap-pod"
time="2023-05-04T09:50:27-07:00" level=info msg="Deleting Configmap... nginx-config"
--- PASS: TestCreatePodWithConfigMap (35.63s)
    --- PASS: TestCreatePodWithConfigMap/Configmap_Pod (35.63s)
        --- PASS: TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data (0.41s)
=== RUN   TestCreatePodWithSecret
=== RUN   TestCreatePodWithSecret/Secret_Pod
=== RUN   TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data
time="2023-05-04T09:51:02-07:00" level=info msg="Username inside volume: admin"
time="2023-05-04T09:51:02-07:00" level=info msg="Password inside volume: 123456"
time="2023-05-04T09:51:02-07:00" level=info msg="Deleting pod... secret-pod"
time="2023-05-04T09:51:02-07:00" level=info msg="Deleting Secret... nginx-secret"
--- PASS: TestCreatePodWithSecret (35.75s)
    --- PASS: TestCreatePodWithSecret/Secret_Pod (35.75s)
        --- PASS: TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data (0.52s)
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP
time="2023-05-04T09:51:33-07:00" level=info msg="Pinging www.google.com ..."
time="2023-05-04T09:51:33-07:00" level=info msg="Output of ping command in busybox : PING www.google.com (<IP_ADDRESS>): 56 data bytes\n64 bytes from <IP_ADDRESS>: seq=0 ttl=53 time=107.901 ms\n\n--- www.google.com ping statistics ---\n1 packets transmitted, 1 packets received, 0% packet loss\nround-trip min/avg/max = 107.901/107.901/107.901 ms\n"
--- PASS: TestCreatePeerPodContainerWithExternalIPAccess (30.58s)
    --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container (30.58s)
        --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP (0.44s)
PASS
ok  	github.com/confidential-containers/cloud-api-adaptor/test/e2e	180.392s

#903 has been merged now, so once this PR has enough reviews I will re-build quay.io/confidential-containers/peer-pods-runtime-payload then re-test this PR without my manually changes and assuming it works, then merge it.

The tests are passing against the rebuilt runtime payload, with this PR:
Wait for the pod cloud-api-adaptor-daemonset-2bxnl be ready
Wait for the kata-remote runtimeclass be created
=== RUN   TestCreateSimplePod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created
time="2023-05-09T04:45:36-07:00" level=info msg="PodVM name: simple-peer-pod"
time="2023-05-09T04:45:37-07:00" level=debug msg="Instance number: 0, Instance id: 0797_be405e2c-43ca-458f-b6a3-3aa55ecedce5, Instance name: podvm-simple-peer-pod-1af7e942"
--- PASS: TestCreateSimplePod (40.38s)
    --- PASS: TestCreateSimplePod/Simple_Peer_Pod (40.38s)
        --- PASS: TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created (0.22s)
=== RUN   TestCreatePodWithConfigMap
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data
time="2023-05-09T04:46:07-07:00" level=info msg="Data Inside Configmap: Hello, world"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting pod... configmap-pod"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting Configmap... nginx-config"
--- PASS: TestCreatePodWithConfigMap (30.58s)
    --- PASS: TestCreatePodWithConfigMap/Configmap_Pod (30.58s)
        --- PASS: TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data (0.35s)
=== RUN   TestCreatePodWithSecret
=== RUN   TestCreatePodWithSecret/Secret_Pod
=== RUN   TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data
time="2023-05-09T04:46:38-07:00" level=info msg="Username inside volume: admin"
time="2023-05-09T04:46:38-07:00" level=info msg="Password inside volume: 123456"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting pod... secret-pod"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting Secret... nginx-secret"
--- PASS: TestCreatePodWithSecret (30.95s)
    --- PASS: TestCreatePodWithSecret/Secret_Pod (30.95s)
        --- PASS: TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data (0.72s)
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP
time="2023-05-09T04:47:09-07:00" level=info msg="Pinging www.google.com ..."
time="2023-05-09T04:47:09-07:00" level=info msg="Output of ping command in busybox : PING www.google.com (<IP_ADDRESS>): 56 data bytes\n64 bytes from <IP_ADDRESS>: seq=0 ttl=53 time=107.578 ms\n\n--- www.google.com ping statistics ---\n1 packets transmitted, 1 packets received, 0% packet loss\nround-trip min/avg/max = 107.578/107.578/107.578 ms\n"
--- PASS: TestCreatePeerPodContainerWithExternalIPAccess (30.63s)
    --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container (30.63s)
        --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP (0.48s)
PASS
ok  	github.com/confidential-containers/cloud-api-adaptor/test/e2e	195.874s

So I think we are ready to merge this, and get the staging branch back and working, but happy to wait for @snir911's review though first

The tests are passing against the rebuilt runtime payload, with this PR:
Wait for the pod cloud-api-adaptor-daemonset-2bxnl be ready
Wait for the kata-remote runtimeclass be created
=== RUN   TestCreateSimplePod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created
time="2023-05-09T04:45:36-07:00" level=info msg="PodVM name: simple-peer-pod"
time="2023-05-09T04:45:37-07:00" level=debug msg="Instance number: 0, Instance id: 0797_be405e2c-43ca-458f-b6a3-3aa55ecedce5, Instance name: podvm-simple-peer-pod-1af7e942"
--- PASS: TestCreateSimplePod (40.38s)
    --- PASS: TestCreateSimplePod/Simple_Peer_Pod (40.38s)
        --- PASS: TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created (0.22s)
=== RUN   TestCreatePodWithConfigMap
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data
time="2023-05-09T04:46:07-07:00" level=info msg="Data Inside Configmap: Hello, world"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting pod... configmap-pod"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting Configmap... nginx-config"
--- PASS: TestCreatePodWithConfigMap (30.58s)
    --- PASS: TestCreatePodWithConfigMap/Configmap_Pod (30.58s)
        --- PASS: TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data (0.35s)
=== RUN   TestCreatePodWithSecret
=== RUN   TestCreatePodWithSecret/Secret_Pod
=== RUN   TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data
time="2023-05-09T04:46:38-07:00" level=info msg="Username inside volume: admin"
time="2023-05-09T04:46:38-07:00" level=info msg="Password inside volume: 123456"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting pod... secret-pod"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting Secret... nginx-secret"
--- PASS: TestCreatePodWithSecret (30.95s)
    --- PASS: TestCreatePodWithSecret/Secret_Pod (30.95s)
        --- PASS: TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data (0.72s)
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP
time="2023-05-09T04:47:09-07:00" level=info msg="Pinging www.google.com ..."
time="2023-05-09T04:47:09-07:00" level=info msg="Output of ping command in busybox : PING www.google.com (<IP_ADDRESS>): 56 data bytes\n64 bytes from <IP_ADDRESS>: seq=0 ttl=53 time=107.578 ms\n\n--- www.google.com ping statistics ---\n1 packets transmitted, 1 packets received, 0% packet loss\nround-trip min/avg/max = 107.578/107.578/107.578 ms\n"
--- PASS: TestCreatePeerPodContainerWithExternalIPAccess (30.63s)
    --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container (30.63s)
        --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP (0.48s)
PASS
ok  	github.com/confidential-containers/cloud-api-adaptor/test/e2e	195.874s

So I think we are ready to merge this, and get the staging branch back and working, but happy to wait for @snir911's review though first

The tests are passing against the rebuilt runtime payload, with this PR:
Wait for the pod cloud-api-adaptor-daemonset-2bxnl be ready
Wait for the kata-remote runtimeclass be created
=== RUN   TestCreateSimplePod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created
time="2023-05-09T04:45:36-07:00" level=info msg="PodVM name: simple-peer-pod"
time="2023-05-09T04:45:37-07:00" level=debug msg="Instance number: 0, Instance id: 0797_be405e2c-43ca-458f-b6a3-3aa55ecedce5, Instance name: podvm-simple-peer-pod-1af7e942"
--- PASS: TestCreateSimplePod (40.38s)
    --- PASS: TestCreateSimplePod/Simple_Peer_Pod (40.38s)
        --- PASS: TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created (0.22s)
=== RUN   TestCreatePodWithConfigMap
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data
time="2023-05-09T04:46:07-07:00" level=info msg="Data Inside Configmap: Hello, world"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting pod... configmap-pod"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting Configmap... nginx-config"
--- PASS: TestCreatePodWithConfigMap (30.58s)
    --- PASS: TestCreatePodWithConfigMap/Configmap_Pod (30.58s)
        --- PASS: TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data (0.35s)
=== RUN   TestCreatePodWithSecret
=== RUN   TestCreatePodWithSecret/Secret_Pod
=== RUN   TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data
time="2023-05-09T04:46:38-07:00" level=info msg="Username inside volume: admin"
time="2023-05-09T04:46:38-07:00" level=info msg="Password inside volume: 123456"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting pod... secret-pod"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting Secret... nginx-secret"
--- PASS: TestCreatePodWithSecret (30.95s)
    --- PASS: TestCreatePodWithSecret/Secret_Pod (30.95s)
        --- PASS: TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data (0.72s)
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP
time="2023-05-09T04:47:09-07:00" level=info msg="Pinging www.google.com ..."
time="2023-05-09T04:47:09-07:00" level=info msg="Output of ping command in busybox : PING www.google.com (<IP_ADDRESS>): 56 data bytes\n64 bytes from <IP_ADDRESS>: seq=0 ttl=53 time=107.578 ms\n\n--- www.google.com ping statistics ---\n1 packets transmitted, 1 packets received, 0% packet loss\nround-trip min/avg/max = 107.578/107.578/107.578 ms\n"
--- PASS: TestCreatePeerPodContainerWithExternalIPAccess (30.63s)
    --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container (30.63s)
        --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP (0.48s)
PASS
ok  	github.com/confidential-containers/cloud-api-adaptor/test/e2e	195.874s

So I think we are ready to merge this, and get the staging branch back and working, but happy to wait for @snir911's review though first

The tests are passing against the rebuilt runtime payload, with this PR:
Wait for the pod cloud-api-adaptor-daemonset-2bxnl be ready
Wait for the kata-remote runtimeclass be created
=== RUN   TestCreateSimplePod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created
time="2023-05-09T04:45:36-07:00" level=info msg="PodVM name: simple-peer-pod"
time="2023-05-09T04:45:37-07:00" level=debug msg="Instance number: 0, Instance id: 0797_be405e2c-43ca-458f-b6a3-3aa55ecedce5, Instance name: podvm-simple-peer-pod-1af7e942"
--- PASS: TestCreateSimplePod (40.38s)
    --- PASS: TestCreateSimplePod/Simple_Peer_Pod (40.38s)
        --- PASS: TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created (0.22s)
=== RUN   TestCreatePodWithConfigMap
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data
time="2023-05-09T04:46:07-07:00" level=info msg="Data Inside Configmap: Hello, world"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting pod... configmap-pod"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting Configmap... nginx-config"
--- PASS: TestCreatePodWithConfigMap (30.58s)
    --- PASS: TestCreatePodWithConfigMap/Configmap_Pod (30.58s)
        --- PASS: TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data (0.35s)
=== RUN   TestCreatePodWithSecret
=== RUN   TestCreatePodWithSecret/Secret_Pod
=== RUN   TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data
time="2023-05-09T04:46:38-07:00" level=info msg="Username inside volume: admin"
time="2023-05-09T04:46:38-07:00" level=info msg="Password inside volume: 123456"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting pod... secret-pod"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting Secret... nginx-secret"
--- PASS: TestCreatePodWithSecret (30.95s)
    --- PASS: TestCreatePodWithSecret/Secret_Pod (30.95s)
        --- PASS: TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data (0.72s)
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP
time="2023-05-09T04:47:09-07:00" level=info msg="Pinging www.google.com ..."
time="2023-05-09T04:47:09-07:00" level=info msg="Output of ping command in busybox : PING www.google.com (<IP_ADDRESS>): 56 data bytes\n64 bytes from <IP_ADDRESS>: seq=0 ttl=53 time=107.578 ms\n\n--- www.google.com ping statistics ---\n1 packets transmitted, 1 packets received, 0% packet loss\nround-trip min/avg/max = 107.578/107.578/107.578 ms\n"
--- PASS: TestCreatePeerPodContainerWithExternalIPAccess (30.63s)
    --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container (30.63s)
        --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP (0.48s)
PASS
ok  	github.com/confidential-containers/cloud-api-adaptor/test/e2e	195.874s

So I think we are ready to merge this, and get the staging branch back and working, but happy to wait for @snir911's review though first

The tests are passing against the rebuilt runtime payload, with this PR:
Wait for the pod cloud-api-adaptor-daemonset-2bxnl be ready
Wait for the kata-remote runtimeclass be created
=== RUN   TestCreateSimplePod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created
time="2023-05-09T04:45:36-07:00" level=info msg="PodVM name: simple-peer-pod"
time="2023-05-09T04:45:37-07:00" level=debug msg="Instance number: 0, Instance id: 0797_be405e2c-43ca-458f-b6a3-3aa55ecedce5, Instance name: podvm-simple-peer-pod-1af7e942"
--- PASS: TestCreateSimplePod (40.38s)
    --- PASS: TestCreateSimplePod/Simple_Peer_Pod (40.38s)
        --- PASS: TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created (0.22s)
=== RUN   TestCreatePodWithConfigMap
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data
time="2023-05-09T04:46:07-07:00" level=info msg="Data Inside Configmap: Hello, world"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting pod... configmap-pod"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting Configmap... nginx-config"
--- PASS: TestCreatePodWithConfigMap (30.58s)
    --- PASS: TestCreatePodWithConfigMap/Configmap_Pod (30.58s)
        --- PASS: TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data (0.35s)
=== RUN   TestCreatePodWithSecret
=== RUN   TestCreatePodWithSecret/Secret_Pod
=== RUN   TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data
time="2023-05-09T04:46:38-07:00" level=info msg="Username inside volume: admin"
time="2023-05-09T04:46:38-07:00" level=info msg="Password inside volume: 123456"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting pod... secret-pod"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting Secret... nginx-secret"
--- PASS: TestCreatePodWithSecret (30.95s)
    --- PASS: TestCreatePodWithSecret/Secret_Pod (30.95s)
        --- PASS: TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data (0.72s)
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP
time="2023-05-09T04:47:09-07:00" level=info msg="Pinging www.google.com ..."
time="2023-05-09T04:47:09-07:00" level=info msg="Output of ping command in busybox : PING www.google.com (<IP_ADDRESS>): 56 data bytes\n64 bytes from <IP_ADDRESS>: seq=0 ttl=53 time=107.578 ms\n\n--- www.google.com ping statistics ---\n1 packets transmitted, 1 packets received, 0% packet loss\nround-trip min/avg/max = 107.578/107.578/107.578 ms\n"
--- PASS: TestCreatePeerPodContainerWithExternalIPAccess (30.63s)
    --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container (30.63s)
        --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP (0.48s)
PASS
ok  	github.com/confidential-containers/cloud-api-adaptor/test/e2e	195.874s

So I think we are ready to merge this, and get the staging branch back and working, but happy to wait for @snir911's review though first

The tests are passing against the rebuilt runtime payload, with this PR:
Wait for the pod cloud-api-adaptor-daemonset-2bxnl be ready
Wait for the kata-remote runtimeclass be created
=== RUN   TestCreateSimplePod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created
time="2023-05-09T04:45:36-07:00" level=info msg="PodVM name: simple-peer-pod"
time="2023-05-09T04:45:37-07:00" level=debug msg="Instance number: 0, Instance id: 0797_be405e2c-43ca-458f-b6a3-3aa55ecedce5, Instance name: podvm-simple-peer-pod-1af7e942"
--- PASS: TestCreateSimplePod (40.38s)
    --- PASS: TestCreateSimplePod/Simple_Peer_Pod (40.38s)
        --- PASS: TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created (0.22s)
=== RUN   TestCreatePodWithConfigMap
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data
time="2023-05-09T04:46:07-07:00" level=info msg="Data Inside Configmap: Hello, world"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting pod... configmap-pod"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting Configmap... nginx-config"
--- PASS: TestCreatePodWithConfigMap (30.58s)
    --- PASS: TestCreatePodWithConfigMap/Configmap_Pod (30.58s)
        --- PASS: TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data (0.35s)
=== RUN   TestCreatePodWithSecret
=== RUN   TestCreatePodWithSecret/Secret_Pod
=== RUN   TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data
time="2023-05-09T04:46:38-07:00" level=info msg="Username inside volume: admin"
time="2023-05-09T04:46:38-07:00" level=info msg="Password inside volume: 123456"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting pod... secret-pod"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting Secret... nginx-secret"
--- PASS: TestCreatePodWithSecret (30.95s)
    --- PASS: TestCreatePodWithSecret/Secret_Pod (30.95s)
        --- PASS: TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data (0.72s)
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP
time="2023-05-09T04:47:09-07:00" level=info msg="Pinging www.google.com ..."
time="2023-05-09T04:47:09-07:00" level=info msg="Output of ping command in busybox : PING www.google.com (<IP_ADDRESS>): 56 data bytes\n64 bytes from <IP_ADDRESS>: seq=0 ttl=53 time=107.578 ms\n\n--- www.google.com ping statistics ---\n1 packets transmitted, 1 packets received, 0% packet loss\nround-trip min/avg/max = 107.578/107.578/107.578 ms\n"
--- PASS: TestCreatePeerPodContainerWithExternalIPAccess (30.63s)
    --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container (30.63s)
        --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP (0.48s)
PASS
ok  	github.com/confidential-containers/cloud-api-adaptor/test/e2e	195.874s

So I think we are ready to merge this, and get the staging branch back and working, but happy to wait for @snir911's review though first

The tests are passing against the rebuilt runtime payload, with this PR:
Wait for the pod cloud-api-adaptor-daemonset-2bxnl be ready
Wait for the kata-remote runtimeclass be created
=== RUN   TestCreateSimplePod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod
=== RUN   TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created
time="2023-05-09T04:45:36-07:00" level=info msg="PodVM name: simple-peer-pod"
time="2023-05-09T04:45:37-07:00" level=debug msg="Instance number: 0, Instance id: 0797_be405e2c-43ca-458f-b6a3-3aa55ecedce5, Instance name: podvm-simple-peer-pod-1af7e942"
--- PASS: TestCreateSimplePod (40.38s)
    --- PASS: TestCreateSimplePod/Simple_Peer_Pod (40.38s)
        --- PASS: TestCreateSimplePod/Simple_Peer_Pod/PodVM_is_created (0.22s)
=== RUN   TestCreatePodWithConfigMap
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod
=== RUN   TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data
time="2023-05-09T04:46:07-07:00" level=info msg="Data Inside Configmap: Hello, world"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting pod... configmap-pod"
time="2023-05-09T04:46:07-07:00" level=info msg="Deleting Configmap... nginx-config"
--- PASS: TestCreatePodWithConfigMap (30.58s)
    --- PASS: TestCreatePodWithConfigMap/Configmap_Pod (30.58s)
        --- PASS: TestCreatePodWithConfigMap/Configmap_Pod/Configmap_is_created_and_contains_data (0.35s)
=== RUN   TestCreatePodWithSecret
=== RUN   TestCreatePodWithSecret/Secret_Pod
=== RUN   TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data
time="2023-05-09T04:46:38-07:00" level=info msg="Username inside volume: admin"
time="2023-05-09T04:46:38-07:00" level=info msg="Password inside volume: 123456"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting pod... secret-pod"
time="2023-05-09T04:46:38-07:00" level=info msg="Deleting Secret... nginx-secret"
--- PASS: TestCreatePodWithSecret (30.95s)
    --- PASS: TestCreatePodWithSecret/Secret_Pod (30.95s)
        --- PASS: TestCreatePodWithSecret/Secret_Pod/Secret_is_created_and_contains_data (0.72s)
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container
=== RUN   TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP
time="2023-05-09T04:47:09-07:00" level=info msg="Pinging www.google.com ..."
time="2023-05-09T04:47:09-07:00" level=info msg="Output of ping command in busybox : PING www.google.com (<IP_ADDRESS>): 56 data bytes\n64 bytes from <IP_ADDRESS>: seq=0 ttl=53 time=107.578 ms\n\n--- www.google.com ping statistics ---\n1 packets transmitted, 1 packets received, 0% packet loss\nround-trip min/avg/max = 107.578/107.578/107.578 ms\n"
--- PASS: TestCreatePeerPodContainerWithExternalIPAccess (30.63s)
    --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container (30.63s)
        --- PASS: TestCreatePeerPodContainerWithExternalIPAccess/Peer_Pod_Container/Peer_Pod_Container_Connected_to_External_IP (0.48s)
PASS
ok  	github.com/confidential-containers/cloud-api-adaptor/test/e2e	195.874s

So I think we are ready to merge this, and get the staging branch back and working, but happy to wait for @snir911's review though first

Sorry for all the comment spam. The github API has had errors in the last hour which means some actions (like posted comments it seems) only partially happened. Deleting them seems to not work now either, but when it is back I'll tidy it up.

@stevenhorsman sorry maybe i missed something, shouldn't
https://github.com/confidential-containers/cloud-api-adaptor/blob/0a3040aa6bafc2c3e2797b2835a9a6c0d85aa43c/install/yamls/ccruntime-peer-pods.yaml#L8
be changed also?

@stevenhorsman sorry maybe i missed something, shouldn't
https://github.com/confidential-containers/cloud-api-adaptor/blob/0a3040aa6bafc2c3e2797b2835a9a6c0d85aa43c/install/yamls/ccruntime-peer-pods.yaml#L8
be changed also?

Good question, and I'm probably showing my ignorance in operators here, but when I looked at this, I decided not to change it as I didn't think that the runtimeName field being used here was the same as the runtimeClassName we use for the pods. I had a look in the coco operator and this runtimeName of kata was still being used in the peer-pod version of ccruntime, which is what I'm trying to replicate with our fork.
That's why I decided to try it out without this change and it worked, so I figured I'd leave it. That being said I'm not at all an expert, so if you think it needs changing then I'm happy to try it out. Thanks!

@stevenhorsman sorry maybe i missed something, shouldn't
https://github.com/confidential-containers/cloud-api-adaptor/blob/0a3040aa6bafc2c3e2797b2835a9a6c0d85aa43c/install/yamls/ccruntime-peer-pods.yaml#L8
be changed also?

Good question, and I'm probably showing my ignorance in operators here, but when I looked at this, I decided not to change it as I didn't think that the runtimeName field being used here was the same as the runtimeClassName we use for the pods. I had a look in the coco operator and this runtimeName of kata was still being used in the peer-pod version of ccruntime, which is what I'm trying to replicate with our fork.
That's why I decided to try it out without this change and it worked, so I figured I'd leave it. That being said I'm not at all an expert, so if you think it needs changing then I'm happy to try it out. Thanks!

Since the runtimeName is still Kata it shouldn't be changed.


Fix some issues in bash autocompletion

What type of PR is this?

bug

What this PR does / why we need it:
With current version of autocomplete script, shell quotes gets expanded incorrectly
Consider the following example:
my-cli --url http://localhost:8000 he (pressing tab should auto-complete to help, but it doesn't)
Why doesn't it auto-complete?
Because it calls the following command:
my-cli --url http : //localhost : 8000 --generate-bash-completion
And if we put it in quotes my-cli --url "http://localhost:8000" he
It calls:
my-cli --url '"http://localhost:8000"' --generate-bash-completion
Both fail, so CLI fails to call correct URL and return a list of completions.
With this PR it sends correct data
Actually I am not sure if that's the best solution, I checked how cobra does this and converted to our use case
It looks like the _init_completion function does all the magic and makes it work, I don't understand why unfortunately
P.S. I hope it'll be backported to 2.x series too (:
Testing
I tested multiple cases, i.e. sending one positional argument, 2 of them, or argument + flag, the CLI receives same arguments as before, but now more cases work
Release Notes
Fixed shell expansion in bash autocompletion scripts

@MrNaif2018 Can you add a test case(s) for this ? I will attempt to backport to v2.x after that. Thanks

Sure! Could you guide me where to check? Because bash behavior I tested was via tab, so not sure how to test it non-interactively

@MrNaif2018 You could use this test as a starting point. You can either add additional cases for this test or add a new test
https://github.com/urfave/cli/blob/f9831417f33ad87e175dd44abbd91ce13840b2ee/help_test.go#L1177

@dearchap I've added a simple test, but the issue is, it won't catch the bug anyway :D
No go-based code can catch the bug
The library is parsing and doing everything correctly, just that the bundled bash autocomplete script did something wrong, which caused arguments to be transformed wrong, hence by default bash parsing rules, go cli couldn't parse arguments correctly (because they were passed so)

@MrNaif2018 Just to confirm you want to merge this in v2 or v3 ?

I am currently using v2 version, so I would like if it would land in v2 too. v3 probably needs this too if it uses same setup

@MrNaif2018 Can you re-submit a PR for v2 ? I will merge this into main for now

Is it v2-maint?

Yes

#1676


[SPARK-49335][BUILD] Upgrade Maven to 3.9.9

What changes were proposed in this pull request?
This PR aims to upgrade Maven to 3.9.9.
Why are the changes needed?
Release Note:

https://maven.apache.org/docs/3.9.9/release-notes.html

Notable improvements in area of memory usage arrives with Resolver 1.2.22.

Bug Fixes:

MNG-8159 - Fix search for topDirectory when using -f / --file for Maven 3.9.x
MNG-8165 - Maven does not find extensions for -f when current dir is root
MNG-8177 - Warning "'dependencyManagement.dependencies.dependency.systemPath' for com.sun:tools:jar refers to a non-existing file C:\Temp\jdk-11.0.23..\lib\tools.jar"
MNG-8178 - Profile activation based on OS properties is broken for "mvn site"
MNG-8180 - Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
MNG-8182 - Missing or mismatching Trusted Checksum for some artifacts is not properly reported
MNG-8188 - [REGRESSION] Property not resolved in profile pluginManagement

Does this PR introduce any user-facing change?
No.
How was this patch tested?
Pass the CIs.
Was this patch authored or co-authored using generative AI tooling?
No.

Test first

Thanks @dongjoon-hyun


500 Error When Creating New Repository

Description
I run gitea on a local machine. Today I updated gitea to the latest version. When I created new repository, gitea return this page

Gitea Version
Gitea version 1.19.3
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
arch linux
How are you running Gitea?
I installed gitea with sudo pacman -S gitea. I run gitea with systemctl.
Database
PostgreSQL

Could you please provide some logs?

https://docs.gitea.io/en-us/seek-help/

I uninstalled and installed it again and it works now. It might be some configuration things.


Fix Sky News app

Description
The API I was using has (sort of) closed so I'm now self-hosting the XML-to-JSON script.
Copilot

🤖 Generated by Copilot at 05ea439
Summary
🔄🆗📰

Fixed the Sky News app by changing the XML-to-JSON converter service URL in skynews.star. This restores the functionality of fetching and displaying the news headlines.

URL changes
XML-to-JSON converter
Fall of old service

Walkthrough

Update the XML-to-JSON converter service URL to fix the Sky News RSS feed parsing (link)

@meejle - have you thought about using the RSS feed direct instead?  that's what I am doing for the Fox/CNN/FinTimes/Guardian/Wall Street Journal apps.    I had similar problems where the APIs were getting dinged, changed, etc - but those RSS feeds were working just great & consistent (even when Guardian had their hack, their API went down - but RSS kept going).    Just my 2 cents.

@meejle - have you thought about using the RSS feed direct instead?

I... don't know how to do that 🙈 But I'll have a look at your apps later and see if I can figure it out, thanks.
This was only really meant as a stopgap tbh, I hate to have a dead app in the 'store' haha.

here's the code I use.  call the RSS feed direct via the URL   and then parse it:
`def get_cacheable_data(url, articlecount):
key = url
data = cache.get(key)
articles = []
if data == None:
    res = http.get(RSS_STUB.format(url))
    if res.status_code != 200:
        fail("request to %s failed with status code: %d - %s" % (url, res.status_code, res.body()))
    data = res.body()
    cache.set(key, data, ttl_seconds = CACHE_TTL_SECONDS)

data_xml = xpath.loads(data)

for i in range(1, articlecount + 1):
    title_query = "//item[{}]/title".format(str(i))
    desc_query = "//item[{}]/description".format(str(i))
    articles.append((data_xml.query(title_query), str(data_xml.query(desc_query)).replace("None", "")))

return articles`


Failed to get destination ERROR

Issue Description
Hello,
I'am trying to reach a destination by using the DestinationAccessor api of the java cloud sdk library but I'am facing the following error
2024-07-17T12:52:54.485+0000 [APP/PROC/WEB/0] STDOUT 2024-07-17T12:52:54.485Z  INFO 7 --- [nio-8080-exec-8] c.e.s.ServiceGetCredential               : ServiceGetCredential::getSolCredentialProtect - Name Destination Credential Store PLTS005_CRED_STORE
2024-07-17T12:52:54.487+0000 [APP/PROC/WEB/0] STDOUT 2024-07-17T12:52:54.487Z  INFO 7 --- [nio-8080-exec-8] c.s.c.s.c.c.DestinationAccessor          : Creating a new DestinationLoaderChain with EnvVarDestinationLoader as the primary DestinationLoader implementation.
2024-07-17T12:52:54.503+0000 [APP/PROC/WEB/0] STDOUT 2024-07-17T12:52:54.503Z  INFO 7 --- [nio-8080-exec-8] c.s.c.s.c.c.DestinationAccessor          : Using an instance of ScpCfDestinationLoader as the secondary DestinationLoader implementation.
2024-07-17T12:52:54.602+0000 [APP/PROC/WEB/0] STDOUT 2024-07-17T12:52:54.602Z ERROR 7 --- [nio-8080-exec-8] c.e.s.ServiceGetCredential               : Failed to get destination with name 'PLTS005_CRED_STORE'.
in attachment you can find the code snippet and the definition of the destination.
Failed to get destination ERROR.docx

Hi @Ind791,
Can you also attach the stack trace from your application to see what is the cause of the issue?
Please also attach your maven dependency tree.
Regards,
Kavitha

Hi @KavithaSiva,
Here in attachment are the requested files.
Regards,
Nauzet
Maven dependency tree.txt
Stack Trace.txt

Hi @Naucana,
There seems to be a mix-up of XSUAA v2 and v3 artifacts in your dependency tree(artifacts in groupId com.sap.cloud.security).
Please manage your XSUAA dependency versions by using com.sap.cloud.security:java-bom(v3.3.1) in your dependency management section. This should hopefully solve the issue.
Also, please note that we no longer provide support for version 4  of the SAP Cloud SDK, please update to version 5.
Regards,
Kavitha

Hi @KavithaSiva,
This solution works for us.
Can you proceed to close this issue?
Thank you so much for the support.
Regars,
Nauzet

Hi @Naucana,
Good to know that the issue is resolved now.


Provide exported key with encryption

Prerequisite to https://github.com/MetaMask/KeyringController/pull/152
Provides the key in string format so it may be used to unlock.
Supercedes https://github.com/MetaMask/browser-passworder/pull/20

@Gudahtt Should I rename createKeyFromString to importKey?  Seems like it might make sense.

That would make sense to me!
Personally I think of this more as serialization/deserialization than import/export, but, import/export is fine and matches the crypto API.


WIP: Reduce the amount of bootstrap async methods

Motivation
When adding new async methods for all the bootstrap we had to create 3 sets of method for every bootstrap. This resulted in lots of code and only provided little benefit for users.
Modification
This PR removes all bind/connect methods except the most generic ones. This leaves it up to the user to wrap their channels in a NIOAsyncChannel or to await the protocol negotiation result.
Result
Less code to maintain on our side.

5.9 is a known allocation regression
Nightly is a known crash
API breakage is also expected

@Lukasa Could you merge this over the failing API breakage CI please


Initialise Message Without Populating all Fields

I'm using prost as a dependency on tower-grpc, but I'm struggling as I was using another protobuf implementation.
I have a protobuf message that has a lot of fields, and prost requires me to initialise all of them when creating the message. Is there an equivalent of Message::new() that would set default values? Sometimes I only want to set 1-2 fields out of a message that has much more, but it's so far cumbersome.
I'm using proto3 btw.

Thanks @per-gron, what does the ..Default::default() magic do?
So then if I want an 'empty' message, can I do the below?
let mut message = myproto::Message {
  ..Default::default()
}

It's not all that magic: it's a combination of the .. struct update syntax and the Default trait.
The syntax you used in the previous comment should work, but you can also use only Default without struct update syntax:
let mut message : myproto::Message = Default::default();

if you just want a default value.


Option to force cache regardless of Cache-Control headers?

I tried setting mode to ForceCache, and playing around with `options -- to no avail. Is this simply not implemented?

ForceCache should return the object from cache should it exists, ignoring staleness, but return a network error should the object not exist.
What is the behavior you are experiencing?

After checking more into this I did find I needed to adjust the test for the ForceCache mode to make sure the cached object would be stale upon retrieval from cache (https://github.com/06chaynes/http-cache/commit/994cd41ebd67cf82ea3064809b9ffe2514389760), the test did pass though so things should be working as expected for that mode.

i believe what he's looking for is a way to ignore the cache headers and just always cache the result of a request for a duration....  basically
            && self.mode != CacheMode::NoStore
            && self.mode != CacheMode::Reload;```

an escape hash for this like

```let is_cacheable = self.mode == CacheMode::AlwaysCache || (middleware.is_method_get_head()
            && self.mode != CacheMode::NoStore
            && self.mode != CacheMode::Reload);```

which i don't think is possible currently?

@cchance27
She/her please, but yes, I recall having trouble with this. For the project I was working on, I ended up refactoring to use my own crude content-addressable cache logic in that project, but I can probably still dig up the experimental branch if need be.

@alxpettit sorry fixed :) Would have been cool to PR that in, if this projects accepting PRs or is active still. As I can definitely see the usefulness of an option like that, for instance i call out to an API and the http-cache tags are irrelevant to me as I don't really need more than 1 update per 24 hours, so being able to just say set my own TTL as an override, would be so much better.

It's something I can look into on my free time (if that ever becomes a thing again), but I absolutely would be happy to consider any PRs to the project.

Welcoming any thoughts on what I've worked out so far on this matter. I have a branch with the changes made here if interested https://github.com/06chaynes/http-cache/blob/ignore-rules/http-cache/src/lib.rs#L294
Right now this adds a new variant to CacheMode called IgnoreRules. This should ignore the the checks that determine if a response can be cached (other than being a 200 status) and the check that determine staleness. This will assume that you are managing the expiry of the cache record somewhere else (such as the options for the cache manager you are using if provided or by interfacing with the cache in a more direct manner).

@cchance27 @alxpettit forgot to tag, curious if you have any input on this new mode before merging to develop.

Sorry been bit busy with work, a cursory look I think it meets what I was expect originally to be supported, leaving the TTL to the backend for the storage makes sense i think, i'll try to find time to play with it but i don't see any reason it shouldn't be mergeable as doesn't appear to break any of the original workflows you were originally handling, and does give us that option to override the is_cacheable checking on 200 returns, which is great.

@06chaynes Seems reasonable :)

Just merged this change into develop, it'll be part of the next release once I have a chance to finish a few other changes up. Thanks again!

Thanks for implementing the suggestion! :D

Also added a docs page for the cache modes to hopefully explain them a bit better
https://http-cache.rs/book/cache-modes.html