Set up CI

It would be really great to someday set up CI using GitHub Actions. Ideally, this would let us run our entire test suite on every PR to make sure we don't break anything.
The one tricky thing about this will be getting odgi set up. We could use our existing Dockerfile for that—perhaps more reasonably—we could just run odgi from the official Docker image. That is, it may be as simple as using docker run pangenome/odgi in place of odgi, or whatever the Actions-endorsed equivalent is for bringing in a tool from a published Docker image.

Love it; will explore!

I've taken a tiny step towards this by adding a formatting-checker for all our Python code. #87, which presently open, passes this. A more serious CI is coming up!

So I think odgi is indeed going to be the big hurdle, and I think using their Docker is not quite going to work. I'd like to show you my thrashing just to make sure I'm correct in dismissing this approach. Please let me know if I missed something!!
$ # The following won't work
$ docker pull pangenome/odgi
Using default tag: latest
Error response from daemon: manifest for pangenome/odgi:latest not found: manifest unknown: manifest unknown

$ # We actually need to get it from quay, as described here:
$ # https://odgi.readthedocs.io/en/latest/rst/installation.html#docker
$ docker pull quay.io/biocontainers/odgi:0.8.2--py38h3b68952_0
0.8.2--py38h3b68952_0: Pulling from biocontainers/odgi
Digest: sha256:1f77a96eb368331805a01856c0c9432f872033e869b9e2d19de2aa17bc12f760
Status: Image is up to date for quay.io/biocontainers/odgi:0.8.2--py38h3b68952_0
quay.io/biocontainers/odgi:0.8.2--py38h3b68952_0

$ # Now the following should work, but doesn't
$ docker run quay.io/biocontainers/odgi
Unable to find image 'quay.io/biocontainers/odgi:latest' locally
docker: Error response from daemon: manifest for quay.io/biocontainers/odgi:latest not found: manifest unknown: manifest unknown.
See 'docker run --help'.

$ # This works; it needs the tag
$ docker run quay.io/biocontainers/odgi:0.8.2--py38h3b68952_0 odgi
odgi: optimized dynamic genome/graph implementation, version v0.8.2-0-g8715c55

usage: odgi <command> [options]

Overview of available commands:
  -- bin           Binning of pangenome sequence and path information in the graph.
  -- break         Break cycles in the graph and drop its paths.
  ...

$ # But actually passing it a graph is another story. I have test/k.gfa locally.
$ docker run quay.io/biocontainers/odgi:0.8.2--py38h3b68952_0 odgi depth -i test/k.gfa
[odgi::depth] error: the given file "test/k.gfa" does not exist. Please specify an existing input file in ODGI format via -i=[FILE], --idx=[FILE].
$ # I think this is because the container doesn't have access to the local filesystem.

# To make this work, we need to mount the local directory into the Docker container...
# ...and at that point I'm not sure why we're using the odgi Docker at all.
# We could just get GitHub Actions to install it and run it directly.

When we did up our Dockerfile, we figured out a log of the gunk re: installing ODGI and getting it added to the paths etc such that (1) odgi on the command line and (2) import odgi in a Python shell both work.
I am now thinking of just getting Github Actions to, at every PR:

build the Pollen image using Dockerfile; this includes the latest commit to odgi's main branch
run our tests in that Docker container
If successful, publish our Docker container to Dockerhub.

Thoughts? :)

Update after meeting: this is probably possible, but too slow and annoying.
Try the mounting-of-volumes thing (which I whined about here) instead!

Indeed! Here's something that works with volumes, FWIW:
docker run --rm -v `pwd`/test:/test quay.io/biocontainers/odgi:0.8.2--py38h3b68952_0 odgi depth -i /test/basic/ex1.gfa

Annoying that there is not a latest tag on the Docker registry so we have to use stuff like 0.8.2--py38h3b68952_0. It's also kinda worrisome that the latest build there seems to be from 5 months ago. But maybe that's OK?

The other option is to run all our stuff inside a Docker container based on the odgi one. GitHub Actions can apparently start within a container, so we could plausibly make the whole test job run with container: quay.io/biocontainers/odgi:0.8.2--py38h3b68952_0. Could be silly in its own way, but it could also work?

Sorry to have gotten behind on this, but I am looking at this with fresh eyes and here's my resolution for what to try next:

the latest Pollen code (from the branch being PR'ed)
Calyx from cargo
odgi from its quay container (using the volume trick Adrian shows above)

There are risks inherent to using static versions of Calyx and odgi, and the odgi risk is bigger still because we can't just do up a new release ourselves, but this setup will basically get us going.

Yes, sounds great. My hope is that odgi changes pretty slowly so it won't matter, and our use of Calyx will evolve only when we're aware that it does, so it won't be too hard to bump those dependencies manually.


Add a run_constrained for starlette to starlette-base

Fixes https://github.com/conda-forge/fastapi-feedstock/issues/43
Fixes https://github.com/conda-forge/starlette-feedstock/issues/57
cc @conda-forge/starlette

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

LGTM! Can you post a section of the diff before we merge?

LGTM! Can you post a section of the diff before we merge?

Downloading: https://conda.anaconda.org/conda-forge/noarch/repodata_from_packages.json.bz2
Downloading: https://conda.anaconda.org/conda-forge/noarch/repodata.json.bz2
noarch::starlette-base-0.13.5-py_2.tar.bz2
-  "version": "0.13.5"
+  "version": "0.13.5",
+  "constrains": [
+    "starlette 0.13.5"
+  ]
noarch::starlette-base-0.13.6-py_0.tar.bz2
-  "version": "0.13.6"
+  "version": "0.13.6",
+  "constrains": [
+    "starlette 0.13.6"
+  ]

Downloading: https://conda.anaconda.org/conda-forge/noarch/repodata_from_packages.json.bz2
Downloading: https://conda.anaconda.org/conda-forge/noarch/repodata.json.bz2
noarch::starlette-base-0.13.5-py_2.tar.bz2
-  "version": "0.13.5"
+  "version": "0.13.5",
+  "constrains": [
+    "starlette 0.13.5"
+  ]
noarch::starlette-base-0.13.6-py_0.tar.bz2
-  "version": "0.13.6"
+  "version": "0.13.6",
+  "constrains": [
+    "starlette 0.13.6"
+  ]


As a registered user, I want to be able to view other people’s posts on the explore page so that I can know how’s they going and not miss anything important

Estimate
medium
Acceptance Criteria
Feature: view other people’s posts
  As a registered user, I want to be able to view other people’s posts so that I can know how’s they going and not miss anything important

Scenario: Successfully view other people’s existing posts
  Given I am a registered user
  When I log in the Microblog
  And I navigate to the explore tab
  Then other people’s posts should be displayed in the page
  And they are displayed as newest at the top

moved this from In Review to Done


functions_miray_cengil.py

Describe your changes
Checklist

[ ] I have read the [CONTRIBUTING]
[ ] I have performed a self-review of my own code
[ ] I have run the code locally and it works as expected
[ ] I have commented my code, particularly in hard-to-understand areas

Screenshots (if appropriate)

I hope it's complete this time. :'(


DON-768: Refactor: Change language from Donation Credits to Donation …

…Funds

Codecov Report
Patch and project coverage have no change.

Comparison is base (7820c80) 76.42% compared to head (b75acc7) 76.42%.

Additional details and impacted files
@@            Coverage Diff             @@
##             develop      #91   +/-   ##
==========================================
  Coverage      76.42%   76.42%
  Complexity       203      203
==========================================
  Files             33       33
  Lines            615      615
==========================================
  Hits             470      470
  Misses           145      145

Impacted Files
Coverage Δ

.../Actions/GetDonatinonFundsTransferInstructions.php
90.90% <ø> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Update Credit_Card_Validator.py

Add fix for Maestro Card

Thank you for you contribution to the repo and the community


virus detected

it was working fine yesterday, today virus detected

YEA THERE ACUALLY IS A VIRUS LMAOOOOOOOOOOOOOO FACTSSSSS BROOOOO
HE IS TRYING TO GIVE US A VIRUS!!!!!
DONT DOWNLOAD LATETEST RELEASE

lmao where


Refactors and generic Item Page

Refactored use of StyleSheet to Styled-Components in TabBarIcon component
Refactored App component (see comments)
Introduced Theme component. This uses the ThemeProvider from Styled-Components. (see comment in Theme)
This also makes the colors and layout constants obsolete
Added reusable Items page. We can now use this page for every Item time by passing the right props which will then retrieve the right data from backend. This way we don't have to create a separate page for each category.
Added LoadingIndicator component for showing a loader when data is being fetched.

Messed up some commits. Will recreate when fixed

I forgot to set upstream branch :| Half of my commits are already merged in last PR. This one can be reviewed


Support both Java8 and Java11

We need to design a mechanism for Java-based runtimes to choose their base version - s2i builder of JDK7 or 8.
First blush, we could surface this as an option when choosing the runtime as a dropdown just like the user may select the version of the runtime itself.  A UX issue for us to work through.
This request has come from the business and is tracked there as https://issues.jboss.org/browse/RHOAR-102
Let's use this issue to detail how we accomplish and deliver this in the launcher upstream, leaving JIRA for business/PM tracking.

@gastaldi, we were tracking this issue as a dependency for Launcher to support RHEL 8.  Is that accurate?

@rdruss not necessarily, but good to have :smiley:


[CI] Prevent writing minor version file when release build is performed

Description of changes:
Prevent writing minor version file when release build is performed
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Job PR-890-2 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-890/2/index.html

Job PR-890-2 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-890/2/index.html


Authentication

As user I want to be able to authenticate with my github account to be able to create new questions and answer to existing questions.

Check passport or another authectication component.
The authentication should be client side.


can't build?

Any recommendations?
Using Gentoo Linux 5.10.27; GCC 10.3.0
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/src/mod_pagespeed/psol/lib/Release/linux/x64/pagespeed_automatic.a(107.signals.o.o): in function pagespeed_ol_apr_signal_description_get': signals.c:(.text.apr_signal_description_get+0xe): undefined reference to sys_siglist'
collect2: error: ld returned 1 exit status
make[1]: *** [objs/Makefile:276: objs/nginx] Error 1
make[1]: Leaving directory '/var/tmp/portage/www-servers/nginx-1.21.0/work/nginx-1.21.0'
make: *** [Makefile:10: build] Error 2

As already outlined in bug #1717 ,
it's impossible to build on any recent OS if GLIBC >= 2.32
OS and GCC versions don't really matter.
As outlined among the major features of GLIBC 2.32:

The deprecated arrays sys_siglist, _sys_siglist, and sys_sigabbrev
are no longer available to newly linked binaries, and their declarations
have been removed from <string.h>.  They are exported solely as
compatibility symbols to support old binaries.  All programs should use
strsignal instead.

As already outlined in bug #1717 ,
the building phase works just fine even on GCC >= 10 if GLIBC < 2.32 (that's the case of Fedora 32 as outlined by the former bug reporter; only Fedora 33 switched to GLIBC >= 2.32)
PSOL needs to be fixed in order to be compliant with GLIBC >= 2.32; until then, it's going to be impossible to build pagespeed on any OS shipping a GLIBC released in the last 11 months.

The problem for good solution is that I just can't build PSOL for ngx with mod_pagespeed later than commit #409bd76 (after this one the bazel-build was implemented)
https://github.com/apache/incubator-pagespeed-mod/issues/2069

Thanks @acachy.  I put sed in my deployment script and I managed to compile the latest-stable branch on Ubuntu Hirsute (21.04)

Cannot build on latest debian stable (11 bulseye) and unless this is fixed it won't build on the next Ubuntu LTS either

Cannot build on latest debian stable (11 bulseye) and unless this is fixed it won't build on the next Ubuntu LTS either

This

sed -i -r 's/sys_siglist[signum]/strsignal(signum)/g' third_party/apr/src/threadproc/unix/signals.c
does the trick on at least ubuntu 21.04 (rolling) and 21.10 (devel)

https://github.com/apache/incubator-pagespeed-ngx/issues/1717#issuecomment-1229360950
also in NixOS stable.
nix error: building nix env: exit status 100
Output has been trimmed to the last 20 lines
/nix/store/rq6bh3qfrqnyqwik0w3q6w180zg3w2pa-binutils-2.38/bin/ld: warning: libssl.so.1.1, needed by /nix/store/2ksd6iaqmqk3q53jd2j01z7k1f3i8kl7-srt-1.4.4/lib64/libsrt.so.1.4, may conflict with libssl.so.3
/nix/store/rq6bh3qfrqnyqwik0w3q6w180zg3w2pa-binutils-2.38/bin/ld: warning: libcrypto.so.1.1, needed by /nix/store/2ksd6iaqmqk3q53jd2j01z7k1f3i8kl7-srt-1.4.4/lib64/libsrt.so.1.4, may conflict with libcrypto.so.3
/nix/store/rq6bh3qfrqnyqwik0w3q6w180zg3w2pa-binutils-2.38/bin/ld: warning: libcrypto.so.1.1, needed by /nix/store/2ksd6iaqmqk3q53jd2j01z7k1f3i8kl7-srt-1.4.4/lib64/libsrt.so.1.4, may conflict with libcrypto.so.3
/nix/store/rq6bh3qfrqnyqwik0w3q6w180zg3w2pa-binutils-2.38/bin/ld: /nix/store/dgg4ycikp5wmln9jvg4dx6hp245am2mw-ngx_pagespeed/psol/lib/Release/linux/x64/pagespeed_automatic.a(107.signals.o.o): in function `pagespeed_ol_apr_signal_description_get':
signals.c:(.text.apr_signal_description_get+0xe): undefined reference to `sys_siglist'
/nix/store/rq6bh3qfrqnyqwik0w3q6w180zg3w2pa-binutils-2.38/bin/ld: /nix/store/dgg4ycikp5wmln9jvg4dx6hp245am2mw-ngx_pagespeed/psol/lib/Release/linux/x64/pagespeed_automatic.a(107.proc_mutex.o.o): in function `proc_mutex_pthread_tryacquire':
proc_mutex.c:(.text.proc_mutex_pthread_tryacquire+0x3c): undefined reference to `pthread_mutex_consistent_np'
/nix/store/rq6bh3qfrqnyqwik0w3q6w180zg3w2pa-binutils-2.38/bin/ld: /nix/store/dgg4ycikp5wmln9jvg4dx6hp245am2mw-ngx_pagespeed/psol/lib/Release/linux/x64/pagespeed_automatic.a(107.proc_mutex.o.o): in function `proc_mutex_pthread_acquire':
proc_mutex.c:(.text.proc_mutex_pthread_acquire+0x2c): undefined reference to `pthread_mutex_consistent_np'
/nix/store/rq6bh3qfrqnyqwik0w3q6w180zg3w2pa-binutils-2.38/bin/ld: /nix/store/dgg4ycikp5wmln9jvg4dx6hp245am2mw-ngx_pagespeed/psol/lib/Release/linux/x64/pagespeed_automatic.a(107.proc_mutex.o.o): in function `proc_mutex_pthread_create':
proc_mutex.c:(.text.proc_mutex_pthread_create+0xac): undefined reference to `pthread_mutexattr_setrobust_np'
/nix/store/rq6bh3qfrqnyqwik0w3q6w180zg3w2pa-binutils-2.38/bin/ld: /nix/store/dgg4ycikp5wmln9jvg4dx6hp245am2mw-ngx_pagespeed/psol/lib/Release/linux/x64/pagespeed_automatic.a(107.thread.o.o): in function `pagespeed_ol_apr_thread_yield':
thread.c:(.text.apr_thread_yield+0x1): undefined reference to `pthread_yield'
collect2: error: ld returned 1 exit status
make[1]: *** [objs/Makefile:468: objs/nginx] Error 1
make[1]: Leaving directory '/tmp/nix-build-nginx-1.22.0.drv-0/nginx-1.22.0'
make: *** [Makefile:10: build] Error 2
builder for '/nix/store/y0zhgn8q7bslw1mjqrlaw0zcq6yrj5jh-nginx-1.22.0.drv' failed with exit code 2
error: build of '/nix/store/y0zhgn8q7bslw1mjqrlaw0zcq6yrj5jh-nginx-1.22.0.drv' failed


Reword the call out message for giving back in PR #5308

This is in regards to PR #5308.
I really feel the tone of the message is not the best, and after much thought concluded that it's because the message singles out profitable companies/individuals. To me the tone is kind of like "if you're making money, pay up". I'm sure this is not the sentiment of the team, and it's more of an appeal to those who can afford it to help us cover the costs, so let's phrase it that way and leave it open for the individuals to decide if they can afford it.
Here are some alternative messages we can use:

Bundler and RubyGems.org are currently free for everyone to use, but maintaining them costs more than $20,000 USD every month. Help us cover those costs so we can keep the gem ecosystem free for everyone: https://rubytogether.org/join

We need your help. It costs Ruby Together more than US$20,000 per month to maintain Bundler and RubyGems.org. Help us cover the costs by joining for as little as US$10/month at https://rubytogether.org/join and let's keep the gem ecosystem free for everyone.

Bundler and RubyGems.org are currently free for everyone to use, but maintaining them costs more than $20,000 USD every month. Help us cover those costs so we can keep the gem ecosystem free for everyone by joining for as little as US$10, see: https://rubytogether.org/join

Please help Ruby Together keep the gem ecosystem free for everyone because it costs more than US$20,000 a month to maintain Bundler and RubyGems.org. You can help for as little as US$10 by joining at https://rubytogether.org/join

Feel free to change it as desired but avoid singling out a group and let's try to keep a friendly "need help" tone. If we can think of a stronger benefit than simply keeping the gem ecosystem free, that would be good. Also, would be good to track the url leads so when we try different messages, we can see conversions.
I appreciate you reconsidering the message, @indirect, @segiddins. 😃

@hmistry ahh, I see what you're saying. Far from trying to call out profitable companies, I included that because I often need to ask people to not give money unless they are making money using Ruby. Devs who feel good about Ruby get very concerned and start offering money, even if they are only casual users or are otherwise not making a profit. What we want is for profitable devs and companies to give back to the community, so that devs and companies that are bootstrapping, or teaching, or just doing it for fun, can all use the same tools for free.
My goal with that wording was to clarify that we are not looking for money from casual users, but we are looking for money from those using Ruby to make a profit. Can you update your suggestions to include that point?

@indirect Ok so that makes this more complicated. Here are some quick thoughts:
If you want to reach out to profitable businesses, then I'd say this is the wrong place to do it. A direct email campaign would be a better approach. For a message in bundler, one thought is we have a broader message to evangelize the dev's to talk to their businesses to help us... think of this as lead generation and the landing page on rubytogether.org/join can go in more details.
I wouldn't worry about profitability requirement because I think that's what turns the message negative, and it's automatically taken care of by what people can afford. For the 1 out of 10 that are not profitable and still want to support us, well these people who are serious do-gooders and it makes them happy to do it. Refusing them makes them unhappy and we steer them to some other org's, so let's not close that door because they will be even bigger supporters when they do turn a profit.
I'll think about how we can change the message, and I'll talk to you offline because I have some questions and need to understand your angle better.

Agree this seems like to wrong place to do it.
This post install message would have the opposite effect to me. Because it is annoying, I'd not contribute to the project.

@rafaelfranca if the companies that use ~$40k/mo worth of servers and ~$20k/mo worth of dev time had agreed to join when we reached out to them directly, we wouldn't be adding this message. But almost all of those companies told us they weren't interested in helping keep RubyGems running, so here we are.
@hmistry I'll tweak the wording to remove references to profitability so that we can ship something that isn't contentious. Later on maybe we can get a version that's been tuned by the marketing team. 👍

@indirect I'm happy with that. Thank you for reconsidering.

@indirect Posting here so we can refer back in future.
Here are more messages that ask for companies (or call it businesses) instead of individuals. From a marketing perspective, this is going to be mostly an awareness campaign to developers. I wouldn't expect any strong leads from it because it's not the business decision makers that will be seeing this message.  If you want to make this more effective, you'd want to create a different landing page that's tailored to helping these developers presenting a good case to the company decision makers... more work, I know but that's how to make it more effective.
Messages:
Bundler and RubyGems.org are free for anyone to use, but maintaining them costs more than $20,000 USD every month. We are looking for company sponsorships to help us cover those costs so we can keep the gem ecosystem free for everyone: https://rubytogether.org/join
We need your help. It costs Ruby Together a minimum of US$20,000 per month to maintain Bundler and RubyGems.org. Ask your company if they would like to help us cover the costs by joining for as little as $50/month at https://rubytogether.org/join and let's keep the gem ecosystem free for everyone.
We need your help. It costs Ruby Together a minimum of US$20,000 per month to maintain Bundler and RubyGems.org. We are looking for companies to help us cover the costs by joining for as little as $50/month at https://rubytogether.org/join. Let's keep the gem ecosystem alive and free for everyone so we can all benefit from open source gems.

I realize this is closed, but speaking as a consultant, I've seen at least two companies in Chicago literally drop plans for using Ruby (mainly for their test ecosystem, not so much for core development) because of these messages.
The concern was that RubyGems and Bundler are "in trouble" or eventually will be.
I'm just throwing this out there as an (admittedly very limited) data point. But I'm also hearing more talk of this in various test forums as well, where testers are being asked to move to "healthier" ecosystems, like JavaScript or Python and, at least if what I'm being told is accurate, it's due to the perception of "trouble" and a perception that parts of the ecosystem may "stop working" if money doesn't roll in.

@jeffnyman it's a tough conundrum. If we don't tell people that it's expensive to run the service, no one will help fund it, and it will collapse. If we do tell people it's expensive to run the service, lots of people will help fund it, and we'll be fine.
A small amount of research into the ecosystems around these languages would go a long way, I think. Ruby Together is funded well enough to sustain the RubyGems ecosystem right now... the reason we're talking about this is because it is still growing, quickly. Python, on the other hand, has publicly discussed how they don't actively have anyone taking care of this problem in their ecosystem, even though the problem is present there as well. As for JavaScript, maybe you should suggest that your clients check out the many millions of dollars that NPM has raised, and their recent round of layoffs.
Ultimately, we can't make everybody happy. We may be able to word the message in a less alarming way, but I think that message is the best chance we have of escaping the situation that Ruby and Python and JavaScript are all trapped in, in the long run.


[FLINK-5552][runtime] make JMXServer static per JVM

What is the purpose of the change
This is the first step to allow JMXServer information being returned via REST API.
After we have the JMXServer available in each JVM, we could poke and retrieve the JMX server URL via REST API.
Brief change log

Moved JMXServer from JMXReporter private class into flink-runtime.
Added new configuration option jmx.server.port to allow configuration of the jmx server.
Launch JMXServer at start of each JMV entry (ClusterEntrypoint & TaskManagerRunner)

Verifying this change
This change is already covered by existing tests, such as

flink-runtime/tests
flink-metrics-reporter-jmx/tests/

This change added tests and can be verified as follows:

JMXReporterTests checks that there's only one singleton JMXServer being created across multiple JMXReporter.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): yes
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? yes
If yes, how is the feature documented? docs

I was not able to reproduce this exception locally but it seems to happen in Travis for the flink-metrics-jmx consistently.
[ERROR] testJMXAvailability(org.apache.flink.metrics.jmx.JMXReporterTest)  Time elapsed: 0.159 s  <<< ERROR!
java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root exception is java.rmi.NoSuchObjectException: no such object in table]
	at org.apache.flink.metrics.jmx.JMXReporterTest.testJMXAvailability(JMXReporterTest.java:194)

Azure seems to pass just fine. any suggestions is highly appreciated.

Note that due to some security concerns (about which I cannot go into more detail at the moment) we will have to delay the merge of this PR for the time being.

Officially unblocked now that CVE-2020-1960 was published. This will need a rebase now since the JMX logic has changed.

Thanks @zentol .. I will start rebasing my changes.

I just rebased and incorporated changes in FLINK-16697 into the static JMXServer. please kindly take another look @zentol .  -- Thanks, Rong


Fix media merge with variants and compound variants

Check after #31 , #32.
I fixed media properties can be used with variants and compound variants styles.
I removed These code, because it's been ever ignored and not worked due to key format is used  instead of @key. Now media properties must be kept as media variants style work.
I add new examples of this features.

Thank you for these PRs! On a quick glance they look very good 👍🏻 I'll try to find some time to review and test them locally 🙂
It looks like these three PRs build on top of each other so I'm wondering if it would be easier for me to review just the latest PR that contains all the fixes 🤔 They are all related to responsive styles so it wouldn't be too bad to review all the fixes as one big PR.
Is it okay to you if I just review and test this PR and close the other two?

@Temzasse

Is it okay to you if I just review and test this PR and close the other two?

Yes, of course.
Thank you for reaction and taking your time.

Thank you for setting up the Expo Web support in the example app! 🙌🏻
I noticed that running the example app in iOS Simulator doesn't seem to be working anymore because it's not able to resolve stitches-native. I think it's very nice to be able to test the lib in a web browser but the main target of this lib is native app development so it's very important to be able to test the app inside iOS/Android simulator.
I wonder why the web version is working but not the native one 🤔

Sorry for this pitfall. It may be caused by expo and react-native latest versions.
I will check  tomorrow both android and iOS simulator. Let me share if I find the reason.

I think we can have both metro and webpack configs in the example Expo app. Metro will be used for native and webpack for web. I took a look at this RN library called Zeego that has both config files in the example app. I will play around with the bundler setup today and see if I can get it to work.

Ah... . I see. I certainly removed metro.config.js. The reason is  mentioned in https://github.com/Temzasse/stitches-native/pull/31. But, you're right, we must use metro or repack as  native module bundler. Especially I don't  know whether we can use repack with expo so we should use metro. Thank you for investigation and I'll try to fix it, too.

I think I got it working with both webpack and metro. Can you give me rights to push to your PR branch?

@Temzasse Thank you, I worked just restore metro.config.js, too. If you do another way and want more fix, could you do after merging my code?

I tested and worked in our local environment like this.

@Temzasse Thank you, I worked just restore metro.config.js, too. If you do another way and want more fix, could you do after merging my code?

Sure that works too 👍🏻

@Temzasse
Sorry, let you review many times.
If you still have problems to work, I will set permission my repository.

@tkow Thank you for being patient with my many reviews 🙏🏻  After making the changes requested in my last review round I can merge this PR and fix anything else that comes up on my own 🙂

@Temzasse
Sure. Thank you for many advises.
I don't know why, but this instruction can't be applied. So, our repository public you may be able to push without any setting if you can't do so and need doing, I'll suggest another way after fix the your review points.

Sorry, for after finishing review, but I found the type problem for https://github.com/Temzasse/stitches-native/issues/34 and, example's @type/react version's not compatible with installed react. Then, I add compoundVariants example for check.
These are not so much change and essentially bug fix, thus I'll merge it to PR.

@Temzasse
In addition, I don't know why but found the bug defaultVariants combination doesn't match compoundVariants, though
the  passed props  work.
This bug may have ever been and not very serious because passing props explicitly  so, Could I ask you to get it out of scope in this PR?

@tkow thank you so much for these fixes! 👏🏻
Let's not add any more fixes outside of the media styles related bug fixes or improvements into this PR so that that I'm able to review things more efficiently.
I will try to merge this as soon as possible so that you can get these fixes from the npm instead of your git submodule 🙂


Increase the severity of several StyleCop rules

Over time, this particular project should strictly adhere to the StyleCop rules.
This pull request overrides the default severity "Warning" to be "Error" for several StyleCop rules when the analyzer runs on this project.
The following rules would become errors following this change:

SA1001: CommasMustBeSpacedCorrectly
SA1101: PrefixLocalCallsWithThis
SA1106: CodeMustNotContainEmptyStatements
SA1111: ClosingParenthesisMustBeOnLineOfOpeningParenthesis
SA1119: StatementMustNotUseUnnecessaryParenthesis
SA1300: ElementMustBeginWithUpperCaseLetter
SA1303: ConstFieldNamesMustBeginWithUpperCaseLetter
SA1304: NonPrivateReadonlyFieldsMustBeginWithUpperCaseLetter
SA1309: FieldNamesMustNotBeginWithUnderscore
SA1311: StaticReadonlyFieldsMustBeginWithUpperCaseLetter
SA1400: AccessModifierMustBeDeclared
SA1401: FieldsMustBePrivate
SA1402: FileMayOnlyContainASingleClass
SA1403: FileMayOnlyContainASingleNamespace
SA1603: DocumentationMustContainValidXml
SA1642: ConstructorSummaryDocumentationMustBeginWithStandardText
SA1643: DestructorSummaryDocumentationMustBeginWithStandardText

@pdelvo @macpak @camilojd Please review the above list to see if it includes any items which will cause maintainability problems.

Looks good to me. Would it be possible to have warnings when developing locally and having errors when doing a CI build? That way you could ignore them if you want to test something locally without having to fix all stylecop errors before you can start debugging. With them being enabled when doing a CI build we are still making sure we don't have these warnings in the main repo.

Ok, but I think we may need to fix some of the issues, especially PrefixLocalCallsWithThis (at least if it comes to me :) )

@pdelvo These items all either have fully-functional code fixes in place, or are items which the developer must go out of their way to get wrong (e.g. by adding invalid XML to a documentation comment).
@macpak There's no need to go back and edit any open pull requests for this; I can make the necessary adjustments during the merge. In the future it will be easy to keep track of this because the code fix will help you out if you forget. :+1:

Looks good to me too, most of the fixes are straightforward enough and integration with CI/build process will be really helpful :-)

