enh(ruby) Support for character literals (#2950)

Resolves #2950
Changes
Improved the regex to detect character literals.
Here is the new regex with a little reasoning for each.
{
  /* To detect, \nnn octal bit pattern, where nnn is 1-3 octal digits ([0-7]) */
  begin: /\B\?(\\\d{1,3})/
},
{
  /* To detect, \xnn hexadecimal bit pattern, where nn is 1-2 hexadecimal digits ([0-9a-fA-F]) */
  begin: /\B\?(\\x[A-Fa-f0-9]{1,2})/
},
{
  /* To detect,
   * \unnnn         Unicode character, where nnnn is exactly 4 hexadecimal digits ([0-9a-fA-F])
   * \u{nnnn ...}   Unicode character(s), where each nnnn is 1-6 hexadecimal digits ([0-9a-fA-F])
   */
  begin: /\B\?(\\u\{?[A-Fa-f0-9]{1,6}\}?)/
},
{
  /* To detect,
   * \cx or \C-x    control character, where x is an ASCII printable character
   * \M-x           meta character, where x is an ASCII printable character
   * \M-\C-x        meta control character, where x is an ASCII printable character
   * \M-\cx         same as above
   * \c\M-x         same as above
   * \C-\M-x        where x is an ASCII printable character
   */
  begin: /\B\?(\\M-\\C-[\x20-\x7e]|\\M-\\c[\x20-\x7e]|\\c\\M-[\x20-\x7e]|\\M-[\x20-\x7e]|\\C-\\M-[\x20-\x7e])/
},
{
  /* To detect, \C-a or \c? */
  begin: /\B\?(\\c[\x20-\x7e]|\\C-[\x20-\x7e])/
},
{
  /* To detect, ?あ */
  begin: /\B\?(\\?\S)/
}

I have referred to the following from the Ruby documentation.

Note:
c = ?abc     #=> SyntaxError  highlights as

Checklist

[x] Added markup tests, or they don't apply here because...
[x] Updated the changelog at CHANGES.md
[ ] Added myself to AUTHORS.txt, under Contributors

@il3ven Thanks fo much!

@il3ven Thanks fo much!


azuredatastudio 1.44.1 > 1.47

Description of changes
Update version for azuredatastudio
Things done
checked if it compiles and runs and can do the basic functions like install extensions and connect to a database.

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[x] (Package updates) Added a release notes entry if the change is major or breaking
[x] (Module updates) Added a release notes entry if the change is significant
[x] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

List of open PRs: https://github.com/NixOS/nixpkgs/pulls
Reviewing guidelines: https://nixos.org/manual/nixpkgs/unstable/#chap-reviewing-contributions
-->
Priorities
Add a :+1: reaction to pull requests you find important.

Please follow the contributing guide when naming your commits.

I squashed the commits in https://github.com/NixOS/nixpkgs/pull/269635/commits/2537d8b8f124995e503eb72cf8c4a7264bd1bdf2 and gave them a more descriptive name. I then removed the formatting changes, didn't realise I had my formatter on for that file.


Coveralls Testing via Continuous Integration System

More detail will need to be flushed out on this item in preparation for the March 11 project meeting.

Now that RSG has admin on the repo, @toliwaga will take ownership of the Travis integration and make sure everything is working.  Then we'll add a new test.  We will also write protect the master branch to require automated testing with Travis.

I added a separate ticket (#64) for the write-protection. It seems like a discrete task in my head.

This is working now, with travis running tests with --cov-report and after_success notification to coveralls.


Remove unused PhysicsShapeQueryResult3D & PhysicsShapeQueryResult2D

These classes are not referenced anywhere in c++ or scripting API, so it can be misleading to keep them in the codebase and documentation.

What about the Parameters one, is it used? I thought Parameters was to configure a query and Result to hold the results.

@akien-mga PhysicsShapeQueryParameters is used, but the results are then stored in either an Array or a Dictionary containing different fields that depend on the type of query:
https://docs.godotengine.org/en/stable/classes/class_physicsdirectspacestate.html

Thanks!


Code of multi gpus training of diffusion model

I want to train the diffusion model with multi gpus. But there are not relevant codes.

Hi, @ganchaofan0000, I just add the multi-GPU training codes for MHAD dataset. The training on the other datasets should be similar to MHAD. Please feel free to let me know if you have any other questions.

Thanks!


As a user, I want to run repo mirroring services, so that the feature is enabled and works.

With quay-v3.1.0 there is a new feature named "repo mirroring". This feature defaults to off and thus must be enabled via the config.yaml/config app. In addition, by default the worker (aka service) that does the mirroring is not started in the "registry" container mode. Instead, a new entrypoint "repomirror" is available to run only the services necessary for this feature. The intent is that there will be both a "registry" pod and the "repomirror" pod running. The "repomirror" pod requires access to the database (like "registry" does), as well as access to external registries to be mirrored. An external endpoint is not required.
An alternate starting mechanism for "repomirror" is available to run the worker inside the "registry" container. To do this, the environment variable QUAY_OVERRIDE_SERVICES is given a value of repomirrorrowker=true. This mode is intended to be for POC but is fully functional and may, in fact, be the most common mode for users.
For the quay-operator, I'd suggest two phase approach: First, add the env var method to allow usage. Next, add effectively a duplicate setup as "registry" but change entry point to "repomirror".
Differences in "repomirror" pod:

At this time, there is no readiness/liveness endpoints so default them to be omitted. Leave the functionality, though, since upcoming release will support that.
An external route to this pod is unnecessary at this time. A distant release may support this, though, so if it makes sense to leave support in code but disabled, that would not be wasted effort.
Scaling, sizing, and other pod aspects should be available but separate from the "registry" pods (ie. they will be adjusted separately).

@thomasmckay

At this time, there is no readiness/liveness endpoints so default them to be omitted. Leave the functionality, though, since upcoming release will support that.

Did Quay 3.2 introduce this functionality?
@sabre1041
Here is my recommendation for the implementation of this functionality:

The operator should introduce a new pod into the ecosystem. Example name: quay-mirror-worker
The Pod should run the Quay image but its entrypoint should be repomirror.
This Pod should be ran only after the main Quay pod is finished initializing.
Stretch-goal: The ability to scale the quantity of mirror worker pods may be beneficial.
Enabling this feature is typically performed in Quay's configuration application. Therefore, the operator may need to expose a CR value to enable/disable this feature.
For documentation, it is important to note that this feature may only be enabled by the operator during the initial installation/setup. It is possible to work-around it by modifying the config.yaml used by Quay but IMHO that's out of scope for the initial change.
If the readiness endpoint was included in Quay 3.2, it would be fantastic to use that. If not, then perhaps we mark this feature as tech-preview until we can better integrate it with Kubernetes/OpenShift.
I do not think there is any reason to allow Users to specify a different image for this pod. If different versions of Quay are ran simultaneously then unexpected results may occur.


Does not find python

using github actions + actions/setup-python@v4 with: update-environment: true
I am using https://github.com/wingtk/gvsbuild to build https://github.com/pygobject/pycairo/blob/main/meson.build which has
pymod = import('python')
python = pymod.find_installation(get_option('python'), pure: false)

in the build error I get:
"Need python for x86, but found x86_64"
if I delete all other python folder from the action runner in a step before the build process I get:
Program python3 found: NO
meson.build:16:15: ERROR: python3 not found
full action log can be found here:
first error
https://github.com/doadin/gvsbuild-release/actions/runs/8443809356/job/23128136908
second error
https://github.com/doadin/gvsbuild-release/actions/runs/8446242953/job/23134712079
in the log for the first error you can see in the trace that x86 python is what is executing the command yet meson says "Need python for x86, but found x86_64". This seems to be a meson issue? however im not familiar with meson build system if this is a build file issue sorry.

Something is wrong with your setup or with gvsbuild. Here https://github.com/doadin/gvsbuild-release/actions/runs/8443809356/job/23128136908#step:3:1 you install Python 3.10 for x86, but the meson setup fails find Python 3.12 for x86_64, here https://github.com/doadin/gvsbuild-release/actions/runs/8443809356/job/23128136908#step:7:22120

in the log for the first error you can see in the trace that x86 python is what is executing the command

Where do you see that this?

@dnicolodi https://github.com/doadin/gvsbuild-release/actions/runs/8443809356/job/23128136908#step:7:22154

We would need to have a look at C:\gtk-build\build\Win32\release\pycairo\_gvsbuild-meson\meson-logs\meson-log.txt too see which Python environments Meson is considering and eventually why it is discarding the x86 one. For now this looks like a problem with build environment setup

Also, meson-python has nothing to do with this.

@dnicolodi unless I am miss understanding the error it says the command being run starts with it calling Python\3.10.11\x86\python.exe which is the correct version. I supposed there could be a weird situation where python 3.12 is being used to start a Python\3.10.11\x86\python.exe process but even then Python\3.10.11\x86\python.exe is the process calling the meson build so that python should be the one found.

@dnicolodi sorry, was not sure where to report this but its a messon and python issue I thought maybe meson-python would be the place to report, I am not really familiar with meson in general.

Python\3.10.11\x86\python.exe is the process calling the meson build so that python should be the one found.

There isn't a direct correspondence between the python used to run Meson and the python returned by import('python').find_installation().

@dnicolodi https://mesonbuild.com/Python-module.html
"pymod.find_installation(name_or_path, ...)
Find a python installation matching name_or_path.
That argument is optional, if not provided then the returned python installation will be the one used to run Meson."
Is this not what should be happening? Maybe I am way off here I don't know.

The documentation tells a somehow simplified story. Anyhow, what's going on is very likely explained in the detailed log file.

"Need python for x86, but found x86_64"

This is because you have a 32-bit Python installed on 64-bit Windows. If that's by accident, please remove it and install 64-bit Python. If it's on purpose that you're using 32-bit Python, then you need to activate 32-bit MSVC (see for example numpy/numpy#24704 (comment)).
I've been meaning to improve this error message in Meson to include what is actually happening and how to fix it.

"C compiler for the host machine: cl (msvc 19.29.30154 "Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30154 for x86")
Host machine cpu family: x86
Host machine cpu: x86"
does this not mean that 32-bit MSVC is active?

@rgommers that very link shows you had the error but it pointed to 19.35.32217.1 for x64, mine does not.

@rgommers In the build logs I don't see meson-python involved in any way.

@rgommers In the build logs I don't see meson-python involved in any way.

Yes indeed, I agree. If that is intended (no idea, because I know nothing about gvsbuild) then what I was pointing out is that the likelihood of picking up the wrong interpreter goes up a lot. meson is just finding one at random here probably.

(added the invalid label only because meson-python isn't involved at all, not because there is nothing to improve here)


[Bug][GitExtractor] Some commits are missing during collectGitCommits

Search before asking

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

What happened
Hello everyone. I am using the latest main branch version and trying to collect gitlab commit data with Devlake. However, I found that sometimes some commits are not collected into the database after the pipeline run. Specifically, I have tested on 3 projects, each's outcome respectively:

all commits on 28 branches/tags are stored successfully
only the 7th latest commit (sha:7d7600..) on dev branch is missing. The commits on master branch are all stored
same as the second project, only the 7th latest commit on dev branch is missing

I'm not sure whether it is related to '7th latest commit' or the branches with name 'dev' or something else. But these are some things I tried and observed:

The first project also has a branch named 'dev' and all commits seems to be collected well
I submit a new commit on the second project and the 7d7600 commit (which is the 8th latest now) is still missing, and other commits are all collected.

This is how I query the commits on a specific branch:
with res as ( SELECT   @r AS _sha,   (SELECT @r := parent_commit_sha FROM commit_parents WHERE commit_sha = _sha limit 1) AS parent_sha,   @l := @l + 1 AS lvl  FROM (SELECT @r := (SELECT commit_sha FROM refs WHERE id='gitlab:GitlabProject:1:175:origin/dev'), @l := 0) vars, commit_parents h)  SELECT _sha, parent_sha FROM res WHERE parent_sha IS NOT NULL;
This is what I got:

It shows that there are only 7 commits on this branch, and the commit 7d7600.. are not found in commit_parents table so it is the end. However, the 7d7600 is also not found in commits table,

and the gitlab shows that there are more commits before 7d7600:

Moreover, I check the sha of the parent commit of 7d7600 from the gitlab (acc33d..), and I found that the commits after 7d7600 are all stored well in the tables:

...

So I think this commit is probably missing during the collection some how. This is the logs of the pipeline run for the second project:
[task #18] [gitextractor].log
I might did something wrong on this, thanks a lot for any ideas.
What you expected to happen
All commits on all branches of the project should be collected and stored.
How to reproduce
Use the latest devlake, create a gitlab blueprint and run.
Anything else
No response
Version
main
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

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

This is the most thorough report I ever seen in my life. Thanks, man, will look into it.

I would like to know was the dev branch newer than main for the 1st repo (the one with all commits collected correctly)?

I would like to know was the dev branch newer than main for the 1st repo (the one with all commits collected correctly)?

Yes, the dev branch is newer than the master branch. Actually I've just checked again and found that the 1st latest commit on the master branch in the 1st repo is also missing. (Sorry for the mistake)
I also checked the logs again and found that, it is might actually the first processed commit will not be stored.
In the first repo, the logs are:

and the ebce1d.. is the missing one.
In the second repo, the logs are:

and the 7d7600.. is the missing one.

Hi, @dealexce , the bug was fixed by #2654 on the main branch, please take a look, and feel free to re-open if the problem still exists

Hi, @dealexce , the bug was fixed by #2654 on the main branch, please take a look, and feel free to re-open if the problem still exists

Everything looks fine now. Thanks, you guys are awesome!


Create generic publisher class

Description

Rename old Publisher -> BinaryPublisher
Create Publisher<T> class to abstract over converting from T to std::vector<std::byte>.

lgtm, maybe we could call BinaryPublisher RawPublisher instead?

+1 for RawPublisher.
Great changes @filippobrizzi . I knew you'd have a nicer suggestion when I created createPublisher :D


Add markdownlint Automatic Auditing Feature

This is a Feature Request

What would you like to be added

I would like to add an automatic markdownlint auditing feature to our website project. This feature would automatically check and highlight potential formatting issues and errors in Markdown files during each commit or edit, ensuring consistency and adherence to formatting standards.
Why is this needed
Introducing this feature has several important benefits for our project:

Improves the quality and consistency of documentation, reducing the manual review workload.
Prevents common Markdown formatting errors, such as missing headers and inconsistent formatting.
Enhances project maintenance efficiency, allowing team members to focus more on content creation and updates.

Comments
We could consider using the markdownlint tool, which can be integrated into our CI/CD process to ensure automatic auditing on every commit. We can refer to official documentation and example projects for specific configuration and integration methods to implement this feature quickly.

Here are the three main concerns discussed regarding the introduction of the markdownlint automatic auditing feature:
Three Major Concerns

Extensive Updates Required for Existing Documents:

Many current documents have been around without enforcing Markdown linting, leading to numerous formatting issues that would need significant updates to comply with new checks. This process is not only time and effort-intensive but also requires involvement from other team members who would need to review these updates to ensure nothing is accidentally broken during the process.

Impact on Contributor Experience:

Many contributors might be accustomed to writing Markdown that looks fine locally but might not be entirely spec-compliant. This could lead to situations where their submissions appear fine locally, but build jobs fail on their PRs due to formatting issues, which can be frustrating for both occasional and regular contributors. Their efforts might be rejected due to seemingly trivial issues.

Technical Implementation and Integration Challenges:

While introducing markdownlint as a tool is a great idea, the Kubernetes community currently uses Prow instead of GitHub Actions for automation processes. This presents a technical challenge on how to effectively run Markdownlint as a Prow job and have the results commented on the GitHub PR. This requires additional configuration and integration efforts, possibly involving the development of new tools or adapters to bridge these technological gaps.

Can you assign it to me?

Having been someone that has added this to multiple projects in the past, and someone that is a big proponent of well strucutred and "correct" markdown, I'm a little mixed on this proposal.
There are a couple concerns I have for adding this to k/website.
The current docs have been around for quite some time without enforcing markdown linting. This means there are a lot of issues everywhere in the content that will need to be updated. This will cause a lot of churn and failing tests that will take some effort and attention. Not just for you to make the updates, but for the folks that will need to review those updates and verify nothing accidentally gets broken.
The other concern is the contributor experience. A lot of people are very used to writing markdown that works but is not quite fully spec compliant. I've found it can be very frustrating for casual (and even regular) contributors to write some docs that render just fine locally, only to have jobs fail on their PR for what really ends up being a trivial issue.
So no doubt this would improve the overall quality of our markdown. And it likely would uncover a few cases where there are rendering issues. But as a whole it needs to be decided if this is worth the effort, and if so, how to go about getting all of the existing content in a state that will pass linting without being too disruptive.

I agree with your opinion, stmcginnis. While Markdownlint is an excellent tool and the effort to introduce it is a great idea, there will likely be some challenges.
Another concern is that the Kubernetes community uses Prow instead of GitHub Actions. Is there a good way to run Markdownlint as a Prow Job and have the results commented on the GitHub PR?

A halfway house is to have the job, and have it fail when new changes make a page subjectively “worse“, but still allow a merge.

I also believe that the concerns raised by the seniors are worth discussing, and I'd like to share my thoughts on the three concerns:

Indeed, this requires attention, and I suggest we could start by limiting the scope of affected markdown files. Perhaps we can initially focus only on README documents and later consider extending this to other markdown documents.
As for this point, markdownlint itself can help fix some formatting issues. Could we possibly delegate this task to a robot, or incorporate automatic fixes into the CI process?
I am not very familiar with this aspect yet, but I will make an effort to learn more about it in the future.

@ywh555hhh
I was checking out some discussions on CI and automation. Some helpful PR discussions here:

https://kubernetes.slack.com/archives/C01672LSZL0/p1724091591242469?thread_ts=1724089319.657699&cid=C01672LSZL0

A comment about GHA permissions from GitHub Admins. It seems they do not allow GHA with permission: write. (This is due to a past incident, but I am not familiar with this details.)

https://github.com/kubernetes/test-infra/pull/33333

A PR to introduce Markdownlint to the etcd-io/website. I believe moving this PR forward will lead to its introduction in k/website as well.

A halfway house is to have the job, and have it fail when new changes make a page subjectively “worse“, but still allow a merge.

Completely Agree. Linting the entire codebase from the first step will cause many CI errors and confusion.

@ywh555hhh
I was checking out some discussions on CI and automation. Some helpful PRs / discussions here:

https://kubernetes.slack.com/archives/C01672LSZL0/p1724091591242469?thread_ts=1724089319.657699&cid=C01672LSZL0

Comment about GHA permissions from GitHub Admins. It seems they do not allow GHA with permission: write. (This is due to a past incident, but I am not familiar with this details.)

etcd: Add etcd-website lint presubmit job test-infra#33333

PR to introduce Markdownlint to etcd-io/website. I believe moving this PR forward will lead to its introduction in k/website as well.

Thank you. I'll take the time to look at it as soon as possible

Hi, team. I see that my PR (kubernetes/test-infra#33333) was referenced from this issue. This issue may be related to the work we've been doing at the etcd website. We didn't have a Markdown linter. The main challenge is that enabling it across all the documents on the website will keep CI runs failing, as we don't have a plan/bandwidth to address the warnings across all files. However, we decided to do an incremental check, and we'll be checking (and returning an error) if there are violations in the changes from the PR. Otherwise, it will just raise a warning.
Please take a look at our issues and PRs. They may help set a path/decision on how to do it for k/website:

https://github.com/etcd-io/website/pull/879
https://github.com/etcd-io/website/issues/857
https://github.com/etcd-io/website/pull/774#discussion_r1498552258

folks, is anyone working on this issue?

Very busy recently

/remove-lifecycle stale


White text rendering too heavy in Firefox

Expected behaviour
That the font weight / anti-aliasing is consistent - preferably have Firefox using Chrome's rendering weight. This is only notable where text is white on colour.
Actual behaviour
Firefox is rendering reversed text more heavily than Chrome. (Firefox top vs Chrome below)
Note 'BETA' and 'Monthly' and 'Notice is given...' which are heavier in the Firefox rendering

Steps to reproduce the behaviour
Preview in Firefox and Chrome
Technical information
Browser
Chrome - 57.0.2987.133
Firefox - 52.0.2 (64-bit)
Operating System
Macintosh OS X 10.12.4
Screenshot

@armstrongb Do you know if this has been looked at?

This appears to still be an issue, might be worth fixing as part of #1710 @boxadesign?


How does orbitdb sync?

I have prepared a cluster of 2 nodes in IPFS with IPFS Daemon and swarm key.
I am running orbitdb and connecting to the IPFS node with "ipfs-api" in HTTP protocol.
I am able to post data through orbitdb (feed, keyvalue) from one node and am able to fetch it back in another orbitdb instance connected to the other node.
The issue is that when I am calling a "put" in one instance and trying to "get" it from another instance, its not able to "get" it the first time. But if the same "get" is being called from the same node the second time, its showing the data.
I am not sure how orbitdb sync works but below is the code that I am running.
Node 1-----------
const OrbitDB = require('orbit-db');
const IpfsApi = require('ipfs-api');
const ipfs = IpfsApi('localhost', '5002', {protocol: 'http'})
const orbitdb = new OrbitDB(ipfs);
const writePermissions = [orbitdb.key.getPublic('hex'), ];
const kv = await orbitdb.kvstore('new-db',{write:writePermissions});
await kv.load();
await kv.put('test', 80);
Node 2------------
const OrbitDB = require('orbit-db');
const IpfsApi = require('ipfs-api');
const ipfs = IpfsApi('localhost', '5002', {protocol: 'http'})
const orbitdb = new OrbitDB(ipfs);
const db = await orbitdb.open('/orbitdb/QmPJ4QXJDfBjPKB6JKZcqmrDfDxbubC85BMQvxDcR2Gunb/new-db');
await db.load();
db.get('test');
Please help!!!

@subhasisbanik I know what the cause of this issue is (I ran into the same thing myself). db.load() resolves only after the database has finished loading from storage into memory. It does not wait for the database to be replicated from peers. The replication happens in the background, and is likely completing a split second after db.get('test') is run. That's why when you run the code a second time, you get the expected value.
If you want to wait for the replication to finish, you can listen for the replicated event. E.g.
await Promise.resolve(resolve => {
  db.events.on('replicated', resolve)
})

Beware, though; if no replication occurs, the above code will hang indefinitely. (For example, if the peers are already fully in sync.) This is a major problem; I don't know of  good solution off the top of my head, though I am looking into options. I'll report back if I find anything.

Thanks for the explanation.
I would surely wait for a reply from you..
On Tue, Nov 20, 2018, 10:06 AM Tyler Yasaka<EMAIL_ADDRESS>wrote:

@subhasisbanik https://github.com/subhasisbanik I know what the cause
of this issue is (I ran into the same thing myself). db.load() resolves
only after the database has finished loading from storage into memory.
It does not wait for the database to be replicated from peers. The
replication happens in the background, and is likely completing a split
second after db.get('test') is run. That's why when you run the code a
second time, you get the expected value.
If you want to wait for the replication to finish, you can listen for the
replicated event. E.g.
await Promise.resolve(resolve => {
db.events.on('replicated', resolve)
})
Beware, though; if no replication occurs, the above code will hang
indefinitely. (For example, if the peers are already fully in sync.) This
is a major problem; I don't know of good solution off the top of my head,
though I am looking into options. I'll report back if I find anything.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/orbitdb/orbit-db/issues/474#issuecomment-440135153,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYPkaAqZ7xiYgFJYQ7_nQtulBRrtfNWuks5uw4bHgaJpZM4XR1S9
.

Hi @subhasisbanik I did find a solution, which requires a couple modifications to orbit-db.
First, I made this change to orbit-db: https://github.com/projectaspen/orbit-db/commit/f91220d3b5a8de38389464675a4db5e00319f180
Then I made this minor adjustment to orbit-db-store: https://github.com/projectaspen/orbit-db-store/commit/a31e1f728c8edd0395b2722766a0d181e3f088eb
This allows me to wait for the new synced event which is fired once for each peer + database, after all of the data has been copied over. If you wait for this event (once after opening each database) for each node you want to sync with, then when you retrieve data for orbit-db, it will be up-to-date.
To make this process smoother, I created 2 packages: 1 for the orbit-db server node, one for the client. They're experimental right now, but feel free to check them out! They use the orbit-db repo changes I linked to above.

orbit-connect-client
orbit-connect-server

Awesome.
I will revert once I have a look into it.
On Wed, Nov 21, 2018, 3:07 PM Tyler Yasaka<EMAIL_ADDRESS>wrote:

Hi @subhasisbanik https://github.com/subhasisbanik I did find a
solution, which requires a couple modifications to orbit-db.
First, I made this change to orbit-db: projectaspen@f91220d
https://github.com/projectaspen/orbit-db/commit/f91220d3b5a8de38389464675a4db5e00319f180
Then I made this minor adjustment to orbit-db-store:
projectaspen/orbit-db-store@a31e1f7
https://github.com/projectaspen/orbit-db-store/commit/a31e1f728c8edd0395b2722766a0d181e3f088eb
This allows me to wait for the new synced event which is fired once for
each peer + database, after all of the data has been copied over. If you
wait for this event (once after opening each database) for each node you
want to sync with, then when you retrieve data for orbit-db, it will be
up-to-date.
To make this process smoother, I created 2 packages: 1 for the orbit-db
server node, one for the client. They're experimental right now, but feel
free to check them out! They use the orbit-db repo changes I linked to
above.

orbit-connect-client
https://github.com/projectaspen/aspen/tree/master/packages/orbit-connect-client
orbit-connect-server
https://github.com/projectaspen/aspen/tree/master/packages/orbit-connect-server

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/orbitdb/orbit-db/issues/474#issuecomment-440597921,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYPkaClMoTPUZRD71BejXmN3D8QioSaAks5uxR7cgaJpZM4XR1S9
.

Moving this to the Field Manual repo so we can detail this in the book


Can't change shortcut for toggling terminal to cmd+ instead of ctrl+

VSCode Version: Code 1.7.2 (7ba55c5860b152d999dda59393ca3ebeb1b5c85f, 2016-11-21T22:01:10.756Z)
OS Version: Darwin x64 15.6.0
Extensions:

Extension
Author
Version

cjsx
crisward
0.0.6

git-common-commands-suite
samschneller
0.2.2

vscode-jumpy
wmaurer
0.3.1

Steps to Reproduce:

Even when disabling the macOS shortcut for focussing the next window, the shortcut does not work when defined in keybindings.json. Interesting when using Add Keybinding inside the editor and you type Cmd+` you get Cmd+Unknown in the dialog.

@kieferrm What keyboard layout are you using? When seeing cmd+unknown it usually means we do not receive this keybinding in vscode. There is a glitch in that widget where pressing only cmd is rendered as cmd+unknown due to how the Keybinding represents a modifier key. I've filed #17158 to track that.
@kieferrm Does pressing cmd+` work for you in Chrome when visiting https://www.w3.org/2002/09/tests/keys.html
More info available at: https://github.com/Microsoft/vscode/wiki/Troubleshooting-Keybindings

@alexandrudima This is what I get in Chrome on the test page when pressing Cmd+`:

keydown (0): [keyCode: 91][shift: false][ctrl: false][alt: false][meta: true]
keydown (1): [keyCode: 91][shift: false][ctrl: false][alt: false][meta: true]
keyup (2): [keyCode: 91][shift: false][ctrl: false][alt: false][meta: false]
keyup (3): [keyCode: 91][shift: false][ctrl: false][alt: false][meta: false]

I use the regular US keyboard layout:

I have just tried today on the mac mini in the office.
I have followed some steps explained in http://apple.stackexchange.com/a/50759 and proceeded to uncheck the following checkbox:

I then switched to VSCode and used the define keybinding widget. Still, cmd+` does not reach VSCode.
There is no possible code change I can do in VS Code if we don't get a keydown event. I am no mac expert to even begin figuring this out.


[core] Wildcard emitted event listener

You can now use a wildcard to listen for any emitted event from an actor:
actor.on('*', (emitted) => {
  console.log(emitted); // Any emitted event
});

@Andarist ping 🏓


bump solana to v1.10.19

Updating solana to v1.10.19.

@samkim-crypto just wondering, how did you make the changes for this?  When upgrading to 1.10.29 in #3303 I noticed that not all of them were updated after running ./update-solana-dependencies.sh 1.10.29, because some of them were left behind to 1.10.15 during this PR.  Did something go wrong with the script?


Make individual tools should update their submodule first

make tools updates submodules and then installs tools
make verilator e.g. does not, and just fails if it's the only tools getting installed.
Each make x should update the tool submodule first.

Credit to @stdavids for reporting!

Fixed in dev


feat(ir): add list comprehension to IR

Partly addressing #87. This PR adds list comprehension and list folding support to the IR.

@grjte I've addressed your comments except adding more detailed docs. I'm working on them now.
One question is if we should rename unfold_lc to something like expand_lc (or something else) because unfold might be confusing since we also have list folding?

Thank you @bobbinth and @grjte for the reviews. Made suggested changes.


Dropdown entries using long names

Discord username
No response
What type of issue is this?
Permanent – Occurring repeatably
Is this issue blocking you from using Enso?

[ ] Yes, I can't use Enso because of this issue.

Is this a regression?

[ ] Yes, previous version of Enso did not have this issue.

What issue are you facing?

Expected behaviour
Short and elegant dropdown entries names.
How we can reproduce it?
No response
Screenshots or screencasts
just create drop on any text and expand the dropdown for range
Enso Version
2023.5.3 nightly
Browser or standalone distribution
Standalone distribution
Browser Version or standalone distribution
standalone
Operating System
Windows
Operating System Version
Win11pro 22H2 22621.1555
Hardware you are using
12th Gen Intel(R) Core(TM) i9-12900HK / RTX3060 Laptop / Nvidia Drivers 531.68

Duplicate #6455


Fix remoteJoin/remoteLeave methods

The callback was triggered before the socket has actually joined/left the room.
Fix https://github.com/socketio/socket.io-redis/issues/198

HI i am trying to use remoteJoin but give me error
 io.sockets.adapter.remoteJoin("RG-RmuWBWRmAHigQAAC_", "rooom",  (err)=> {//join to new room     if(err) console.log("join room error %s", JSON.stringify(err));     else console.log("%s join to room %s", socket.id, "1");
TypeError: io.sockets.adapter.remoteJoin is not a function


setCropBox depends on the width of the container.

[x] Bug report
[x] Feature request

Current behavior
If I try to resize an image inside a small container adjusting the setCropBoxData to a size that it´s bigger than the container itself it will not do it, it will stop in the maxim width of the container

built: function () {
    var w = "a value bigger than the container width"
    var h = "a value bigger than the container height"
    let to_this = {width:w,height:h};
    $(this).cropper('setCropBoxData', to_this);
  },

## Expected behavior
the image would scale and the cropbox itself too to allowing this to happen
Minimal reproduction of the problem with instructions
here I show the problem
https://codepen.io/anon/pen/djprKo
What is the motivation / use case for changing the behavior?
to allow to setCropBox at any size that fits the image independently of the container
Environment

Cropper version: 2.3.4

Browser:
- [X] Firefox version 60
- [X] Chrome

Not support that.


cant establish connection to wamp with autobahn!

I want to use use RPC via autobahn to my ratchet wamp server. But i could not establish the connection.
My server side:
$server = new \Ratchet\App('localhost',3000);
       $server->route('', new WebSocketController,['*']);
       $server->run();

My Class:
use Ratchet\ConnectionInterface as Conn;
use Ratchet\Wamp\WampServerInterface;

class WebSocketController extends Controller implements WampServerInterface {
   public function onPublish(Conn $conn, $topic, $event, array $exclude, array $eligible) {
        $topic->broadcast($event);
    }

    public function onCall(Conn $conn, $id, $topic, array $params) {
        $conn->callError($id, $topic, 'RPC not supported on this demo');
    }

    // No need to anything, since WampServer adds and removes subscribers to Topics automatically
    public function onSubscribe(Conn $conn, $topic) {}
    public function onUnSubscribe(Conn $conn, $topic) {}

    public function onOpen(Conn $conn) {
        echo "opened";
    }
    public function onClose(Conn $conn) {
         echo "close";
    }
    public function onError(Conn $conn, \Exception $e) {
         echo $e;
    }
}

And the client side:
 var autobahn = require('autobahn');
 var connection = new autobahn.Connection({url: 'ws://localhost:3000'});
 connection.onopen = function (session, details) {
   console.log(sessions);
};

connection.onclose = function (reason, details) {
   console.log(reason);
   console.log(details);
}
connection.open();

Here what i get from autobahn console.log:
unreachable
{ reason: null,
message: null,
retry_delay: 1.7760546390824472,
retry_count: 1,
will_retry: true }
unreachable
{ reason: null,
message: null,
retry_delay: 2.883934737974839,
retry_count: 2,
will_retry: true }
and what i get from serve side console output
opened close opened close
Anyone can help???

What does the Network tab in debug tools show? Try making a basic WebSocket connection, does that connect?

According the search I did among issues, I should use autobahn 0.8.* since it doesnt support wamp v2. I could not install that version via npm. The problem was probably this. I solved it by using thruway.
Thanks.

Yes it is, I do so. Autobahn 0.9+ implements wampv2, we have to use autobahn 0.8, and I also don't find it on npm. Instead I find wamp1, but I haven't tested it yet.

Hi - Might I suggest putting some sort of disclaimer on the bottom of the push demo page? One's natural tendency when working with Javascript these days is to reach for libraries via npm. I personally wasted a good two hours trying to figure this out yesterday...

Hi, I have seriously been trying for days to get this stuff working, using different autobahns and ratchet php and thruway. Does anyone have a complete example of this? :)

@topproto If you use Thruway, use https://github.com/voryx/Thruway.js/ with it. Ratchet, when used with autobahn expects a version that supports WAMPv1, IIRC the current versions only support WAMPv2 at this point.

https://github.com/ratchetphp/Ratchet/issues/655#issuecomment-404176983


Fix a bug in parsing userParam value

When calling the function convert_xml_value in one of the places, the order of arguments was reversed.
Thanks @ZhengnanCheng for the bug reporting

@gtluu  JFYI


Move "package-versions" to dev deps

ocramius/package-versions should be a dev dependency. currently installation fails with:
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Conclusion: don't install palicao/php-redis-time-series 2.0.3
    - Conclusion: don't install palicao/php-redis-time-series 2.0.2
    - Conclusion: don't install palicao/php-redis-time-series 2.0.1
    - Conclusion: remove composer/package-versions-deprecated 1.8.1
    - Installation request for palicao/php-redis-time-series ^2.0 -> satisfiable by palicao/php-redis-time-series[2.0.0, 2.0.1, 2.0.2, 2.0.3].
    - Conclusion: don't install composer/package-versions-deprecated 1.8.1
    - palicao/php-redis-time-series 2.0.0 requires ocramius/package-versions 1.4.2 -> satisfiable by composer/package-versions-deprecated[1.8.0], ocramius/package-versions[1.4.2].
    - Can only install one of: composer/package-versions-deprecated[1.8.0, 1.8.1].
    - don't install ocramius/package-versions 1.4.2|don't install composer/package-versions-deprecated 1.8.1
    - Installation request for composer/package-versions-deprecated (locked at 1.8.1) -> satisfiable by composer/package-versions-deprecated[1.8.1].

@palicao will you do a new release soonish? ;)


Refactor Card Component

Cleaned up code, created components and created indexes for base file in each folder

Cleaned up code, created components and updated typing


Cascaded Booleans - intermediate mesh repair possible?

Hi!  In your paper, you mention that Diazzi and Attene'a approach solved the robustness problem for cascaded booleans by  "implicitly repairing the input during the process" but doing so introduced a performance penalty.  Is such an approach possible with your pipeline for applications that can afford to be non-interactive?  Or, if possible in theory, would the difficulty of doing so be comparable to that of solving the cascading for indirect predicates problem?
For context - the potential application I'm interested in is evaluation of complex CSG boolean trees used to define complex models in the BRL-CAD computer aided design software package  - we convert implicit primitives to meshes (when the primitives aren't already meshes) and then attempt to evaluate the booleans on the meshes.  Each intermediate mesh is then used as an input for parent CSG operations - which, unless I'm mistaken, constitutes a classic example of cascading booleans.  As expected, our current implementation encounters robustness issues, and I'm very interested in whether your research can be used to improve the outcomes of our use case.  Since this evaluation is normally done during a conversion step we can afford (within reason) non-interactivity for the sake of robustness.  Before doing a deep dive into the reference code, I thought it might be worth asking if a) the elements to do a repair step are already present in cinolib or one of the other supporting codes b) if not, what approach you would recommend, and c) if you have any sense of how difficult such a repair step would be to implement.
Thanks for your time and for making a very interesting effort available!

hi! thanks for the interest in our research.  Indeed, the scenario that you described is a case of cascaded boolean, because the output of the boolean operation at time t becomes the input for the subsequent boolean operation at time t+1.
I feel there is some confusion between being robust in the computation of booleans and being robust against possibly defective inputs meshes passed to the boolean operator. These are two different things. Specifically:

the code in this repository computes booleans robustly, but it assumes that the input meshes are always well formed (manifold watertight meshes with a coherent surface orientation and no self intersections). If these assumptions do not hold, the algorithm may not work as expected

Diazzi and Attene's work is robust against possibly ill-defined input meshes. For example, if the input meshes are not watertight or they contain self intersections, the program would still perform as expected. The price to pay for this feature is using an explicit volume mesh, with consequent slowdown

Note that none of these two methods supports cascading at the moment, which is another beast.
The issue with cascading has to do with the fact that the output of a boolean operator contains intersection points that are only implicitly represented, because their coordinates cannot be represented exactly into the floating point system of your computer. Both algorithms mentioned above use the Attene's Indirect Predicates to represent such points "indirectly", that is, memorizing what input elements generated the intersection, and then using only this information during computation.
Given this premise, the reason why cascading is currently not possible is because Indirect Predicates do not permit to construct a new implicit point as the intersection of mesh elements that already contain some other implicit point (this is exactly what would happen if you cascade).
In the final part of the paper we briefly mention that this is not a theoretical limitation, but just a limitation of the tools that we are currently using.  In particular, one can easily observe that the result of a boolean operation (also cascaded) is always a subset of all input meshes that participated in the boolean. Therefore, if all my input meshes have floating point coordinates, it should always be possible to express all intersection points as the intersection of input primitives. What we miss right now, is the ability to do a backtracking to retrieve the correct input mesh elements during cascading.
So, long story short, cascading is not currently supported but it will be eventually supported. The time necessary to bridge the gap will mostly depend on our ability to get funding and hire somebody to do the missing part. If you are an academic and want to collaborate on it, or if you are a company and want to somehow contribute to it, just let us know :)

