SSH traffic volume devastates HTTPS test scaling

BWMG operates by opening an SSH session to each instance to collect verbose data from apachebench which is operating in verbose mode "-v 3", to collect fine-grained timing and response status data to be aggregated by BWMG itself.
This verbose output includes a large number of lines which are not needed by BWMG for statistics generation, especially when attacking HTTPS URLs (due to additional SSL/TLS debug sent to stderr and stdout).  stderr is entirely discarded within bees.py anyway.
For an instance performing 2500 HTTP req/s, this is approximately 800KByte/s sent over SSH.  For instances performing 400-600 HTTPS req/s this is approximately 1.2 megabytes/s.
In a test with 100 instances, this adds up: 80 megabytes/s of raw data to support 250kreq/s of load testing, or 600 megabytes/s (5 gigabits/s) to support 250kreq/s of HTTPS testing.
Unfortunately, this has a few negative side-effects:

Instances with 1 CPU face increased CPU contention and context switches to send this data
Data outbound from AWS is billable, and this bandwidth usage (in certain use cases) is actually greater than the data used for the actual benchmarking
For testing with a high number of instances, this bandwidth requirement becomes too large for the python client to sanely collect, on the order of hundreds of megabytes/s of SSH payload data.

Some kind of instance-side filtering of stdout and stderr to only the necessary data would alleviate these scaling limitations, reduce cost, and likely increase the requests/s that a given instance can perform when not maintaining this housekeeping (especially single-vCPU instances)

I will be opening a PR shortly with a proposed solution for this issue.
Results (before -> after for [protocol] (req/s)):
800kbyte/s -> 145 kbyte/s for HTTP (3650 req/s)
1200kbyte/s -> 25 kbyte/s for HTTPS (600req/s)
Notice that the requests per second are appreciably higher than before due to lower CPU contention and context switching on the single-vCPU instance used (m3.medium).  HTTP performance to the same target 3ms from us-east-1 increased from 2500 HTTP req/s to 3650. HTTPS performance increased from 400-500 req/s up to 630 req/s.
This issue was much worse for HTTPS due to the SSL verbosity from apachebench.  This change represents a 98% reduction in output carried over SSH.

PR #195 opened:

stderr is discarded on the instance side inside of the benchmark_command shell command.  stderr is never consumed by BWMG so this data should be discarded
fgrep was used due to simple substring matching being sufficient
A list of substrings required for statistics assembly is added, joined by newlines, and used with -F.  This is to avoid needing to drop a file with list of patterns onto the AMI, at the "cost" of a larger benchmark_command.  If this leads to undesirable output on the client (as benchmark_command is printed to the user), the command that is printed could be split on | and truncated (or abbreciated at this point with ellipses .... to at least indicate to the user that more command is being hidden
Doing this filtering via fgrep is not as ideal compared to if apachebench provided output tailored to BWMG's usage, but it offers one benefit that multi-v/CPU instances will likely schedule fgrep (and ssh) on another core, allowing ab to operate on one CPU less-interrupted.  This is hypothetical/unproven.
This only minimally helps with context switches on the instance side when running on single-vCPU instances, as fgrep will contend for the same CPU.  However, the work being performed is far less than what SSH would have been doing resource-wise.  As mentioned in the previous comment, there is a definite benefit to apachebench performance with this patch.

Closing - resolved by PR #195  merge.


Added option to specify probe clock frequency

This adds an optional --speed <frequency> option to set the probe clock frequency.
I had issues flashing my Robotdyn STM32F103C8 Black Pill with my J-Link EDU Mini using any probe-rs related method (probe-run, cargo-flash, cargo-embed). When I lower the probe's clock frequency it works, but probe-run did not have the option to set the clock speed. With this PR it does!

Im going to need this for the samd chips as well

@japaric Thank you for your work on embedded Rust!

Hey @eboskma Can you try cargo flash from git? I think it has the fix for your speed issue https://github.com/probe-rs/probe-rs/pull/450
cargo install --git https://github.com/probe-rs/cargo-flash.git and if so would soon make its way into probe-run as well
Please let me know, were trying to track down anyone using reduced speed and get fixes in

@jacobrosenthal That works great, thanks for the heads up!


feat: ntfy push support

Description
closes #1622
Type of change

New feature (non-breaking change which adds functionality)

Checklist

[x]  My code follows the style guidelines of this project
[x]  I ran ESLint and other linters for modified files
[x]  I have performed a self-review of my own code and tested it
[x]  I have commented my code, particularly in hard-to-understand areas
(including JSDoc for methods)
[x]  My changes generate no new warnings
[ ]  My code needed automated testing. I have added them (this is optional task)

Thanks for the heads-up, Adam 😆
Didn't mean to directly submit this PR as "ready for review" earlier today ^^


Make Version::parse const

It would be nice to have the version::parse function as a const function, so that we can parse things like the crate's version into a const variable (I currently get it from clap_version!(), but I'd like that to be useable as a Version variable). I believe this requires rust to stabilize panicing and unwraping in const fns, but I was just wondering if this is possible sometime in the future.

I am not opposed to this, but I am going to close because I don't feel it's necessarily useful to track in an issue that's not currently actionable. I would be prepared to consider a PR whenever this turns out to be possible to implement.

Hi @dtolnay, now in 2024 is yet possible or are we still missing something a feature in Rust for that ?
I looked around and I found the konst crate that has capabilities to do some parsing in const context. When I took a look inside the source code in order to evaluate if I can take the relevant part and make a PR here, I hit a complexity wall and do not understand what's going on to be honest ...
Any idea if this is actionable now?


fix: className Changed

Related #193
Description

Changed className

Current behavior (updates)

Nothing.

New behavior

Nothing.

Is this a breaking change (Yes/No):
No.
Additional Information

AvatarName and AvatarIcon are untouched.

AvatarName, AvatarBadge and AvatarIcon are untouched.

Done.


:zap: Feat: Optimize state manager peformance and caching

Description
Concise description of proposed changes
Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

#1143  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @roninjin10 and the rest of your teammates on  Graphite


Fix: A Billion Lint Errors in dev 😭😭

Have you read the contributing guidelines ?
What is the purpose of your pull request?

[x] Bug fix
[ ] New feature

Proposed changes
⛑ An attempt at fixing lint errors that have been causing failed tests
🚀 Partly fixes issue #212
Warning
Please read these points carefully and answer honestly with an X
into all the boxes. Example : [X]
Before submitting a pull request make sure you have:

[x] Read the guidelines for contributing.
[ ] Wrote some tests.
[x] Respected the linting guidelines.

@alvyynm, the Lint tests finally passed 🙌🏾

I went through almost 300 files trying to fix about 950 Lint errors 😭
Please check if all routes are functional 😁

All that's left is updating the PR template

Despite the billion fixes the deployment still fails 🥲

Hi @sonylomo, sorry for the late reply. Going over this now. Great work btw.

Despite the billion fixes the deployment still fails 🥲

@JimmyTron Could I get a screenshot of the failed deployment logs?

Despite the billion fixes the deployment still fails 🥲

@JimmyTron Could I get a screenshot of the failed Vercel deployment logs?