Is there anything that is holding this one back? I think this can be merged in.


Add an isLoading property

That way, instead of returning a promise to the onLoadMoreAsync method, we can instead control the control mechanism with the isLoading property 😃

the promise that you return from onLoadMoreAsync is the mechanisma for telling this component whether you're currently loading data or not.

But this forces us to have such a promise. When using React with Redux, dispatch does not necessarily return a promise, but you will build props that changes (including a loading one).

We don't want to have two sources of truth or to maintain two different APIs.
If you want to hide the promise construction you could either (a) write helper that creates a promise that is resolves based on a subscription to the Redux store, (b) write a component that takes an isLoading prop and wraps this one, (c) fork this component, or some other approach I'm not thinking of.

Fair enough. Thanks for the answer.


Pre Alpha 1.2 Release Checklist - The Shape & Data Update

[ ] Add a way to generate a chunk in the constructor thread so chunks and generated in parallel.
[ ] Change regions objects in WorldData and WorldMatrix to have another nested object called columns and each column object will then have chunks.
[ ] Consider moving the heightmap to the world column and not having per-chunk ones or having an engine setting to switch between the current system and the new one.
[ ] Make a way for different voxel shapes to cull faces. For instance, have a half-box call its bottom face only if it is directly on top of a box.
[ ] Fix the problem with the voxel state data not being properly set and passed.
[ ] Upgrade the ShapeBuilder to have more options and transform vectors for creating many different types of shapes.
[ ] Add a "Face state" vertex data attribute for all meshes to control shaders. For instance, if a fluid meshes face is flipped that state should be set and the texture should be set to flow in the correct direction.
[ ] Also, correct the flora shader to create the "wind" effect only if the proper face state is set. Also have different modes for something like leaves vs vines and so on.
[ ] Add new types of shapes. Something like vines, stairs, and pillars.
[ ] Implement the shape state data.
[ ] Add a way to flip a texture. Must account for when the texture is flipped.
[ ] Implement a helper UV function to generate the correct UV data.
[ ] Add an overlay texture mode and add it to the chunk templates and the generated mesh data.
[ ] Will have to make an overlay texture for each mesh type.
[ ] Add filter options to the Queues object.
[x] Create a way to save a region and a way to load in a region.
[ ]  Create a way to save a chunk and a way to load in a chunk.