Given this premise, the reason why cascading is currently not possible is because Indirect Predicates do not permit to construct a new implicit point as the intersection of mesh elements that already contain some other implicit point (this is exactly what would happen if you cascade).

I see.  So if the result of one computation is "stepped down" to an approximation using all floating point numbers (as must be done if the boolean result is going to be exported to something like an OBJ), that mesh may (if it satisfies the necessary properties) in turn be used as the input for a new boolean operation - however, in doing so, that approximation will lose the correctness guarantees that properly propagating the original IP intersections from the original boolean operation would provide?

The idea here would be to take the output of each boolean and cast all points to floats. This is a lossy cast (and may create all sort of troubles!) but these defects can be compensated by the "mesh repairing feature" of the algorithm.

So the  write_OBJ output mesh from main.cpp in your example will, in principle, need PolyMender or some similar repair steps to ensure a manifold watertight, non-self-intersecting output?  Eventually, we'd want to produce a final mesh that was "clean".

So, long story short, one may try Diazzi and Attene's heuristic cascading and see what happens. Truly robust cascading is not currently supported but it will be eventually supported. The time necessary to realize it will mostly depend on our ability to get funding and hire somebody to do the missing part. If you are an academic and want to collaborate on it, or if you are a company and want to somehow contribute to it, just let us know :)

