stream settings: Rephrase info to state guest user can't join public stream.

Change wording of public stream description to
"Any member of the organization" from "Anybody"
to indicate that guest users can't subscribe even
public stream of organization.
Followup of #10779

Testing Plan:
GIFs or Screenshots:

@rishig thoughts on whether "member" should be capitalized here?

How about:
This is a public stream. Organization members can join without an invitation.

That sounds great to me.

Merged as 766bdbfe89568cc2e6b4536ddf6bec9be2d085ec, thanks @YJDave and @rishig!


Separation of data and metadata

Separation of primary data and metadata (Principles 3.1 and 3.2, page 26) While this is certainly current best practice we would like to point out that this separation is being challenged in the archival community, where discussion about the convergence of data and metadata is growing.

Connected to overall comment https://github.com/DILCISBoard/GroupDocumentation/issues/13

Covered in issues #366 #367 and #369


Python : Tuple(documentation) issue #3689

Description 📜
I had created the documentation for some more data structure > sets
issue number #3689

Type of change 📝

[ ] Au#dio (Should be in mp3 format Includes speech clarity, Concise ,Low distortion)
[ ] Vi#deo (Animations, screen-recordings, presentations and regular explanatory films are all possibilties etc)
[x] Documentation (Content Creation in the form of codes or tutorials)
[ ] Other (If you choose other, Please mention changes below)

Domain of Contribution 📊

[x] Python_Domain

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

@apeksha235 @adityabisoi  I would be so thankful if you please hacktoberfest tag 😁


Enable RPC for validator thru config flag

Currently the RPC endpoint is disabled for validators by default as for here:
https://github.com/MystenLabs/sui/blob/958854e1121ea746caff7b3bd2b3accb5076e370/crates/sui-node/src/lib.rs#L1309
We would like to enable RPC on the validator and make it accessible locally. This is mainly for monitoring. Currently there's no way to do such thing.
Request:
Please add a config flag to explicitly enable the RPC, even if it's a validator (overruling default 'off')

@randall-Mysten any update/eta on this? We have to source external nodes now, while we would like to keeps things local on the validator.

Sorry, I overlooked this issue. Added some folks who can provide more info about your inquiry

Also adding @bmwill, who I know had similar thoughts about RPCs for monitoring on validators.

I'm not sure we want to broadly expose the json rpc apis on validators, although I have been looking into adding a more stripped down interface to all nodes that would better help with simple monitoring and health checking


adding support for Markdown using recommonmark

This pull request uses recommonmark (which is maintained by ReadTheDocs) to allow people to use Markdown in limited ways within this Sphinx project. We won't be able to do major things in Markdown, but simple pages could use it if desired.

Nice example! I do want to bring up though that we've attempted to use recommonmark in the past for this very same documentation (but before it became a Sphinx project on its own) with subpar results. The CommonMark dialect has quite a few limitations (as can be seen in your example) and with this extension you're left with embedded ReST markup whenever you hits one of those limitations. I also (vaguely) recall unexpected behavior when using hyperlinks. What I mean by all this is that using Markdown here is not the pleasant experience it appears to be initially.

Yeah, but I think most of our wiki pages that were migrated from GitHub could have been ok with the limitations in this pr. Only a few use tables or strange URL's (at the very least links to external links and local files seem to work).

Anyone else have an opinion about this? Should we move forward with adding it or not?
When we selected Sphinx/rst some people asked for markdown support, which I totally understand despite the fact that I still think we need rst and sphinx for this kind of documentation due to the features that come with it. Personally I don't mind writing in rst, but I do think it would be nice to have an option for Markdown for those that want to use it for trivial pages or for incorporating documents that are already written in Markdown.

The above feedback mentions "unexpected behavior when using hyperlinks". It would be good to know what these are. If they can be "resolved" by providing proper documentation than it sounds fine to me. If using Markdown results in plenty of issues then I am not convinced the extra convenience is work the hassle.