Changes

List of things that I will need to update the wiki for. Will also have to update the wiki for 1.1.
So, I changed the voxel data type definition.
It is now:
type VoxelData = {
 name: string;
 shapeId: string;
 id: string;
 substance: VoxelSubstanceType;
 states?: string[];
 lightSource?: boolean;
 lightValue?: number;
};

This is a breaking change from other versions. But now voxel states actually work. So, when you add a state to the states array it will be passed to the voxel process function so you can do different things with it.
Also realized that the defaultState literally did nothing so I just removed it.

Alpha 1.2 is out now.


add initial generate json snippets fn

@atbe @jakeloo this basically adds a bunch of code examples & other descriptions & documentation that then gets built into a docs/snippets.json with yarn build
that docs/snippets.json -> gets pulled in by console at run-time to generate the Code section on modules (& we may also re-use this for the code snippets page in portal)


Authorization policy not being applied to Gateway

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
What happened:
authorization policy not being applied to Gateway
What you expected to happen:
authorization policy is applied to Gateway and traffic denied
How to reproduce it (as minimally and precisely as possible):
I have this gateway configured in GKE with a static regional IP.
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
  namespace: istio-ingress
  labels:
    istio.io/gateway-name: ci-webhooks
spec:
  gatewayClassName: istio
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: All
  addresses:
    - value: "x.x.x.x"
      type: IPAddress

the service:
apiVersion: v1
kind: Service
metadata:
  name: my-gateway-istio
  namespace: istio-ingress
  labels:
    gateway.istio.io/managed: istio.io-gateway-controller
    istio.io/gateway-name: ci-webhooks
spec:
  externalTrafficPolicy: Local
  ports:
    - appProtocol: tcp
      name: status-port
      port: 15021
      protocol: TCP
      targetPort: 15021
    - appProtocol: http
      name: http
      port: 80
      protocol: TCP
      targetPort: 80
  selector:
    istio.io/gateway-name: my-gateway
  type: LoadBalancer

HTTPRoute:
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-gateway-http-route
spec:
  parentRefs:
    - name:  my-gateway
      namespace: istio-ingress
  rules:
    - matches:
        - path:
            type: Exact
            value: "/test"
      backendRefs:
        - name: my-service
          port: 8080

and the authorization policy:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: my-gateway-authorization-policy
  namespace: istio-ingress
spec:
  selector:
    matchLabels:
      istio.io/gateway-name: my-gateway
  action: ALLOW
  rules:
    - from:
        - source:
            ipBlocks:
              - x.x.x.x # Test IP

Version
$istioctl version
client version: 1.11.0
control plane version: 1.17.1
data plane version: 1.17.1 (20 proxies)

$kubectl version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
Client Version: v1.26.1
Kustomize Version: v4.5.7
Server Version: v1.24.11-gke.1000

Additional Information
The policy is not working. I've gone through some troubleshooting, changing some configs, reinstalling everything, and also trying to check the istio pod logs:
kubectl patch deployment my-gateway -n istio-ingress -p'{"spec":{"template":{"spec":{"containers":[{"name":"istio-proxy","args":["proxy", "sidecar", "--proxyLogLevel=debug"]}]}}}}'
I'm using kubernetes gateway API: https://gateway-api.sigs.k8s.io/guides/
Affected product area

[ ] Ambient
[X] Docs
[X] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[X] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Control Plane Revisions

why do you have

  labels:
    istio.io/gateway-name: ci-webhooks

?
That label si suppose to be auto generated based on the Gateway name. So it may be why its getting confused?

Sorry, I removed the labels.
I added it just for testing. I'm still struggling with this, do you have any better ideas for troubleshooting? I believe that this should work.
I have Kiali configure where I can check some stuff also.

if you do istioctl pc all POD -oyaml, is there anything with the rbac there? That will weed out if the control plane is not sending the config, or if its not being enforced.

After two days without touching it, the IP just appeared there.
I'm trying to add more IPS, but now it's not being updated.
It seems some delay to enforce/update the AuthorizationPolicy.

worked after rollout restart istiod


feat(mj-accordion-text): add new attributes

This PR adds the following attributes to the component mj-accordion-text

font-weight
letter-spacing
line-height

Motivation
It would be nice if mj-accordion-text accepts the same attributes as mj-text does.
I had to change the font-weight from the accordion content and I couldn't because mj-accordion-text does not accept it.

@iRyusa done :+1:

Thanks !


Add inventory unit tests

What this PR does / why we need it:
Increases unit test kubevirt inventory plugin coverage. Also, it fixes some minor issues found:

Loop ranging over vmi labels.
Minor typo on comment.

Unit test coverage has improved from 50% to 83%.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes# CNV-41341
Special notes for your reviewer:
Release note:

None

/cc @lyarwood

/approve
/lgtm


.

why did you close this issue, i don't see the solution yet. i have the  same problem occurring  to me .
{
"requestId":"23951-19301454-1",
"errorCode": "500.001.1001",
"errorMessage": "[MerchantValidate] - Wrong credentials"
}
i think am sure i have used the right test credentials, in python please help


update release note (#4747)

Coverage remained the same at 34.607% when pulling b0b1150c8e6c87b22eeea83d2baa54745018e76a on binyli/master-cherry-pick into c6a1c0cd12721feee995cd40e9d1b7f2f496746f on master.


Now that Rust 1.64.0 is out we don't need nightly anymore

c36797991dd35b0d60aa4c16866d60d9d280febe introduced the need for a nightly compiler because certain crates needed to be compiled for multiple targets. Rust 1.64.0 now supports this in stable as well, so we don't need nightly anymore.

Hmm, looks like it's still using an older Rust version in the workflow. Looking at the yml I'm not actually sure where Rust is being installed in the Workflow, even :)

I'm suspecting the ubuntu image comes with Rust preinstalled, but that would suggest we're probably already at a very old version. actions-rs/toolchain sounds like a fine solution :+1:

Adding the toolchain action seems to have done the trick.


Update reusable quality check action/workflow

After consolidation of quality check tool and dashboard (called now release-automation), tractusx-quality-checks repository is no longer maintained, releases and gh action are outdated. The feature needs to be moved to a new sig-release repository (home of release-automation) so that others can use latest release.

PR https://github.com/eclipse-tractusx/sig-release/pull/400

second PR https://github.com/eclipse-tractusx/sig-infra/pull/396 depends on https://github.com/eclipse-tractusx/sig-release/pull/400


Remove debug code from production builds

Fixes #1053

Are we using different techniques for other warnings or do we miss warnings for other arguments that we have removed?

Good that you mention this, there was another warning in the form component, that wasn't wrapped at all. Added that there too!


Updates for ICAPS developments.

The quick and dirty changes I made for the benchmark of the ICAPS paper are in a separate "icaps-expe" branch. It should not be merged as is.
We should cherry pick the changes we want, and fix the bugs that required a work around.
New features:

planning stops based on a maximum time insead of maximum iterations
shuffler can be configured with JSON
shuffler uses iteration number to decide whether to shuffle or not.
many more different VNS configurations
improvement in benchmarking scripts

Things that should be fixed before merging:

I was not able to use the external configuration file for defining neighborhoods. benchmark.py still used the ones defined in locally. As a result all new neighborhood in this branch were added to "benchmark.py" directly
benchmarking scripts need o be cleaned up to make sure they run on something else than my machine.
I added a flag to make the VNS search silent, but it is not configurable at runtime

I think changes that affect to scripts/benchmarking/analyze.py can be cherry-picked "as-they-are".
Why you weren't able to use the external VNS confs?
There should be a way to connect std::cout to the python logger, so we could configure its "verbosity". A possible clue: https://pybind11.readthedocs.io/en/stable/advanced/pycpp/utilities.html#capturing-standard-output-from-ostream combined with this https://stackoverflow.com/questions/11124093/redirect-python-print-output-to-logger#11124247

Why you weren't able to use the external VNS confs?

When updating the configuration in the external file, the changes where not picked-up. Instead, the benchmark script was still using the configurations defined in benchmark.py. Removing them from benchmark.py resulted in hte configurations no being found.
Let me know if you can reproduce this, otherwise I might have messed up with the command line options.

Also it seems like the --parallel option makes a bad usage of CPU.
Not very scientific tests: simply looking up CPU usage with htop, the CPU usage really does not scale with the number of threads. Its probably fine for development, but not to actually produce results for papers or deep analysis.
Instead running N times benchmark.py would result in N CPUs being consistently used at a 100%.
That's what I used to produce the results for the paper. I have the updated run.sh script on another machine, I'll try to add it.

wrt the external VNS confs I think I discovered the issue. As vns_configurations dictionary is a global variable, when it should be getting replaced by vars(args.vns_conf) it is in fact being assigned to a new vns_configurations that shadows the global definition. This is a --let's say particular-- python behavior.  run_benchmark gets only the name of the conf and access the unchanged global  vns_configurations instead of the new one.
It is easier to get it fixed than explained. It is ok now in #13