Unfortunately I'm neither - I'm just a software developer on the BRL-CAD project :).  I'll start by working with the reference implementation code and see what's involved with hooking it into our facetization pipeline - that'll be the first step regardless.  If I rework it to provide a shared library, would that be of interest as a pull request?

I see. So if the result of one computation is "stepped down" to an approximation using all floating point numbers (as must be done if the boolean result is going to be exported to something like an OBJ), that mesh may (if it satisfies the necessary properties) in turn be used as the input for a new boolean operation - however, in doing so, that approximation will lose the correctness guarantees that properly propagating the original IP intersections from the original boolean operation would provide?

correct

So the write_OBJ output mesh from main.cpp in your example will, in principle, need PolyMender or some similar repair steps to ensure a manifold watertight, non-self-intersecting output? Eventually, we'd want to produce a final mesh that was "clean".

No. Keep in mind that the approximation error affects only the vertex coordinates and not the mesh connectivity. Robust booleans would still guarantee the correct topology. Precisely, if the two shapes are not tangent, the output mesh will be guaranteed to be manifold watertight. But, because of the approximated float coordinates, you may introduce zero area triangles, intersections, and points that move far away from where they should be  (because of errors in the rounding). For the record, Diazzi and Attene's work would remedy zero area elements and intersections, but may "fail" because of badly rounded coordinates that create sort of artificial spikes and stuff like that