[15:56:03.299] Running build in Washington, D.C., USA (East) – iad1
[15:56:03.487] Cloning github.com/spaceyatech-org/SYT-Web-Redesign (Branch: Dev, Commit: 8474c2d)
[15:56:05.317] Previous build caches not available
[15:56:06.640] Cloning completed: 3.150s
[15:56:07.360] Running "vercel build"
[15:56:07.804] Vercel CLI 34.3.0
[15:56:08.563] Detected pnpm-lock.yaml version 9 generated by pnpm 9
[15:56:08.581] Installing dependencies...
[15:56:09.326]  ERR_PNPM_OUTDATED_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with package.json
[15:56:09.326]
[15:56:09.327] Note that in CI environments this setting is true by default. If you still need to run install in such cases, use "pnpm install --no-frozen-lockfile"
[15:56:09.327]
[15:56:09.327]     Failure reason:
[15:56:09.327]     specifiers in the lockfile ({"@emailjs/browser":"^3.11.0","@headlessui/react":"^1.7.15","@hookstate/core":"^4.0.1","@tanstack/react-query":"^5.22.2","@tanstack/react-query-devtools":"^5.24.0","@tanstack/react-table":"^8.17.3","axios":"^1.6.1","class-variance-authority":"^0.7.0","clsx":"^2.1.1","date-fns":"^2.30.0","html-react-parser":"^5.0.6","lucide-react":"^0.395.0","million":"^3.0.2","prop-types":"^15.8.1","react":"^18.2.0","react-dom":"^18.2.0","react-fast-marquee":"^1.6.2","react-helmet-async":"^2.0.5","react-hook-form":"^7.48.2","react-hot-toast":"^2.4.1","react-icons":"^5.2.1","react-lazy-load-image-component":"^1.6.0","react-photo-album":"^2.3.0","react-router-dom":"^6.11.2","react-share":"^5.1.0","react-simple-wysiwyg":"^2.2.5","tailwind-merge":"^2.3.0","tailwind-scrollbar-hide":"^1.1.7","tailwindcss-animate":"^1.0.7","yet-another-react-lightbox":"^3.15.6","@playwright/test":"^1.44.1","@types/node":"^20.14.1","@types/react":"^18.0.28","@types/react-dom":"^18.0.11","@vitejs/plugin-react":"^4.0.0","autoprefixer":"^10.4.19","concurrently":"^8.2.2","eslint":"^8.43.0","eslint-config-airbnb":"^19.0.4","eslint-config-prettier":"^9.1.0","eslint-plugin-import":"^2.27.5","eslint-plugin-jsx-a11y":"^6.7.1","eslint-plugin-prettier":"^5.1.3","eslint-plugin-react":"^7.32.2","eslint-plugin-react-hooks":"^4.6.0","husky":"^8.0.0","knip":"^4.6.0","postcss":"^8.4.38","prettier":"^3.3.2","tailwindcss":"^3.4.3","typescript":"^5.4.5","vite":"^5.0.0","vitest":"^1.6.0"}) don't match specs in package.json ({"@playwright/test":"^1.44.1","@types/node":"^20.14.1","@types/react":"^18.0.28","@types/react-dom":"^18.0.11","@vitejs/plugin-react":"^4.0.0","autoprefixer":"^10.4.19","concurrently":"^8.2.2","eslint":"^8.43.0","eslint-config-airbnb":"^19.0.4","eslint-config-prettier":"^9.1.0","eslint-plugin-import":"^2.27.5","eslint-plugin-jsx-a11y":"^6.7.1","eslint-plugin-prettier":"^5.1.3","eslint-plugin-react":"^7.32.2","eslint-plugin-react-hooks":"^4.6.0","husky":"^8.0.0","knip":"^4.6.0","postcss":"^8.4.38","prettier":"^3.3.2","tailwindcss":"^3.4.3","typescript":"^5.4.5","vite":"^5.0.0","vitest":"^1.6.0","@emailjs/browser":"^3.11.0","@headlessui/react":"^2.1.2","@hookstate/core":"^4.0.1","@tanstack/react-query":"^5.22.2","@tanstack/react-query-devtools":"^5.24.0","@tanstack/react-table":"^8.17.3","axios":"^1.6.1","class-variance-authority":"^0.7.0","clsx":"^2.1.1","date-fns":"^2.30.0","html-react-parser":"^5.0.6","lucide-react":"^0.395.0","million":"^3.0.2","prop-types":"^15.8.1","react":"^18.2.0","react-dom":"^18.2.0","react-fast-marquee":"^1.6.2","react-helmet-async":"^2.0.5","react-hook-form":"^7.48.2","react-hot-toast":"^2.4.1","react-icons":"^5.2.1","react-lazy-load-image-component":"^1.6.0","react-photo-album":"^2.3.0","react-router-dom":"^6.11.2","react-share":"^5.1.0","react-simple-wysiwyg":"^2.2.5","recharts":"^2.12.7","tailwind-merge":"^2.3.0","tailwind-scrollbar-hide":"^1.1.7","tailwindcss-animate":"^1.0.7","yet-another-react-lightbox":"^3.15.6"})
[15:56:09.343] Error: Command "pnpm install" exited with 1
[15:56:09.568]

Despite the billion fixes the deployment still fails 🥲

@JimmyTron Could I get a screenshot of the failed Vercel deployment logs?

[15:56:03.299] Running build in Washington, D.C., USA (East) – iad1
[15:56:03.487] Cloning github.com/spaceyatech-org/SYT-Web-Redesign (Branch: Dev, Commit: 8474c2d)
[15:56:05.317] Previous build caches not available
[15:56:06.640] Cloning completed: 3.150s
[15:56:07.360] Running "vercel build"
[15:56:07.804] Vercel CLI 34.3.0
[15:56:08.563] Detected pnpm-lock.yaml version 9 generated by pnpm 9
[15:56:08.581] Installing dependencies...
[15:56:09.326]  ERR_PNPM_OUTDATED_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with package.json
[15:56:09.326]
[15:56:09.327] Note that in CI environments this setting is true by default. If you still need to run install in such cases, use "pnpm install --no-frozen-lockfile"
[15:56:09.327]
[15:56:09.327]     Failure reason:
[15:56:09.327]     specifiers in the lockfile ({"@emailjs/browser":"^3.11.0","@headlessui/react":"^1.7.15","@hookstate/core":"^4.0.1","@tanstack/react-query":"^5.22.2","@tanstack/react-query-devtools":"^5.24.0","@tanstack/react-table":"^8.17.3","axios":"^1.6.1","class-variance-authority":"^0.7.0","clsx":"^2.1.1","date-fns":"^2.30.0","html-react-parser":"^5.0.6","lucide-react":"^0.395.0","million":"^3.0.2","prop-types":"^15.8.1","react":"^18.2.0","react-dom":"^18.2.0","react-fast-marquee":"^1.6.2","react-helmet-async":"^2.0.5","react-hook-form":"^7.48.2","react-hot-toast":"^2.4.1","react-icons":"^5.2.1","react-lazy-load-image-component":"^1.6.0","react-photo-album":"^2.3.0","react-router-dom":"^6.11.2","react-share":"^5.1.0","react-simple-wysiwyg":"^2.2.5","tailwind-merge":"^2.3.0","tailwind-scrollbar-hide":"^1.1.7","tailwindcss-animate":"^1.0.7","yet-another-react-lightbox":"^3.15.6","@playwright/test":"^1.44.1","@types/node":"^20.14.1","@types/react":"^18.0.28","@types/react-dom":"^18.0.11","@vitejs/plugin-react":"^4.0.0","autoprefixer":"^10.4.19","concurrently":"^8.2.2","eslint":"^8.43.0","eslint-config-airbnb":"^19.0.4","eslint-config-prettier":"^9.1.0","eslint-plugin-import":"^2.27.5","eslint-plugin-jsx-a11y":"^6.7.1","eslint-plugin-prettier":"^5.1.3","eslint-plugin-react":"^7.32.2","eslint-plugin-react-hooks":"^4.6.0","husky":"^8.0.0","knip":"^4.6.0","postcss":"^8.4.38","prettier":"^3.3.2","tailwindcss":"^3.4.3","typescript":"^5.4.5","vite":"^5.0.0","vitest":"^1.6.0"}) don't match specs in package.json ({"@playwright/test":"^1.44.1","@types/node":"^20.14.1","@types/react":"^18.0.28","@types/react-dom":"^18.0.11","@vitejs/plugin-react":"^4.0.0","autoprefixer":"^10.4.19","concurrently":"^8.2.2","eslint":"^8.43.0","eslint-config-airbnb":"^19.0.4","eslint-config-prettier":"^9.1.0","eslint-plugin-import":"^2.27.5","eslint-plugin-jsx-a11y":"^6.7.1","eslint-plugin-prettier":"^5.1.3","eslint-plugin-react":"^7.32.2","eslint-plugin-react-hooks":"^4.6.0","husky":"^8.0.0","knip":"^4.6.0","postcss":"^8.4.38","prettier":"^3.3.2","tailwindcss":"^3.4.3","typescript":"^5.4.5","vite":"^5.0.0","vitest":"^1.6.0","@emailjs/browser":"^3.11.0","@headlessui/react":"^2.1.2","@hookstate/core":"^4.0.1","@tanstack/react-query":"^5.22.2","@tanstack/react-query-devtools":"^5.24.0","@tanstack/react-table":"^8.17.3","axios":"^1.6.1","class-variance-authority":"^0.7.0","clsx":"^2.1.1","date-fns":"^2.30.0","html-react-parser":"^5.0.6","lucide-react":"^0.395.0","million":"^3.0.2","prop-types":"^15.8.1","react":"^18.2.0","react-dom":"^18.2.0","react-fast-marquee":"^1.6.2","react-helmet-async":"^2.0.5","react-hook-form":"^7.48.2","react-hot-toast":"^2.4.1","react-icons":"^5.2.1","react-lazy-load-image-component":"^1.6.0","react-photo-album":"^2.3.0","react-router-dom":"^6.11.2","react-share":"^5.1.0","react-simple-wysiwyg":"^2.2.5","recharts":"^2.12.7","tailwind-merge":"^2.3.0","tailwind-scrollbar-hide":"^1.1.7","tailwindcss-animate":"^1.0.7","yet-another-react-lightbox":"^3.15.6"})
[15:56:09.343] Error: Command "pnpm install" exited with 1
[15:56:09.568]