wrt to --parallel, I'm a bit disappointed but not surprised. cPython can not run multiple threads at the same time because of the Global Interpreter Lock. But, as most of our planning is done in the C++ library we can release the GIL when calling plan_vns. I hopped joblib was correctly using the multiprocessing module to parallelize the python part but apparently not... 😞


Start dropping lambdas from operator.go

What this PR does
Get rid of several lambda functions from tests/operator/operator.go
Why we need it and why it was done in this way
operator.go is a single file in its package. There is no reason to use lambdas there, because there is no risk for naming pollution, as there are no other files in this package.
Some of the functions are only used once - then this PR drops them and copies their logic to the relevant tests. Other lambdas are now regular functions.
Release note

None

/cc @RamLavi

@dankenigsberg - rebased with main and changed all the commit messages to be more verbose.

/retest

/retest-required

Why we need it and why it was done in this way
operator.go is a single file in its package. There is no reason to use lambdas there, because there is no risk for naming pollution, as there are no other files in this package.

As written in above comments, I have to say that I don't agree with this reasoning, both because more files and tests could be added in the future but also because this doesn't explain what positive value is gained from removing those lambdas but instead says that there is no negative value (i.e. no risk for ...).
If a lambda function is not bounded to any specific scope (example: https://github.com/kubevirt/kubevirt/pull/11820/commits/fe0d9623221d82b517814dff7e62b36cd7449ad0), than I think there is a small value of making the code slightly more readable, and that the functions could be used by others in the package which is a benefit. I think you should consider adding it to the PR description.
Is there any other positive value of removing these lambdas that I'm missing?

/lgtm

Thank you very much @nunnatsa!! Awesome work! Looks much much better, only one small comment left

Done

re-LGTMing on @avlitman's behalf based on https://github.com/kubevirt/kubevirt/pull/11820#issuecomment-2157501517.
@avlitman let us know if there's something missing from your end.
/lgtm


docs(repo): Fixed broken link in readme

I know this is a nano-detail, but I like what you're doing.

Hey! Thanks for the correction, IIRC that was written before the link changed 😅.


kong ingress controller bypassing the oidc plugin in kubernetes

Hi,
Summary
I have deployed the kong with oidc container v2.3.3-1 (https://github.com/revomatico/docker-kong-oidc/releases/tag/2.3.3-1) on the kubernetes in AWS. I have to integrate the keycloak with this kong. But after doing all the configuration in keycloak and creating the kong plugin entity using YAML, the request to microservice is bypassing the oidc plugin and I can directly access the service from ingress.
Steps To reproduce

Created the OIDC Plugin Entity using YAML:

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
labels:
    global: "true"
metadata:
  name: oidc
  namespace: kong
config:
  client_id: kong_api_access
  client_secret: 093c6dd1-XXXX-XXXX-XXXX-XXXXXXXXXXXX
  scope: openid
  realm: kong
  discovery: http://keycloak.abc.com/auth/realms/kong/.well-known/openid-configuration
  introspection_endpoint: http://keycloak.abc.com/auth/realms/kong/protocol/openid-connect/token/introspect
plugin: oidc

Created the test microservice using YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo
  annotations:
    plugins.konghq.com: oidc
    kubernetes.io/ingress.class: kong
spec:
  rules:
  - http:
      paths:
      - path: /echo
        backend:
          serviceName: echo
          servicePort: 80

Accessing the service using https://test.abc.com/echo
This is directly getting me to the service instead of loading the keycloak login page

Additional Information

I can see the oidc plugin is enabled in kong

curl -s --insecure https://<IP_ADDRESS>:8444/plugins/enabled
{"enabled_plugins":["grpc-web","correlation-id","pre-function","cors","rate-limiting","loggly","hmac-auth","zipkin","request-size-limiting","azure-functions","request-transformer","oauth2","response-transformer","ip-restriction","statsd","jwt","proxy-cache","basic-auth","key-auth","http-log","oidc","session","datadog","tcp-log","prometheus","post-function","ldap-auth","acl","grpc-gateway","file-log","syslog","udp-log","response-ratelimiting","aws-lambda","bot-detection","acme","request-termination"]}

I am assuming you have:

deployed the kong ingress controller? It will be enabled by default if you are using helm chart to deploy Kong.
set redirect_uri plugin param as well

We do not use yet ingress controller, as we have a lot of stateless configuration to migrate to ingress definitions and CRD. But will do this soon and be able to test it thoroughly, but as of right now we do not have the resources to test your scenario.

What do the logs say, with log_level=debug or KONG_LOG_LEVEL=debug env say?
What do the ingress controller logs say?

Thanks @cristichiru for checking this out. The problem is resolved now.
I was using incorrect annotation in ingress.yaml. Instead of  plugins.konghq.com: oidc, the correct annotation is konghq.com/plugins: oidc. The correct ingress yaml is:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo
  annotations:
    konghq.com/plugins: oidc
    kubernetes.io/ingress.class: kong
spec:
  rules:
  - http:
      paths:
      - path: /echo
        backend:
          serviceName: echo
          servicePort: 80


Add pagination support for rpcs that use a map field in lieu of a repeated field

AIP-158 specifies that paginated rpcs should use a repeated proto field to contain the results. For a map<K, V>, we should return a StreamRange<std::pair<K, V>> for rpcs that want to paginate a map field.

@scotthart will figure out if this is needed for GA.


[Bug] [Clickhouse Sink]   Sink to Clickhouse failed

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
kafka Source     Clickhouse Sink  job.mode=Streaming   Spark Jobs or stages had completed  but   clickhouse table not have  data
but  job.mode=BATCH  it's  ok
SeaTunnel Version
2.3.0-dev
SeaTunnel Config
env {
      spark.app.name = "SeaTunnel"
      spark.executor.instances =1
      spark.executor.cores = 2
      spark.executor.memory = "4g"
      spark.executor.memoryOverhead="1g"
      spark.streaming.batchDuration = 2
      job.mode = "STREAMING"
      #job.mode = "BATCH"
      spark.streaming.kafka.maxRatePerPartition= 100
      spark.streaming.batch.duration.seconds = 2
      spark.streaming.backpressure.enabled=true
}

source {
  kafka {
      topic = "xxxxxxxxxxxx"
      bootstrap.servers = "xxxxx:9092"
      partition = 3
      consumer.group = "seatunnel_group01"
      format = json
      kafka.request.timeout.ms = 60000
      #kafka.max.poll.records = 200
      kafka.fetch.max.bytes = 10485760
      result_table_name = test
      semantics = EXACTLY_ONCE
      kafka.auto.offset.reset = latest
      kafka.config = {
      	max.poll.records = 100
      }
      schema = {
            fields {
            xxx= double
            xxxx= double
            xxxx= double
      }
    }
       }
}

transform{

}

sink {
    Console {

    }
     Clickhouse {
           source_table_name = test
           host = "xx.xx.xx.xxx:8123"
           clickhouse.socket_timeout = 50000
           database = "xxxxxx"
           table = "xxxxx"
           fields = ["xxxx","xxxx","xxxx""]
           username = "xxxxx"
           password = "xxxxxx"
          bulk_size = 20000
      }
}

Running Command
/start-seatunnel-spark-2-connector-v2.sh  --master yarn  --deploy-mode cluster   --config ../config/examplespark01.conf

Error Exception
23/03/06 10:18:16 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:17 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:18 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:19 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:20 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:21 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:22 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:23 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:24 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:25 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:26 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:27 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:28 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:29 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:30 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:31 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:32 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:33 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:34 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)
23/03/06 10:18:35 INFO yarn.Client: Application report for application_1677118697195_0046 (state: RUNNING)

Flink or Spark Version
spark 2.4.4
Java or Scala Version
jdk1.8
Screenshots

Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

The clickhouse v2 connector is 20000 writes at a time. The Clickhouse V2 connector is 20000 writes at a time
@PG-Young


[Algo] Insertion Sort [Java]

https://en.wikipedia.org/wiki/Insertion_sort

GitMate.io thinks possibly related issues are https://github.com/NITSkmOS/Algorithms/issues/63 ([Algo] Insertion Sort [Java]), https://github.com/NITSkmOS/Algorithms/issues/149 ([Algo] Merge Sort [Java]), https://github.com/NITSkmOS/Algorithms/issues/145 ([Algo] Selection Sort [C]), https://github.com/NITSkmOS/Algorithms/issues/46 ([Algo] Binary Search [Java]), and https://github.com/NITSkmOS/Algorithms/issues/150 ([Algo] Quick Sort [Java]).

Duplicate of https://github.com/NITSkmOS/Algorithms/issues/63


feat(router-link): add router-link and deprecate anchor

Pull request checklist
Please check if your PR fulfills the following requirements:

[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been reviewed and added / updated if needed (for bug fixes / features)
[x] Build (npm run build) was run locally and any changes were pushed
[x] Lint (npm run lint) has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, renaming)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Does this introduce a breaking change?

[ ] Yes
[x] No

Other information

Add ion-router-link to excludeComponents in stencil.config.ts for the angular bindings generation.
Move ion-anchor and ion-router-link to the routing bundle in stencil.config.ts!

Done!

Has ion-anchor been deprecated or different behavior? I get an error with using target on ion-anchor now:

Object literal may only specify known properties, and 'target' does not exist in type 'IonAnchor'.

It was renamed from ion-anchor to ion-router-link to make it better known that. ion-router-link is a new component that didn't exist prior to 4.6.0. I added download and target to ion-anchor in the following PR: https://github.com/ionic-team/ionic/pull/17883
I removed download and target from it in this PR after discussing with @manucorporat, prior to any release. I'm not sure how you were using it before? It was not in 4.5.0 or 4.6.0. If you need target with it, could you please tell us more about your use case? Thanks!

@brandyscarney thanks for explaining (:
Before, we were using it like
<ion-anchor href="/some/page" target="_blank">Some page</ion-anchor>

(which worked in 4.5.0)
I'm generally against opening links in new tabs by default, and I know about tabnabbing (which is not an issue in our case because the href is safe), but it's a requirement for one of our components to open links in a new tab by default. 🤷🏻♂
Just to be clear, we're not opening a third-party url, just a route of our app (like a link to a user profile), which is why we were using ion-anchor, or rather ion-router-link now.

@simonhaenisch It's interesting that that broke. Are you using Stencil or is it just Ionic Core?
I believe the idea is that the ion-router-link would only be used for navigating with the Ionic Router and being able to change the router-direction which would not be needed if opening in a new tab or not navigating to a URL within the app, but @manucorporat would know more on this. I'm up for learning more and discussing the use cases of this though as I want to make sure we are covering all use cases for it and it isn't confusing.

Using it in a Stencil + Ionic PWA<EMAIL_ADDRESS>and @ionic/core@4.6.0).
One thing that the router also takes care of (afaik?) is to deal with the /# in the url depending on useHash. By using ion-anchor/ion-router-links instead of normal as it's easy to change that setting without breaking anything. That's why I believe that at least the target prop should be implemented (download is a different story). I can make a PR for that if you want.

@simonhaenisch I might be missing something, but i don't see how target might be useful at all. Ion-router does not understand target at all. ion-router-link is just a declarative API to call:
router.push(url)

instead of performing an actual page reload.
target="_black" means a new tab (completely new page and context) will load. I have reviewed some of the equivalent APIs in React Router, Angular and Stencil and I don't see "target" either.
Why you can't just use ? I just don't understand the use case

Just for context, the use case is a table component where each row links to a document, but at the end of each row there's an icon that will link to the same document but open it in a new tab.

I would not use target="_blank" but I don't have the final say over it and apparently a lot of our users don't know how else to open links in new tabs 🤷🏻♂ (Just in a recent user testing session, two out of two users didn't get that they had to fill in their email and password in the login form, because there's placeholders<EMAIL_ADDRESS>and *** on the inputs.)

Anyway, I guess it's just a matter of consistency. In general, I would not use an a for any app routing (as it would cause a reload) and always use ion-router-link instead. However in this one case, where I also want to route to a certain part of the app, but launch it in a new tab, it's kind of inconvenient having to switch to an a tag.
interface Td {
  content: string | VNode;
  href?: string;
  target?: string; // can be set but doesn't have to be
}

tds.map(({ content, ...linkProps}) => (

    <ion-router-link {...linkProps}>{content}</ion-router-link>

));

This template would become unnecessarily complex
tds.map(({ content, href, target}) => (

    {target ? (
      {content}
    ) : (
      <ion-router-link href={href}>{content}</ion-router-link>
    )}

));

Looking at React Router, they have actually implemented it. See this comment. The way they do it is: if target is set, just let the browser handle the link (rather than using router.push in our case). I think that's a rather good approach.

Thanks for the thorough response @simonhaenisch! We are going to add the target to the ion-router-link. One question though: have you been using the @ionic/core@one builds to develop your app? If so - is it possible that you added in the target to the ion-anchor after this PR (https://github.com/ionic-team/ionic/pull/17883) went in and then it broke from being removed? Or are you sure it worked in 4.5.0? I tried it out in a Stencil project with 4.5.0 and saw the same error:

@brandyscarney ah yes, I was using the @one tag, which indeed was a dev build. Sry, false alarm about it being broke then 🙈
Thanks!


readme is missing documentation for the new commands

Oclif has a way to generate command help documentation if we are going with that we just need to set it up.

Yeah, just watch out that it might generate documentation of commands separated by colons (:) instead of spaces.

Hi @Souvikns 👋, automating this would be really interesting so that when we add new commands, the docs on the README are automatically updated. I had a look on the package.json and there is already a script for the readme, are we already using it on GitHub actions?
I'd like to help with this issue if no one is working on it 🙂. I messed around with oclif readme command to see the output, and I just want to clarify if the generated docs are correct:
Usage

$ npm install -g @asyncapi/cli
$ asyncapi COMMAND
running command...
$ asyncapi (-v|--version|version)
@asyncapi/cli/0.12.7 linux-x64 node-v16.13.0
$ asyncapi --help [COMMAND]
USAGE
  $ asyncapi COMMAND
...

Commands

asyncapi config
asyncapi config:context
asyncapi config:context:add CONTEXT-NAME SPEC-FILE-PATH
asyncapi config:context:current
asyncapi config:context:list
asyncapi config:context:remove CONTEXT-NAME
asyncapi config:context:use CONTEXT-NAME
asyncapi new
asyncapi start
asyncapi start:studio
asyncapi validate [SPEC-FILE]

asyncapi config
access configs
USAGE
  $ asyncapi config

OPTIONS
  -h, --help  show CLI help

See code: src/commands/config.ts
asyncapi config:context
USAGE
  $ asyncapi config context

OPTIONS
  -h, --help  show CLI help

See code: src/commands/config/context.ts
asyncapi config:context:add CONTEXT-NAME SPEC-FILE-PATH
Add or modify a context in the store
USAGE
  $ asyncapi config context add CONTEXT-NAME SPEC-FILE-PATH

ARGUMENTS
  CONTEXT-NAME    context name
  SPEC-FILE-PATH  file path of the spec file

OPTIONS
  -h, --help  show CLI help

See code: src/commands/config/context/add.ts
asyncapi config:context:current
Shows the current context that is being used
USAGE
  $ asyncapi config context current

OPTIONS
  -h, --help  show CLI help

See code: src/commands/config/context/current.ts
asyncapi config:context:list
List all the stored context in the store
USAGE
  $ asyncapi config context list

OPTIONS
  -h, --help  show CLI help

See code: src/commands/config/context/list.ts
asyncapi config:context:remove CONTEXT-NAME
Delete a context from the store
USAGE
  $ asyncapi config context remove CONTEXT-NAME

ARGUMENTS
  CONTEXT-NAME  Name of the context to delete

OPTIONS
  -h, --help  show CLI help

See code: src/commands/config/context/remove.ts
asyncapi config:context:use CONTEXT-NAME
Set a context as current
USAGE
  $ asyncapi config context use CONTEXT-NAME

ARGUMENTS
  CONTEXT-NAME  name of the saved context

OPTIONS
  -h, --help  show CLI help

See code: src/commands/config/context/use.ts
asyncapi new
creates a new asyncapi file
USAGE
  $ asyncapi new

OPTIONS
  -e, --example=example      name of the example to use
  -h, --help                 show CLI help
  -n, --file-name=file-name  name of the file
  -p, --port=port            port in which to start Studio
  -s, --studio               open in Studio
  --no-tty                   do not use an interactive terminal

See code: src/commands/new.ts
asyncapi start
starts a new local instance of Studio
USAGE
  $ asyncapi start

OPTIONS
  -h, --help  show CLI help

See code: src/commands/start.ts
asyncapi start:studio
starts a new local instance of Studio
USAGE
  $ asyncapi start studio

OPTIONS
  -f, --file=file  path to the AsyncAPI file to link with Studio
  -h, --help       show CLI help
  -p, --port=port  port in which to start Studio

See code: src/commands/start/studio.ts
asyncapi validate [SPEC-FILE]
validate asyncapi file
USAGE
  $ asyncapi validate [SPEC-FILE]

ARGUMENTS
  SPEC-FILE  spec path, url, or context-name

OPTIONS
  -h, --help  show CLI help

See code: src/commands/validate.ts

Unfortunately, I wasn't able to test the current CLI commands by installing the asyncapi/cli package, I believe this error: [MODULE_NOT_FOUND] Error Plugin: @asyncapi/cli: Cannot find module '@oclif/plugin-help/lib/command' Require stack: is related to #192 😢
Feel free to give me any feedback on my assumption, I appreciate it 👍.

Awesome @BOLT04 the generated docs are correct 👍🏻. No one is working on this issue as of now so you can take it up.
Yeah the CLI is kinda breaking in production but it works fine in the development and you can just clone the repo and run /bin/run in the project to run the CLI. Currently working on https://github.com/asyncapi/cli/pull/203 to fix the issue. I think you have to wait for this as we are updating oclif version and the oclif readme command might work differently from right now.

the only problem with the generated stuff is : that should be spaces. So asyncapi config:context is actually asyncapi config context

The new version has some inbuilt support for topic separators maybe this would help.

ok, then for this issue we'll wait on #203 👍 . Then setup the topicSeparator on the package.json and build a new workflow to automatically run this script when there is a push to master. The next step would be to open a PR with those changes to be merged.
Is there a better way to run this script what does everyone think?

@BOLT04, cli documentation was a part of GSOD, but don't know what is the status. https://github.com/asyncapi/website/issues/602, https://github.com/asyncapi/cli/issues/232 were planned for this. I don't know if anyone is working on CLI documentation right now. Give me some time, I will check on the status and update you.

@Souvikns  we can continue on the CLI command reference using this tool
And I will be writing the getting started document

I think this one is still valid

this is still valid, although I'm not sure what the solution is

This issue is part of the AsyncAPI Bounty Program, interested contributors need to follow the guidelines below to ensure fairness and timely completion of assigned tasks:
Task Assignment
The assignment of tasks will be prioritized in the following order:

AsyncAPI maintainers (from any repository)
Regular contributors (individuals who have merged three or more pull requests)
Other (if an individual doesn't fall under the above, the maintainer can determine the criteria i.e regular volunteers, etc)

We encouraged everyone to apply as long as the task is for you (falls under your skill set). We will not be using the first comment - get assigned method for assignments. Instead, we will provide 3 days to consider all individuals interested before assigning any bounty task.
Deadline
To maintain accountability and ensure the timely completion of the deadline for this task will be 4- 6 weeks from the date of assignment. If a contributor requires an extension on their task, it should be communicated and approved by the maintainer.
Issue Tracking and Updates
Contributors must provide weekly updates on the task they are working on to help maintainers stay informed of progress. If a contributor fails to provide an update, they will be reminded via a ping. If a contributor fails to provide an update after three pings over three weeks, we will assume they have silently dropped the issue, and it will be reassigned to someone else.
Issue Drop-outs
Any contributor who drops an assigned issue will be penalized and will not be eligible to participate in the bounty program for 6 months. We understand that unforeseen circumstances can arise, and dropping an assigned issue may be unavoidable in some cases. However, we believe that enforcing this penalty is necessary to ensure the effectiveness of the bounty program, respect maintainer time, and honor the efforts of other contributors who could have solved the issue but were unable to do so due to the drop-out.
We encourage all contributors to follow these guidelines to ensure a fair and timely completion of tasks assigned through our bounty program.

This issue is part of the AsyncAPI Bounty Program, interested contributors need to follow the guidelines below to ensure fairness and timely completion of assigned tasks:
Task Assignment
The assignment of tasks will be prioritized in the following order:

AsyncAPI maintainers (from any repository)
Regular contributors (individuals who have merged three or more pull requests)
Other (if an individual doesn't fall under the above, the maintainer can determine the criteria i.e regular volunteers, etc)

We encouraged everyone to apply as long as the task is for you (falls under your skill set). We will not be using the first comment - get assigned method for assignments. Instead, we will provide 3 days to consider all individuals interested before assigning any bounty task.
Deadline
To maintain accountability and ensure the timely completion of the deadline for this task will be 4- 6 weeks from the date of assignment. If a contributor requires an extension on their task, it should be communicated and approved by the maintainer.
Issue Tracking and Updates
Contributors must provide weekly updates on the task they are working on to help maintainers stay informed of progress. If a contributor fails to provide an update, they will be reminded via a ping. If a contributor fails to provide an update after three pings over three weeks, we will assume they have silently dropped the issue, and it will be reassigned to someone else.
Issue Drop-outs
Any contributor who drops an assigned issue will be penalized and will not be eligible to participate in the bounty program for 6 months. We understand that unforeseen circumstances can arise, and dropping an assigned issue may be unavoidable in some cases. However, we believe that enforcing this penalty is necessary to ensure the effectiveness of the bounty program, respect maintainer time, and honor the efforts of other contributors who could have solved the issue but were unable to do so due to the drop-out.
We encourage all contributors to follow these guidelines to ensure a fair and timely completion of tasks assigned through our bounty program.

AsyncAPI Bounty Program Guidelines
Welcome to the AsyncAPI Bounty Program! We are excited to have you onboard as a contributor. To ensure fairness and timely completion of assigned tasks, we have established the following guidelines.
Task Assignment
Tasks will be assigned based on the following prioritized order:
AsyncAPI maintainers (from any repository)
Regular contributors (individuals who have merged three or more pull requests)
Other (if an individual doesn't fall under the above, the maintainer can determine the criteria i.e regular volunteers, etc)
As long as the task falls under your skill set, we encourage everyone to apply. To ensure transparency and fairness, we will provide three days for all interested individuals to consider the task before making any assignments. We will not be using the "first comment - get assigned" method.
Deadline
To maintain accountability and ensure timely completion, the deadline for this task will be 4-6 weeks from the date of assignment. If a contributor requires an extension, it should be communicated and approved by the maintainer.
Issue Tracking and Updates
Contributors must provide weekly updates on the task they are working on to help maintainers stay informed of progress. Failure to provide updates will result in a reminder via a ping. If a contributor fails to provide an update after three pings over three weeks, we will assume they have dropped the issue and it will be reassigned.
Issue Drop-outs
Any contributor who drops an assigned issue will be penalized and will not be eligible to participate in the bounty program for six months. We understand that unforeseen circumstances can arise, and dropping an assigned issue may be unavoidable in some cases. However, we believe that enforcing this penalty is necessary to ensure the effectiveness of the bounty program, respect maintainer time, and honor the efforts of other contributors who could have solved the issue but were unable to do so due to the drop-out.
We encourage all contributors to follow these guidelines to ensure a fair and timely completion of tasks assigned through our bounty program. Thank you for your participation!

In the README, you could add a brief description of what the AsyncAPI CLI does and how it can be useful for users working with AsyncAPI specifications.
You could update the package.json script for generating the README to automatically run whenever changes are pushed to the main branch. This would ensure that the README is always up-to-date with the latest CLI commands.
You could add a CONTRIBUTING.md file to the repository, which would provide guidelines for contributing to the project, including how to submit bug reports, feature requests, and pull requests. This would make it easier for users to contribute to the project and help improve its functionality.

I would like to work on this issue.

@mhmohona I just assigned this issue to you to make it clear for others you work on it
@mediba123 we actually have automation that updates table of contents in readme and also a contribution guide. Did you check it before making that comment? 😄

@mhmohona how is the task going so far??

@mhmohona hey, so it looks like automation worked, scripts got triggered and we got https://github.com/asyncapi/cli/pull/601 but as you can see, commands section is empty 🤔

@mhmohona I'm pretty sure it is because of some delay on oclif readme command, and the JS code just needs to wait.
can you open a followup PR with fix like below:
/* eslint-disable @typescript-eslint/no-var-requires */
const {writeFile, readFile} = require('fs').promises;

// Define the paths to the README and usage files
const README_PATH = './scripts/README.md'; // File path for the generated README file
const USAGE_PATH = './docs/usage.md'; // File path for the usage documentation file

const header = `---
title: 'Usage'
weight: 40
---

<!--

This file is automatically generated from updateUsageDocs.js script. In package.json in line 158-161 lines the following steps has been executed in order to run this script successfully -

* generate:readme:create: It creates the initial content for the README file by printing the usage and commands tags using printf and redirects the output to scripts/README.md file.
* generate:readme:commands: It changes the directory to the scripts folder and executes the oclif readme command. This command generates the usage and commands sections based on the CLI commands and updates the content in the scripts/README.md file.
* generate:assets: This script combines the two previously mentioned scripts (generate:readme:toc and generate:commands) to generate the necessary assets, such as the README file and usage documentation.
* generate:commands: This script executes the following steps:
 - Runs the generate:readme:create script to create the initial content for the README file.
 - Executes the generate:readme:commands script to generate the usage and commands sections based on the CLI commands.
 - Runs the updateUsageDocs.js script using Node.js to update the usage documentation file with the contents of the generated README file.
 - Deletes the scripts/README.md file using the rimraf command.

-->

The AsyncAPI CLI makes it easier to work with AsyncAPI documents.
`;

// Define an async function to write the header and the README contents to the usage documentation file
async function run() {
  try {
    await writeFile(USAGE_PATH, header);
    const readmeContents = await readContents();
    // Append the contents of the README file to the usage documentation file
    await writeFile(USAGE_PATH, readmeContents, { flag: 'a' });
  } catch (e) {
    console.error(e);
  }
}

run();

async function readContents() {
  let readmeContents;
  let commandsContent = '';

  while (commandsContent.length === 0) {
    readmeContents = await readFile(README_PATH, 'utf8');

    // Check if the content between <!-- commands --> and <!-- commandsstop --> is empty
    const commandsStartText = '<!-- commands -->';
    const commandStartIndex = readmeContents.indexOf(commandsStartText);
    const commandStopIndex = readmeContents.indexOf('<!-- commandsstop -->');
    //cutting the content between the above mentioned tags, removing white spaces and checking if there is some text as it will mean text was added by oclif
    commandsContent = readmeContents.slice(commandStartIndex + commandsStartText.length, commandStopIndex).trim();

    if (commandsContent.length === 0) {
      console.log('No content between <!-- commands --> and <!-- commandsstop -->. Trying again...');
    } else {
      console.log('Content found!');
    }

    await delay(3000); // 3-second delay
  }

  return readmeContents;
}

function delay(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

Thank you so much for pointing this @derberg! I have updated the code and created new PR.
I thought of adding it but then thought it might be unnecessary but it seems it is needed. :3

ok, so 😄 it didn't work
workflow was running for over 3min and below was just logged out
No content between <!-- commands --> and <!-- commandsstop -->. Trying again...

I don't think it is normal so I cancelled the run. Not sure yet what is the solution

I can't figure from their code what might be wrong, but we can log more things in the GitHub Action
so please open another PR with change in the package.json where you run oclif readme so it is DEBUG=* oclif readme
so basically make sure it says "generate:readme:commands": "cd scripts && DEBUG=* oclif readme",
this will give us a lot of insights and info where it stucks with commands generation

@mhmohona is still doesn't work, logs show
2023-05-30T04:42:52.932Z config:@asyncapi/cli loading IDs from /home/runner/work/cli/cli/lib/commands
2023-05-30T04:42:52.939Z config:@asyncapi/cli found commands []

while on local I get
config:@asyncapi/cli loading IDs from /Users/wookiee/sources/cli/lib/commands +0ms
  config:@asyncapi/cli found commands [
  'bundle',                'convert',
  'diff',                  'optimize',
  'validate',              'config',
  'config:versions',       'generate:fromTemplate',
  'generate',              'generate:models',
  'new:file',              'new:glee',
  'new',                   'new:project',
  'start',                 'start:studio',
  'config:context:add',    'config:context:current',
  'config:context',        'config:context:list',
  'config:context:remove', 'config:context:use'
]

so looks like oclif cannot figure what commands are available, but I do not know why

@mhmohona congrats, topic completed. Look what we got on the website thanks to your work ❤ -> https://www.asyncapi.com/docs/tools/cli/usage
@thulieblack another bounty issue completed, over to you
cc @Souvikns fyi usage docs are not automatically updated 💪🏼

Hey, @mhmohona, congratulations on completing your issue!!
This is how'll claim your bounty:

Go to AsyncAPI Open Collective page
Submit an expense and add details for the bounty issue

Voila!


Sync have stopped on block 1212419

We have 4 xtz nodes (v7.4), with tzindex (v6.0.4) all standing at 1212419, the xtz node is working properly.
2020/11/13 08:49:07.879207 ERRO SRVR BW-43d60447f3e1a497c3ea685f1a697fd97b02edce 404 (1305) GET /explorer/account/tz1ikZ1E6Exw1vAb4NWzuUpmbyADTHM2TNad/op?offset=0&limit=0 HTTP/1.1 - ReadAccountOps failed (no such account): account not indexed
2020/11/13 08:49:08.353959 ERRO SRVR BW-ab11fe0b14f0aaf45547a469576d50afbe1fbf58 404 (1305) GET /explorer/account/tz1cQSQtfALQDgW3HZQqtbWvntR4JHiHEGBT/op?offset=0&limit=0 HTTP/1.1 - ReadAccountOps failed (no such account): account not indexed
2020/11/13 08:49:08.477131 ERRO SRVR BW-c433ee25f01f3582e0f66c66971a005b88fd2bad 404 (1305) GET /explorer/account/tz1Xis4LgvB8UuABjmaGEJJJqEWgt6a8kCJR/op?offset=0&limit=0 HTTP/1.1 - ReadAccountOps failed (no such account): account not indexed
2020/11/13 08:49:09.165164 ERRO SRVR BW-96419613bf9c36f357ce3dd0500a617b1f57a9f0 404 (1305) GET /explorer/account/tz1QdL1Nij979xPe3UMduAsH9b2Gz8ZgH5Cq/op?offset=0&limit=0 HTTP/1.1 - ReadAccountOps failed (no such account): account not indexed
2020/11/13 08:49:09.412012 ERRO SRVR BW-20de90f0a669221abc8ae1b42c2664bef1a2ce70 404 (1305) GET /explorer/account/tz1VtWX8ALGGSxmvNuJGSBYor7XvWC3XuUyT/op?offset=0&limit=0 HTTP/1.1 - ReadAccountOps failed (no such account): account not indexed
2020/11/13 08:49:10.041517 ERRO SRVR BW-9c75f96e337084652c19f51e4431d7b8dcba7efe 404 (1305) GET /explorer/account/tz1d3jAWYn4ym73TkGkjse5L5gTMo6RPkbJf/op?offset=0&limit=0 HTTP/1.1 - ReadAccountOps failed (no such account): account not indexed
2020/11/13 08:49:10.433871 ERRO SRVR BW-784f5a46e57b3fffa743afd656596b683ab679c4 404 (1305) GET /explorer/account/tz1WYBq8jr922opGEWx81W9xLSRXLaaxJJgY/op?offset=0&limit=0 HTTP/1.1 - ReadAccountOps failed (no such account): account not indexed

Hi, when should I expect an update?

Can we not wait for the new issue?

Hi!
Have you solved the issue?
I am getting a related problem when running tzindex:
2021/01/15 14:48:38.334549 WARN MAIN Missing config file, using default values.
2021/01/15 14:48:38.334601 INFO MAIN Blockwatch tzindex v6.0.4 -- 4aac17f
2021/01/15 14:48:38.334606 INFO MAIN (c) Copyright 2018-2020 -- Blockwatch Data Inc.
2021/01/15 14:48:38.334612 INFO MAIN Starting Blockwatch-tzindex/v<IP_ADDRESS>aac17f on 8 cores
2021/01/15 14:48:38.334615 INFO MAIN Go version go1.15.3
2021/01/15 14:48:38.345068 INFO MAIN Profiling mutex/blocking at 1.00% sample rate.
...
2021/01/15 14:48:50.641353 INFO BLOC Starting blockchain sync from height 1212420.
2021/01/15 14:48:50.641519 INFO BLOC Starting blockchain ingest.
2021/01/15 14:48:50.641680 INFO BLOC Starting blockchain monitor.
2021/01/15 14:48:50.646759 INFO SRVR Starting HTTP server at <IP_ADDRESS>:8000
2021/01/15 14:48:51.337136 ERRO BLOC Processing block 1212420 BLE7odzqxejetPA4KcwDZQwHYNFEJYogDL857TiThogcupGyQfv: build stage 3: transaction op [15:0]: patch bigmap: bigmap patch unknown contract KT1Acfs1M5FXHGYQpvdKUwGbZtrUkqrisweJ
2021/01/15 14:48:52.137355 INFO BLOC Stopping blockchain sync due to too many errors at 1212419.
2021/01/15 14:48:52.174412 ERRO BLOC Exiting monitor loop on cancelled context

Hi!
Have you solved the issue?
I am getting a related problem when running tzindex:
2021/01/15 14:48:38.334549 WARN MAIN Missing config file, using default values.
2021/01/15 14:48:38.334601 INFO MAIN Blockwatch tzindex v6.0.4 -- 4aac17f
2021/01/15 14:48:38.334606 INFO MAIN (c) Copyright 2018-2020 -- Blockwatch Data Inc.
2021/01/15 14:48:38.334612 INFO MAIN Starting Blockwatch-tzindex/v<IP_ADDRESS>aac17f on 8 cores
2021/01/15 14:48:38.334615 INFO MAIN Go version go1.15.3
2021/01/15 14:48:38.345068 INFO MAIN Profiling mutex/blocking at 1.00% sample rate.
...
2021/01/15 14:48:50.641353 INFO BLOC Starting blockchain sync from height 1212420.
2021/01/15 14:48:50.641519 INFO BLOC Starting blockchain ingest.
2021/01/15 14:48:50.641680 INFO BLOC Starting blockchain monitor.
2021/01/15 14:48:50.646759 INFO SRVR Starting HTTP server at <IP_ADDRESS>:8000
2021/01/15 14:48:51.337136 ERRO BLOC Processing block 1212420 BLE7odzqxejetPA4KcwDZQwHYNFEJYogDL857TiThogcupGyQfv: build stage 3: transaction op [15:0]: patch bigmap: bigmap patch unknown contract KT1Acfs1M5FXHGYQpvdKUwGbZtrUkqrisweJ
2021/01/15 14:48:52.137355 INFO BLOC Stopping blockchain sync due to too many errors at 1212419.
2021/01/15 14:48:52.174412 ERRO BLOC Exiting monitor loop on cancelled context

Please try v7. I'm sorry, I forgot to push the new version tag.

Please try v7. I'm sorry, I forgot to push the new version tag.

Closing this old issue as the underlying problem should have been solved in v7 (and v8).


Pointer cursor usage

Summary
I'd like the pointer cursor to only be used for links only.  It's currently used on buttons as well.
Relevant information

The hand cursor is for links
The hand (and often underlined text) signifies a link. Links are not buttons. Links came along with the web. To help users understand that they are different, they are given the hand cursor. It serves as an extra clue. Here’s why:

Clicking a link opens a web page or resource.
(On desktop) I can right-click on a link and do many things (that I can’t do with a button). Open in new tab/window, save a link, copy address, add to reading list, bookmark it and more.
(On mobile devices) I can tap and hold on a link and get a similar context menu as per the previous point.
A link also tells me that I am just going somewhere else. I am not modifying any data or making changes in anyway (like a button is likely to do).

Source: Buttons shouldn’t have a hand cursor
Guidance from standards bodies and industry leaders is consistent:

The cursor is a pointer that indicates a link.

Source: W3C CSS3 UI Specification

Hand pointers
Text and graphics links use a hand or “link select” pointer (a hand with the index finger pointing) because of their weak affordance. While links may have other visual clues to indicate that they are links (such as underlines and special placement), displaying the hand pointer on hover is the definitive indication of a link.
To avoid confusion, it is imperative not to use the hand pointer for other purposes. For example, command buttons already have a strong affordance, so they don’t need a hand pointer. The hand pointer must mean “this target is a link” and nothing else.

Source: Microsoft Design Guidelines

Even though they are "industry standards" from a guidelines perspective they are not industry standard from a what-is-actually-done perspective. I think this is an important point from the users perspective. I think most users in a browser setting have come to expect the pointer cursor with buttons and other interactive elements. We run the risk of users thinking an element is not clickable. Perhaps someone can run some usability tests on this topic?
Do you know of any sites that do this the standards way? I'd like to look at one.


fix: add and correct field names

Correct misnamed fields in HashtagEntity and CashtagEntity (reference).
Add media_count to UserV2, as it is included in the API response.
Add 'edit_history_tweet_ids' to TTweetv2TweetField (reference).
Add media_key to TweetEntityUrlV2 (reference - Sample Response).

Indeed, thank you for the fixes (and the clean description)!

Published in 1.19.0


Make booster default in Foundry proofs

Partially addresses https://github.com/runtimeverification/evm-semantics/issues/1958.
This PR is aimed to improve the default observable performance of Kontrol by using the Booster backend in foundry-prove and generating an LLVM library during foundry-kompile by default.

We should also adjust here: https://github.com/runtimeverification/evm-semantics/blob/ba06470f78f9b37ff9058b62a87c749a5c7aee13/.github/workflows/test-pr.yml#L172, to add the option --no-use-booster, so that we're still testing non-booster on CI.

This PR shuold probably wait for https://github.com/runtimeverification/evm-semantics/pull/2034 to merge, which simplifies the booster building process a bit and build sit by default every time we build Foundry proofs anyway.

Decided not to merge this PR and enable booster by default until its behavior is stabilized. Moving to Blocked.

@palinatolmach What is this blocked by?

The instability of the booster backend — technically, we can merge it and there's no specific issue that should be fixed first, but it just doesn't make sense to do it now as the booster is quite problematic now.

Closing as we decided not to use booster by default until the booster stabilizes. Will open a similar PR against Kontrol repository when that happens.


Experimental Design

Implement a class to do experimental design. I have a code skeleton and a few unit tests written, but nothing particularly significant.

Pushed an implementation of experimental design with uncorrelated parameter values to the topic branch experimentaldesign. Includes classes for performing Monte Carlo and Latin Hypercube sampling from designs that can handle parameter distributions flexibly, and should be easy to extend to other LHD protocols such as minimax and maximin.


Disable Head Title Escaping

Hey there!
Firstly let me congratulate! You made a very awesome thing here!
I am developing a site where i need to display html code in Head Titles. Is there any config where i can disable escaping?
Thanks again!

Did you try to use https://docs.angularjs.org/api/ng/service/$sce ?
I mean, something like using $sce.parseAsHtml;
$scope.resource = {
  "header": [
    { "name":  $sce.parseAsHtml("
Name
") },
    { "star": "Star" },
    { "sf-Location": "SF Location" }
  ],
  "rows": [
    { "name": "Ritual Coffee Roasters", "star": "★★★★★", "sf-location": "Hayes Valley"},
    ...
    { "name": "Flywheel Coffee Roasters", "star": "★★★★★", "sf-location": "Upper Haight" }
  ],
  "sortBy": "name",
  "sortOrder": "asc"
};

not sure will work, let me know after giving a try please.


Saving Images

user error

DAYTIME_CAPTURE determines whether images are taken (and saved in tmp).  DAYTIME_SAVE determines if those captured images are saved in allsky/images/DATE.


Value of recent_list_remove in /res/values/strings.xml

When you're on the "repositories" tab in the app, there is a "Recently Viewed" section up top.
But when you long-press one of those items, the second option in the dialog reads "Remove from recently used".
Should this be "Remove from recently viewed"?

That would certainly make sense.

Close via #717


Split into train, validation and test

Since we will use Spotlight data, is it ok to close this issue?