Unfortunately I'm neither - I'm just a software developer on the BRL-CAD project :). I'll start by working with the reference implementation code and see what's involved with hooking it into our facetization pipeline - that'll be the first step regardless. If I rework it to provide a shared library, would that be of interest as a pull request?

The code is shaped in a way that, to my understanding, making a library out of our tool would be as easy as saying to cmake "make a library" and not "make an executable". But of course, if you massage the code and create anything that looks like useful for the community, please let us know, we'll be happy to include it in the repo!


[CI] Fix vulnerable base images

Check the doop dashboard for vulnerable images. We have issues in all our deployments

https://github.wdf.sap.corp/cc/base-images

[ ] Elektra
[ ] Supernova (standalone)
[ ] Cypress Dashboard
[ ] Juno UI Storybook
[ ] Workspaces


Fix for #8 issue

If the '.env.example' didn't exist, the commands would fail.
Now we check the environment list, loop through it, and if any of the files are not present we'll create them with a sample ".env.example".

The reported issue: #8

Will fix this in half an hour. @a-bashtannik

@a-bashtannik Thanks for pointing me in the right direction.
I didn't pay attention to the fact that we're supporting two versions of Laravel.
So the way I'm handling it now is that we check the laravel version first, based on the version we copy the ".env.example" file accordingly.


