Check and fix the example with the default theme

Not sure if we have any dataset left, either we update one of the examples to use the new default widgets design or we create a new example.
We could also use the npm dataset: http://npmjs-instant-search-demo.heroku.com/
And also fix a few bugs:

[ ] hierarchical menu: based on float left, it breaks the margin top of the elements below
[ ] searchbox: no background
[ ] numeric range: inputs are too big

That's a neat idea to revive this dataset :D This way I'll have a convenient to know where it is. Also it'll speak to users :)

Isn't the dataset a little bit short about the widgets we can display?

Yes maybe,
keywords => refinement list
authors => refinement list
download group => sortBy
searchBox
hits
Is all I can think of right now

There is an hidden example in which we can iterate : docgen/src/examples/default-theme

React InstantSearch has been moved here: https://github.com/algolia/react-instantsearch
This issue has either been rewritten or placed inside our backlog.


Added Time and Space complexities to algorithms

This is in reference to the issue number #707

Although I have kept the Linear search algorithm the same, it is still not passing the test.

Although I have kept the Linear search algorithm the same, it is still not passing the test.

don’t worry i’ll take care of it.

Can you please merge the pull request?

Can you please merge the pull request?

I didn’t checked the pr yet. Will check it tomorrow.


Create a merchant system?

With my async campaign, it could be cool to create a merchant type for characters and give them inventory that is purchaseable!
Basically:

allow characters to be toggled as a merchant
allow assigning inventory
/ command for seeing merchants
/ command for purchasing from merchant
/ command for entering a roll and getting a discount
/ command to trade? I think that needs to be roleplayed by DM
/ command for transactions? Might be nice but idk necessary. Greater load for storage too.

maybe a new channel to log that? No storage on server-side

inventory class: { name, cost, discountThres?, discount?, stock = 1, description }

Dude I just found your bot. The description alone is mind blowing. I think you have something big. I currently run an rp server for GTA I’ve just added your bot, and I’d love to keep contact for updates and just common communication. I think this is going to be my fav bot!

@Ninety1zeus Happy to hear you are enjoying my bot!! 😁 I'm open to suggestions or fixes you want too! This is very much something I try to get to in my free time, so I may be slow haha.
I have a server for the bot here https://discord.gg/xjQGEwX5, feel free to join!


Adding support for SpatiaLite?

Curious, any plans to add support for SpatiaLite?
SpatiaLite

Not directly, no.
SpatiaLite doesn't require any new C interfaces, it is commonly used through virtual tables and custom functions which are available through the sqlite3 package by just running SQL queries.
I don't actually know whether SpatiaLite is a full sqlite3 fork or a loadable extension, but I don't have the capacity to distribute it via something like spatialite_flutter_libs. But if you find another way to include SpatiaLite libraries, you can likely use it with this package.


Pods stuck in terminating state after AMI amazon-eks-node-1.16.15-20201112

What happened:
Since upgrading to AMI 1.16.15-20201112 (from 1.16.13-20201007), we see a lot of Pods get stuck in Terminating state. We have noticed that all of these Pods have readiness/liveness probes of type exec.
What you expected to happen:
The Pods should be deleted.
How to reproduce it (as minimally and precisely as possible):
Apply the following YAML to create a deployment with exec type probes for readiness/liveness:
$ cat << EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 20
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        readinessProbe:
          exec:
            command:
            - /bin/sh
            - -c
            - "true"
          failureThreshold: 5
          initialDelaySeconds: 1
          periodSeconds: 1
          successThreshold: 1
          timeoutSeconds: 1
        livenessProbe:
          exec:
            command:
            - /bin/sh
            - -c
            - "true"
          failureThreshold: 5
          initialDelaySeconds: 1
          periodSeconds: 1
          successThreshold: 1
          timeoutSeconds: 1
EOF

and once all Pods become ready, delete the Deployment:
$ kubectl delete deployment nginx-deployment

Anything else we need to know?:
We also tried the above with a 1.17 EKS cluster (AMI release version 1.17.12-20201112) and it exhibits the same behavior.
Environment:

AWS Region: eu-central-1
Instance Type(s): m5d.xlarge
EKS Platform version (use aws eks describe-cluster --name <name> --query cluster.platformVersion): eks.4
Kubernetes version (use aws eks describe-cluster --name <name> --query cluster.version): 1.16
AMI Version: 1.16.15-20201112

Same problem occurs on 1.17 on EKS Platform version eks.4

Also on EKS 1.17 platform version eks.2

Same issue on EKS 1.18 platform version eks.1

We also tested side-by-side deployments, one with liveness and readiness probes as above, and one without. The one without was able to terminate correctly, the one with the probes were stuck in Terminating state.

We are experiencing the same thing on EKS 1.17 (eks.2) with AMI version 1.17.12-20201112.

Reverting to amazon-eks-node-1.17-v20201007 ami version seems to resolve it for us

Not sure if its similar or not, but we are experiencing an issue on EKS 1.15 (eks.4) with AMI version 1.15.12-20201112, where the aws-node pods are repeatedly producing k8s events with the following message, we do not see this on the v20201007 ami
Message:             Readiness probe errored: rpc error: code = DeadlineExceeded desc = context deadline exceeded

@paxos-cs We are experiencing the same thing on 1.18. I think it's all related. We noticed the issue when we were using some automation to do kubectl exec commands inside the container and they would hang and never return. Terminating the pod also seems to hang.

Seems to be related to this https://github.com/moby/moby/issues/41352#issuecomment-728746859. Can someone run this on their node (if its not a production cluster) and let me know if this fixes the issue -
cat << EOF > upgrade-containerd.sh
#!/bin/bash
set -eo pipefail
docker ps
systemctl stop docker
systemctl stop containerd
wget https://github.com/containerd/containerd/releases/download/v1.4.1/containerd-1.4.1-linux-amd64.tar.gz
tar xvf containerd-1.4.1-linux-amd64.tar.gz
cp -f bin/c* /bin/
systemctl start docker
systemctl start containerd
systemctl restart kubelet
systemctl status docker
systemctl start containerd
systemctl status kubelet
docker version
docker ps
EOF
chmod +x upgrade-containerd.sh
sudo ./upgrade-containerd.sh

We are working on releasing a new AMI with containerd 1.3.2. Until then please rollback your worker nodes to the last AMI v20201007

We are working on releasing a new AMI with containerd 1.3.2. Until then please rollback your worker nodes to the last AMI v20201007

It's not possible to rollback to a previous AMI (or create a new nodegroup with an AMI that is not the latest) when using managed node groups. Do you have an ETA for the new AMI?

We are working on releasing a new AMI with containerd 1.3.2. Until then please rollback your worker nodes to the last AMI v20201007

It's not possible to rollback to a previous AMI (or create a new nodegroup with an AMI that is not the latest) when using managed node groups. Do you have an ETA for the new AMI?

We are rolling back Managed Nodegroup as well. The rollback should complete today. We will try to release the new AMI today as well but I will keep this issue updated. Appreciate the patience.

We are working on releasing a new AMI with containerd 1.3.2. Until then please rollback your worker nodes to the last AMI v20201007

It's not possible to rollback to a previous AMI (or create a new nodegroup with an AMI that is not the latest) when using managed node groups. Do you have an ETA for the new AMI?

We are rolling back Managed Nodegroup as well. The rollback should complete today. We will try to release the new AMI today as well but I will keep this issue updated. Appreciate the patience.

Thanks for the quick response. As a stopgap measure, is it possible to update the "latest marker" so that new managed nodegroups get created using the previous, working AMI?

Even on nodes with old ami, we are seeing this happen because our userdata script runs yum update -y which brings along containerd 1.4.0. we shall try 1.4.1 to see if that helps.

We've been battling with this ever since performing system updates last week. Our nodes essentially became time bombs after about a day and a half where we started getting this dockerd error in our logs: error: write unix /var/run/docker.sock->@: write: broken pipe, and then after a few hours the nodes start becoming unresponsive and workloads go haywire. Once it's in this state, it no longer allows us to terminate the workloads until the node has been restarted. We just reverted back to ami id  ami-00651928502cc143d last night and removed yum updates from our user data script in hopes of getting back to a stable system.

We ran into the same issue.
EKS cluster version: 1.18.9
We do create the a custom AMI w/ upgraded kernel version from the eks optimized AMI. But during bootup the instances seems to upgrade docker and containerd versions to 19.3.13 and 1.4.0 respectively. And these version seems to run into the following issue.

Deployments works as expected
Start seeing Readiness and Liveness probes failing on some of the containers
No pod restarts
Kubelet logs SyncErrors
Trying delete/evict the pods they get stuck in terminating state

Some diagnosis. On the working cluster for docker events for the probes show three events exec_create, exec_start and exec_die. But on the cluster with above-mentioned docker and containerd version after a while of deploying the pods, we see only exec_create and exec_start, and there are no exec_die events.
So we decided to pin the version of docker(to 19.3.6) and contairnerd(to 1.3.2) during AMI creation. And we deployed this AMI and we are clear of all SyncErrors, and pod terminating issues.

@dgarbus

It's not possible to rollback to a previous AMI (or create a new nodegroup with an AMI that is not the latest) when using managed node groups