The remaining issue with CI is that there is a Python UserWarning which is related to using links in Markdown, which works, but produces the warning. It's been discussed here:
https://github.com/rtfd/recommonmark/issues/130
It looks like some people are using 0.4.0 (rather than 0.5.0) to work around that. I'm not sure what to do in that case, but I'll keep looking into it.
Also, I noticed that we're checking the contents of stderr, which is good, but other people use SPHINXOPTS += -W in their Makefile or python -W ... when invoking sphinx to turn Python warnings into errors, which maybe we should do as well.

The above feedback mentions "unexpected behavior when using hyperlinks".

I'm not sure what that was exactly, the example page I added in this pr does three kinds of links like so:
Here's a link to [a website](http://foo.bar).

And to a [local doc (about)](../About).

And to a [section heading in the current doc](#an-h2-header).

All of which work as far as I can tell. I think the second one is responsible for this user warning, but I think that's an issue with recommonmark which should get resolved at some point (it's not a completely dead project, 0.5.0 was released at the beginning of 2019). I'd even consider investigating and providing a pr to them if it's trivial.
If there are other kinds of links that don't work, or something I'm missing then I'd like to know so I can try them. I know that footnotes don't work, for example. But I think the available functionality allows for enough common things (e.g. headers, text styling, inline html, and links) that it's usable. More complex things like tables and math can be done, you just have to use embedded rst for it, which sucks, but may be slightly better than having to rewrite the whole document in rst. Again my MarkdownExample.md in this pr has details for each case.

Ok, I rebuilt rosindex locally with the proper dependencies and the examples that William added so far work just fine there. I briefly spoke with Alexis, because I just couldn't recall why we had moved away from Markdown and I dug up https://github.com/ros-infrastructure/rosindex/issues/48#issuecomment-430256499 and https://github.com/ros-infrastructure/rosindex/issues/48#issuecomment-430347609. For what is worth, we didn't pursued https://github.com/ros-infrastructure/rosindex/issues/45 anyways because of https://github.com/ros-infrastructure/rosindex/issues/45#issuecomment-424005328, but the intersphinx limitation remained a problem.

e.g. ..