Pester Runner in Azure PowerShell

@rfennell - this is a great VSTS Task - I have been using it loads. Thank you. I have an enhancement request. I am using it more and more for Integration tests, Smoke tests (post-release, as part of a VSTS Release Configuration), that sort of thing. I am finding that I want to run AzureRM cmdlets in my tests but of course I need to Login-AzureRMAccount. I was wondering if it would be possible to have an "Azure PowerShell" version of the Task (if you know what I mean) or if you could propose a workaround.
Thanks in advance.

How did you envision it working?
If I add a couple of extra parameters and logic similar to the following
param
(
$azureAccountName ,
$azurePassword
)
$psCred = New-Object System.Management.Automation.PSCredential($azureAccountName, (ConvertTo-SecureString $azurePassword  -AsPlainText -Force))
Login-AzureRmAccount -Credential $psCred
// then the pester logic we have

would that work for what you envisage?
Basically adding the login call if the parameters are provided

Would that allow me to use an (AAD Application) Service Principal? If so, great! I will do some research on the Azure PowerShell (builtin) task and see what their logic is...

let me know what you discover, I think I would prefer to add a flag/switch to enable the extra function. but not against a second version of the task

The Azure PowerShell task requires an input of type connectedService:AzureRM
AzurePowerShell.ps1 then runs Initialize-Azure which in turn calls Initialize-AzureSubscription . It appears that the Endpoint knows the ServicePrincipalId and the ServicePrincipalKey and so can create the PSCreds for the Principal.
I wonder if Tasks/Common/VstsAzureHelpers_ are available to all tasks, or if they would need to be shipped with the Task?
@ericsciple, @pragupta-ms - care to comment?

you would need to copy the code and bundle it with your task. the build process in the vsts-tasks repo copies it into place for the tasks that consume it.

My concern of bundling is the overhead it cause to make sure any modules are kept up to date. That said should like there is an outline idea here.
I will try to have a look to see what can be done, but not sure how quickly as I am going to be offline for a few weeks on holiday, going to be November at the soonest.
Happy to look at Pull Request submissions though

@rfennell yes, I agree. I was hoping it would be an easy addition but I don't think it is worth the effort right now. Also, I am assuming that Pester will be installed software on Hosted Build Agents when they are upgraded to Windows 2016? I am not sure what the timeline for this is though.
If I get stuck and really need the feature I would be happy to Submit a PR :)
Thanks again.


monaco.KeyMod.chord improperly typed

monaco.KeyMod.chord yields Typescript error error TS2554: Expected 2 arguments, but got 1. when using like the example in the playground - https://microsoft.github.io/monaco-editor/playground.html#interacting-with-the-editor-adding-an-action-to-an-editor-instance.
Using a workaround that looks like this for now:
// good
monaco.KeyMod.chord(monaco.KeyMod.CtrlCmd | monaco.KeyCode.KEY_S, monaco.KeyCode.Unknown)

// TS error
monaco.KeyMod.chord(monaco.KeyMod.CtrlCmd | monaco.KeyCode.KEY_S)

A possible solution would be to make the second parameter in the definition optional, but not sure if that would have side effects down the line.
Currently, it requires 2 params:
https://github.com/microsoft/monaco-editor/blob/dfaf55beb9561c2bbbc8b23574f005d5d22947f4/monaco.d.ts#L380

@gperl27 I'm not 100% sure what the problem is. monaco.KeyMod.chord appears to be properly typed:
	export class KeyMod {
		static readonly CtrlCmd: number;
		static readonly Shift: number;
		static readonly Alt: number;
		static readonly WinCtrl: number;
		static chord(firstPart: number, secondPart: number): number;
	}

To create a chord keybinding, you need to specify the first part and the second part.