Indeed. We have opened an issue for that (see https://github.com/awslabs/amazon-eks-ami/issues/435), which resulted to a open request in containers-roadmap (see https://github.com/aws/containers-roadmap/issues/810). Given the magnitude of the current problem, this missing feature becomes even more relevant now.

It looks like a new AMI has been released, hopefully this will solve these issues.

It looks like a new AMI has been released, hopefully this will solve these issues.

All managed nodegroups on release version 20201112 can now be upgrade to 20201117 to alleviate impact. If you create new nodegroups, they will automatically get 20201117 release version. Please let us know if you see any issues.

anyone still seeing pods stuck terminating? we're running fresh clusters with 1.15.11 ami v20201007, and still getting stuck pods.
could the issue be with latest patch version running on the control plane?
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T23:41:55Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15+", GitVersion:"v1.15.12-eks-31566f", GitCommit:"31566f851673e809d4d667b7235ed87587d37722", GitTreeState:"clean", BuildDate:"2020-10-20T23:25:14Z", GoVersion:"go1.12.17", Compiler:"gc", Platform:"linux/amd64"}```

we have other clusters still showing 1.15.11 for server version that do not show the issue

@jpke Can you check the containerd version running on your nodes? We're not aware of issues with the v20201007 AMI around pods getting stuck terminating, so could be unrelated to the most recent issue.

Thanks for the info. We've experienced the issue and it has gone away once we are on the 20201117 AMIs

We were seeing the same things mentioned above. The new AMI (20201117) solved it for us with the pinned containerd version at 1.3.2. Thanks all.

@jpke Can you check the containerd version running on your nodes? We're not aware of issues with the v20201007 AMI around pods getting stuck terminating, so could be unrelated to the most recent issue.

Thanks @mmerkes, that appears to have been the issue. We run sudo yum update -y during our build, which installed containerd 1.4.0, even when we rebuilt v20201007.
Containerd 1.4.1 gets installed now during yum update. No stuck pods so far.

@rtripat Curious to know how come this got past your QA or testing cycles? Doesn't seem like a deep-rooted corner case that it can't be caught? This impacted my production deployments bigtime today. :(

We upgraded our cluster two hours after AWS aknowledge the issue https://github.com/awslabs/amazon-eks-ami/issues/563#issuecomment-729065059 but we got upgraded to this already known broken version :/

If you want a quick workaround, you can set the amid in your property-set for the cluster, then deploy the worker node action again (in Windsor). The AMI you want depends on the regions, but for us-east-1, ami-03f1bd4665a6fd084 is the latest patched one.
By setting the amid in the parameter-set you force the automation to use the exact ami. That one is patched up, and has the latest kernel and security patches as well.
The automation will replace your nodes one by one, or the number specified in the asgMaxBatchSize parameter in the parameter-set for the cluster. The default is 1, but it can be overridden if you create/change that parameter.
-Don
From: Matthieu Paret<EMAIL_ADDRESS>Date: Thursday, November 19, 2020 at 5:18 PM
To: awslabs/amazon-eks-ami<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [awslabs/amazon-eks-ami] Pods stuck in terminating state after AMI amazon-eks-node-1.16.15-20201112 (#563)
Sent by an external sender
We upgraded our cluster two hours after AWS aknowledged the issue #563 (comment)https://github.com/awslabs/amazon-eks-ami/issues/563#issuecomment-729065059 but we got upgraded to this already known broken version :/
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/awslabs/amazon-eks-ami/issues/563#issuecomment-730642883, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAA6QAPAGNGWZXTU57OJPU3SQWDTNANCNFSM4TYKUPXQ.

All managed nodegroups on release version 20201112 can now be upgraded to 20201117. If you create new nodegroups, they will automatically get 20201117 release version. Please let us know if you see any issues.

@rtripat I can also confirm that the issue has been resolved for us since upgrading to version 20201117. Thanks for fixing this. I guess this issue can be closed now.
However, given the magnitude of this, I think you should increase the priority of https://github.com/aws/containers-roadmap/issues/810. It became apparent that users couldn't follow your proposed workaround of rolling back to version 20201007 (https://github.com/awslabs/amazon-eks-ami/issues/563#issuecomment-729065059) because there is no way to choose the version of the AMI to deploy in managed nodegroups.

Last Saturday, we upgraded our clusters in 4 production regions (AP, AU, EU, US) from v1.14 to v1.18 and nightmares happened.
The issue caused our many of pods in our zookeeper's clusters stuck in "Terminating" state and affected other clusters (Kafka clusters, SolrCloud clusters). Doing the "kubectl delete pod --force --grace-period=0 xxx" sometimes cause filesystem corruptions. We tried our bests to keep you systems up and running but it is a bad experience on upgrading EKS clusters. Positive things: the issue is fixed and we have another 1 more happy year living without the need of upgrading EKS clusters :)

All managed nodegroups on release version 20201112 can now be upgraded to 20201117. If you create new nodegroups, they will automatically get 20201117 release version. Please let us know if you see any issues.

@rtripat I can also confirm that the issue has been resolved for us since upgrading to version 20201117. Thanks for fixing this. I guess this issue can be closed now.
However, given the magnitude of this, I think you should increase the priority of aws/containers-roadmap#810. It became apparent that users couldn't follow your proposed workaround of rolling back to version 20201007 (#563 (comment)) because there is no way to choose the version of the AMI to deploy in managed nodegroups.

We are taking multiple steps to prevent recurrence of this issue. Specifically, we have added a regression test for this specific case which creates a container with HEALTHCHECK, monitors it’s liveness for a period of time and ensures a cleanup on termination. We are also working on changes to allow creating EKS Managed Nodegroup at any AMI version and mark them as Degraded  if they are on recalled AMI release versions.

We are taking multiple steps to prevent recurrence of this issue. Specifically, we have added a regression test for this specific case which creates a container with HEALTHCHECK, monitors it’s liveness for a period of time and ensures a cleanup on termination. We are also working on changes to allow creating EKS Managed Nodegroup at any AMI version and mark them as Degraded if they are on recalled AMI release versions.

That's great to hear, thank you @rtripat. I have also commented on the corresponding issue asking for an ETA.
Do you want me to close this issue as resolved, or are you going to do it?

the same problem for us:
AWS EKS 1.18.9 since ~ 2 weeks ago
Imagine the nightmares with horizontal pod scaler enable! so we disabled it and over-resize our nodes.
❯ kubectl version --short
...
Server Version: v1.18.9-eks-d1db3c

❯ kubectl get nodes
NAME                                         STATUS   ROLES    AGE     VERSION
ip-10-62-52-32.eu-west-1.compute.internal    Ready    <none>   5d22h   v1.18.9-eks-d1db3c
ip-10-62-53-209.eu-west-1.compute.internal   Ready    <none>   22h     v1.18.9-eks-d1db3c
ip-10-62-54-119.eu-west-1.compute.internal   Ready    <none>   22h     v1.18.9-eks-d1db3c
ip-10-62-59-119.eu-west-1.compute.internal   Ready    <none>   22h     v1.18.9-eks-d1db3c
ip-10-62-59-182.eu-west-1.compute.internal   Ready    <none>   47h     v1.18.9-eks-d1db3c
ip-10-62-65-227.eu-west-1.compute.internal   Ready    <none>   2d7h    v1.18.9-eks-d1db3c
ip-10-62-71-134.eu-west-1.compute.internal   Ready    <none>   21h     v1.18.9-eks-d1db3c
ip-10-62-72-42.eu-west-1.compute.internal    Ready    <none>   5d22h   v1.18.9-eks-d1db3c
ip-10-62-77-213.eu-west-1.compute.internal   Ready    <none>   2d6h    v1.18.9-eks-d1db3c

Thanks to @leokhoa  for the command kubectl delete pod --force --grace-period=0 xxx we mitigated a little bit the issue.
And we are trying the workaround described by @SaranBalaji90 in our ASG user data to mitigate until you release the new AMI.

@christiangda A new AMI was released last week, so if you can upgrade your AMI to 20201117, you should see the issue resolved.

Hi @mmerkes, thank you for the information, yesterday I notice this.
Today we updated all our EKS clusters and reactivated the Pod Autoscaler.

All managed nodegroups on release version 20201112 can now be upgraded to 20201117 or higher. If you create new nodegroups, they will automatically get 20201117 release version. Please let us know if you see any issues.

@rtripat, Can you confirm if this is fixed for self managed nodes with "yum update" or "apt update" on user data script? If not,  this is still open I guess.

@rtripat, Can you confirm if this is fixed for self managed nodes with "yum update" or "apt update" on user data script? If not, this is still open I guess.

Are you using EKS optimized AMI? You can upgrade to AMI version 20201117 or higher for self managed nodes too.

@rtripat , yes we were using version 20201117 for our self managed nodes and having "yum update -y" in our user data which upgraded the containerd to 1.4.1 and had the same issue. Right now, to come out of the issue, we are not doing update on instance startup.

20201117 was pinned to containerd 1.3.2 which doesn't have the bug. You dont need to update yum update -y on startup.
Can you post the output of rpm -q containerd from an instance where you did run yum update -y?

With "yum update -y" the output is containerd-1.4.1-2.amzn2.x86_64.
Without that the output is containerd-1.3.2-1.amzn2.x86_64.
But the actual issue is not fixed, right?

I see. You are asking for an EKS Optimized AMI where you get containerd-1.4.x? We just released one today which has containerd-1.4.1-2 and patch for CVE-2020-15257
https://github.com/awslabs/amazon-eks-ami/releases/tag/v20201126

Hi @rtripat, we have used the new AMI (v20201126)which was released yesterday. it looks to be fine and no issues noticed. Thanks.

FYI: You can create or update a Managed Nodegroup to any AMI release version.

@rtripat is you reply because something has changed for managed node groups since this issue was active and resolved?

Thanks @rtripat, this is great news!


spv server: Functional tests for basic commands

@shyba commented on Tue May 15 2018
Depends: #4
Add functional tests for all claim related commands, except resolve (which is a special case since it calls other commands, will be done in #6 ).

done in torba/lbrynet tests


[Backport-1.x]Introduce replaceRoutes() method and 2 new constructors to RestHandler.java (#947)

Add addRoutesPrefix() method to RestHandler.java

Signed-off-by: Azar Fazel<EMAIL_ADDRESS>Signed-off-by: cliu123<EMAIL_ADDRESS>Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

start gradle check


ingress-nginx: support CAPZ provider

https://gigantic.slack.com/archives/C02GLN41UP2/p1704891555705479

https://github.com/giantswarm/ingress-nginx-app/pull/587

https://github.com/giantswarm/ingress-nginx-app/releases/tag/v3.5.0


Missing libglib-2.0.so.0 and/or libpython3.11.so.1.0 when running on non-Python system

I will update this issue with more of the requested information, but since I have an idea already what's going wrong, maybe that much information isn't even required (not true any more: I am using system Python, so I guess nuitka should include system DLLs - right?). I am building with nuitka on some internal GitLab CI running Docker containers. I use the python:3.11 container for compilation and a non-Python container for testing. Testing fails with error messages such as

Exception ignored in: 'PySide6-postLoad'
Traceback (most recent call last):
File "/project/project-v0.1.2/PySide6-postLoad.py", line 21, in
ImportError: libglib-2.0.so.0: cannot open shared object file: No such file or directory

(standalone) or

./project-v0.1.2.bin: error while loading shared libraries: libpython3.11.so.1.0: cannot open shared object file: No such file or directory

(onefile).
$ python -m nuitka --version
2.0.1
Commercial: None
Python: 3.11.7 (main, Feb  1 2024, 05:02:20) [GCC 12.2.0]
Flavor: Unknown
Executable: /usr/local/bin/python
OS: Linux
Arch: x86_64
Distribution: Debian 12
Version C compiler: /usr/bin/gcc (gcc 12).

How did you install Nuitka and Python

Pulling docker image python:3.11 ... and pip install nuitka==2.0.1 PySide6-Essentials=6.6.1

Also supply a Short, Self Contained, Correct, Example

This is not easy. I compile on one container and run on another (both Debian-based).

Provide in your issue the Nuitka options used

python nuitka.py --standalone/--onefile with nuitka.py like this:
# nuitka-project: --static-libpython=no
# nuitka-project: --enable-plugin=pyside6
# nuitka-project: --nofollow-import-to=tkinter
# nuitka-project: --noinclude-default-mode=error

# nuitka-project: --include-module=pydicom.encoders.gdcm
# nuitka-project: --include-module=pydicom.encoders.pylibjpeg

# nuitka-project-if: {OS} == "Linux":
#   nuitka-project: --output-filename=project.bin
#   nuitka-project: --linux-icon=project/icon/favicon.ico
#   nuitka-project: --noinclude-pytest-mode=allow
#   nuitka-project: --noinclude-unittest-mode=allow
#   nuitka-project: --include-package=_pytest
#   nuitka-project: --include-package=pytestqt
#   nuitka-project: --include-module=PySide6.QtTest
#   nuitka-project: --include-module=pytest_order.plugin
#   nuitka-project: --include-module=project.test_project
#   nuitka-project: --include-data-file=pyproject.toml=./
#   nuitka-project: --include-data-file=conftest.py=./
#   nuitka-project: --include-data-file=project=project/=**/test_*.py
#   nuitka-project: --include-data-dir=example=example
#   nuitka-project: --include-data-dir=test=test
#   nuitka-project: --nofollow-import-to=doctest
#   nuitka-project: --no-deployment-flag=self-execution

# nuitka-project: --assume-yes-for-downloads

# nuitka-project-if: "CI" in os.environ:
#   nuitka-project: --show-progress
#   nuitka-project: --show-memory
#   nuitka-project: --show-scons
#   nuitka-project: --show-modules

There seems to be no code associated with this, the container you are using seems to have an unsupported flavor of Python, I don't think I want or can add support for every containerized Python there is.
For PyPI packages, system DLLs are not included. The glib one seems to be a requirement of the PyPI package of PySide6, programs won't run without a minimal set of dependencies installed.

the container you are using seems to have an unsupported flavor of Python, I don't think I want or can add support for every containerized Python there is

That's surprising - I seem to be using the python "Docker Official Image"s. So I had expected if any Docker images would be supported, it must at least be those ones.
If you agree that this Docker image should be supported, I might come up with a small Dockerfile that recreates the problem.

 In that case recently, the link libraries needed for embedding Python were just not present, unless you unpack them first.
For creating standalone software, Debian bookwork is like the worst choice to make, for running it, probably yes, but then why use standalone mode, if you run inside an image that already has it all.
The glib issue is one of the target system though. If I am not mistaken, that's not a DLL that you are allowed to bring along and expect to work well with the OS you are bringing it to, it has to come from there.
Building on latest Linux is not recommended for many reasons, not the least being that the Python library compiled for new OS is not going to like older systems a lot. In Nuitka commercial I have a tool to build inside an old container so it works on old systems too: https://nuitka.net/doc/commercial.html which does this automatically. But basically you ought to build on CentOS 7 or very old Debian, but for later I am not entirely sure how good it is I fear not as portable. I don't know when, but eventually run-inside-nuitka-container should grow into a solution that allows you to use CentOS 8 for compilation transparently.

With Debian, you do not have to install recommended packages, which is default, and that will likely make it a lot smaller. Read the docs of apt on that.
Integrating with a Linux desktop, for Qt requires that desktop to be present. If there is no glib, X11 client, wayland libs, that kind of thing, that's kind of hard to do. Bringing those desktop libraries along yourself, you can try it, but your chances of it working are going to vary. Linux standalone is kind of weak, yes, I agree. That's probably why desktops use other OSes usually. You can use flatpaks and what not to deploy your software, but I don't care.
Also popularity of a docker container means nothing to me, if the purpose doesn't align with requirements and purposes of Nuitka. It obviously has one user too few as otherwise that user would contribute the necessary changes to make it work. I am not that user at this time.


Upgrade silently fails if you have a groups email address book policy

Took quite some time running this down with a support case, but if you have an email address book policy that includes GroupMailbox (created with -IncludeUnifiedGroupRecipients), your groups will fail to upgrade without throwing any errors.
It is necessary to remove the addressBookPolicy in order for the upgrade to succeed.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e592c000-368e-f430-75ca-51d4c4b0c831
Version Independent ID: 7e16242b-dcdf-1c57-83e2-b67c4118bbc7
Content: Upgrade-DistributionGroup (exchange)
Content Source: exchange/exchange-ps/exchange/users-and-groups/Upgrade-DistributionGroup.md
Service: exchange-powershell
GitHub Login: @chrisda
Microsoft Alias: chrisda

@dsolodow, thanks for the information. I updated the topic.


[improve][doc] Improve code snippets and fix typo/grammar issues

Motivation
To improve the developer experience and make the whole doc set grammar-issue-free, this PR targets to cover all the doc files in the master branch and catch up with the 2.11.0 release, so that the upcoming latest version can also benefit.
Modifications

Improve code snippets:

remove $ to make copy&paste easy.
remove the first/last empty lines to make line numbers accurate.
correct/add language-specific highlights

Fix grammar issues and typos (synced to 2.8.x/2.9.x/2.10.x).

Documentation

[x] doc

Ping @Anonymitaet @Technoboy- for review.

@Anonymitaet @Technoboy- thanks for your approval. Can it be merged as soon as possible? Otherwise, there might be endless conflicts with other contributions to docs.


Update README contents

Like title

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


Initial Sizing

Title
Initial Sizing  Guidance
Description
CockroachDB cluster is elastic in that the number of nodes in the cluster can be increased or decreased at any time.  The elasticity de-risks the initial planning on sizing the cluster.  The sizing is typically performed for pricing and budgetary estimates and to right-size a POC and initial starting environment.
After the initial environment has been used, real-world measurements can be used to calibrate the sizing.  The initial sizing requires adjustments after observing nodes' resource usages such as CPU, RAM, Disk, and Network.  Adjustments are required for user response time, application throughput, and availability as well.  If the cluster was undersized, add more nodes.  If the cluster was oversized, remove the unneeded nodes.  The tuning of applications and database objects can have a significant impact which is not addressed here.
With the elasticity in mind, iterative steps for sizing is described here.  Each successive step results in incremental accuracy.  The first method is capacity based which is easy to use.  The 2nd method is model based which requires matching the application to a known model.  The 3rd method is simulation based which requires running the actual application.
Outline
The capacity based method is a process of estimating platform resource requirements (CPU, RAM, disk, network) of a planned application.  Technical descriptions of the application’s requirements are used and thus this is an ”educated guess” rather than a precise calculation.  The model based method simplifies the application by taking the most germane and the most critical portions of the application.  This allows controlled experiments and what-if scenarios that are impossible with the actual application.  This method can be highly effective once ratios hav been established to calibrate to the actual workload.
The capacity based method uses the online tool called CockroachDB Survival. The tool simulates survivable failures in different homogeneous network topologies in a CockroachDB cluster.  Based on this, CockroachDB Survival will produce minimal starting hardware sizing following the CockroachDB Platform Provisioning and Sizing Best Practices.
The model based method uses a downloadable tool called CockroachDB Workload.  The tool has about a dozen different industry workloads, such as YCSB and TPCC.  A workload is selected that resembles the target workload with database capacity and concurrency.  Using the selected workload, start with the configuration determined from the capacity method.  After reviewing the performance profile, increase or decrease the numbers of nodes until the desired goal is reached.
The simulation based method uses the actual workload in the testing environment.  Again, start with the configuration determined from the capacity method and or model.  This allows a set of calibration ratios to be built so that capacity and model based methods can be used with higher accuracy in the future.  After reviewing the performance profile, increase or decrease the number of nodes until the desired goal is reached.
Below are examples of the capacity and CockroachDB workload based methods:

Capacity based method

CockroachDB workload TPC-C model based method:

Expected Audience
Architect, Developer, Operator

@taroface not really sure if this falls into deployment/operations so feel free to re-route if necessary.

Relates to #7818.


Users getting logged on as others after seeing 502 bad gateway error

Frontend Deployment type

[X] Cloud Foundry Application (cf push)
[ ] Kubernetes, using a helm chart
[ ] Docker, using docker compose
[ ] Docker, single container deploying all components
[ ] npm run start
[ ] Other (please specify below)

I have Stratos deployed from the stable branch as of Feb 6.  This is deployed to a very heavily used CF foundation.
We have had two users report a potential security issue where they received a 502 Bad Gateway error when trying to log into Stratos.  When they hit refresh on their browser window (Chrome) they were logged into the Stratos UI but as another user who is in an org that they are not a member of.  I think this is a serious security flaw.  I am unable to recreate it but I have screenshots from the user that backs up the claim.

@cwb124 Okay - I'll need your help to get to the bottom of this - its not something we've encountered but we definitely need to understand what issue is here as clearly as you describe it there is a security problem.
Are you able to share any further information to help diagnose?
What would really help is if you can using the Chrome browser, open the developer tools, go to the network tab and check 'Preserve Log'. If you can then reproduce the issue in the browser and then export the network log to a HAR file, so we can take a look - you can do this by right-clicking on any of the network requests on the left and choose "Save as HAR with content". If you could share that with us, that would be very helpful.
Otherwise, would it be possible to for us to arrange to meet with you or one of your users and user a shared session to observe and diagnose the issue as it happens for them?

We have communication out for users to let us know if they experience it.  We've been using Stratos for the better part of a year and I've only had this issue reported to us twice but both were reported in the last week or so.  My team is unable to reproduce so I am not sure where we go from here.  I apologize for the vagueness of this bug and the lack of logs/data but will do our best to get something in the event it happens again.

@cwb124 Couple of quick question to help us attempt to reproduce ...

How many instances does the Stratos cf application have?
Is there an external database service linked to the Stratos application?

5 instances of Console in the particular environment where we saw this happen twice.  We haven't seen this reported in any of our other 7 sites that use Stratos btw, but this one is the heaviest used.  No external database linked.

@cwb124 are you using SSO for login, or the Stratos username/password?

No SSO in our environments.

Addressed in 2.3.0


Add flag to omit default case in getSwitchClauseTypeOfWitnesses

In light of #32695 the code that was ensuring that the cast was safe is now checked by the caller of isExhaustiveSwitchStatement. Rather than worrying about whether the caller has the necessary invariants in place to make the cast safe, just handle it directly.

I think #32695 has fixed some other bugs which are causing lint errors for now redundant assertions.


Add issue templates

I propose to add these issue templates to ensure we get more context information when bugs are reported or questions get asked.

This looks great, @petergtz.  Thank you for setting this up.
A quick question, do we want to encourage people to ask "questions" (or some kinds of questions?) on the discussions board?

A quick question, do we want to encourage people to ask "questions" (or some kinds of questions?) on the discussions board?

@emrekiciman I see the discussions board more as a space for more fundamental or conceptual discussions, not so much as a "need help" forum. Of course, this is purely based on gut feeling and I'm open to counter proposals. Maybe it's also that I find them a bit too clunky. Not sure, I just haven't really gotten used to them yet. Do you have a specific preference?


accuracy of k400

I have read the log file of 8x1x4. I find that the error rate of val dataset in the training process is 31.35 and the test accuracy rate of 8x1x1  is 74.41.  As far as I am concerned, the val dataset and the test dataset are the same. So I want to know why the two results are different. Thanks for your reply.

Thanks so much. I understood.

As there is no more activity, I am closing the issue, don't hesitate to reopen it if necessary.


Remove newtonsoft ref and sharedsource false flag

Cleanup

Note: draft PRs don't show merge conflicts which prevent ci checks from running

@ajcvickers can you review?


Language translation issue with user location

The country shows up in Spanish on the English page of user profiles:

for me, whatever is the language I choose on the website it always shows in English

@jcr looks the address fields simply aren't configured to be translatable, do they need to be?

After further testing last week, this actually now works as expected.
The Location field will translate in the language in which the Organization is displayed.
Note for Organizations:

if they have no language (neutral) they will display in EN and all other language - the location fields will be in EN as well.
if they have a specific language they will only display in that language and the location will be translated (ie: if you set and org to EN and do not translate it, it will not show up in the other lang.)


Fix release notes link

Because the release notes file name has an underscore (as it is embedded in the CF docs as a partial), a link to the release notes in the spec doesn't work both in this repo and in the CF docs.
Moved the link out of the spec, and added it to the README. In the CF docs we'll add a link to the release notes by other means.

Both links are displayed in the same line. Add a line break and we can merge it.

Fixed.

LGTM


refactor(rust): refactor tuple to ApiTransport struct

Current behavior & Proposed changes
fixes #4442
This commit introduces an implementation of ApiTransport struct, which allows to get rid of boilerplate code.
Checks

[x] All commits in this Pull Request are signed and Verified by Github.
[x] All commits in this Pull Request follow the Ockam commit message convention.
[x] I accept the Ockam Community Code of Conduct.
[x] I have accepted the Ockam Contributor License Agreement by adding my Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate pull request to the build-trust/ockam-contributors repository. The easiest way to do this is to edit the CONTRIBUTORS.csv file in the github web UI and create a PR, this will mark the commit as verified.

During previous CI run some tests related to kafka failed for some reason. This might be due to the changes of command module, although no new logic has been added. It might also be due to the discrepancy of the naming mentioned above. I published a could of changes to fix clippy issues, but those errors might occur again. If they do, do you have any thought how to fix them?

I checked logs of the failed tests, here they are:
Failed bats test
> bats ockam/ockam_command/tests/bats/unit.bats -f "tcp connection - CRUD"
unit.bats
 ✗ tcp connection - CRUD
   (from function `assert_success' in file /opt/homebrew/lib/bats-assert/src/assert.bash, line 114,
    in test file ockam/ockam_command/tests/bats/unit.bats, line 213)
     `assert_success' failed

   -- command failed --
   status : 70
   output (2 lines):
     Version 0.82.0, hash: ee2b35ce6f7d0be59276a08f815f09f8e469c17c
     An error occurred while processing the request. Status code: 500 InternalServerError. Message: failed to handle request: operation failed for address 0#<IP_ADDRESS>:5000
   --

1 test, 1 failure

it fails on log deletion here:
  # Delete the connection
  id=$($OCKAM tcp-connection list --node n1 | grep -o "[0-9a-f]\{32\}" | head -1)
  run "$OCKAM" tcp-connection delete --node n1 "$id"  # <-- fails
  assert_success

2023-03-13T07:20:34.132039Z  INFO ockam_node::worker_builder: Initializing ockam worker '0#8d91aa38cc7c56290e59c8bce68882c4' with access control in:LocalSourceOnly out:DenyAll
2023-03-13T07:20:34.132364Z DEBUG ockam_node::router::start_worker: Starting new worker '0#8d91aa38cc7c56290e59c8bce68882c4'
2023-03-13T07:20:34.133589Z DEBUG ockam_node::router: Setting cluster on address 0#8d91aa38cc7c56290e59c8bce68882c4
2023-03-13T07:20:34.133750Z  INFO ockam_node::processor_builder: Initializing ockam processor '0#adc6ab1de3432c7f854551c2ee8bbd61' with access control in:DenyAll out:LocalOnwardOnly
2023-03-13T07:20:34.133901Z DEBUG ockam_node::router::start_processor: Starting new processor '0#adc6ab1de3432c7f854551c2ee8bbd61'
2023-03-13T07:20:34.133951Z DEBUG ockam_node::router: Setting cluster on address 0#adc6ab1de3432c7f854551c2ee8bbd61
2023-03-13T07:20:34.134152Z DEBUG ockam_transport_tcp::workers::listener: Waiting for incoming TCP connection...
2023-03-13T07:20:34.134586Z DEBUG ockam_api::nodemanager::service: request id=eec1625a method=Some(Post) path=/node/tcp/connection body=true
2023-03-13T07:20:34.134699Z  INFO ockam_api::nodes::service::transport: Handling request to create a new transport: TCP, Remote connection, <IP_ADDRESS>:5000
2023-03-13T07:20:34.134768Z DEBUG ockam_transport_tcp::workers::sender: Connecting addr=<IP_ADDRESS>:5000
2023-03-13T07:20:34.136442Z DEBUG ockam_transport_tcp::workers::sender: Connected addr=<IP_ADDRESS>:5000
2023-03-13T07:20:34.136761Z  INFO ockam_node::worker_builder: Initializing ockam worker '0#64bd3f84558f8efd109bb74bb7436d53' with access control in:LocalSourceOnly out:DenyAll
2023-03-13T07:20:34.137123Z DEBUG ockam_node::router::start_worker: Starting new worker '0#64bd3f84558f8efd109bb74bb7436d53'
2023-03-13T07:20:34.137281Z  INFO ockam_node::processor_builder: Initializing ockam processor '0#ae10afad2760a2a5c5e6ee2e84c36e9b' with access control in:DenyAll out:LocalOnwardOnly
2023-03-13T07:20:34.137469Z DEBUG ockam_node::router: Setting cluster on address 0#64bd3f84558f8efd109bb74bb7436d53
2023-03-13T07:20:34.137547Z DEBUG ockam_node::router::start_processor: Starting new processor '0#ae10afad2760a2a5c5e6ee2e84c36e9b'
2023-03-13T07:20:34.137598Z DEBUG ockam_node::router: Setting cluster on address 0#ae10afad2760a2a5c5e6ee2e84c36e9b
2023-03-13T07:20:34.137812Z DEBUG ockam_api::nodemanager::service: responding re=eec1625a method=Some(Post) path=/node/tcp/connection
2023-03-13T07:20:34.139783Z  INFO ockam_transport_tcp::workers::receiver: Connection to peer '<IP_ADDRESS>:59904' was closed; dropping stream
2023-03-13T07:20:34.140342Z  INFO ockam_transport_tcp::workers::sender: Stopping sender due to closed connection <IP_ADDRESS>:59904
2023-03-13T07:20:34.140404Z DEBUG ockam_node::context: Shutting down worker 0#8d91aa38cc7c56290e59c8bce68882c4

During previous CI run some tests related to kafka failed for some reason.

There are some known issues around the kafka tests and they are not related to this PR, so don't worry about them, we can retry that CI job until it passes. I'll let the team know about this so we can fix it as soon as possible.

I checked logs of the failed tests, here they are:

I think that might be happening because the output changed. Could it be related to the bug you found regarding the worker_address/socket_address argument order issue?

Could it be related to the bug you found regarding the worker_address/socket_address argument order issue?

I tried to change the order of the arguments in ockam_commands file, but it didn't affect the result.

I think that might be happening because the output changed

I am not sure, because it fails due to the internal error.
I just realized that I published wrong server logs. Here are the correct ones:
2023-03-13T08:40:41.427349Z DEBUG ockam_transport_tcp::workers::listener: TCP connection accepted
2023-03-13T08:40:41.427558Z  INFO ockam_node::worker_builder: Initializing ockam worker '0#893bb756fc5aa8dcc612373c66c1d139' with access control in:LocalSourceOnly out:DenyAll
2023-03-13T08:40:41.427674Z DEBUG ockam_node::router::start_worker: Starting new worker '0#893bb756fc5aa8dcc612373c66c1d139'
2023-03-13T08:40:41.427782Z DEBUG ockam_node::router: Setting cluster on address 0#893bb756fc5aa8dcc612373c66c1d139
2023-03-13T08:40:41.427848Z  INFO ockam_node::processor_builder: Initializing ockam processor '0#db58acb6452e1b112e85ff6d279088ad' with access control in:DenyAll out:LocalOnwardOnly
2023-03-13T08:40:41.427949Z DEBUG ockam_node::router::start_processor: Starting new processor '0#db58acb6452e1b112e85ff6d279088ad'
2023-03-13T08:40:41.428015Z DEBUG ockam_node::router: Setting cluster on address 0#db58acb6452e1b112e85ff6d279088ad
2023-03-13T08:40:41.428119Z DEBUG ockam_transport_tcp::workers::listener: Waiting for incoming TCP connection...
2023-03-13T08:40:41.428901Z DEBUG ockam_api::nodemanager::service: request id=678c3b6e method=Some(Delete) path=/node/tcp/connection body=true
2023-03-13T08:40:41.429004Z  INFO ockam_api::nodes::service::transport: Handling request to delete transport: 61f255520d7a87e503f6fc0c0e99a530
2023-03-13T08:40:41.429048Z DEBUG ockam_node::context: Shutting down worker 0#<IP_ADDRESS>:5000
2023-03-13T08:40:41.429167Z ERROR ockam_api::nodemanager::service: failed to handle request re=678c3b6e method=Some(Delete) path=/node/tcp/connection code=[Origin::Node; Kind::NotFound] cause=Some(Address(0#<IP_ADDRESS>:5000))
2023-03-13T08:40:41.429243Z DEBUG ockam_api::nodemanager::service: responding re=678c3b6e method=Some(Delete) path=/node/tcp/connection
2023-03-13T08:40:41.431875Z  INFO ockam_transport_tcp::workers::receiver: Connection to peer '<IP_ADDRESS>:60264' was closed; dropping stream
2023-03-13T08:40:41.432069Z  INFO ockam_transport_tcp::workers::sender: Stopping sender due to closed connection <IP_ADDRESS>:60264
2023-03-13T08:40:41.432098Z DEBUG ockam_node::context: Shutting down worker 0#893bb756fc5aa8dcc612373c66c1d139

Okay, it seems that I found the problem in my code. I was passing socket_address instead of worker_address to NodeManager disconnect function. Now the test is passing

I have some difficulties solving a conflict without creating an additional commit. Could you give me a hint?

I have some difficulties solving the conflict without creating an additional commit. Could you give me a hint?

I'm not sure I understand what is the problem you are facing exactly, but I'll cover the whole rebasing process in case it can help you figure out what you are missing.
Here is the process I use to follow (it's pretty much the same as described at here):
git checkout develop
git pull --rebase # To sync the `develop` branch
git checkout jungletryne/refactor_api_transport
git rebase --develop # To rebase your commits on top of `develop`; a merge conflict will occur here
# Open and edit the conflicts at ockam_command/src/node/create.rs
git add .
git commit -m "refactor(rust): refactor tuple to api-transport struct"
git rebase --continue

If you end up with two commits, you can squash them into a single one and force-push the result.

I have some difficulties solving the conflict without creating an additional commit. Could you give me a hint?

I'm not sure I understand what is the problem you are facing exactly, but I'll cover the whole rebasing process in case it can help you figure out what you are missing.
Here is the process I use to follow (it's pretty much the same as described at here):
git checkout develop
git pull --rebase # To sync the `develop` branch
git checkout jungletryne/refactor_api_transport
git rebase --develop # To rebase your commits on top of `develop`; a merge conflict will occur here
# Open and edit the conflicts at ockam_command/src/node/create.rs
git add .
git commit -m "refactor(rust): refactor tuple to api-transport struct"
git rebase --continue

If you end up with two commits, you can squash them into a single one and force-push the result.

Thanks for help! I managed to solve the conflict

Thank you for the opportunity to contribute to your project!
Although CI fails with We require that all commits in a pull request are signed and Verified by Github. Do I need to do something with it?

Hi @JungleTryne. Yes all your commits need to be signed. It is actually mentioned in the first item in the PR checklist :-).
You can follow the instructions on the Github page to learn how to do it. The cool thing that, once you do it, you won't ever have to think about it again 🎸.

Hi @JungleTryne. Yes all your commits need to be signed. It is actually mentioned in the first item in the PR checklist :-). You can follow the instructions on the Github page to learn how to do it. The cool thing that, once you do it, you won't ever have to think about it again 🎸.

Hi @etorreborre! I am a bit confused because I noticed that etorreborre force-pushed the jungletryne/refactor_api_transport branch from 4e4e282 to e545c6f, and I thought that it might break my signature. All my commits used to be signed properly by me. I ammended and force-push the commit now to sign it again, will it do the trick?


Implement submissions as Google Maps images/graphics

[x] #104
[x] #105
[ ] #106
[x] #107

https://github.com/sopra-fs24-group-12/PeekSeek-client/commit/a1e806f14dbf7edd008e1b6e37e7f27d37205b08


Update 1.5 api

fixes https://github.com/istio/istio/issues/20577

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

Test name
Commit
Details
Rerun command

gencheck_istio_release-1.5
d0bd7988d333d71a96d1446c1484cf2b8a524404
link
/test gencheck_istio_release-1.5

integ-security-k8s-tests_istio_release-1.5
d0bd7988d333d71a96d1446c1484cf2b8a524404
link
/test integ-security-k8s-tests_istio_release-1.5

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

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

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio_release-1.5
d0bd7988d333d71a96d1446c1484cf2b8a524404
link
/test integ-security-k8s-tests_istio_release-1.5

gencheck_istio_release-1.5
d8b4f2fc6053c9fd6a3ff8171029ab364bc9ef12
link
/test gencheck_istio_release-1.5

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

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

Test name
Commit
Details
Rerun command

gencheck_istio_release-1.5
dc578fa1c16d975a53a50e44e3033e9146d94edc
link
/test gencheck_istio_release-1.5

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

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

Test name
Commit
Details
Rerun command

gencheck_istio_release-1.5
dc578fa1c16d975a53a50e44e3033e9146d94edc
link
/test gencheck_istio_release-1.5

unit-tests_istio_release-1.5
dc578fa1c16d975a53a50e44e3033e9146d94edc
link
/test unit-tests_istio_release-1.5

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

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

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio_release-1.5
9d6e3903d378bb21247fa5488b0ac6485dc54ee5
link
/test integ-pilot-k8s-tests_istio_release-1.5

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

/retest


Descriptions of nodes in LLM context.

LLM extracts nodes, but it misinterprets their meaning.
We would like to have an "Event" node with a "date" property for historical events, but llm-graph-builder generates nodes for the date values (01.01.1995)
Perhaps it can be solvable by providing descriptions of schemas.
    "schema": "healthcare",

    "description": "AgeGroup is one of \"<18\", \"18-80\", \">80\". Case is ...",

    "labels": [
      "AgeGroup",
      "Case",
      "Drug",
      "Manufacturer",
      "Outcome",
      "Reaction",
      "ReportSource",
      "Therapy"
    ]

That's something you can do when using the langchain integration directly.
Not yet in the app, and no near term plans as it needs much additional metadata.
https://python.langchain.com/v0.1/docs/use_cases/graph/constructing/#llm-graph-transformer


Cant download folders as a zip

Thank you for this awesome tool. I tried to download folders as zip using createArchive function but can't download folders as a zip with the returning URL..

Hi @TharukaMannapperuma, the issue is with seedr itself that it is returning invalid archive link. I already contacted seedr, they are currently working on a new API, hope they fix it there.

Is this issue solved by seedr ?
and the bot you have deployed does not provide captcha to solve when trying to get download link. here is the Screenshot of the bot

That will be Very Helpful if you could solve the issue in this module if you could.


docs: Rename back upgrading guide

The new location breaks existing release notes https://github.com/argoproj/argo-workflows/releases/tag/v3.3.6
Renaming back so we can also use it to document anything that's worth attention to our users, e.g. https://github.com/argoproj/argo-workflows/pull/8860.
Signed-off-by: Yuan Tang<EMAIL_ADDRESS>

@alexec  >> 22 spelling errors found in 126 files I don't think those are easy fixes. Not sure why this didn't complain earlier. I propose to remove the spelling check completely since it's tedious to keep adding stuff like usernames, release prefixes, etc. to this list: https://github.com/argoproj/argo-workflows/blob/master/.spelling

Ok noticed that the file name is hard-coded in make docs-spellcheck. It should be fixed now.

Getting false positives like these:
FILE: docs/metrics.md

  [✖] https://prometheus.io/docs/concepts/metric_types/

  8 links checked.
  ERROR: 1 dead links found!
  [✖] https://prometheus.io/docs/concepts/metric_types/ → Status: 403

   FILE: docs/use-cases/data-processing.md
  [✖] https://towardsdatascience.com/running-a-data-replication-pipeline-on-kubernetes-with-argo-and-singer-io-2fab5b0bad?utm_source=argo-docs

  ERROR: 1 dead links found!

@alexec Should we remove the spell check?

Getting false positives like these:
FILE: docs/metrics.md

  [✖] https://prometheus.io/docs/concepts/metric_types/

  8 links checked.
  ERROR: 1 dead links found!
  [✖] https://prometheus.io/docs/concepts/metric_types/ → Status: 403

   FILE: docs/use-cases/data-processing.md
  [✖] https://towardsdatascience.com/running-a-data-replication-pipeline-on-kubernetes-with-argo-and-singer-io-2fab5b0bad?utm_source=argo-docs

  ERROR: 1 dead links found!

@alexec Should we remove the spell check?

I think this error is from the docs-linkcheck rather than spellcheck.
The linkcheck can be flaky on git actions

Alright I re-ran the tests and now they passed.


Prevent MutationObserver destroying on DOM move

Closes #190

Thanks for your solution. I will merge it.


Examples

This PR solves some issues I encountered on a Win10/git mingw64 system.
Tests should still pass with these modifications.

Coverage remained the same at 97.862% when pulling 55a8247e10359a3c9117a27cbe95f1de61942644 on RainerAtSpirit:examples into dc7749f5ed7b93a331330fb5f3ae1e60c84b9c5c on Profiscience:next.

Thanks!


[Enhancement]: The desktop version accesses the web service directly using <IP_ADDRESS>

What would you like to be added?
The desktop version accesses the web service directly using <IP_ADDRESS>
Why is this needed?
The host file for the desktop version of odc may be modified, resulting in no access to back-end service

added in dev-4.3.1


How to change dead keys to modifiers?

Goal
I want to use the keys ' and " as modifiers to get those kind of accented letters é and ë.
I want to do that with the US QWERTY traditional layout and it is worth to note that ' and " are on the same key " = S-'.

But I have found a strange workaround for Firefox. You just need to add a second layout to Gnome:US QWERTY intl. with dead keys (which I was using before discoverging kmonad). And now, everything works fine even in Firefox.
What is happening here?
Additional question

Is there a way to do that without using a left-shift layer like above?

I had to setup Firefox to use wayland!

Ahhh interesting. UTF-8 character entry is sadly not uniform at all in Linux, Gnome and KDE apps do things one way, standard X11 stuff does stuff slightly differently. Happy to hear you found a solution.


Dev experience

We must work to improve the dev experience before working on this website takes days to run and build.
The issues to solve are:

[x] load a subset of versions to speed up the npm start command. Note that it exists the onlyIncludeVersions for this purpose
[x] generate static contents (plugins.json, benchmarks.json etc..) on the fly because the website will not start without these mandatories files
[ ] suggestions?

I'll load up the website locally and report back if I think of any suggestions :)

Should we use typescript (tsx)?

I can't launch the project locally. It should be enough to do an npm install then npm start.

What do you think about creating a slack channel to discuss the project?

What do you think about creating a slack channel to discuss the project?

we can create a discord one - will do later today

I can't launch the project locally

Please, read the readme and run npm run build:website too. of course, this is one of the parts we need to improve 😄

I have created the discord channel: https://discord.com/channels/725613461949906985/1067900422376935504

@Eomm  I can't access follow this https://support.discord.com/hc/en-us/articles/204155938-How-do-I-invite-friends-to-my-server-

You can find it in the main fastify repo
https://discord.gg/fastify

When I opened the repo in Vscode locally, the colors changed, I think it is too vibrant for me 😅

is it necessary to keep the colors saved in Vscode JSON?

I wonder if there could another way other than installing GitHub CLI to run the website locally.

When I opened the repo in Vscode locally, the colors changed, I think it is too vibrant for me

Here my statement https://github.com/fastify/website-next/pull/60#pullrequestreview-1270560143
TLDR: Yes, remove it and send a PR, but I think the suggested plugins are useful

I wonder if there could another way other than installing GitHub CLI to run the website locally.

Yes, but we need someone to replace it with bash scripting + we will need another GitHub token. the client is handy because it deals with it without annoying the dev IMHO

Sadly I've never contributed to the website repo, but my take from the comments it seems that we are mostly lacking portability to be able to run the project easily in locally.
Is there anything else do you think is missed or requires re-work?

@Eomm, I am trying to launch the website locally on my machine, I am following the instructions provided in fastify/website repo to launch the website locally, however npm start command keeps complaining about missing static/generated/benchmarks.json file while running docusaurus start, can someone please help me with this ?

What is the output of npm run build:website?
What is your system?

I am using mac, here is the output when i run npm run start:dev

<EMAIL_ADDRESS>start:dev
NODE_ENV=development docusaurus start

[INFO] Starting the development server...
[ERROR] Error: Missing generated file: static/generated/benchmarks.json. Run the "npm run build:website" once.
at /Users/MCX060/Documents/Docs/Docs/Playground/JavaScript/OpenSource/Fastify/Website/fastify_website/docusaurus.config.utils.js:28:13
at Array.forEach ()
at Object.checkGeneratedData (/Users/MCX060/Documents/Docs/Docs/Playground/JavaScript/OpenSource/Fastify/Website/fastify_website/docusaurus.config.utils.js:25:18)
at Object. (/Users/MCX060/Documents/Docs/Docs/Playground/JavaScript/OpenSource/Fastify/Website/fastify_website/docusaurus.config.js:15:3)
at Module._compile (node:internal/modules/cjs/loader:1233:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1287:10)
at Module.load (node:internal/modules/cjs/loader:1091:32)
at Module._load (node:internal/modules/cjs/loader:938:12)
at Module.require (node:internal/modules/cjs/loader:1115:19)
at module.exports (/Users/MCX060/Documents/Docs/Docs/Playground/JavaScript/OpenSource/Fastify/Website/fastify_website/node_modules/import-fresh/index.js:32:59)
[INFO] Docusaurus version: 2.4.1
Node version: v20.4.0

then i ran npm run build:website but that doesn't seem to generate that file as well. It complains about missing versioned_docs/version-latest/Guides/Ecosystem.md file and then fails with the same error

I am using a mac, when i run npm run build:website it downloads the releases and then it throws this error
`node:internal/process/promises:289
triggerUncaughtException(err, true /* fromPromise */);
^
Error: Client network socket disconnected before secure TLS connection was established
at connResetException (node:internal/errors:720:14)
at TLSSocket.onConnectEnd (node:_tls_wrap:1682:19)
at TLSSocket.emit (node:events:524:35)
at endReadableNT (node:internal/streams/readable:1378:12)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
code: 'ECONNRESET',
path: undefined,
host: 'raw.githubusercontent.com',
port: 443,
localAddress: null
}`
And then it fails with error [ERROR] Error: Missing generated file: static/generated/benchmarks.json. Run the "npm run build:website" once.

It seems an error connecting to github. are you logged in with your cli?
could you add all the output? it help us to understand which step of the process blocks you

Yes, it was github connectivity indeed. I have logged in but the connection was somehow not getting established, i am able to launch the application now. Please let me know if there are any immediate tasks which i can take up and start contributing.

I would start from this one: https://github.com/fastify/website/issues/131
No idea here - but you can add be creative!


Update play-ahc-ws-standalone to 2.1.7

Updates com.typesafe.play:play-ahc-ws-standalone from 2.1.3 to 2.1.7.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.typesafe.play", artifactId = "play-ahc-ws-standalone" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #135.


[YorushikaBridge] Add language selection parameter

The site got now language selection, so I implemented that to the bridge as well

nice


Create music-track-display

A simple plugin that displays the current music track as a game message in the console.
Fair warning that this was created by someone relatively novice.

This isn't at all a full review but doing this every game tick is VERY quickly going to spam the user's chatbox with nothing but this message

Hi Chris,
Thanks for your message.
Apologies if I'm replying the wrong way, I couldn't see your message on
GitHub and can only see it in my emails. It's probably obvious that I'm new
to this.
With regard to what you said, I have tested this and it doesn't seem to
spam the chatbox - it only sends the message when the music track changes.
I have it running every tick because there didn't seem to be a better way
to check for the track change as an event (there's no associated variable
client-side).
Did you test it and see it spam the chatbox?
Kind regards,
Thomas
On Fri, Dec 27, 2024 at 9:31 PM Chris @.***> wrote:

This isn't at all a full review but doing this every game tick is VERY
quickly going to spam the user's chatbox with nothing but this message
—
Reply to this email directly, view it on GitHub
https://github.com/runelite/plugin-hub/pull/7182#issuecomment-2563560091,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACUA6RALMIP4AIL4X7XNOGT2HUUAVAVCNFSM6AAAAABUIMUFHSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRTGU3DAMBZGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

I would assume there is a varbit changed or client script that's called.

The checks you're performing are simple enough and I wouldn't worry about trying to optimize it prematurely. But you should remove your config since it is unused.

The checks you're performing are simple enough and I wouldn't worry about trying to optimize it prematurely. But you should remove your config since it is unused.

Thank you for your suggestion.
Is it okay if I leave the config file in there and comment out everything related to it, including its contents? I was thinking of using the config later when I have more time to add some other features and my intention was to keep it as a template for when I do make changes.

Sure, but in that case you should also comment out its @Provides block in the plugin class.
I say this only because having it present means there will be a config gear icon beside the plugin name, which can be confusing for users if it opens to a blank page. If you want to add the config later it won't cause any issues to re-add the provider.

Sure, but in that case you should also comment out its @Provides block in the plugin class.
I say this only because having it present means there will be a config gear icon beside the plugin name, which can be confusing for users if it opens to a blank page. If you want to add the config later it won't cause any issues to re-add the provider.

Thank you LlemonDuck, that makes sense. I have updated the file.


Shipyard High Availability Deploy

Shipyard High Availability
This document will detail how to setup a highly available Shipyard cluster.
Draft Design

This design is in terms of AWS but is very loosely coupled and could easily be changed to work in a non-AWS environment.  The only AWS component is the Elastic Load Balancer.
Overview
In this example, there are three (3) different zones.  Each zone has one (1) Docker host.  Each Docker host runs containers that provide HA and redunant capabilities for the various Shipyard services.  The RethinkDB containers provide the HA data storage.  Interlock provides the app routing and load balancing for containers launched in the cluster and the Shipyard controllers provide the management.
Docker
Each Docker host is configured to listen on TCP (ideally using TLS).  This is needed for Shipyard.
RethinkDB
A primary RethinkDB instance is launched binding to ports 28015 and 29015 on the host and optionally port 8080 for the management UI (this can also be dynamically allocated by Docker).  There are two (2) other RethinkDB instances launched that "join" the primary.  These also are configured to listen on ports 28015 and 29015 on the host (you can use any known ports but these are the defaults) and optionally port 8080 for the management UI (this can also be dynamically allocated by Docker).  These two instances join the RethinkDB cluster and can then be used for replication.  Since we run the RethinkDB instances in containers, you must also use the --canonical-address option when running.
Once all of the instances are launched, we can use either the RethinkDB CLI or the web UI to configure the replication.  A datacenter is created containing all instances.  After the Shipyard controller is started it creates the database and tables.   In RethinkDB, the tables are configured to have, at minimum, two (2) shards and one (1) datacenter replica and one (1) datecenter write ack.  This will allow for a single node fail and still keep the data store available.
Shipyard Controllers
Each Docker host also runs a Shipyard controller.  The controller is configured to connect to the same zone RethinkDB instance.  The controllers simply connect to RethinkDB and have no other state so they can safely be accessed behind the Interlock app router.
Interlock
Interlock provides HAProxy powered app routing and load balancing.  Each Docker host has an Interlock container running that uses the Shipyard API to listen on the cluster event stream and automatically configure upstreams for containers.  Interlock has no external dependencies or configuration.  It builds the HAProxy configuration upon startup and event notification.  The Interlock containers are bound to port 80 on the Docker host.
Controller ELB
The controller ELB is a separate load balancer that access the controllers direct.  This eliminates the failure situation where the Interlock instances are down making the controllers unavailable to manage the cluster.
Container ELB
This provides a redundant setup to connect to the backend Interlock app routers.  The ELB is configured to listen on port 80 (and optionally port 443 for SSL) with the backends configured on port 80.  The ELB will load balance and provide failover in the event one of the Interlock containers fail.
Failure Scenarios
The following are some example failure scenarios and how it would affect the cluster in terms of Shipyard.  Other Docker containers and how they are affected are out of scope.
Zone Unavailability / Docker host failure
In the event a zone is unreacheable, the ELB will route requests to the other Interlock containers that will direct controller traffic to the two (2) availale nodes in the other zones.  Since RethinkDB is configured with replication, the other controllers will stay available as well.
Controller Failure
If a controller fails, the ELB will route traffic to the other Interlock routers and service will remain available via the other controllers.
Interlock Failure
If an Interlock container fails, the ELB will route traffic to the other Interlock containers.  Since the Interlock containers listen to events cluster-wide, all containers on the the zone with the router failure will be available via the other Interlock instances.

@ehazlett whats the best/right way to automate provisioning of Shipyard to multiple "zones" such as above? Are the methods described in the 'quick start' the only or best way to do that ? (ie. the 3 docker run commands). When I don't shut down the containers properly , docker tends to complain to me that the volume name is being used and I'll need to go manually docker rm & rmi each of that.

I started an issue in the repo to get this type of documentation in.  I
would love feedback - you can at least use it as a starting point.
https://github.com/shipyard/shipyard/issues/307
On Sat, Jan 17, 2015 at 7:00 PM, perryloh<EMAIL_ADDRESS>wrote:

@ehazlett https://github.com/ehazlett whats the best/right way to
automate provisioning of Shipyard to multiple "zones" such as above? Are
the methods described in the 'quick start' the only or best way to do that
? (ie. the 3 docker run commands). When I don't shut down the containers
properly , docker tends to complain to me that the volume name is being
used and I'll need to go manually docker rm & rmi each of that.
—
Reply to this email directly or view it on GitHub
https://github.com/shipyard/shipyard/issues/307#issuecomment-70390245.

sorry i responded via email and didn't realize you were posting to this thread :)
yeah basically instead of launching the shipyard controller via links, you would point it to the local rethinkdb or master if you chose too (or an ELB etc).  I would really like to have an easy way to deploy this out.  Perhaps a way like before where there is a meta container that launches others.

Hey Evan,
Thanks for your quick response. I'm actually having a look at shipyard for
some orchestration and liked it because it was so simple to set up and use.
I'm working towards a POC which includes some orchestration & management in
terms of docker containers. I also noticed that you're now working at
Docker and since Swarm seems to be the "official" way to go for this? Will
Shipyard still be actively maintained?
Please correct me if I'm wrong :)
Thanks,
Perry
On Sun, Jan 18, 2015 at 1:36 PM, Evan Hazlett<EMAIL_ADDRESS>wrote:

sorry i responded via email and didn't realize you were posting to this
thread :)
yeah basically instead of launching the shipyard controller via links, you
would point it to the local rethinkdb or master if you chose too (or an ELB
etc). I would really like to have an easy way to deploy this out. Perhaps a
way like before where there is a meta container that launches others.
—
Reply to this email directly or view it on GitHub
https://github.com/shipyard/shipyard/issues/307#issuecomment-70394097.

Hey!  Yes Shipyard will continue to be maintained and developed.  As for
the backend, the current backend will be replaced with Swarm.  The other
features (cli, account management, deploy integration, service keys,
extensions etc) will continue to be developed outside of that.
I have a lot planned for the future and hope to make it happen :)
On Sunday, January 18, 2015, perryloh<EMAIL_ADDRESS>wrote:

Hey Evan,
Thanks for your quick response. I'm actually having a look at shipyard for
some orchestration and liked it because it was so simple to set up and
use.
I'm working towards a POC which includes some orchestration & management
in
terms of docker containers. I also noticed that you're now working at
Docker and since Swarm seems to be the "official" way to go for this? Will
Shipyard still be actively maintained?
Please correct me if I'm wrong :)
Thanks,
Perry
On Sun, Jan 18, 2015 at 1:36 PM, Evan Hazlett<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>>
wrote:

sorry i responded via email and didn't realize you were posting to this
thread :)
yeah basically instead of launching the shipyard controller via links,
you
would point it to the local rethinkdb or master if you chose too (or an
ELB
etc). I would really like to have an easy way to deploy this out.
Perhaps a
way like before where there is a meta container that launches others.
—
Reply to this email directly or view it on GitHub
https://github.com/shipyard/shipyard/issues/307#issuecomment-70394097.

—
Reply to this email directly or view it on GitHub
https://github.com/shipyard/shipyard/issues/307#issuecomment-70429697.

That's great , I'm happy to hear such news. Had a conversation with a
colleague earlier and he was thinking that shipyard will not be further
developed as per usual NDA, etc :) So there's a few factors we're looking
into for this POC, mainly understanding/achieving (1) dev/prod parity via
docker , (2) cluster/node orchestration/management (3) configuration
management via puppet and (4) enabling HA(high availability) in prod
environments.
I tried to provision shipyard via the quickstart methods using the
garethr/docker puppet module and ran into a block since the ''--entrypoint"
parameter wasn't supported yet. So I'm now provisioning my own rethinkdb
containers(master/2 slaves config), and will try to hook that up to
shipyard.
Next step is to automate that provisioning via puppet :)
On Mon, Jan 19, 2015 at 1:14 PM, Evan Hazlett<EMAIL_ADDRESS>wrote:

Hey! Yes Shipyard will continue to be maintained and developed. As for
the backend, the current backend will be replaced with Swarm. The other
features (cli, account management, deploy integration, service keys,
extensions etc) will continue to be developed outside of that.
I have a lot planned for the future and hope to make it happen :)
On Sunday, January 18, 2015, perryloh<EMAIL_ADDRESS>wrote:

Hey Evan,
Thanks for your quick response. I'm actually having a look at shipyard
for
some orchestration and liked it because it was so simple to set up and
use.
I'm working towards a POC which includes some orchestration & management
in
terms of docker containers. I also noticed that you're now working at
Docker and since Swarm seems to be the "official" way to go for this?
Will
Shipyard still be actively maintained?
Please correct me if I'm wrong :)
Thanks,
Perry
On Sun, Jan 18, 2015 at 1:36 PM, Evan Hazlett<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>>
wrote:

sorry i responded via email and didn't realize you were posting to
this
thread :)
yeah basically instead of launching the shipyard controller via links,
you
would point it to the local rethinkdb or master if you chose too (or
an
ELB
etc). I would really like to have an easy way to deploy this out.
Perhaps a
way like before where there is a meta container that launches others.
—
Reply to this email directly or view it on GitHub
https://github.com/shipyard/shipyard/issues/307#issuecomment-70394097.

—
Reply to this email directly or view it on GitHub
https://github.com/shipyard/shipyard/issues/307#issuecomment-70429697.

—
Reply to this email directly or view it on GitHub
https://github.com/shipyard/shipyard/issues/307#issuecomment-70438724.

Hey Evan,
Now that I have a cluster of rethinkdb containers up and running. Is there
any easy way I can quickly provision the 'shipyard/shipyard' container to
point to a rethinkdb ip/port ?
I have 1 master and 2 slaves configured for rethinkdb running in 3
containers.
The only way I'm seeing from the quick-start is the container linking so
I'm assuming I could also link to the master container(as long as /data is
available)?
Regards,
Perry
On Mon, Jan 19, 2015 at 2:12 PM, Perry Loh<EMAIL_ADDRESS>wrote:

That's great , I'm happy to hear such news. Had a conversation with a
colleague earlier and he was thinking that shipyard will not be further
developed as per usual NDA, etc :) So there's a few factors we're looking
into for this POC, mainly understanding/achieving (1) dev/prod parity via
docker , (2) cluster/node orchestration/management (3) configuration
management via puppet and (4) enabling HA(high availability) in prod
environments.
I tried to provision shipyard via the quickstart methods using the
garethr/docker puppet module and ran into a block since the ''--entrypoint"
parameter wasn't supported yet. So I'm now provisioning my own rethinkdb
containers(master/2 slaves config), and will try to hook that up to
shipyard.
Next step is to automate that provisioning via puppet :)
On Mon, Jan 19, 2015 at 1:14 PM, Evan Hazlett<EMAIL_ADDRESS>wrote:

Hey! Yes Shipyard will continue to be maintained and developed. As for
the backend, the current backend will be replaced with Swarm. The other
features (cli, account management, deploy integration, service keys,
extensions etc) will continue to be developed outside of that.
I have a lot planned for the future and hope to make it happen :)
On Sunday, January 18, 2015, perryloh<EMAIL_ADDRESS>wrote:

Hey Evan,
Thanks for your quick response. I'm actually having a look at shipyard
for
some orchestration and liked it because it was so simple to set up and
use.
I'm working towards a POC which includes some orchestration &
management
in
terms of docker containers. I also noticed that you're now working at
Docker and since Swarm seems to be the "official" way to go for this?
Will
Shipyard still be actively maintained?
Please correct me if I'm wrong :)
Thanks,
Perry
On Sun, Jan 18, 2015 at 1:36 PM, Evan Hazlett<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>>
wrote:

sorry i responded via email and didn't realize you were posting to
this
thread :)
yeah basically instead of launching the shipyard controller via
links,
you
would point it to the local rethinkdb or master if you chose too (or
an
ELB
etc). I would really like to have an easy way to deploy this out.
Perhaps a
way like before where there is a meta container that launches others.
—
Reply to this email directly or view it on GitHub
<
https://github.com/shipyard/shipyard/issues/307#issuecomment-70394097>.

—
Reply to this email directly or view it on GitHub
https://github.com/shipyard/shipyard/issues/307#issuecomment-70429697.

—
Reply to this email directly or view it on GitHub
https://github.com/shipyard/shipyard/issues/307#issuecomment-70438724.

Yes you can run the controller with the "--rethinkdb-addr" arg.  See
http://shipyard-project.com/docs/usage/controller/ for an example.
On Monday, January 19, 2015, perryloh<EMAIL_ADDRESS>wrote:

Hey Evan,
Now that I have a cluster of rethinkdb containers up and running. Is there
any easy way I can quickly provision the 'shipyard/shipyard' container to
point to a rethinkdb ip/port ?
I have 1 master and 2 slaves configured for rethinkdb running in 3
containers.
The only way I'm seeing from the quick-start is the container linking so
I'm assuming I could also link to the master container(as long as /data is
available)?
Regards,
Perry
On Mon, Jan 19, 2015 at 2:12 PM, Perry Loh<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','perry.loh@gmail.com');>> wrote:

That's great , I'm happy to hear such news. Had a conversation with a
colleague earlier and he was thinking that shipyard will not be further
developed as per usual NDA, etc :) So there's a few factors we're
looking
into for this POC, mainly understanding/achieving (1) dev/prod parity
via
docker , (2) cluster/node orchestration/management (3) configuration
management via puppet and (4) enabling HA(high availability) in prod
environments.
I tried to provision shipyard via the quickstart methods using the
garethr/docker puppet module and ran into a block since the
''--entrypoint"
parameter wasn't supported yet. So I'm now provisioning my own rethinkdb
containers(master/2 slaves config), and will try to hook that up to
shipyard.
Next step is to automate that provisioning via puppet :)
On Mon, Jan 19, 2015 at 1:14 PM, Evan Hazlett<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>>
wrote:

Hey! Yes Shipyard will continue to be maintained and developed. As for
the backend, the current backend will be replaced with Swarm. The other
features (cli, account management, deploy integration, service keys,
extensions etc) will continue to be developed outside of that.
I have a lot planned for the future and hope to make it happen :)
On Sunday, January 18, 2015, perryloh<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>> wrote:

Hey Evan,
Thanks for your quick response. I'm actually having a look at
shipyard
for
some orchestration and liked it because it was so simple to set up
and
use.
I'm working towards a POC which includes some orchestration &
management
in
terms of docker containers. I also noticed that you're now working at
Docker and since Swarm seems to be the "official" way to go for this?
Will
Shipyard still be actively maintained?
Please correct me if I'm wrong :)
Thanks,
Perry
On Sun, Jan 18, 2015 at 1:36 PM, Evan Hazlett <
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>');>>
wrote:

sorry i responded via email and didn't realize you were posting to
this
thread :)
yeah basically instead of launching the shipyard controller via
links,
you
would point it to the local rethinkdb or master if you chose too
(or
an
ELB
etc). I would really like to have an easy way to deploy this out.
Perhaps a
way like before where there is a meta container that launches
others.
—
Reply to this email directly or view it on GitHub
<
https://github.com/shipyard/shipyard/issues/307#issuecomment-70394097>.

—
Reply to this email directly or view it on GitHub
<
https://github.com/shipyard/shipyard/issues/307#issuecomment-70429697>.

—
Reply to this email directly or view it on GitHub
https://github.com/shipyard/shipyard/issues/307#issuecomment-70438724.

—
Reply to this email directly or view it on GitHub
https://github.com/shipyard/shipyard/issues/307#issuecomment-70590973.

We plan to have a more featureful installer that will support customization and control over the deployment process.  We will use this as a basis.  Closing for now.

is there any progress of the HA feature ?


[Repro Provided] alert() triggers immediately on Base State

Version
5.1.1
Browser and OS info
Firefox 67.0.4 (64-bit) / Windows 10 Enterprise
Steps to reproduce

Create a vue cli project that has a vuex store.
Make a getters function inside of the vuex store.
Add an alert() to the inside of the getters function.
Run serve inside of vue ui.
Open app.
Open Developer Tools.
Go to the Vue Tab.
Once Base State loaded in, the alert() immediately runs.