I can try that in the example locally to see if it is a problem with recommonmark/sphinx, but it sounded like the issue was (ab)using the anchor syntax (#anchor) to select the distro (rather than say using GET arguments). Which is something I also ran into where you cannot link to the README or any anchors in it because the # is always interpreted as a distro and there are only a few special #distro-thing anchors you can use.

After a couple of hours of trial/error I was unable to find a way to make Sphinx to correctly resolve inter-sphinx links from md files, they work flawlessly when invoked from within rst files though.

... but the intersphinx limitation remained a problem.

If I understand correctly that is about linking between sphinx projects. I'll try that too, but my understanding was that the markdown links get converted into a docutils link just like rst ones do, so I think it ought to work... I'll have to try it though.


Support API versioning

rippled actually has a version 2 of the API that is not yet enabled. We need to implement those.

We will create issues when we get if ever.


how to mock POST request with a file in the request body

Hi,
i am new to wiremock and i am trying to mock a soap end point in which i want to give xml in the request and it produce a xml output.
it should return a success response if some xml data like firstname, lastname matches with the request data.

I suggest reading the following two pages in the documentation:
http://wiremock.org/docs/stubbing/
http://wiremock.org/docs/request-matching/
If there's anything specific you need help with after that, then please post questions on the mailing list.

Hi @tomakehurst ,
i tried to add equaltoxml, xpath it is wotking with single node (abc)if i give full xml it is failing. could you please suggest me is there any possibility to give xml file in the request.
thank you

+1 to the mentioned question.
Is there any way to pass the file path within request body in the mapping file?
We do similar thing in Response as:
"bodyFileName": "../mockDataForMappings/CreateContactResponse-Example.xml"
Is there a way to do similar thing within request mock?

Please can you direct questions to the mailing list as per the README, thanks.

i want to know how to pass xml in request
like in reponse "bodyFileName"


Removing 'timeout' from func.yaml does not take effect

Description

Steps to reproduce the issue:

fn init --runtime go --name test and fn -v deploy --app testapp --local
fn inspect fn testapp test shows timeout value as 30 - this is fine
update timeout in func.yaml (to 60) and re-deploy the app. fn inspect fn testapp test shows timeout value as 60 - so far so good
remove the timeout from func.yaml and re-deploy the app

Describe the results you received:
fn inspect fn testapp test still shows timeout value as 60
Describe the results you expected:
fn inspect fn testapp test should show timeout value as 30 (default value)
Output of fn version (CLI command):
Client version: 0.5.23 is not latest: 0.5.26

Additional environment details (OSX, Linux, flags, etc.):
Linux

Hi, your assumption is quite incorrect. Because when you delete the timeout from the func.yaml and calling fn deploy you're basically saying to Fn update my function with no timeout changes, that's why the timeout will remain as it was from the last update.
So, IMHO, it's not a bug but expected behaviour.

this is a dupe of https://github.com/fnproject/fn/issues/803 - thanks for filing, feel free to add to discussion there, it's something we've/we're considering solutions to


[Request] Helm chart for the operator

Describe the feature
Hi, I would like to install operator using helm chart - can you provide one ? Or is there any already existing
Anything other information?
N/A

There is no such thing existing, we have either the Operator or the Helm Chart available. Can you describe what your requirements are that you want the Operator functionality but installable via Helm Chart? Maybe there is another way to accomplish what you need.

I wanted to install operator via helm as I do not use OLM - like Prometheus operator have helm chart or manifest for its installation. I did not notice any manifest to setup cryostat operator as well.
My use case is simple, wanted to explore how much easier it would be to install cryostat via CRD however I do not see a way to install operator via helm of kubectl apply

I wanted to install operator via helm as I do not use OLM - like Prometheus operator have helm chart or manifest for its installation. I did not notice any manifest to setup cryostat operator as well.
My use case is simple, wanted to explore how much easier it would be to install cryostat via CRD however I do not see a way to install operator via helm of kubectl apply

The operator is built as a Go-based operator. See https://sdk.operatorframework.io/docs/building-operators/golang/. Thus, it can't be installed with helm. I don't know if there is any plan for helm-based operator.
But if you are looking for a single yaml file to use with kubectl apply. There is a Make target deploy (i.e. run make deploy) that builds all necessary resources into a single k8s yaml and kubectl apply it. You can also build the yaml yourself with kustomize: kubectl kustomize config/default. Note: the namespace is default to: cryostat-operator-system. Though, this requires you to checkout the source code.

There are no current plans for such a "helm chart to install the operator". It could be something we investigate, but adding yet another way to install and configure everything seems like it would be a relatively heavy maintenance burden on top of all the rest of the work to develop features and things. It could maybe be something we maintain on a best-effort basis upstream if someone provides it to begin with.
Distributing a bundle.yaml seems simple enough and just uses existing Operator tooling, so I can see that being a pretty realistic goal. We could just have a release action that generates this YAML bundle and publishes it somewhere.

Distributing a bundle.yaml seems simple enough and just uses existing Operator tooling, so I can see that being a pretty realistic goal. We could just have a release action that generates this YAML bundle and publishes it somewhere.

Looks related to #144

It could maybe be something we maintain on a best-effort basis upstream if someone provides it to begin with.

Right, I was also thinking of having support for upstream only.

I think #144 got left by the wayside because our Helm chart came into existence not too long after too. That along with getting the Operator published on OperatorHub achieved the original goal there of a "one-click install", since at the time the only installation method available was to clone the git repo and use the Makefile.

Ah make sense! I think it would be nice to solve #144 too to cover above case of "one-click install" with helm/static file. It's pretty common on upstream k8s. For example, cert-manager, nginx, aws acks, and even OLM itself, all distribute a static yaml for use with kubectl apply.
For static field, the only problem I am seeing though is the namespace of resources. Some have annotations that reference "namespace/resource-name", which would be hard to support unless namespace is hard-coded.

It could maybe be something we maintain on a best-effort basis upstream if someone provides it to begin with.

https://github.com/arttor/helmify. This looks promising. It might be possible to generate helm chart from static manifest.

If you are looking for a single yaml file to use with kubectl apply. There is a Make target deploy (i.e. run make deploy) that builds all necessary resources into a single k8s yaml and kubectl apply it. You can also build the yaml yourself with kustomize: kubectl kustomize config/default. Note: the namespace is default to: cryostat-operator-system. Though, this requires you to checkout the source code.

@grzesuav Seems like you can avoid cloning the repo with to get a static manifest. Again, the namespace is hard-coded to cryostat-operator-system.
# Replace ref with any version tag or branch
kubectl kustomize https://github.com/cryostatio/cryostat-operator.git/config/default?ref=v2.4.0

Thanks for the comments, I named the issue Helm chart as wasn't aware there is a static manifest or kustomize here, thanks for the pointers !
Re. helming the static manigest, I use sth like
kubectl kustomize ./kustomize | kubectl slice --output-dir ./helm/argocd/templates/base

however this helmify look like doing better job, will try it out.
One last thing, if you can add to README or to the documentation that there is static manifes/kustomize, it would be great !


Draw image with configured opacity

Fixes #10655
Bug was introduced here: 542b77eef89d389c36aa566cce02a33ec4bfc6d5

We should add a rendering test here to prevent regression.

Thanks for the nice examples (in #10655), the fix, and the additional test, @M393.
I added a rendering test to your branch that uses an icon symbolizer with 0.5 opacity.
On a separate subject, we should discuss what to do with opacity for RegularShape styles (including Circle).  Your example uses setOpacity to change the opacity.  If this works, then it would make sense if the opacity provided to the constructor worked (it is currently set to 1 regardless of what is passed).

Tests fail with
Failed to launch the browser process!
Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"
[775:775:0219/013522.423113:ERROR:browser_main_loop.cc(1512)] Unable to open X display.

Restarting...

Looks like we have a problem running tests with the circleci/node:latest-browsers image.  I'll debug later...


Changing dependency path doesn't invalidate node_modules

Repro: change "bs-platform": "esy-ocaml/bucklescript#esy" to "bs-platform": "/path/to/local/bucklescript", then do esy install while having an existing node_modules.

I think the current approach is that it creates the build cache key on the dependency's version number and package name. So if you bump the version number I suspect it will work, but I think we might want to hash on either the package contents, or the hash of mtimes on files within the package (which might be faster and sufficiently unique - as well as detecting when you modify a file).

BTW I'm not modifying the package's content (they're symlinked and I wouldn't touch them anyway). I'm switching from a remote git url to a local one. What you said applies if I keep the same path but changes some content. In this case, the path's changed.

Also, since we'll be finding little bugs/fixes in the build cache, maybe we should have an escape hatch called esy purge myPattern, which will say:
> esy purge myPattern

There are (3) build caches for packages matching "myPattern":
---------------------------------------------------------------
  myPattern-1.0.0
  └─ ~/.esy/store/_build/myPattern-1.0.0-83b5bc03c594d2
  myPattern-1.0.1
  └─ ~/.esy/store/_build/myPattern-1.0.1-9877bc03c594d0
  myPatternxyz-2.0.0
  └──   ~/esy/store/_build/.....

And two other packages that depend on those cached builds:

  dependsOnThatPackage-2.0.0
  └─ ~/.esy/store/_build/blah
  anotherThingThatDependsOnThem-4.0.0
  └─ ~/.esy/store/_build/blah

╭───────────────────────────────────────────────────────────────╮
│ WARNING ┊                                                     │
│   ♼     ┊  Would you like to purge the above packages? [Y/n]? │
│ WARNING ┊                                                     │
╰───────────────────────────────────────────────────────────────╯
Answer: [Y/n]?


[Bug] Media Element Not Playing MP3s.

Description
If I have the IsVisible to false in the media element, then it will not play any songs.
Also, even if IsVisible is true, if i don't specify the area to be filled and expanded, then it won't play songs.
There are many cases where a person may want to play a song but not see anything else so other controls can be there and they can still play the song.  In the WPF MediaElement, if Visibility is hidden, a person can still play a song.  Same thing should happen even with xamarin forms.
Steps to Reproduce

Set IsVisible to false.
Set source to song.

Expected Behavior
Still hear the song because you put the path in there and wanted to play the song.
Actual Behavior
Nothing happens.  No errors.  But nothing plays either.
Basic Information

Version with issue:

Last known good version:

IDE:

Platform Target Frameworks:
Any android version.

Nuget Packages:

Affected Devices:

Screenshots

Reproduction Link
Workaround

Hi, any update on this? I am also facing the same issue.