@alexandrudima you are correct. However the example in the playground (link above) implements a chord without the second parameter, indicating that the interface for chord's second parameter could be optional.
Hence, updating secondPart in the interface to be an optional number could be the correct interface.
Or the example could correctly implement the chord (even if it's not getting type-checked).

@gperl27 The sample that is linked uses monaco.KeyMod.chord with two arguments:
	// An optional array of keybindings for the action.
	keybindings: [
		monaco.KeyMod.CtrlCmd | monaco.KeyCode.F10,
		// chord
		monaco.KeyMod.chord(monaco.KeyMod.CtrlCmd | monaco.KeyCode.KEY_K, monaco.KeyMod.CtrlCmd | monaco.KeyCode.KEY_M)
	],

Ah you're right, my apologies.


Adding translation for pt-BR (Brazilian Portuguese)

With this commit, users of the project will be able to use
translated messages for the Brazilian Portuguese language.
As this is a translation addon, no tests were added.

Thanks for this @ramirovjr. For the time being we've decided not to accept localization PRs into clearance itself. There are a couple of different reasons for this:

We're not really suited to check if changes to functionality would impact translated text.
If we add new keys for a feature, do we have to wait for all translations in order to ship?

We have clearance-i18n which is both a gem that users can opt into and also meant as a starting point for people to extract the translations they may require. We haven't publicized it much because, to be honest, I'm not 100% satisfied with this approach either (versioning compatibility has me worried).
For the time being, at least, we will continue this approach. The PT-BR translations do already exist in clearance-i18n. You can open a PR there if there are differences (particularly if the existing ones are incorrect).
Thanks!


PgListener holds open connection so PgPool::close never finishes

I'm trying to implement graceful shutdown in my application. I have a task that waits for a quit notification, then calls PgPool::close to close the connection pool. I have another task which is calling PgListener::try_recv in a loop and exits the loop if it gets an error or None. However, the close call never returns because the connection is being held open by the PgListener. From the docs it seems like try_recv would return an error or None when the pool is closed, but that doesn't seem to be happening.
I'm using sqlx 0.5.10 with Postgres and tokio on Rust 1.57.0.

To be fair, there's nothing in the documentation that suggests that this is how it'll work. If there's an error on the connection, try_recv() will try to acquire another from the pool at which point it would return PoolClosed, but not before.
From the pool's perspective, PgListener isn't anything special. The task using it is just like any other that's sitting on an acquired connection or waiting on an in-flight query. Calling close() doesn't cancel in-flight queries (which requires a separate connection with superuser privileges to do so in Postgres anyway), nor does it have any way in general to notify tasks that are currently holding a connection that the pool is closed.
Similarly, if you .leak() a PoolConnection it'll simply prevent the pool from ever closing, which I honestly didn't realize until just now makes that method particularly hazardous. Pool should probably maintain an internal count of leaked connections so it doesn't wait forever for them to never be returned, but that's an orthogonal issue.
That kind of stuff is too tied into application-level semantics to be handled automatically, although I appreciate that it would be annoying to retrofit your own "application is shutting down, please stop listening" notification.
Given that try_recv() would eventually return PoolClosed anyway, I don't see a huge issue with changing it to be returned eagerly when the pool is closed.
However, I think it could be really useful to make it possible to listen for the closed notification on Pool directly so other application code that acquires and holds a connection for long durations can implement the same behavior. It could be something as simple as:
impl<T> Pool<T> {
    /// Resolves when `.close()` is called.

    /// Can be used with something like `select!()` to cancel tasks that acquire and hold onto connections for a long time,
    /// which would otherwise prevent the pool from closing.
    pub async fn closed(&self) {

    }
}

To be fair, there's nothing in the documentation that suggests that this is how it'll work. If there's an error on the connection, try_recv() will try to acquire another from the pool at which point it would return PoolClosed, but not before.

So just to make sure I understand, you're saying that in my situation, I would eventually get a PoolClosed from try_recv(), but only after something else causes an error? I think it would be much more useful if that happened immediately.
I suppose I could always try to interrupt the try_recv() if my own quit signal gets notified, but according to this comment I think that might run into other issues? If not, your Pool::closed suggestion sounds great.

I suppose I could always try to interrupt the try_recv() if my own quit signal gets notified, but according to https://github.com/launchbadge/sqlx/issues/643#issuecomment-675728317 I think that might run into other issues?

Theoretically yeah, but if your application is immediately quitting anyway, it doesn't really matter.

Well that's the thing, I'm trying not to immediately quit, I wanted the shutdown to be as "nice" as possible and let everything close that needs to. I'll try cancelling try_recv() and see if that works.

I mean if you're not going to use the connection again, which you won't be as the connection will be closed as soon as you return it to the pool.

Ah okay I see what you mean, that makes sense.
I was able to get a working solution by using select on the try_recv() call to interrupt it when my application is exiting. This works fine for me, but I can definitely see the general use in the Pool::closed future you suggested so you don't need to use an external quit notification and can just tell if you're exiting from the pool itself.

Leaving this open as a note to implement that close notification and integrate it into PgListener.


tdd/IndexStateController

Is a kind of state controller that
is a Map hashFunctionResult to entity id[]
respond
add(hashFunctionResult, id[])
remove(hashFunctionResult, id[])
select(hashFunctionResult, hashFunctionResultFrom)
includes(hashFunctionResult)
It has SearchTree underneath
it has deserilized tree in its state

#23


Added content for debug page updates

Closes #4075

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/36fbda7d18029829ca3818dfe03f18ee6044bb68/


Clicking inside tooltip content and moving the mouse away closes the tooltip

Hi, I have simplified the problem in this demo: https://stackblitz.com/edit/react-rv7mmr
As you can see, clicking inside Content and moving the mouse away closes the Tooltip.
Commenting isCapture in ReactTooltip solves the issue, but makes the Tooltips keep opening without closing the previous ones.

Solved it with
	const stopEventPropagation = e => { 		e.stopPropagation(); 	};
and
afterShow={e => { 					window.addEventListener("mouseleave", stopEventPropagation, true); 				}}
afterHide={e => { 					window.removeEventListener("mouseleave", stopEventPropagation); 				}}


Bad filename results in cryptic error

If you call report.save with a super long (or invalid filename), you get a really weird error. At first I thought something was wrong with my plots, but nope it was just a filename issue.
Error validating report document:

.....

validate_report_doc
    rng_validator.assertValid(xml_doc)
  File "src/lxml/etree.pyx", line 3623, in lxml.etree._Validator.assertValid
lxml.etree.DocumentInvalid: Error validating datatype string

Thanks for raising, i think I know why this is occurring - we'll look into and try publish a fix in the next week or so.

fixed in b9b41ea2abceb8971c26948056f089e2d0f7d104


static: set default_library flag for meson in makeStaticLibrary

Adds support for building static libraries with meson.

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Could you rebase this?


Callerid2

@guokeno0 Here is a small change that adds some more test coverage for effective_caller_id.

@dumbunny A quick note on the PR itself: You pushed the branch to the official Github repository and not your fork dumbunny/vitess.
That's fine for now. I'll revise our Git + Github documentation tomorrow. Once that's available, let's make sure that you follow the triangular workflow using your fork then :)

@dumbunny I also talked with Liang yesterday and looks like you guys are all using branches from the youtube/vitess master yet I'm using my fork and sync with the upstream every time. That's why your push will always go to the master directly

@dumbunny
git checkout callerid2
// make change locally
git add .
git commit -amend
git push -f // this forces changes in github in sync with your local change
// at this point, your PR should reflect your latest change

FYI, we prefer to use forked model to do development. Fork youtube/vitess repo in your own github repo, do the development, send PR to youtube/vitess for your changes :)

@guokeno0 @yaoshengzhe
I'll update our Git instructions later to reduce the confusion around this and avoid accidental pushes to the official Github repo in the future.

Overall LGTM, it is better to improve the test coverage by testing other cursor APIs


[boost] Update to 1.74.0

Library name: boost
New version number: 1.74.0
Other information that may be useful (release notes, etc...)
There are some mingw related fixes in boost-build that I'd like to have

If there were instructions on how to do this, I'm happy to help as it's something a project I'm working on needs to fully move to VCPKG as a packange manager.

It has something to do with this PowerShell script I think