What is expected?
I expected that initializing Base State would not trigger the alert() inside of the getters function.
What is actually happening?
Base State triggers the alert() inside of the getters function. This behavior only occurs when Base State loads in so this is definitely a vue-devtools problem. When vue-devtools is disabled, the alert() stays untriggered.

I made a unit test of that demonstrates this issue: https://codesandbox.io/s/vue-devtools-alert-bug-44ewg
It seems that vue-devtools cannot hook up to the vue that's loaded into the preview window so please go to the preview url in a separate tab and THEN open vue-devtools. Note: It may take a couple of seconds for the page to load.

Duplicate of #443
Also side effects in getters is a very bad idea. 😸


Business Forms plugin not working in Grafana Cloud

Context
We are planning to move to Grafana Cloud (currently we host our own instances of Grafana).
Since disable_sanitize_html is not possible in Granafa Cloud, running javascript in a Text visualisation is not possible.
We discovered Business Forms, it looks great to do the job.
For testing, we set up a Grafana Cloud Free instance.
Issue / reproduction
I installed the Business Forms plugin through the Grafana plugins panel.
Ater a few minutes, the plugin appears as installed.
Next, when I edit a Grafana panel and select Business Forms as a Visualisation. the Edit Panel fields are not changed to those of the Business Forms, but stay the same as the last selected visualisation. (for example, if the visualisation was Text Visualisation and I change it to Business Forms, I keep seeing the fields of the Text Visualisation).
Environment
Currently Grafana Cloud latest is v11.2.0-74515.
Browsers: Chrome Version 127.0.6533.120 (Official build) (64-bits) / Edge Version 127.0.2651.105 (Official build) (64-bit)
On a self hosted Grafana v11.1.4 (2355de00c6) Enterprise Free instance on Ubuntu  20.04.6 LTS,  Business Forms works as expected.