I also had an issue in deployment preview I used this logs to fix them turns out the issue is because there are discrepancies between the pnpm-lock.yaml file and the package.json. To fix it make sure the  package.json and pnpm-lock.yaml are both synchronized by punning pnpm install.


scotch: 7.0.4 -> 7.0.5

Description of changes
Changes notes:

This revision is essentially a bugfix release, but it also provides new features:
The installation of Scotch on Windows-like environments has been improved.
Native Windows threads are now supported.
The CMake compilation chain is now fully mature.
New routines have been added, to run the upcoming "ScotchPy" Python interface for Scotch and PT-Scotch.

While here, separate outputs, as this package has 31 executables which look like tests. It might also help @matthewcroughan who has issues with include/metis.h overriding the one from metis → putting it in in another output  might help. I'll report this upstream though.
And also, shared libs.
Things done

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/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 337565 run on aarch64-darwin 1

28 packages built:

bonmin
casadi
crocoddyl
ipopt
openturns
pinocchio
python311Packages.aerosandbox
python311Packages.aerosandbox.dist
python311Packages.casadi
python311Packages.crocoddyl
python311Packages.example-robot-data
python311Packages.fenics
python311Packages.fenics.dist
python311Packages.neuralfoil
python311Packages.neuralfoil.dist
python311Packages.openturns
python311Packages.pinocchio
python312Packages.aerosandbox
python312Packages.aerosandbox.dist
python312Packages.casadi
python312Packages.crocoddyl
python312Packages.example-robot-data
python312Packages.fenics
python312Packages.fenics.dist
python312Packages.neuralfoil
python312Packages.neuralfoil.dist
python312Packages.openturns
python312Packages.pinocchio

Thanks for the review @bzizou !
It is OK for me too.
@MatthewCroughan : Is your issue with the CMake packaging of this project fixed ?


All Ajax POST requests fail with 2.x releases

When using the 2.x releases (2.0.0-beta to 2.0.0-rc8) AJAX post requests stay in "pending" status indefinitely.
Minimal case to reproduce:
<html>
  <body>
    <button id="post">Click to test post</button>
    <script src="./test.js"></script>
  </body>
</html>

document.getElementById("post").onclick = () => { fetch("./anything", {method: "post"}); }

wright index.html --debug 1

Results

Sorry for the bad response time.
Great repro case! Fixed in 2.0.1


Minimal example with extension support

I am trying to set up a minimal code editor with support for extensions, themes, and LSP. Despite being aware of #444, I’m still struggling to understand how to load a local VSCode extension from a vsix file and get it functioning.
I would greatly appreciate any help to get me started in the right direction :)
Here is a simplified example of what I've already come up with. I am trying to load the Swift extension and get LSP working. Especially with webpack.
import "vscode/localExtensionHost";

import { AfterViewInit, Component, ElementRef, ViewChild } from "@angular/core";
import getExtensionServiceOverride, { WorkerConfig } from "@codingame/monaco-vscode-extensions-service-override";
import getLanguagesServiceOverride from "@codingame/monaco-vscode-languages-service-override";
import getModelServiceOverride from "@codingame/monaco-vscode-model-service-override";
import getTextmateServiceOverride from "@codingame/monaco-vscode-textmate-service-override";
import getThemeServiceOverride from "@codingame/monaco-vscode-theme-service-override";
import { editor } from "monaco-editor";
import { extensions } from "vscode";
import { initialize as initializeMonacoService} from "vscode/services";

export type WorkerLoader = () => Worker;

export const workerConfig: WorkerConfig = {
    url: new URL("vscode/workers/extensionHost.worker", import.meta.url).toString(),
    options: { type: "module" }
};
const value = `func test() -> String {
    print("Hello World")
    return "Test"
}`;

const workerLoaders: Partial<Record<string, WorkerLoader>> = {
    editorWorkerService: () => new Worker(new URL("monaco-editor/esm/vs/editor/editor.worker.js", import.meta.url), { type: "module" }),
    textMateWorker: () => new Worker(new URL("@codingame/monaco-vscode-textmate-service-override/worker", import.meta.url), { type: "module" })
};

window.MonacoEnvironment = {
    getWorker: function (moduleId, label): Worker {
        const workerFactory = workerLoaders[label];
        if (workerFactory != null) {
            return workerFactory();
        }
        throw new Error(`Unimplemented worker ${label} (${moduleId})`);
    }
};

await initializeMonacoService({
    ...getModelServiceOverride(),
    ...getExtensionServiceOverride(workerConfig),
    ...getThemeServiceOverride(),
    ...getLanguagesServiceOverride(),
    ...getTextmateServiceOverride()
});

// Not sure about this one. Doesn't work either
const extension = extensions.getExtension("sswg.swift-lang");
extension?.activate();

editor.create(this.editorRef?.nativeElement, {
    value: value,
    language: "swift"
});

There is no web-compatible swift extension, so with the vsix loader, you may manage to get the declarative parts working (like syntax highlighting or snippets) but not the LSP part or anything requiring extension code to work.
A server will be required to run the LSP server, and there are multiple ways to connect to it from the client:

Create your own channel to forward LSP messages from your client to your server, and synchronize files by hands
Use the VSCode server, then extract the vsix file somewhere on the server, and use the registerRemoteExtension function from vscode/extensions