Ah… OK…, let me have a look at that and see what I can come up with!
Thanks,
Sean.
From: Long Nguyen<EMAIL_ADDRESS>Sent: 25 August 2020 14:50
To: microsoft/vcpkg<EMAIL_ADDRESS>Cc: Sean Farrow<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [microsoft/vcpkg] [boost] Update to 1.74.0 (#13033)
It has something to do with this PowerShell scripthttps://github.com/microsoft/vcpkg/blob/master/scripts/boost/generate-ports.ps1 I think
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vcpkg/issues/13033#issuecomment-680037301, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALDK7QFW5DOEKLDWYILAG3SCO6RBANCNFSM4QGLJGLA.

Ok, if you change all the references from 1.73 to 1.74 in the script you reference, change the PowerShell execution policy to unrestricted for the current session and have VCPKG somewhere on the path, you should be able to run the script and update the port locally.
There is a new header-only library with 1.74, Nowide, so I’m not sure how new libraries are handled as we might want a new installable package for that.
From: Long Nguyen<EMAIL_ADDRESS>Sent: 25 August 2020 14:50
To: microsoft/vcpkg<EMAIL_ADDRESS>Cc: Sean Farrow<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [microsoft/vcpkg] [boost] Update to 1.74.0 (#13033)
It has something to do with this PowerShell scripthttps://github.com/microsoft/vcpkg/blob/master/scripts/boost/generate-ports.ps1 I think
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vcpkg/issues/13033#issuecomment-680037301, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALDK7QFW5DOEKLDWYILAG3SCO6RBANCNFSM4QGLJGLA.

It should be automatically handled by this line

Ok, can you try just changing the version references from 1.73 to 1.74 and let me know how that goes.
I can’t check this myself before the weekend unfortunately.
Thanks,
Sean.
From: Long Nguyen<EMAIL_ADDRESS>Sent: 25 August 2020 15:52
To: microsoft/vcpkg<EMAIL_ADDRESS>Cc: Sean Farrow<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [microsoft/vcpkg] [boost] Update to 1.74.0 (#13033)
It should be automatically handled by this linehttps://github.com/microsoft/vcpkg/blob/master/scripts/boost/generate-ports.ps1#L230
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vcpkg/issues/13033#issuecomment-680073936, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALDK7TXDW3IYYA6V46EF4TSCPF23ANCNFSM4QGLJGLA.

Alright I'll test it tomorrow

OK, I've now started some work on this on a private branch.
I'm struggling to get Nowide building as the jam.v2 file has changed and is now looking for config, which it searches for in the wrong directory.
I'm thinking of adding a cmake file to handle this and update where it thinks the config file is, or should we crate a patch, if so what againsh?

Can anyone works on this? I'm quite busy now

I think I know what the fix is, give me the weekend to validate my thinking.
From: Long Nguyen<EMAIL_ADDRESS>Sent: 09 September 2020 08:09
To: microsoft/vcpkg<EMAIL_ADDRESS>Cc: Sean Farrow<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [microsoft/vcpkg] [boost] Update to 1.74.0 (#13033)
Can anyone works on this? I'm quite busy now
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vcpkg/issues/13033#issuecomment-689355088, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALDK7XU5LU2BLIW2VALNM3SE4SYLANCNFSM4QGLJGLA.

I see boost/STLInterfaces has been added in the 1.74 update, https://www.boost.org/users/history/version_1_74_0.html

I'll try to get some time to work on this tonight

OK, I’ve forked and finished 90 % of the work, so If you want to carry on, go to:
https://github.com/SeanFarrow/vcpkg.git
The branch you want is Issue13033.
The only issue I can see remaining is the completion of correctly building the nowide library, they changed the way this works in 1.74 and used config checks.
Thanks,
Sean.
From: Long Nguyen<EMAIL_ADDRESS>Sent: 22 September 2020 02:41
To: microsoft/vcpkg<EMAIL_ADDRESS>Cc: Sean Farrow<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [microsoft/vcpkg] [boost] Update to 1.74.0 (#13033)
I'll try to get some time to work on this tonight
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vcpkg/issues/13033#issuecomment-696467335, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALDK7USRSAPWJU7KUWKYNDSG76BFANCNFSM4QGLJGLA.

-@SeanFarrow, can't see the Issue13033 branch...

Give me until tomorrow, I forgot to push!
From: niclar<EMAIL_ADDRESS>Sent: 12 October 2020 15:06
To: microsoft/vcpkg<EMAIL_ADDRESS>Cc: Sean Farrow<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [microsoft/vcpkg] [boost] Update to 1.74.0 (#13033)
-@SeanFarrowhttps://github.com/SeanFarrow, can't see the Issue13033 branch...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vcpkg/issues/13033#issuecomment-707141816, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALDK7ST6RYXAHXJU5JGRD3SKMEM5ANCNFSM4QGLJGLA.

@niclar,
This has now been pushed, the branch you want from my fork is Issue13033.
I've updated the version in scripts/boost/generate-ports.ps1, but when I try to do:
vcpkg install boost-nowide:x86-windows-static
There is an issue around finding the config folder (we need a cmake file to copy this in.)
Then, this library fails to build, I'm assuming because it fails to find some targets in the .bjam file.
Once these two issues have been fixed, we can do some testing and then should be good to go!
Thanks,
Sean.

@niclar Are you able to submit a PR to my original branch, I'll then take things from there.￼

sure, https://github.com/SeanFarrow/vcpkg/pull/1

I don't really know much about the way vcpkg handles boost, so @SeanFarrow and @niclar please finish it for me, and I'll work on the mingw part.

works now for linux & windows (including the latest toolset) in: https://github.com/niclar/vcpkg/tree/Issue13033

@niclar  if you can create a pull request to my fork, I'll fix this this weekend and we can get it merged upstream as soon as practically possible.￼

@longnguyen2004  Did you manage to have a look at the pull request created by @niclar?

I'll try to find some free time to test it with llvm-mingw.

Fantastic, it’s working fine with Visual Studio 2019.
From: Long Nguyen<EMAIL_ADDRESS>Sent: 27 October 2020 10:33
To: microsoft/vcpkg<EMAIL_ADDRESS>Cc: Sean Farrow<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [microsoft/vcpkg] [boost] Update to 1.74.0 (#13033)
I'll try to find some free time to test it with llvm-mingw.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vcpkg/issues/13033#issuecomment-717146209, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALDK7XQIFI2LL2MI2ALRDDSM2OVLANCNFSM4QGLJGLA.

Seems to work fine with llvm-mingw as well!

Are you happy to merge this?
As an FYI, when boost 1.75 is released (scheduled for around the 2nd December), I’ll create an issue/patch.
Thanks,
Sean.
From: Long Nguyen<EMAIL_ADDRESS>Sent: 28 October 2020 08:38
To: microsoft/vcpkg<EMAIL_ADDRESS>Cc: Sean Farrow<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [microsoft/vcpkg] [boost] Update to 1.74.0 (#13033)
Seems to work fine with llvm-mingw as well!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vcpkg/issues/13033#issuecomment-717782783, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALDK7W2WONQXXS5OCAQUB3SM7J4XANCNFSM4QGLJGLA.

@niclar How's the PR going? It looks pretty good to me

Alright we can close this now :)


aarch64 build failures with gcc 10 and binutils 2.34

Describe the bug
https://github.com/NixOS/nixpkgs/pull/89793#issuecomment-751692132
Additional context
Add any other context about the problem here.
Notify maintainers

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

Using gcc 9 for now with aarch64.

Using gcc 9 for now with aarch64.


Fix zcoin builder

PR intention
Update dockerfile zcoin-builder to fix build fail when target to windows
Code changes brief

Add mingw alternatives updating to dockerfile

@riordant Thanks, rebased.

@riordant @ultimaweapon Please check.


OpenVINO-EP v4.0 samples update

Description:
Updated README documents.
Updated csharp sample with latest ImageSharp API
Updated cpp samples with nchw changes
Note: The samples are now compatible with the latest openvino 2022.1 version.

This branch is out-of-date with the base branch Seems like we need to merge in master before I can merge the PR.


split FutureResult to interface and implementation

Coverage remained the same at 83.29% when pulling 2ca9d2aa37fb2d33d7ed8cb1bf30a9d660148b77 on sadam21:future_result into b30ef372cd35a2b6c614ec1c82e79fa525df1c91 on martiner:master.

Coverage remained the same at 83.29% when pulling 5c736c3bbb5324275391710a641ff0d3f66b9f01 on sadam21:future_result into b30ef372cd35a2b6c614ec1c82e79fa525df1c91 on martiner:master.

Closes: #144


Add API documents

@queenypingcap Please help to review the descriptions.

can swagger find Handler comment and generate the doc directly?

Beego supports auto document generation.
But seems swagger is not.

Got it.

May be we can try some plugins later, like this.

Maybe later we can have a try，if we can do this, it will be more convenient to generate api document, that is cool:)

LGTM
I suggest using comment generation ASAP.

LGTM
@queenypingcap  PTAL

I merge this now, @queenypingcap feel free to add comments at any time, thanks.


i18n of "Create" and "Update" action buttons

Hey guys,
Using ActiveAdmin 0.4.0, I'm running AA with the spanish locale, and every label is perfectly translated except for the "Update" and "Create" actions.

I have added the following keys in the activeadmin.es.yml file, just like I found in other languages' yml files, but it doesn't work:
es:
  active_admin:
    #...
    create_model: "Guardar %{model}"
    update_model: "Guardar %{model}"
    #...

In the AA initializer I set the locale to :es.

Have you added all the following keys?
pt-BR:
active_admin:
new_model: "Cadastrar %{model}"
create_model: "Cadastrar %{model}"
edit_model: "Editar %{model}"
update_model: "Editar %{model}"

Yes, in fact I copied the keys from the pt-BR yaml file so I don't see
why it doesn't work. Is it working for you in Portuguese?
El 01/02/2012, a las 20:28, "Fábio Maia"
<EMAIL_ADDRESS>escribió:

Have you added all the following keys?
pt-BR:
active_admin:
new_model: "Cadastrar %{model}"
create_model: "Cadastrar %{model}"
edit_model: "Editar %{model}"
update_model: "Editar %{model}"

Reply to this email directly or view it on GitHub:
https://github.com/gregbell/active_admin/issues/961#issuecomment-3769460

Yes. It is working at my project and I've updated my active_admin version to 0.4.0 as well and in my application.rb file I wrote down config.i18n.default_locale = 'pt-BR'.

I have te same problem in PL. Other translations are working, but those for update/create buttons, still are in english.

Ok i have answer:
If we are talking about submit buttons , that are generated from formtastic  then we need :
en:
formtastic:
:yes: 'Yes'
:no: 'No'
:create: 'Create %{model}'
:update: 'Update %{model}'
:submit: 'Submit %{model}'
:cancel: 'Cancel %{model}'
:reset: 'Reset %{model}'
:required: 'required'
Btw. fabiormoura: i don't belive it was working for you with your sollution;]

I thought the problem of bbonmain was in the view title (Editar Usuario, Nuevo(a) Usuario). I'm already using the formtastic keys in my project :)

Adding the formtastic keys worked perfectly! Thanks @panSarin and everyone else! I'll submit a pull request with these keys added in my locale. Cheers


Can't connect to IMAP server via SSL/TLS on port 993, no error detail given

This is likely related to or a duplicate of issue #3141 or #893.
Expected behavior
Connection should be made to my host via SSL/TLS on port 993.
Actual behavior
An error message "Setup could not finish / Cannot connect to server. (Unable to connect)" is shown without further details.
Steps to reproduce

Enter hostname, select SSL/TLS, port 993, enter username and password, and click Done.

Environment
K-9 Mail version: 5.403
Android version: 4.4.4
Account type (IMAP, POP3, WebDAV/Exchange): IMAP
Ciphers supported by server: 0xc027, 0xc028, 0xc02f, and 0xc030.
Ciphers supported by client: According to SSLLabs client test:

0xcc14
0xcc13
0xcc15
0xc014
0xc00a
0x39
0x38
0x35
0xc012
0xc008
0x16
0x13
0xa
0xc02f
0xc02b
0xc013
0xc009
0xa2
0x9e
0x33
0x32
0x9c
0x2f
0xc011
0xc007
0x5
0x4
0xff

k9-log.txt

Nothing in the logs. Unfortunately there's not much we can do about this - we don't get told why the connection is closed.

Closing as duplicate of #1789


recipients [nfc]: Small refactors to new filteredRecipientsForPM helper.

This is a quick followup to #3874. It turns out this new helper function has some close relatives already existing, collected in one module, so we move it next to them. Then make a couple of small tweaks within the function.
There's plenty that could be improved about this whole family of very similar functions, and their names and documented interfaces. Tomorrow I may make a go at trying to find a minimal PR in that direction that doesn't block on doing any big broader refactors. In any case, I think this branch is helpful as is.
/cc @agrawal-d

Also, just to say this explicitly: thanks @ray-kraesig and @agrawal-d for pulling this function out in the first place! That was a necessary step in anything we might do to try to clean up this cluster of logic.

Thanks @ray-kraesig for the review!
Yeah, display_recipient is definitely a mess. Documenting would be a very good start; normalizing (at the app's outward boundary, i.e. at a crunchy shell) would be great too. I suspect normalizing will happen in stages (rather than in one go), and will probably involve some iteration on finding the shape we want to normalize it into.


Tmux exits after started with @continuum-restore 'on'

I am running tmux 3.3a with the following minimal configuration.
# change TMUX plugin manager path
set-environment -g TMUX_PLUGIN_MANAGER_PATH '~/.tmux/plugins/'

# set path
set-environment -g PATH '/usr/local/bin:/bin:/usr/bin'

set -g @continuum-boot 'on'
set -g @continuum-restore 'on'
set -g @continuum-save-interval '5';

# list of plugins
set -g @tpm_plugins '              \
    tmux-plugins/tpm               \
    tmux-plugins/tmux-resurrect    \
    tmux-plugins/tmux-continuum    \
'

# Initialize tmux plugin manager
# NOTE: KEEP THIS LINE AT THE VERY BOTTOM OF tmux.conf
run -b '~/.tmux/plugins/tpm/tpm'

On starting with user systemd, I get the followings in journalctl
$ journalctl --user -u tmux
Jun 29 13:49:16 manjaro-pc systemd[4016]: Starting tmux default session (detached)...
Jun 29 13:49:16 manjaro-pc systemd[4016]: Started tmux default session (detached).
Jun 29 13:49:18 manjaro-pc save.sh[635829]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635875]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635880]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635897]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635902]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635905]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635908]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635912]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635914]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635921]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635923]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635924]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635925]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc save.sh[635926]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc systemd[4016]: tmux.service: Control process exited, code=exited, status=1/FAILURE
Jun 29 13:49:18 manjaro-pc save.sh[635868]: Terminated
Jun 29 13:49:18 manjaro-pc save.sh[635927]: no server running on /tmp/tmux-1000/default
Jun 29 13:49:18 manjaro-pc systemd[4016]: tmux.service: Failed with result 'exit-code'.