@paulfirstimpression Thank you for reporting the issue. It's a breaking change in the Grafana Cloud introduced recently.
Related issue - https://github.com/grafana/grafana/issues/92000

@paulfirstimpression Plugin was updated in Grafana Cloud and works as expected.
https://grafana.com/grafana/plugins/volkovlabs-form-panel/

@mikhail-vl great work! Thanks for the quick response!


Freezing on exit

After executing val influxdb = InfluxDB.connect("localhost", 8086), the program won't exit after finish the main function.

You can now call the close method at the end to make sure that your program doesn't hang.
Thanks for reporting this


ludusavi kept getting stuck in a loop trying to scan something

Ludusavi version
v0.21.0
Operating system
Linux
Installation method
Flatpak
Description
ludusavi kept getting stuck in a loop trying to scan something

Logs
ludusavi_rCURRENT.log

This can happen if there is one game with significantly more save data than the others (e.g., 10+ GB for a single game), since the progress bar only updates per game rather than per file/byte. It should finish scanning eventually, but it could take a long time depending on the game and system. I'll look into better ways to represent progress in this kind of situation.

I'm not sure, but the errors in your log might be a permissions issue with accessing /var/home/heus/.var/app/com.usebottles.bottles. The Flatpak version of Ludusavi now has broader permissions by default, so it should be able to read that path now. You can also use Flatseal to allow additional paths if needed.
If you still see this issue, could you try running with --env=RUST_LOG=ludusavi=trace? That way, the log file should indicate the last game being scanned that takes so much extra time.

I'm not sure, but the errors in your log might be a permissions issue with accessing /var/home/heus/.var/app/com.usebottles.bottles. The Flatpak version of Ludusavi now has broader permissions by default, so it should be able to read that path now. You can also use Flatseal to allow additional paths if needed.
If you still see this issue, could you try running with --env=RUST_LOG=ludusavi=trace? That way, the log file should indicate the last game being scanned that takes so much extra time.

I tried to create a backup recently and the bug no longer appeared


Empty data in file when changing :fields value after generated

Hello @hapo-caominh could you explain me more?

@jecovier
I'm set up json_fields as a component's data variable.
When page created, it worked perfectly fine until i change value of the json_fields. The result excel file is now total empty.
Any ideas why ?


Cleanup duplicate code by standardizing on one way

Now that https://github.com/dependabot/dependabot-core/pull/4434/ landed,
the only reason for the native go helpers is https://github.com/dependabot/dependabot-core/blob/9060bc4a10d5a8254e674358e72db0f23095c5e0/go_modules/lib/dependabot/go_modules/path_converter.rb#L17-L20
However, looking at that file, I noticed that right after that function there's
another variant of git_url_for_path that is implemented in pure ruby so doesn't
require the native go helper:
https://github.com/dependabot/dependabot-core/blob/9060bc4a10d5a8254e674358e72db0f23095c5e0/go_modules/lib/dependabot/go_modules/path_converter.rb#L25-L28
Weirdly it says the dependabot backend doesn't have access to go, which
certainly isn't true, otherwise the code removed by #4434 wouldn't have been
added in the first place.
So it'd be best to standardize on one of these two functions and remove the other to reduce confusion.
The tradeoff here appears to be that the pure ruby func would be simpler and allow
completely eliminating the native go helpers, but according to the code comment is less robust.
I have no opinion on which is the better way to go here, just that having two methods doing
the same thing with misleading code comments is definitely not the right way! 😄

Also, if chosen solution is to remove the native go helper, then https://github.com/dependabot/vcs can be archived or even deleted (since it's an unused fork).

Yeah, agreed. I think that the native version handles more than just git repo's (mercurial/svn etc) and the ruby version does only git. I am doubtful that Dependabot currently handles non-git sources well, and I wonder if switching to the pure ruby version would break any existing functionality but it's definitely worth a short investigation

To move this forward, can I just put up a PR switching to the pure ruby version and see if any tests break? Or is this something that needs to be investigated on your side because breakage would most likely be internal/invisible to external contributors?

Digging into this more, and took me a while to find the historical commits due to multiple file renames/re-orgs:

Initial commit rewriting the Ruby helper in Go: https://github.com/dependabot/dependabot-core/commit/43be2e13cd4fbd1f8b1260b2dd20e1af2b333fc8
Follow-on commit adding back the Ruby helper: https://github.com/dependabot/dependabot-core/commit/bd4a9c0ac60dc6939826a30033e16ea49f9ac0f7

There's no information on what motivated the initial rewrite in Go, I'm checking internally for more info.

From one of the original authors:

I think the code is trying to map a Go import path back to a repository so we can e.g. link to the repo in the Dependabot PR, find the CHANGELOG, link to the diff between versions, etc, etc.
It’s not totally trivial with Go because:

they’ve got that whole vanity URL thing going on, where you have to pass go-get=1 in to make it act like a fancy redirect to a repo
a Go import path doesn’t necessarily actually match a repo URL. For instance, I might be able to import https://github.com/go-kit/kit/tracing, but that’s not a valid URL on GitHub. The repo is github.com/go-kit/kit, and the package is browsable at https://github.com/go-kit/kit/tree/master/tracing. So Go bakes in some logic to handle that for a series of SCMs, and the Masterminds/vcs package does a similar thing too.

Ideally, we’d just use whatever golang/go does, but IIRC that wasn’t importable so the next best thing was the Masterminds/vcs implementation. The Ruby code you linked to predates our usage of that Go library, and I’d guess is just a really incomplete Ruby implementation of the same thing.
Perhaps these days a) there’s a good Ruby implementation, or b) we think the VCS list is stable enough we’d be happy to translate it to Ruby, or c) we could somehow codegen the Ruby from the canonical Go implementation? Or we just stick with that one-off Go helper?


support displaying bd cad objects with color tagged

This PR adds support for YACV to display different colors in objects as set forth in build123d objects in "color" attributes.
This is particularly helpful when working with larger assemblies where there are a number of components and different colors are used to distinguish them

Nice idea and nice work! I still have to test it locally when I have some time but I have an initial question:
Should we also support colors for edges and vertices? I know it is a less likely use case, but if build123d supports it (does it?), we should too. Also, to avoid painting everything the same way, we could set it up so that edges are only colored when no faces are present, and vertices only when neither edges nor faces exist. This would give the user more control over how to paint each part of the model or assembly.
Are you willing to implement this change?

I just had a quick look into it. build123d has color attribute defined on the Shape base class, so technically any shape can have color. But I am no so sure about whether a b123d solid object's component faces and edges can have different colors (rather than the main color defined on the solid object). The problem is wrapped TopoDS_Shape objects do not have color attributes, so I am not sure if the color of component edges and vertices are preserved after they are added to form the solid, I need to look into this deeper, but I might not have immediate time for it.
I can get back in one week or two with a follow-up and maybe the implementation if it is doable.

During my testing, I added basic coloring support for edges and vertices, but only when they are the primary feature passed to show(). Here's how it works:

If the object has faces, only the faces are colored.
If there are no faces but edges exist, the edges are colored.
If neither faces nor edges exist, the vertices are colored.

This setup allows for highlighting specific parts of an object by applying different colors, although it requires adding a separate model for the highlights. While this solution works for now, we can revisit it if build123d supports coloring individual parts of an object.
Currently, both the example and the logo make use of custom colors for faces and edges.

I will release v0.9.0 with these changes.

Thanks for the follow up! Was quite occupied by other stuff in the past few weeks...
I just double checked to make sure but it did seem that build123d does not support coloring different colors on the same object at the moment, so I guess this is the best we can do right now.


[BUG]: wrong link declard for contributing guidelines on bug issue template ❌🚨

Description

The bug is about the wrongly redirected link of Contributing Guidelines on Bug issue template.
You can check this on the Checkboxes field, click the Contributing Guidelines It will navigate you to the LinksHub Repository.
Actually it needs to redirected to Contributing Guidelines documentation on Informatician' Repository.

Screenshots
https://github.com/rohansx/informatician/assets/92252895/2af55579-168c-4eb3-9af5-3a3afd2d2da0
Any additional information?
No response
What browser are you seeing the problem on?
No response
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I have read the discussion tab thoroughly and got the project idea
[X] I am willing to work on this issue (optional)
[X] I am a GSSoC'23 contributor

Hey there @rohansx, @crocmons, @SiddhantPawar03, @s2sharpit 👋🏻
Please make sure to assign this issue to me to fix this Bug as soon as possible, Thank you!