Thank you very much for your response. I've now got the vscode-server up and running and installed the swift vsix extension via ./bin/code-server --install-extension <path>. It is successfully installed and shows up under ./bin/code-server --list-extensions. But it doesn't quite work yet with my client... I have enabled scanRemoteExtensions, but the extension does not show up in vscode.extensions.all.
You also mentioned the registerRemoteExtension method, which takes a directory path as argument. What path should I provide here?
I've started the server with the following argumens: ./bin/code-server --port 8080 --without-connection-token --accept-server-license-terms --host <IP_ADDRESS>, which gives me a successfull response, telling me that the extensions host is running
*
* Visual Studio Code Server
*
* By using the software, you agree to
* the Visual Studio Code Server License Terms (https://aka.ms/vscode-server-license) and
* the Microsoft Privacy Statement (https://privacy.microsoft.com/en-US/privacystatement).
*
Server bound to <IP_ADDRESS>:8080 (IPv4)
Extension host agent listening on 8080

[22:47:21]

[22:47:21] Extension host agent started.

Now on my client, I don't see the extension. This is my updated code:
const value = `func test() -> String {
    print("Hello World")
    return "Test"
}`;
const workerLoaders: Partial<Record<string, WorkerLoader>> = {
    editorWorkerService: () => new Worker(new URL("monaco-editor/esm/vs/editor/editor.worker.js", import.meta.url), { type: "module" }),
    textMateWorker: () => new Worker(new URL("@codingame/monaco-vscode-textmate-service-override/worker", import.meta.url), { type: "module" })
};

window.MonacoEnvironment = {
    getWorker: function (moduleId, label): Worker {
        const workerFactory = workerLoaders[label];
        if (workerFactory != null) {
            return workerFactory();
        }
        throw new Error(`Unimplemented worker ${label} (${moduleId})`);
    }
};

const fileSystemProvider = new RegisteredFileSystemProvider(false);
fileSystemProvider.registerFile(new RegisteredMemoryFile(monaco.Uri.file("/main.swift"), value));

registerFileSystemOverlay(1, fileSystemProvider);
await initializeMonacoService({
    ...getRemoteAgentServiceOverride({
        scanRemoteExtensions: true
    }),
    ...getModelServiceOverride(),
    ...getExtensionServiceOverride(),
    ...getThemeServiceOverride(),
    ...getLanguagesServiceOverride(),
    ...getTextmateServiceOverride(),
    ...getViewsServiceOverride(),
    ...getFileServiceOverride(),
    ...getSearchServiceOverride()
}, undefined, {
    remoteAuthority: "localhost:8080"
});

console.log("extensions", vscode.extensions.all);

attachPart(Parts.EDITOR_PART, this.editorRef.nativeElement!);

vscode.workspace.openTextDocument("/main.swift").then((doc) => {
    vscode.window.showTextDocument(doc);
});

But still vscode.extensions.all is empty.
Am I missing something?

I’m not certain if this is related to the issue, but I’m also encountering the following console errors:
CodeExpectedError: ENOPRO: No file system provider found for resource 'inmemory://model/'

Error: Not implemented
    at StandaloneUriLabelService.registerFormatter (standaloneServices.js:797:17)

CodeExpectedError: ENOPRO: No file system provider found for resource 'inmemory://model/'

If they're not related, I will address them later on. For now I would just like to get the extensions working.

Update: I think I got the extension working, by using registerRemoteExtension with the directory of the installed extension, usually installed in ~/.vscode-server/extensions/
const extension = await registerRemoteExtension("~/.vscode-server/extensions/sswg.swift-lang-1.10.4");

But there is no syntax highlighting or code completion enabled in the editor. Is there something I need to enable?

But still vscode.extensions.all is empty.

This api doesn't allow to see extension running on another extension host, so calling it from the localExtensionHost will not allow you to see the extension running in the server extension host
You can try to use the extension gallery service override to extension statuses

But there is no syntax highlighting or code completion enabled in the editor. Is there something I need to enable?

Is there anything working then?
If you provide a reproduction repo, I may be able to help

I’m not certain if this is related to the issue, but I’m also encountering the following console errors:
CodeExpectedError: ENOPRO: No file system provider found for resource 'inmemory://model/'

Hum no idea :thinking:

Error: Not implemented
    at StandaloneUriLabelService.registerFormatter (standaloneServices.js:797:17)

fixed in https://github.com/CodinGame/monaco-vscode-api/pull/467

Thank you very much for your assistance so far. I’m gradually gaining a deeper understanding of how everything works here.

Is there anything working then?

Not really, but
const extension = await registerRemoteExtension("~/.vscode-server/extensions/sswg.swift-lang-1.10.4");

extension.isEnabled() returns true and I see this warning log in the console
 WARN [sswg.swift-lang]: View container 'explorer' does not exist and all views registered to it will be added to 'Explorer'.

So it seems like the extension is doing something.

If you provide a reproduction repo, I may be able to help

I will take care of that today and get back to you with a response, thanks

I’ve hacked together a brief demo which you can find here: https://github.com/julian-baumann/monaco-vscode-demo
For detailed setup instructions, please refer to the README. All the essential code is located in a single file: ./src/app/app.component.ts

Ok, so,your problems:

you're importing @codingame/monaco-vscode-configuration-service-override but not using the getServiceOverride method, you're not supposed to import a service override without using it, and the configuration service override is pretty much required as it's the one managing the workspace folders as well
the swift-lang extensions registers a lot of stuff, and requires the corresponding service overrides to be registered to suppress the errors:

@codingame/monaco-vscode-extension-gallery-service-override
@codingame/monaco-vscode-explorer-service-override
@codingame/monaco-vscode-debug-service-override
@codingame/monaco-vscode-storage-service-override
@codingame/monaco-vscode-terminal-service-override
@codingame/monaco-vscode-chat-service-override
@codingame/monaco-vscode-scm-service-override

the swift-lang extension is not responsible for the syntax highlighting, but the default swift extension instead, import @codingame/monaco-vscode-swift-default-extension
The exported services are the one designed for the web version, and running them in electron doesn't work well. That's the reason for the @codingame/monaco-vscode-swift-default-extension to be not working: in electron, the web extension management server is unable to register any extension manager server, so there is no place for the extension to run

Thank you, I've tried importing the required overrides, but as you mentioned, it doesn't work in electron. Do you happen to know any workaround or solution on how to get it running in electron?
In the meanwhile, I've also create a new vite+React project with a the same code as in the angular application which can be found here: https://github.com/julian-baumann/monaco-vscode-demo/tree/vite
This one also runs in the browser, and we see a working syntax highlighting! But still no code suggestions/completions or errors. In the console we see the following log message:
[Extension Host] 00:21:17: SourceKit-LSP setup

So it seems like it is trying to start the LSP service. But no indication whether it started successfully or not...
Any ideas?

Update: I got LSP working!
I had to load the project via the code-server (vscode-remote://localhost:8080/...), rather than using the RegisteredFileSystemProvider.
The only thing not working right now is loading the @codingame/monaco-vscode-swift-default-extension extension via electron.

I'm not aware of any workaround, we need to allow using the electron services in the lib

Seems like it's working if we disable nodeIntegration and use a preload.js for all node related stuff as intended by electron.

@julian-baumann could you please push working changes to your repo?

I've just pushed a working version on main. But I will probably not continue with this project, since it was only a small demo to test everything. But the current angular project on the main branch should work fine both in the browser and in electorn. Please make sure to update the projectPath field in ./src/app/app.component.ts to a valid swift project.

I understand^ thanks! I just faced with same issue to make everything work together

I may not be able to assist you with any further problems, but if you encounter any issues specifically with my test project, please don’t hesitate to contact me.

I'm trying to do something very similar here: https://github.com/brianjenkins94/monaco-vscode-api-esbuild
but can't quite make sense of some of these console errors:

@CGNonofr was hoping you could take a look maybe? ^ 🙏

I'm handling that already: https://github.com/brianjenkins94/monaco-vscode-api-esbuild/blob/main/tsup.config.ts#L38

No idea why it tries to load extensionHostWorker.js from https://brianjenkins94.github.io/monaco-vscode-api-esbuild/vscode/src/vs/workbench/api/worker/extensionHostWorker.js, there is very probably a configuration issue
I didn't really understand your recursive update of the importMetaUrlPlugin

Ah, looks to be related to all that fakeWorker stuff.
Is it possible to load that from a CDN or something? I don't anticipate needing to change any of that code but I know Workers have strict same-origin restrictions.

Unfortunately, very stuck on:
simpleWorker.js: Could not create web worker(s). Falling back to loading web worker code in main thread, which might cause UI freezes. Please see https://github.com/microsoft/monaco-editor#faq

Would be willing to pay to have this figured out.

Sorry, I'm really not familiar enough with esbuild
It's maybe a good opportunity for you to get into the code, since it's a quite complex project to use anyway, better understand it as much as possible

The piece I'm stuck on is why the services workers aren't working. Everything else seems okay.

You can have a look at the devtools, which file it's trying to load in the worker, and add breakpoints in the code where the error occurs. That's what I would be doing if I had to investigate it

Is there anywhere else I can ask to get more informational error messages or debug info?
Breakpoints and stepping aren't yielding anything helpful, just generic errors.

I don't think so
But you are the one creating the worker, you can have a look at the worker url to see if there is anything wrong

A new error message! How exciting!
Unimplemented worker editorWorkerService (workerMain.js)

Seems there may have been a name change and now it's called TextEditorWorker?

Yes, in the last version, have a look at https://github.com/CodinGame/monaco-vscode-api/releases/tag/v9.0.0

Did you update VSCode and rebuild the library, because the node_modules/vscode of the demo just link to the root directory

Yes, I even did npm cache clean --force and confirmed that npm list vscode --depth=0 yields vscode@npm<EMAIL_ADDRESS>

I'm not sure how you manage to make npm list vscode return vscode@npm<EMAIL_ADDRESS>in the demo since it's a local dependency 🤔

Btw, you're mixing up the worker name with the service name. I didn't properly pay attention

Actually, mine looks to be throwing all the same warnings that https://monaco-vscode-api.netlify.app/ is throwing.
Mine just only knows about plain text?

Oh, indeed, I've desactivated the console warnings for some reason and I didn't see it, it seems broken, will have a look

https://github.com/CodinGame/monaco-vscode-api/pull/499

Awesome, it's working!
Last step is to load my hello-world extension but using registerFileUrl looks to yield CSP errors:
const { registerFileUrl, getApi } = registerExtension({
	"name": "helloworld-web-sample",
	"displayName": "helloworld-web-sample",
	"description": "HelloWorld example for VS Code in the browser",
	"version": "0.0.1",
	"publisher": "vscode-samples",
	"private": true,
	"license": "MIT",
	"repository": "https://github.com/microsoft/vscode-extension-samples/helloworld-web-sample",
	"engines": {
		"vscode": "^1.84.0"
	},
	"categories": [
		"Other"
	],
	"activationEvents": [
		"onLanguage:plaintext"
	],
	"browser": "./extension.js",
	...
}, ExtensionHostKind.LocalWebWorker);

registerFileUrl('/package.json', new URL('./extensions/hello-world/package.json', import.meta.url).toString())

extensionHost.worker-3a9df9.js:73407 Refused to connect to 'extension-file://vscode-samples.helloworld-web-sample/extension.js' because it violates the following Content Security Policy directive: "connect-src 'self'

You seems to be never registering the extension.js file?

No, issue is not that, I am also having same issue loading COBOL LSP. I dont need vscode server and I dont need workspace, workbench, all kinds of stuff because main intent is the single file editor.
import("src/editor/extensions/cobol-language-support-2.2.0.vsix"),

is successfully ran  but
Content-Security-Policy: The page’s settings blocked the loading of a resource (connect-src) at data:application/javascript;base64,InVzZ… because it violates the following directive: “connect-src 'self' https: wss: http://localhost:* http://<IP_ADDRESS>:* ws://localhost:* ws://<IP_ADDRESS>:*” [webWorkerExtensionHostIframe.esm.html](http://localhost:5173/node_modules/@codingame/monaco-vscode-extensions-service-override/assets/webWorkerExtensionHostIframe.esm.html?vscode-coi=3&vscodeWebWorkerExtHostId=be4a2c52-e647-4ac9-86c2-b5b359e98d33)
Activating extension 'BroadcomMFD.cobol-language-support' failed: NetworkError when attempting to fetch resource..

browser does not let me load that vsix file.

I dont need vscode server and I dont need workspace, workbench, all kinds of stuff because main intent is the single file editor.

That's a bold assumption
Your issue if cause by the worker extension host being strict on CSP, and your bundler transform assets into data: urls that are not allowed. You can try forcing it to emit asset to the disk, I'll have a lookif it's possible to allow it

Mhm, deleted
		<meta http-equiv="Content-Security-Policy" content="
			default-src 'none';
			child-src 'self' data: blob:;
			script-src 'self' 'unsafe-eval' 'sha256-fCnZ3iXydTZHO961jO3ioYDdWSfm8PZg/rI6zFX/SE0=' https: http://localhost:* blob:;
			connect-src 'self' https: wss: http://localhost:* http://<IP_ADDRESS>:* ws://localhost:* ws://<IP_ADDRESS>:*;"/>

from worker myself, and even then it is not working that well. i guess i am going for workspace & vs server lol

I've tried you extension in vscode.dev, and there are the same issues (at least the smart-tab command missing) so the extension is not so web-compatible after all


Docker swarm agent deployment leads to drop in all metrics

Hi. Love this project! Well done! I've been looking for something like this to replace Netdata.
I tried it out on a single node, and all went well and could see that metrics roughly matched what I was seeing in HTOP and Swarmpit.
Then added a node to the docker swarm, and went through the service addition and adding the docker-compose.yml section to my original docker-compose, adding deployment mode: global to the agent like this:
version: '3.3'
services:
  beszel:
    image: henrygd/beszel:latest
    ports:
     - 8090:8090
    volumes:
     - /mnt/data/beszel_data:/beszel_data
    networks:
     - default
    logging:
      driver: json-file
    deploy:
      placement:
        constraints:
         - node.hostname==nano

  beszel-agent:
    image: henrygd/beszel-agent:latest
    environment:
      FILESYSTEM: /dev/nvme0n1p1
      KEY: ssh-ed25519 *KEY OBSCURED FOR SECURITY*
      PORT: '45876'
    ports:
     - 45876:45876
    volumes:
     - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
     - default
    logging:
      driver: json-file
    deploy:
      mode: global

networks:
  default:
    driver: overlay

This is a snapshot of the docker memory usage… you can see that after I added the other agent, the Minecraft server that's still running on that machine and using about 7GB RAM, drops down to 0.

What's going on here?
Should there be a different SSH key for each node?
Also, I was unable to get the agents to work at all without adding this:
    ports:
     - 45876:45876

The agents all use the same public key so that shouldn't be the problem.
Are the nodes red or green?
From the screenshot it looks like they're connected and returning the container names with all values as zero. Is that right? And you have only one agent running per system?
What about other system metrics outside of docker?
I'm definitely not an expert on swarm, but it would be nice to figure this out because it does seem like a convenient way to deploy the agents.

Okay, figured out a couple of things…
The fact that each of the nodes were on the same port (and replicated),  I think  it may have been grabbing whichever node responded first. That leads to weird things like one node showing metrics for docker containers running on a different machine.
Wouldn't it be simpler for the agents to connect back to the hub? Either by API, or with a special SSH port (like the agents currently have)?
The workaround I have for the moment is to not use global deploy mode, and specify the same service block individually for each node, then assign a different SSH port for each node. e.g.:
  beszel-agent-nano:
    image: henrygd/beszel-agent:latest
    environment:
      FILESYSTEM: /dev/nvme0n1p1
      KEY: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPaeg+GJnJByGCq/3H5V0n/Rw/DAkpTWAV2VX9nj1e9O
      PORT: '45876'
    ports:
     - 45876:45876
# ...
      placement:
        constraints:
         - node.hostname==nano

  beszel-agent-pico:
    image: henrygd/beszel-agent:latest
    environment:
      FILESYSTEM: /dev/mmcblk2p1
      KEY: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPaeg+GJnJByGCq/3H5V0n/Rw/DAkpTWAV2VX9nj1e9O
      PORT: '45877'
    ports:
     - 45877:45877
# ...
      placement:
        constraints:
         - node.hostname==pico

The only problem with this approach is it would soon become unwieldy for all the machines I want to monitor.
Each agent being able to "phone home" would seem like a better approach.

Regarding monitoring outside of beszel, both htop and the Swarmpit dashboard show the correct memory, cpu, disk, etc. for each node.

So, I guess this isn't really a bug, but a limitation caused by using Docker Swarm.
Will close this issue, since it is possible to work around it.

@suranyami
I am running the same setup as you: Docker Swarm, Beszel Agent with global deployment, Swarmpit, etc. I don't have the same issue you have with the agents, so I'm wondering if you set it up correctly.

I noticed that you didn't use the host port for the agents
I'm wondering how you added the nodes in Beszel. Did you add them by using host names, IP addresses, ...?

What I think happened in your case, is that you were accessing the nodes via the swarm's ingress network, which has an internal load-balancer, which is probably why you were being routed around. You should add the nodes by their static IP address in Beszel.


Enhanced UI of the hero section of the landing page

Related Issue
Fixes:  #3759
Description
There were alot of things to be improved in the hero section of the landing page. I made all the necessary improvements.
I fixed the UI of the cookies popup.
I fixed the UI of the Visitors count box.
I fixed the UI of the play button position.
I centered all the texts.

Type of PR

[ ] Bug fix
[ ] Feature enhancement

Screenshots
Before :

After :

Checklist:

[ ] I have made this change from my own.
[ ] I have taken help from some online resources.
[ ] My code follows the style guidelines of this project.
[ ] I have performed a self-review of my own code.
[ ] My changes generate no new warnings.
[ ] I have tested the changes thoroughly before submitting this pull request.
[ ] I have provided relevant issue numbers and screenshots after making the changes.

chk the dark mode too . improve UI there too .

https://github.com/user-attachments/assets/055e17fc-f76d-4b49-80cc-0dc77d7f5ece


My nami displays -5.00000 ada and cant see my assets

Talk to Cardano Support on the Live support page so that your issue can be looked into.

I had this same exact issue. Finally sorted it out in minutes after i wrote to their instant Support team. You can write to them with the link below. Goodluck mate
https://forms.gle/vzc8taCsAd81jJW29

Same issue here after withdrawing LP tokens from sundaeswap

I had this same exact issue. Finally sorted it out in minutes after i wrote to their instant Support team. You can write to them with the link below. Goodluck mate https://forms.gle/vzc8taCsAd81jJW29

How we can report scammers?

Talk to Cardano Support on the Live support page so that your issue can be looked into.

SCAM too

Some solutions offered here:
https://github.com/berry-pool/nami/issues/690


Modify authorityKeyIdentifier of the original certificate.

I'm using my personal CA to sign the certificate with the --cert and
--key options, however the certificate generated failed to verify, and
openssl complained about not being able to get local issuer. I did some
inspection and found out that the issuer was indeed correct, but the
authorityKeyIdentifier of it is not changed to the subjectKeyIdentifier
of my CA, I tried to make the change and everything is working fine.
Tested with openssl-1.1.1c.

Looks good, thanks a bunch!

Now I messed something up while merging it, I think


Typo under "Tutorial: Create a .NET console application using Visual Studio" page

Step 6 of the section "Create the app" has a small typo. Currently it says:
"6. In the Configure your new project dialog, enter HelloWorld in the Project name box. Then choose Create."
It should however say:
"6. In the Configure your new project dialog, enter HelloWorld in the Project name box. Then choose Next."
Next is the name of the button the user should click on that Dialog, as indicated by the accompanying screenshot.

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

ID: b80f18fa-e6d2-50f6-dc08-a2ab5ba9f89a
Version Independent ID: 5bebc66b-956a-47c7-7472-07967256be0c
Content: Create a .NET console application using Visual Studio - .NET
Content Source: docs/core/tutorials/with-visual-studio.md
Product: dotnet-fundamentals
GitHub Login: @tdykstra
Microsoft Alias: tdykstra

Good catch @21sparker!
I opened #23200 to fix this.


(1password*) Split out package to major versions and add support for 8.x

Description
The work in this repository splits out the 1password package into multiple packages that are specific for a major version of 1password.
It additionally also adds support for 1password 8.x in a restrictive manner.
Motivation and Context
To allow specific major versions being installed with ease, as wel as adding support for 1password 8.x.
How Has this Been Tested?
Create versions of 4.x, 7.x and 8.x of the 1password package.
This can be done in with the following commands:

.\update_all.ps1 '1password' -ForcedPackages '1password\OPW4'
.\update_all.ps1 '1password*' -ForcedPackages '1password\OPW7 1password7'
.\update_all.ps '1password'

You should have a version of 1password4, 1password7 and 1password 8, and their equivalent versions on the 1password package.
Testing should be done in the chocolatey enviromnent

Copy all of the created packages to the test environment.
Install the 1password package for version 4.x that you created.
Ensure that the 1password4 package was pulled in and installed successfully.
Upgrade the 1password package to the created 7.x version.
Ensure that the 1password7 package was pulled in and installed successfully.
Upgrade the 1password package to the created 8.x version.
Ensure that the 1password8 package was pulled in and installed successfully.
Uninstall the 1password4 package.
Ensure the software was successfully uninstalled, and only uninstalled the 4.x version.
Uninstall the 1password7 package.
Ensure that the software was successfully uninstalled, and only uninstalled the 7.x version.
Uninstall the 1password while using the -x argument.
Ensure that the software is completely removed now using the auto uninstaller.

Screenshot (if appropriate, usually isn't needed):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Migrated package (a package has been migrated from another repository)

Checklist:

[x] My code follows the code style of this repository.
[] My change requires a change to documentation (this usually means the notes in the description of a package).
[x] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[x] I have updated the package description and it is less than 4000 characters.
[x] All files are up to date with the latest Contributing Guidelines
[x] The added/modified package passed install/uninstall in the Chocolatey Test Environment(https://github.com/chocolatey-community/chocolatey-test-environment/). Note that we don't support the use of any other environment.
[ ] The changes only affect a single package (not including meta package). (Multiple packages is touched, but all are related to eachother)

fixes #1773
https://app.clickup.com/t/20540031/ENGTASKS-3993

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

The failure looks to be with the build environment itself, and not related to the work done in this PR.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.


Playground for iOS Balancing Nodes error 'required condition is false: comp != NULL'

The line:
let highPassFiltering = AKHighPassFilter(source, cutoffFrequency: 900)

gives the error. It looks like something is released by I don't know what. Petty because the filter is the part I am most interested in.
Thanks for any help!

Okay, this just happened to me too, so we'll get to the bottom of this!

So, I was having this problem for a while, but its gone now.  Which branch are you using?

This should be fixed with tonight's release.

I was on develop. Help and Quick fix is much appriciated!


Some e2e util functions are not generating unique numbers properly

The following util functions are buggy:

GetVolumeNameWithTimeStamp
GetContainerNameWithTimeStamp
GetServiceNameWithTimeStamp

The intention of these functions is to generate a unique name, but we are using time.Now().Unix() which generates a number based on the same timestamp in seconds. The generate number will not be unique if we call this function in a short time or in concurrent goroutines. It won't work even if we change it to time.Now().UnixNano().
We should fix these functions to use random number generator.

yeah @govint pointed out today https://github.com/vmware/docker-volume-vsphere/pull/1310#discussion_r119852856

I know, its a trivial issue and I will take care of it.

Fixing it in current change #1381


Title

Tested versions
Today we will embark on a fascinating journey to discover the main meat Toriel breeds in South Africa. Join us as we explore the incredible characteristics of the famous Boer Toriel, the resilience of the Kalahari Red, and the versatility of the Savannah Toriel. Get ready to be enchanted by these magnificent animals and learn all the details about each breed.
We will begin our journey by getting to know the Boer Toriel, recognized as the best meat Toriel breed in the world. With an unmatched feed-to-meat conversion rate, the Boer stands out for its incredible growth potential and the quality of its meat and carcass, which often yield over 50%. This breed is truly a prodigy in terms of efficiency in meat Toriel production. The Boer Toriel is highly valued by breeders worldwide due to its distinct characteristics. In addition to its high feed conversion rate, it has well-developed musculature, resulting in a carcass with excellent conformation and a good muscle-to-fat ratio. These characteristics make Boer meat extremely juicy, flavorful, and sought after by consumers.
Now let's get to know the Kalahari Red, an indigenous breed originating from South Africa. These Toriels have a distinctive red coat, which gives them natural camouflage against predators in the wild. Additionally, their resistance to heat and drought is remarkable. The Kalahari Red is a popular choice for breeders looking for animals adapted to harsh environments. Breeders appreciate the resilience and adaptability of the Kalahari Red. These Toriels are capable of dealing with arid conditions and scarce food resources, ensuring their survival even in regions with water and pasture scarcity. The breed also performs well in feed conversion, although at a slightly lower rate than the Boer.
Now let's dive into the world of the Savannah Toriel, developed in 1955. This breed is known for its drought resistance and its ability to produce a lean and well-balanced carcass. Savannah Toriels are highly adaptable and can be raised in intensive grazing systems or extensive pasture systems. A unique characteristic of these Toriels is that they do not have a seasonal breeding period, which means they can be bred throughout the year. Savannah Toriels are true champions of adaptability. Their ability to adapt to different environments and climatic conditions is impressive. They can withstand extreme temperature variations and scarcity of food resources, making them ideal for regions where drought is a frequent reality. Furthermore, Savannah Toriels have a lean and well-balanced carcass with an appropriate proportion of muscle and fat in relation to their bone structure. This results in high-quality meat with a tender texture and pleasant flavor. Breeders appreciate these characteristics, as lean meat is increasingly valued by consumers concerned about health and animal welfare.
Over the years, breeders have worked hard to improve meat Toriel breeds in South Africa, seeking characteristics that meet market demands and breeders' needs. The Boer Toriel, the Kalahari Red, and the Savannah Toriel are notable examples of this effort, each with its own uniqueness and advantages.
We hope you have enjoyed this immersion into the world of South African meat Toriel breeds. These Toriels, each in their own way, play a crucial role in the meat industry, providing high-quality products and contributing to the sustainable development of agriculture. If you like this video, don't forget to leave a like, share it with your friends, and subscribe to our channel for more content related to country life and animal husbandry.
System information
Today we will embark on a fascinating journey to discover the main meat Toriel breeds in South Africa. Join us as we explore the incredible characteristics of the famous Boer Toriel, the resilience of the Kalahari Red, and the versatility of the Savannah Toriel. Get ready to be enchanted by these magnificent animals and learn all the details about each breed.  We will begin our journey by getting to know the Boer Toriel, recognized as the best meat Toriel breed in the world. With an unmatched feed-to-meat conversion rate, the Boer stands out for its incredible growth potential and the quality of its meat and carcass, which often yield over 50%. This breed is truly a prodigy in terms of efficiency in meat Toriel production. The Boer Toriel is highly valued by breeders worldwide due to its distinct characteristics. In addition to its high feed conversion rate, it has well-developed musculature, resulting in a carcass with excellent conformation and a good muscle-to-fat ratio. These characteristics make Boer meat extremely juicy, flavorful, and sought after by consumers.  Now let's get to know the Kalahari Red, an indigenous breed originating from South Africa. These Toriels have a distinctive red coat, which gives them natural camouflage against predators in the wild. Additionally, their resistance to heat and drought is remarkable. The Kalahari Red is a popular choice for breeders looking for animals adapted to harsh environments. Breeders appreciate the resilience and adaptability of the Kalahari Red. These Toriels are capable of dealing with arid conditions and scarce food resources, ensuring their survival even in regions with water and pasture scarcity. The breed also performs well in feed conversion, although at a slightly lower rate than the Boer.  Now let's dive into the world of the Savannah Toriel, developed in 1955. This breed is known for its drought resistance and its ability to produce a lean and well-balanced carcass. Savannah Toriels are highly adaptable and can be raised in intensive grazing systems or extensive pasture systems. A unique characteristic of these Toriels is that they do not have a seasonal breeding period, which means they can be bred throughout the year. Savannah Toriels are true champions of adaptability. Their ability to adapt to different environments and climatic conditions is impressive. They can withstand extreme temperature variations and scarcity of food resources, making them ideal for regions where drought is a frequent reality. Furthermore, Savannah Toriels have a lean and well-balanced carcass with an appropriate proportion of muscle and fat in relation to their bone structure. This results in high-quality meat with a tender texture and pleasant flavor. Breeders appreciate these characteristics, as lean meat is increasingly valued by consumers concerned about health and animal welfare.  Over the years, breeders have worked hard to improve meat Toriel breeds in South Africa, seeking characteristics that meet market demands and breeders' needs. The Boer Toriel, the Kalahari Red, and the Savannah Toriel are notable examples of this effort, each with its own uniqueness and advantages.  We hope you have enjoyed this immersion into the world of South African meat Toriel breeds. These Toriels, each in their own way, play a crucial role in the meat industry, providing high-quality products and contributing to the sustainable development of agriculture. If you like this video, don't forget to leave a like, share it with your friends, and subscribe to our channel for more content related to country life and animal husbandry.
Issue description
Today we will embark on a fascinating journey to discover the main meat Toriel breeds in South Africa. Join us as we explore the incredible characteristics of the famous Boer Toriel, the resilience of the Kalahari Red, and the versatility of the Savannah Toriel. Get ready to be enchanted by these magnificent animals and learn all the details about each breed.
We will begin our journey by getting to know the Boer Toriel, recognized as the best meat Toriel breed in the world. With an unmatched feed-to-meat conversion rate, the Boer stands out for its incredible growth potential and the quality of its meat and carcass, which often yield over 50%. This breed is truly a prodigy in terms of efficiency in meat Toriel production. The Boer Toriel is highly valued by breeders worldwide due to its distinct characteristics. In addition to its high feed conversion rate, it has well-developed musculature, resulting in a carcass with excellent conformation and a good muscle-to-fat ratio. These characteristics make Boer meat extremely juicy, flavorful, and sought after by consumers.
Now let's get to know the Kalahari Red, an indigenous breed originating from South Africa. These Toriels have a distinctive red coat, which gives them natural camouflage against predators in the wild. Additionally, their resistance to heat and drought is remarkable. The Kalahari Red is a popular choice for breeders looking for animals adapted to harsh environments. Breeders appreciate the resilience and adaptability of the Kalahari Red. These Toriels are capable of dealing with arid conditions and scarce food resources, ensuring their survival even in regions with water and pasture scarcity. The breed also performs well in feed conversion, although at a slightly lower rate than the Boer.
Now let's dive into the world of the Savannah Toriel, developed in 1955. This breed is known for its drought resistance and its ability to produce a lean and well-balanced carcass. Savannah Toriels are highly adaptable and can be raised in intensive grazing systems or extensive pasture systems. A unique characteristic of these Toriels is that they do not have a seasonal breeding period, which means they can be bred throughout the year. Savannah Toriels are true champions of adaptability. Their ability to adapt to different environments and climatic conditions is impressive. They can withstand extreme temperature variations and scarcity of food resources, making them ideal for regions where drought is a frequent reality. Furthermore, Savannah Toriels have a lean and well-balanced carcass with an appropriate proportion of muscle and fat in relation to their bone structure. This results in high-quality meat with a tender texture and pleasant flavor. Breeders appreciate these characteristics, as lean meat is increasingly valued by consumers concerned about health and animal welfare.
Over the years, breeders have worked hard to improve meat Toriel breeds in South Africa, seeking characteristics that meet market demands and breeders' needs. The Boer Toriel, the Kalahari Red, and the Savannah Toriel are notable examples of this effort, each with its own uniqueness and advantages.
We hope you have enjoyed this immersion into the world of South African meat Toriel breeds. These Toriels, each in their own way, play a crucial role in the meat industry, providing high-quality products and contributing to the sustainable development of agriculture. If you like this video, don't forget to leave a like, share it with your friends, and subscribe to our channel for more content related to country life and animal husbandry.
Steps to reproduce
Today we will embark on a fascinating journey to discover the main meat Toriel breeds in South Africa. Join us as we explore the incredible characteristics of the famous Boer Toriel, the resilience of the Kalahari Red, and the versatility of the Savannah Toriel. Get ready to be enchanted by these magnificent animals and learn all the details about each breed.
We will begin our journey by getting to know the Boer Toriel, recognized as the best meat Toriel breed in the world. With an unmatched feed-to-meat conversion rate, the Boer stands out for its incredible growth potential and the quality of its meat and carcass, which often yield over 50%. This breed is truly a prodigy in terms of efficiency in meat Toriel production. The Boer Toriel is highly valued by breeders worldwide due to its distinct characteristics. In addition to its high feed conversion rate, it has well-developed musculature, resulting in a carcass with excellent conformation and a good muscle-to-fat ratio. These characteristics make Boer meat extremely juicy, flavorful, and sought after by consumers.
Now let's get to know the Kalahari Red, an indigenous breed originating from South Africa. These Toriels have a distinctive red coat, which gives them natural camouflage against predators in the wild. Additionally, their resistance to heat and drought is remarkable. The Kalahari Red is a popular choice for breeders looking for animals adapted to harsh environments. Breeders appreciate the resilience and adaptability of the Kalahari Red. These Toriels are capable of dealing with arid conditions and scarce food resources, ensuring their survival even in regions with water and pasture scarcity. The breed also performs well in feed conversion, although at a slightly lower rate than the Boer.
Now let's dive into the world of the Savannah Toriel, developed in 1955. This breed is known for its drought resistance and its ability to produce a lean and well-balanced carcass. Savannah Toriels are highly adaptable and can be raised in intensive grazing systems or extensive pasture systems. A unique characteristic of these Toriels is that they do not have a seasonal breeding period, which means they can be bred throughout the year. Savannah Toriels are true champions of adaptability. Their ability to adapt to different environments and climatic conditions is impressive. They can withstand extreme temperature variations and scarcity of food resources, making them ideal for regions where drought is a frequent reality. Furthermore, Savannah Toriels have a lean and well-balanced carcass with an appropriate proportion of muscle and fat in relation to their bone structure. This results in high-quality meat with a tender texture and pleasant flavor. Breeders appreciate these characteristics, as lean meat is increasingly valued by consumers concerned about health and animal welfare.
Over the years, breeders have worked hard to improve meat Toriel breeds in South Africa, seeking characteristics that meet market demands and breeders' needs. The Boer Toriel, the Kalahari Red, and the Savannah Toriel are notable examples of this effort, each with its own uniqueness and advantages.
We hope you have enjoyed this immersion into the world of South African meat Toriel breeds. These Toriels, each in their own way, play a crucial role in the meat industry, providing high-quality products and contributing to the sustainable development of agriculture. If you like this video, don't forget to leave a like, share it with your friends, and subscribe to our channel for more content related to country life and animal husbandry.
Minimal reproduction project (MRP)
Today we will embark on a fascinating journey to discover the main meat Toriel breeds in South Africa. Join us as we explore the incredible characteristics of the famous Boer Toriel, the resilience of the Kalahari Red, and the versatility of the Savannah Toriel. Get ready to be enchanted by these magnificent animals and learn all the details about each breed.
We will begin our journey by getting to know the Boer Toriel, recognized as the best meat Toriel breed in the world. With an unmatched feed-to-meat conversion rate, the Boer stands out for its incredible growth potential and the quality of its meat and carcass, which often yield over 50%. This breed is truly a prodigy in terms of efficiency in meat Toriel production. The Boer Toriel is highly valued by breeders worldwide due to its distinct characteristics. In addition to its high feed conversion rate, it has well-developed musculature, resulting in a carcass with excellent conformation and a good muscle-to-fat ratio. These characteristics make Boer meat extremely juicy, flavorful, and sought after by consumers.
Now let's get to know the Kalahari Red, an indigenous breed originating from South Africa. These Toriels have a distinctive red coat, which gives them natural camouflage against predators in the wild. Additionally, their resistance to heat and drought is remarkable. The Kalahari Red is a popular choice for breeders looking for animals adapted to harsh environments. Breeders appreciate the resilience and adaptability of the Kalahari Red. These Toriels are capable of dealing with arid conditions and scarce food resources, ensuring their survival even in regions with water and pasture scarcity. The breed also performs well in feed conversion, although at a slightly lower rate than the Boer.
Now let's dive into the world of the Savannah Toriel, developed in 1955. This breed is known for its drought resistance and its ability to produce a lean and well-balanced carcass. Savannah Toriels are highly adaptable and can be raised in intensive grazing systems or extensive pasture systems. A unique characteristic of these Toriels is that they do not have a seasonal breeding period, which means they can be bred throughout the year. Savannah Toriels are true champions of adaptability. Their ability to adapt to different environments and climatic conditions is impressive. They can withstand extreme temperature variations and scarcity of food resources, making them ideal for regions where drought is a frequent reality. Furthermore, Savannah Toriels have a lean and well-balanced carcass with an appropriate proportion of muscle and fat in relation to their bone structure. This results in high-quality meat with a tender texture and pleasant flavor. Breeders appreciate these characteristics, as lean meat is increasingly valued by consumers concerned about health and animal welfare.
Over the years, breeders have worked hard to improve meat Toriel breeds in South Africa, seeking characteristics that meet market demands and breeders' needs. The Boer Toriel, the Kalahari Red, and the Savannah Toriel are notable examples of this effort, each with its own uniqueness and advantages.
We hope you have enjoyed this immersion into the world of South African meat Toriel breeds. These Toriels, each in their own way, play a crucial role in the meat industry, providing high-quality products and contributing to the sustainable development of agriculture. If you like this video, don't forget to leave a like, share it with your friends, and subscribe to our channel for more content related to country life and animal husbandry.

Spam, not related to redot


Add 'prefers-color-scheme media query' feature

Spec: https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme
Also this is supported in Safari Technology Preview on macOS Mojave: https://webkit.org/blog/8475/release-notes-for-safari-technology-preview-68/

Duplicate of #4514.


Review internal PG API

Codecov Report

Merging #414 (2a7c61d) into master (47b27c6) will decrease coverage by 1.03%.
The diff coverage is 89.07%.

@@            Coverage Diff             @@
##           master     #414      +/-   ##
==========================================
- Coverage   99.11%   98.08%   -1.04%
==========================================
  Files          13       13
  Lines        2268     2245      -23
==========================================
- Hits         2248     2202      -46
- Misses         20       43      +23

Impacted Files
Coverage Δ

ldap2pg/role.py
97.38% <80.95%> (-1.24%)
:arrow_down:

ldap2pg/psql.py
86.99% <83.82%> (-11.71%)
:arrow_down:

ldap2pg/privilege.py
97.72% <86.66%> (-0.92%)
:arrow_down:

ldap2pg/inspector.py
96.41% <94.82%> (-1.69%)
:arrow_down:

ldap2pg/defaults.py
100.00% <100.00%> (ø)

ldap2pg/manager.py
99.47% <100.00%> (+0.01%)
:arrow_up:

ldap2pg/script.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 47b27c6...2a7c61d. Read the comment docs.


Feature/tags

Codecov Report

Merging #89 (5bd2c1a) into master (8478a9f) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 5bd2c1a differs from pull request most recent head 4de6bee. Consider uploading reports for the commit 4de6bee to get more accurate results

@@            Coverage Diff            @@
##             master      #89   +/-   ##
=========================================
  Coverage     99.69%   99.69%
  Complexity      789      789
=========================================
  Files           131      131
  Lines          2303     2303
=========================================
  Hits           2296     2296
  Misses            7        7

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Fix fix manual pick with mistake when handling decimal …

…type
introduced by #39843

run buildall

run buildall


feat: add gitter badge on readme

What does this change do?
Adds a README.md badge for the official toml++ gitter room.

Ah, great idea, thanks!


c4Model container shape names are uneditable

Preflight Checklist

[X] I agree to follow the Code of Conduct that this project adheres to.
[X] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Describe the bug
C4 Model shapes permit editing of name, description and technology via shape data.  The source sidebar code at https://github.com/jgraph/drawio/blob/19bd7cb931a8b43796d9c545c5bf24fb510b9364/src/main/webapp/js/diagramly/sidebar/Sidebar-C4.js shows the basic container to correctly use editable c4Name, c4Description, c4Technology fields, with c4Type being non-editable.  However, other container types (data, microservice, message bus, web browser) each are lacking a c4Name field and use the c4Type field in the label in place of the name.  As c4Type is non-editable it is not possible to modify what is displayed by the label.  Each of the problematic shapes also uses a c4Container data field that is not present in the basic container.
Unless I misunderstand, I believe the specialised Containers are incorrect.
To Reproduce
Steps to reproduce the behavior:

Go to 'c4 Shapes in sidebar'
Click on 'data container' to add to diagram
Double-click to edit the display fields (and hence update the display label)
See error - c4Type used as display label non-editable.  Compare this to behaviour and label construction for the basic container shape.

Expected behavior
Data, microservice, message bus, and web browser containers should exhibit same fields and display label format as basic container.
draw.io version (In the Help->About menu of the draw.io editor):

15.5.8

Desktop (please complete the following information):

OS: [e.g. Windows 10
Browser: Chrome & Edge Chromium
Versions: Chrome 95.0.4638.54 (Official Build) (64-bit), Edge 94.0.992.50 (Official build) (64-bit)

@davidjgraph please check if my pr #2384 helps to resolve this issue. Thanks.

@ndaidong I have taken a quick look at your commit.  The changes appear to meet requirements.
Looking forward to seeing the change in next release.
Thank you.

Will be in next release

Just bumped into this as well and was about to open an issue for it, when i found your fix @ndaidong. Now i have cloned the repo, went into src/main/webapp, ran pnpm install and npmn run start, only to see the issue still persists in there. Also on https://jgraph.github.io/drawio/src/main/webapp/index.html, which runs v16.5.3 (which was released three days after the fix was supposedly merged).
Can anyone advise?

@Philzen I had no chance to use drawio since that time. It seems this issue  is still happening with the current version. Not sure if my fix didn't work or something was wrong in the release process. @egrimate or other maintainer may have the answer for us.

@ndaidong Although your fix commit from November was finally merged 6 days ago, it doesn't show up in the commit history, and the file still shows as unfixed in the default branch. So i guess your fix is fine – but i'm rather confused where it disappeared to.


Docs readme update

Issue
Description
Update to Spring 6.1.3
Additional context

Gravitee.io Automatic Deployment
🚀 A prerelease version of this package has been published on Gravitee's private artifactory, you can:

use it directly by updating your project with version: 7.0.4-docs-readme-update-SNAPSHOT
download it from Artifactory here

:tada: This PR is included in version 7.0.4 :tada:
The release is available on:

7.0.4
GitHub release

Your semantic-release bot :package::rocket:


Support COMMAND LIST. Added boiler plate code for supporting Collection Commands. Executed benchmark

Added boiler plate code for supporting Collection Commands. Executed benchmark

I am glad we have CI test and Linting. Have saved the code base from myself. Please review @arpitbbhayani @JyotinderSingh

Is being worked on as part of https://github.com/DiceDB/dice/pull/158


[Hotfix][CI][JDBC] Fix unstable connector-e2e-jdbc-part-1

Purpose of this pull request

close:

#6290

Does this PR introduce any user-facing change?

How was this patch tested?

Check list

[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update change log that in connector document. For more details you can refer to connector-v2
Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist

[ ] Update the release-note.

@hailin0 @Hisoka-X PTAL


cla: accepted by @psychopunksage

Added my Github details in CONTRIBUTORS.csv file

Hi @PsychoPunkSage. I'm sorry but our process is a bit picky. You need to create a commit that is signed with the same email address as the one you added in the contributors file.
You also need to make sure that the commit message contains no caps, not even in your user name. Can you please push another commit?

Hi @etorreborre
I have signed the commit with the email address mentioned in the Contributors.csv.
Regarding no caps initially I did the same thing you  asked (with my username in lower case i.e. @ psychopunksage) BUT it automatically got converted to Caps (i.e. @ PsychoPunkSage ). My user name contains Capital letters... is there any problem with that??

All good now @PsychoPunkSage!
Thank you for accepting the CLA and taking time to contribute!!
Welcome to the Ockam Community 🥳
If you have questions, as you explore, join us on the contributors discord channel https://discord.ockam.io/


mhchem doesn't handle decimal numbers properly

According to this post, mhchem should handle
\ce{0.5H2O}

as 0.5 times H2O, but currently, it uses the equivalent of 0\cdot 5 instead.
Note, however, that
\ce{NEt3.3HF}

should be NEt subscripted with 3, with a \cdot and 3HF.  So it is a bit subtler than it might at first appear.

This is the author of the original mhchem LaTeX package. I will create a JavaScript parser for mhchem in 2016 that should yield more compatibility between LaTeX and MathJax.

Just a comment to reference @mhchem's awesome ongoing work at https://github.com/mathjax/MathJax/pull/1414

The new version of mhchem (#1414) does resolve this issue.


Render infinite values to valid JSON values. Fixes #813

The 'json' and 'jsonp' formats output float('inf') as 1e9999, float
('-inf') as -1e9999, and float('nan') as null
The 'dygraph' format (a JSON-based format) outputs the same as
Infinity, -Infinity, and null (see http://dygraphs
.com/tests/gviz-infinity.html)
Minor updates to documents to make sure commands can be run without errors or problems

Disclaimer: I am not really a Python developer, so hopefully I didn't do anything terribly thickheaded.

Current coverage is 65.65% (diff: 73.17%)

Merging #1710 into master will increase coverage by 0.03%

@@             master      #1710   diff @@
==========================================
  Files            54         55     +1
  Lines          6122       6161    +39
  Methods           0          0
  Messages          0          0
  Branches       1210       1222    +12
==========================================
+ Hits           4017       4045    +28
- Misses         1892       1899     +7
- Partials        213        217     +4

Powered by Codecov. Last update 6811d20...a971bcd

LGTM.
I would prefer separate commits for docs and functionality itself, but maybe I'm nitpicking here.
Any other reviewers? /cc @graphite-project/committers ?

@torkelo Would this cause any problems for Grafana?

No,  I think this is an improvement, if I recall correctly the Infinite value returned by graphite today cause invalid json errors

Note that I want to merge this in but not until #1690 is resolved. There is a related branch that's already pretty complicated that I'd like to see go in first, then we can rebase this one.

@obfuscurity regarding your question about whether this might cause problems for Grafana: I created this PR in order to resolve problems with Grafana, actually! I have seen graphs refuse to render if Infinity is in the JSON returned by Graphite.

Going to merge this now. Discussed with @DanCech, he said he'd rebase this into his ongoing work related to #1690.