Manual starting of tmux new-session -d and tmux ls shows
no server running on /tmp/tmux-1000/default

If I remove the set -g @continuum-restore 'on', the tmux server starts. Attached are the output from tmux -vvvv new-sesion -d
tmux-client-837926.log
tmux-out-837928.log
tmux-server-837928.log

I noticed this issue today. I had resurrect, continuum, and copycat and had to try with each of them separately and faced this.

Same issue on MacOS (tmux 3.2a). Resolved after commenting out set -g default-command "reattach-to-user-namespace -l $SHELL" in my .tmux.conf.

I'm affected as well, and similarly to OP I can "fix it" by commenting out set -g @continuum-restore 'on'.
I see this backtrace in journalctl --user -f:
Nov 29 18:10:44 bf-laptop systemd-coredump[505739]: [🡕] Process 504232 (tmux: server) of user 1000 dumped core.

                                                    Module linux-vdso.so.1 with build-id 30f1c5e3564573eae5ca9c23fc4657ee37d04afd
                                                    Module libpthread.so.0 with build-id 85431f01160c3de171d3baeb3f8cf1c9578dc441
                                                    Module libgpg-error.so.0 without build-id.
                                                    Module ld-linux-x86-64.so.2 with build-id db50353a26600bb848b9a5541b1506e0a24cb34b
                                                    Module liblz4.so.1 without build-id.
                                                    Module libzstd.so.1 without build-id.
                                                    Module liblzma.so.5 without build-id.
                                                    Module libgcrypt.so.20 without build-id.
                                                    Module libcap.so.2 without build-id.
                                                    Module libc.so.6 with build-id 2bb226bc600b443958c7566207d0d02f8345e6ea
                                                    Module libresolv.so.2 with build-id 88f3bb8423742b08f89ecabb2800b03d17d06e6c
                                                    Module libm.so.6 with build-id b8454b40db819599169f3a948939aed4b3fc7f82
                                                    Module libevent_core-2.1.so.7 without build-id.
                                                    Module libncursesw.so.6 without build-id.
                                                    Module libutempter.so.0 without build-id.
                                                    Module libsystemd.so.0 without build-id.
                                                    Module tmux without build-id.
                                                    Stack trace of thread 504232:
                                                    #0  0x00007fb1180a297d __strlen_avx2 (libc.so.6 + 0x15d97d)
                                                    #1  0x00007fb117fb277e __vfprintf_internal (libc.so.6 + 0x6d77e)
                                                    #2  0x00007fb117fc29b5 __vasprintf_internal (libc.so.6 + 0x7d9b5)
                                                    #3  0x00000000004910a4 xvasprintf (tmux + 0x910a4)
                                                    #4  0x000000000041ac60 cmdq_error (tmux + 0x1ac60)
                                                    #5  0x000000000041d4c2 cmd_select_layout_exec (tmux + 0x1d4c2)
                                                    #6  0x000000000041a63c cmdq_next (tmux + 0x1a63c)
                                                    #7  0x0000000000464a95 server_loop (tmux + 0x64a95)
                                                    #8  0x0000000000453002 proc_loop (tmux + 0x53002)
                                                    #9  0x00000000004651ec server_start (tmux + 0x651ec)
                                                    #10 0x000000000040b532 client_main (tmux + 0xb532)
                                                    #11 0x000000000040634e main (tmux + 0x634e)
                                                    #12 0x00007fb117f6e24e __libc_start_call_main (libc.so.6 + 0x2924e)
                                                    #13 0x00007fb117f6e309 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x29309)
                                                    #14 0x0000000000406705 _start (tmux + 0x6705)
                                                    ELF object binary architecture: AMD x86-64

The stack trace is not consistent between runs. I've seen at least 2 different ones.
I wanted to set a breakpoint on cmd_select_layout_exec, because it seemed like an interesting place to look (based on the traceback), but I had problems getting gdb to do that. I played a bit with detach-on-fork, follow-fork-mode and follow-exec-mode settings, but didn't get satisfactory result -- either things hung or never hit the breakpoint. And I'm that lazy that I don't want to manually traverse the fork()'s.
However, I found this suspicious sleep 1 in $prefix/share/tmux-plugins/continuum/scripts/continuum_restore.sh that I increased to sleep 2, and it seemed to fix the problem! However, after more testing, I cannot reproduce the original issue (server exited unexpectedly) anymore. Related, I tried removing the sleep and saw tmux become semi-broken -- it started fine but windows lacked names.

Hm, now I seem to have the issue again, and sleep 2 doesn't help (I even tested with sleep 5).

I think the problem is old "resurrect" data breaking newer code.
Starting point:
$ tmux
server exited unexpectedly

Now clean up and run again:
$ rm -rf ~/.local/share/tmux/resurrect/
$ tmux
(successfully running)

I think that ~/.local/share/tmux/resurrect/ isn't the default -- I've configured that myself. However, I confused myself some extra because I also had left-over ~/.tmux/resurrect from before that configuration change, and while debugging this issue I kept playing with the state in ~/.tmux/resurrect instead of my actual state data. Doh!
Based on the traceback, I'd say something has changed in how layouts are named/stored and tmux has bad error handling.

@twnaing: I think this can be closed.

Run into the same issue recently (on arch, with fish+tmux+ressurect+continuum) and removing ressurect data like @bjornfor mentioned here https://github.com/tmux-plugins/tmux-continuum/issues/110#issuecomment-1335060795 fixed this for me as well. Cheers bjornfor!

same error here.
rm -rf ~/.local/share/tmux/resurrect/ works

fixed for me

Removing old resurrect files was also the solution for me, but that included these:
rm -rf ~/.tmux/resurrect

Now auto restore works with these settings:
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-restore 'on'


chore: improve styles for collapsed Native Filter sidebar

SUMMARY
The task was to improve styles of Native Filter collapsed bar. Native filter sidebar styling and padding should be consistent with the Data panel in Explore.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before:

After:

This is sidebar in explore panel:

TEST PLAN
Verify manually. Go to config.py and set "DASHBOARD_NATIVE_FILTERS": True
Go to a dashboard and test Native Filter Bar when collapsed.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[x] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migrat@junlincc upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

cc @junlincc @rusackas @adam-stasiak

Late testing on master but ok :)

Late testing on master but ok :)


New batch of problems

Four new problems:

Plump moose
Compound interest
RNA translation
Logistic growth

Will flesh out RNA translation and Logistic growth is a later PR.