Constraints on buffer re-use for std.zlib should be documented.

briancschott reported this on 2018-04-17T20:32:19Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=18773
CC List

edi33416
zan77137

Description
The Compress and UnCompress classes have undocumented restrictions on when the buffers passed to their `compress` and `uncompress` methods can be re-used. This needs to be fixed so that people are not accidentally creating or reading corrupted data.

zan77137 commented on 2020-09-15T11:49:46Z
This issue seems to be implementation problems rather than undocumented restrictions: since the argument of compress/uncompress is requiring const(void)[], the function has to take into account the possibility that the buffer may be changed.

Specifically, the following code does not work:
-----------------------------------------------
auto compressed = appender!(ubyte[])();
scope compress = new Compress(HeaderFormat.gzip);
char[128] buffer;
foreach (e; ["abc", "abcdefghijk"]) {
    auto line = sformat!"%s\n"(buffer, e);
    // Invalid buffer is held by Compress
    const compressedLine = compress.compress(line);
    compressed.put(cast(const(ubyte)[]) compressedLine);
}
compressed.put(cast(const(ubyte)[]) compress.flush());
-----------------------------------------------

To solve this, there are two policies:
1. Change the type of argument to immutable(void)[] (this is a breaking change)
2. Copy the argument's buffer, and manage the life of the copied buffer in Compress/UnCompress.


bridging time

Good if bridging time still reduced to lower.

Better if the bridging time is less than 5 minutes


[WIP] release: v3.3.0

https://github.com/raxjs/rax-app/milestone/11

Codecov Report

Merging #572 (f225dde) into master (2d07dc6) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #572   +/-   ##
=======================================
  Coverage   90.33%   90.33%
=======================================
  Files          21       21
  Lines         797      797
  Branches      204      204
=======================================
  Hits          720      720
  Misses         75       75
  Partials        2        2

Codecov Report

Merging #572 (f225dde) into master (2d07dc6) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #572   +/-   ##
=======================================
  Coverage   90.33%   90.33%
=======================================
  Files          21       21
  Lines         797      797
  Branches      204      204
=======================================
  Hits          720      720
  Misses         75       75
  Partials        2        2


Upgrade to Babel 6 and apply fewer transformations when transpiling babel files

This pull request upgrades babel to the latest version and runs a minimal set of transformations when transpiling babel files. In particular, only the following cases will be affected by the transpilation step:

import or export expressions.
async/await expressions.
Do expressions.
Function bind expressions.
Decorators.
Object rest spread expressions (e.g. {a: 1, b: 2, …anotherObject}).
Class properties.
JSX code.
Flow code.

We shouldn't need any other transformation because Electron runs on a pretty recent V8 version. As a result, the generated code should be cleaner and source maps should look less crazy as well. Please, note that I was forced to update babel because the previous asyncToGenerator plugin had some bugs when not transpiling ES2015 classes.
/cc: @atom/core

@BinaryMuse I'm curious about the roadblocks you ran into when you tried to upgrade our core Babel recently. Is there anything we're missing here?

@nathansobo I was thinking about that too — I don't recall what issues I ran into with upgrading Babel specifically. One may have been a lack of confidence that the upgraded/reconfigured Babel would perform the same way as the old one and would break packages. That said, one of the main reasons I stopped working on that and started on the per-package transpilation was because the Relay Babel transform requires a project-specific schema and so can't be enabled "globally."

This morning I compiled all the babel files that package authors have published and have identified some that can't compile with the current babel configuration. Some of them are clearly related to the changes in this pull request, but others contain syntactic errors that might have existed prior to these changes.  For the former group I will submit a pull request and simply open an issue for the latter.
Packages breaking because of this pull request

[ ] ansible-vault/lib/ansible-vault.js: Deleting local variable in strict mode (106:6)
[ ] atom-go-jump-test/lib/atom-go-jump-test.js: package is a reserved word in strict mode (59:6)
[ ] atom-jive/spec/atom-ternjs-spec.js: package is a reserved word in strict mode (16:6)
[ ] atom-ternjs/spec/atom-ternjs-spec.js: package is a reserved word in strict mode (15:6)
[ ] atom-ysp/lib/product/common.js: Invalid number (169:24)
[ ] autocomplete-lodash/lib/autocomplete-lodash-provider.js: arguments is a reserved word in strict mode (65:45)
[ ] autosave-onchange/lib/autosave-delay.js: package is a reserved word in strict mode (22:6)
[ ] autosave-onchange/spec/package-spec.js: package is a reserved word in strict mode (10:8)
[ ] black-bird/lib/RemoteDirectory.js: Invalid number (14:14)
[ ] copy-path/lib/index.js: package is a reserved word in strict mode (33:40)
[ ] language-blob/lib/blob-provider.js: arguments is a reserved word in strict mode (109:12)
[ ] language-markdown/lib/__main.js: Unexpected token, expected , (16:6)
[ ] linter-erlc/lib/init.js: Unexpected token (112:27)
[ ] medium-upload/lib/medium-upload-view.js: package is a reserved word in strict mode (105:46)
[ ] mope/lib/moie.js: interface is a reserved word in strict mode (120:18)
[ ] mope/lib/util.js: interface is a reserved word in strict mode (27:10)
[ ] neovimbed/spec/spec-helper.js: package is a reserved word in strict mode (24:65)
[ ] package-foreman/lib/package-foreman.js: package is a reserved word in strict mode (33:47)
[ ] package-foreman/lib/package.js: package is a reserved word in strict mode (101:39)
[ ] quicknote/src/components/Overlay.js: package is a reserved word in strict mode (104:10)

Packages with syntactic errors

[ ] atom-calca/lib/parser/CalcaParser.js: Unexpected token, expected , (63:11)
[ ] atom-setup-manager-package/lib/checkout.js: 'super' outside of function or class (17:6)
[ ] autocomplete-jsp/src/tag-provider.js: Unexpected token, expected , (139:5)
[ ] autocomplete-jsp/src/utils.js: Unexpected token, expected , (39:1)
[ ] black-bird/lib/Server.js: Unexpected token, expected , (72:5)
[ ] build-gulp/lib/gulp.js: Unexpected token, expected ; (38:7)
[ ] javascript-importer/lib/import-dialog.js: Unexpected token, expected ; (22:38)
[ ] save-workspace/lib/commands/open.js: Unexpected token, expected , (19:5)
[ ] save-workspace/lib/commands/remove.js: Unexpected token, expected , (19:5)
[ ] save-workspace/lib/commands/save.js: Unexpected token, expected , (19:5)
[ ] xkcd-comics/lib/xkcd.js: Unexpected token, expected , (22:5)
[ ] xkcd-debounce-fix/lib/xkcd.js: Unexpected token, expected , (22:5)

Once CI is 💚 I think this could be ready to go, so that we can let it bake for a while on master before rolling the railcars next month.
I am planning to 🚢 it by the end of today, so it'd be great if anyone could give it a last 👀 before merging it.

Amazing initiative.

Hey @as-cii, I'm running into an issue where export const {foo} = bar isn't exporting the variable. I had to change it to const {foo} = bar; export {foo}. The former syntax is correct, is this something that could have been broken by this PR?

@quarterto That syntax isn't valid AFAIK. See e.g. https://developer.mozilla.org/en/docs/web/javascript/reference/statements/export.

MDN is incomplete here. The spec has export VariableStatement as one of the productions. VariableStatement encompasses destructuring assignment.
The Babel REPL correctly transforms this, so I wonder what's going on.

If I'm reading the spec correctly, VariableStatement only encompasses var statements/declarations.
Briefly scanned through the Declaration grammar "chain" to see if that might include destructuring assignments, but it doesn't look like it does.
I might be wrong, and please let me know if I am, but it looks like Babel has incorrectly implemented the spec.

I think it works via export Declaration → LexicalDeclaration → BindingList → LexicalBinding → BindingIdentifier → BindingPattern.
Either way, this is working in the Babel REPL but for some reason not in Atom's Babel, which I don't understand.

Since we're not using the es2015 preset, it doesn't look like we're actually transpiling that export statement. We're using two plugins that affect export statements, but they do not seem to be related to general exports, only providing support for CommonJS, as well as supporting default or some such.
So if the syntax you're using is indeed valid, this is a problem with the Node.js that ships with the our version of Electron — it simply doesn't support your syntax. Hopefully something that get's resolved with #12696 (but might also require a bump to Electron v1.6.x).

No version of node supports export; you're using babel-plugin-transform-es2015-modules-commonjs which should support this. I'm about to try compiling that with Atom's babelrc to see what the output is.

Even though I am a little unclear about whether or not that syntax is supported in the spec, I actually believe this is a bug in Babel.
Babel seems to recognize that syntax properly with the current configuration, but since we are not using the transform-es2015-destructuring plugin it's failing to apply the transform-es2015-modules-commonjs transformation correctly. For instance, consider the following snippet:
export const {a} = {a: 1}

With the transform-es2015-destructuring plugin, it will be converted by Babel into:
Object.defineProperty(exports, "__esModule", {
  value: true
});
/** @babel */

var _a = { a: 1 };
const a = _a.a;
exports.a = a;

Viceversa, if we exclude the transform-es2015-destructuring plugin, the syntax will still be recognized and parsed properly, but the applied transform-es2015-modules-commonjs will look like the following:
Object.defineProperty(exports, "__esModule", {
  value: true
});
/** @babel */

const { a } = { a: 1 };

Which is confusing and unexpected. Still, I am a little reluctant to add the transform-es2015-destructuring plugin back because I couldn't find other packages using a similar syntax and fixing this issue on the atom-which-key package seems also quite straightforward.
@thomasjo @quarterto: what do you think?

Yeah, that seems reasonable. I didn't know about this syntax either until seeing it in atom-which-key 😄
We should probably report this to Babel.

No version of node supports export; you're using babel-plugin-transform-es2015-modules-commonjs which should support this.

@quarterto Sorry about the false information; I guess I've been confusing actual support with planned support or some such. Thanks for the clarification!

Which is confusing and unexpected. Still, I feel a little reluctant to add the transform-es2015-destructuring plugin back because I couldn't find other packages using a similar syntax and fixing this issue on the atom-which-key package seems also quite straightforward.
@thomasjo @quarterto: what do you think?

@as-cii Makes sense to keep it as is. Might be worth investigating if we have any complex destructuring assignments in core, since those are seemingly an order of magnitude slower in native ES6, compared to transpiled to ES5 via Babel (ref: https://fhinkel.github.io/six-speed/).

I'm only guessing that this is the PR responsible for this change, but https://github.com/atom/toggle-quotes/pull/48 is now the second package that I've had to make that change to for it to work properly under Atom v1.16.0-beta0. Should this be filed as a new issue?

Is it possible to track what version of v8 atom is using easily? I guess it's based on what electron is on?
Because babel-preset-env is a thing, and it auto-selects the transforms necessary.
Specifically, it has a targets.node option (https://github.com/babel/babel-preset-env#targetsnode) which allows you to transpile only what you need.

Open Atom and type process.versions in the developer tools.  The raw data is available here, but it doesn't look like versions other than the latest are displayed on the website.

I'm only guessing that this is the PR responsible for this change, but atom/toggle-quotes#48 is now the second package that I've had to make that change to for it to work properly under Atom v1.16.0-beta0. Should this be filed as a new issue?

I am a little concerned about this as, again, Babel was transpiling things in a weird way and, even though the code in toggle-quotes is syntactically correct, its behavior will change as a result of this pull request. @Arcanemagus: could you show how you had to change that second package, please? Was it because of the same problem?
Anyways, we have received only a few reports about this pull request breaking existing packages and maybe we can keep it, but I wonder if it's just because these changes were rolled out on the beta channel only.
Alternatively, I guess we could use different configurations for bundled packages and third-party packages: we'd use the new config for the former, and keep using the old one for the latter.
@atom/maintainers: thoughts? 💭

@Arcanemagus: could you show how you had to change that second package, please? Was it because of the same problem?

Yep, the exact same issue: It was declaring the activate function (and others) as arrow functions, switching them in the same manner as in toggle-quotes fixed it. (See https://github.com/AtomLinter/linter-glsl/pull/54/commits/d0c6567d9dd03adbbbeb7799aeb987d64ec4c44f)

After searching for usages of activate: () => I was able to find 60 packages that are mistakenly using an arrow function in a global scope. Using this syntax in the new version of babel:
export default {
  activate: () => {
    this.test = 1
  }
}

Will transpile to:
exports.default = {
  activate: () => {
    undefined.test = 1;
  }
}

Which will yield the error @Arcanemagus saw. I am seriously considering reverting this, as things have changed quite significantly in the latest babel version and I have some concerns about breaking lots of packages. It is unfortunate because the code was not supposed to work in the first place, but apparently the previous babel version was more forgiving.

@as-cii Or we divide up the work, and submit PRs to all offending packages. It needs to be fixed, so we might as well do it now before more packages end up using invalid syntax. Thoughts? :thought_balloon:

I can fix all the linter-* ones in the AtomLinter org, I'll get started on that.

We're probably going to revert this change and try again another time. Our current plan is as follows:

Allow arbitrary assets to be published as part of Atom packages rather than requiring everything to be stored in git.
Publish pre-transpiled assets for all current Atom packages depending on transpilation.
Bake a list of packages with assets into Atom, and prompt the user to reinstall these packages on upgrade.
Remove support for global transpilation from Atom. Support custom package transpilers only in dev mode.


PHP 7.2 incompatibility due to "Special class name" conflict.

It seems PHP 7.2 reserves the word Object as a "special class name". This means the plugin throws an error in the JsonClientPlugin.php file due to line 20:
use craft\base\Object;
As this seems to be a reference to a core Craft class, this may require core updates to fix, but I thought it still worth bringing to your attention.
Full screenshot of error message:

Craft itself doesn't have a craft\base\Object class and as far as I can tell, it never has, so not sure what that line is referencing.

Strange. I've simply removed it and from what I can tell there are no adverse effects. I've filed a pull request in the hopes it can be resolved.

I'm getting this when I push it up to my staging site after setting this plugin up locally. Hopefully this gets included.

Should be fixed now :)

@Luuc15 Thanks so much. I think the version number in composer.json will need to be bumped to trigger update notifications?


chore: update readme

This will not work without updating the getToken lambda. So either that change needs to be done first, or this change should include a mapping where the value passed is mapped to one that getToken accepts.

I know, I have a PR for that here https://github.com/smileidentity/lambda/pull/498


Downloads libonnxruntime.so.1.17.3 from pyke cache, but tries to load 1.18.1

Hi,
# Cargo.toml
[dependencies]
ort = { version = "2.0.0-rc.3", features = ["cuda", "tensorrt"] }

// main.rs
    let session = Session::builder()?
        .with_execution_providers([CUDAExecutionProvider::default().build()])?
        .commit_from_file("test.onnx")?;

$ ls target/debug
libonnxruntime.so ⇒ ~/.cache/ort.pyke.io/dfbin/x86_64-unknown-linux-gnu/74F4EC918F00B6517BC71AA23DEA0E0809694D5FAB10A494A7AE571F06AEA0BD/onnxruntime/lib/libonnxruntime.so
libonnxruntime.so.1.17.3 ⇒ ~/.cache/ort.pyke.io/dfbin/x86_64-unknown-linux-gnu/74F4EC918F00B6517BC71AA23DEA0E0809694D5FAB10A494A7AE571F06AEA0BD/onnxruntime/lib/libonnxruntime.so
libonnxruntime_providers_cuda.so ⇒ ~/.cache/ort.pyke.io/dfbin/x86_64-unknown-linux-gnu/74F4EC918F00B6517BC71AA23DEA0E0809694D5FAB10A494A7AE571F06AEA0BD/onnxruntime/lib/libonnxruntime_providers_cuda.so
libonnxruntime_providers_shared.so ⇒ ~/.cache/ort.pyke.io/dfbin/x86_64-unknown-linux-gnu/74F4EC918F00B6517BC71AA23DEA0E0809694D5FAB10A494A7AE571F06AEA0BD/onnxruntime/lib/libonnxruntime_providers_shared.so
libonnxruntime_providers_tensorrt.so ⇒ ~/.cache/ort.pyke.io/dfbin/x86_64-unknown-linux-gnu/74F4EC918F00B6517BC71AA23DEA0E0809694D5FAB10A494A7AE571F06AEA0BD/onnxruntime/lib/libonnxruntime_providers_tensorrt.so

Note this is 1.17.3.
Running:
$ cargo run
target/debug/test: error while loading shared libraries: libonnxruntime.so.1.18.1: cannot open shared object file: No such file or directory

Which is expected. Am I holding this wrong? My understanding is that the download-binaries would download the correct version from the cache, but it doesn't. Changing to an older 2.0 rc doesn't help, 1.18.1 is also expected.

Also having this issue - guessing it might be related to commit https://github.com/pykeio/ort/commit/8f8bbfb4247a8a6091b821f5b80f5299080705d6?

I think this goes deeper: the detection behavior to pick between CUDA 11 and 12 seems to be broken, because regardless of whether I build this in pytorch:2.3.1-cuda11 or pytorch:2.3.1-cuda12, libonnxruntime_providers_cuda.so expects libcublasLt.so.12.

Also having this issue - guessing it might be related to commit 8f8bbfb?

Hm, thanks. The thing I said above is specifically what is documented there and seemingly not happening: https://github.com/pykeio/ort/commit/8f8bbfb4247a8a6091b821f5b80f5299080705d6#diff-d2be1711b3546c95dd42f4622bd1e8a3c46f5e9975d7d36312fa194fe0449895R199

I also just noticed https://github.com/pykeio/ort/blob/8f8bbfb4247a8a6091b821f5b80f5299080705d6/ort-sys/build.rs#L139 in build.rs... might be related?

Ah thanks, couldn't find where that damn version was even referenced. Looks like the issue is indeed in ort-sys.

Impressive turn-around time, just wanted to show some gratitude for that awesome lib. :rocket:

Fixed in v2.0.0-rc.4 - cc @isaac-mcfadyen

Fixed in v2.0.0-rc.4 - cc @isaac-mcfadyen

Amazing, thank you so much for the quick fix! ❤


Object_store: Create an upload method that handles concurrency

This issue is related with #5277. Basically it is created to split the task of creating a download and upload methods in two different tasks with two different PR for easy review.
The original issue was

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
As a user, I would like to utilize the object_store to put and retrieve files. Currently, I can employ the put and get methods for this purpose. However, I am responsible for handling any issues that arise. For instance, when uploading a file to the store, I must verify its size to determine whether multipart upload is necessary. Similarly, when retrieving a large file, I cannot download it in its entirety before writing it to the local file system, as this would cause excessive memory usage. Instead, I may need to use get_range and write specific portions of the file locally. Moreover, downloading different ranges could potentially be executed in parallel.

Regards

take


llvmPackages: change default to 3.9

Motivation for this change
See https://github.com/NixOS/nixpkgs/issues/19195.
Things done

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

[ ] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Note that llvmPackages and llvmPackagesSelf were out of sync—I'm not sure if that was intended. (If that was, we should add a comment explaining this.)
That's probably a mass rebuild (at least for darwin), so opening against staging.

Can you actually make this conditional on darwin and leave it alone (i.e., still at 3.7) on that platform? I'm trying to upgrade to 3.8 right now but there are issues we've been encountering with c++ compatibility and so on.

@copumpkin done

Thanks! I assume you've built whatever depends on it on Linux? I vaguely remember mesa and things downstream from it using llvm.
The issues with LLVM have mostly been around certain changes in libc++ that happened in 3.8, and made several packages stop compiling with it. Those issues are obviously exacerbated by Darwin using LLVM to build everything, but I imagine you might find similar issues on whichever packages build with it on Linux too.

mesa doesn't seem to depend on llvm—Nix took one from the cache.
*** Downloading ‘https://cache.nixos.org/nar/1y90k9rq1mjxd6b594gshzxnizgvmq26zjdfjkxvfc53vixw63g1.nar.xz’ to ‘/nix/store/8rkvqz2x0hr23313qk2wi1ap7nffzj1k-mesa-13.0.1’...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1160  100  1160    0     0    780      0  0:00:01  0:00:01 --:--:--   783

/nix/store/8rkvqz2x0hr23313qk2wi1ap7nffzj1k-mesa-13.0.1

Hmm, I must be misremembering. Either way, nox-review should be able to check stuff for you 😄

Running it now.
btw, it always takes long on ==> We're in a git repo, trying to fetch it moment. Is that ok?

error: while querying the derivation named ‘clang-wrapper-wrapper-3.9.0’:
while evaluating the attribute ‘buildCommand’ of the derivation ‘clang-wrapper-wrapper-3.9.0’ at /home/rasen/.nox/nixpkgs/pkgs/build-support/cc-wrapper/default.nix:40:3:
attribute ‘gcc’ missing, at /home/rasen/.nox/nixpkgs/pkgs/build-support/cc-wrapper/default.nix:194:38

Yay for nox-review! No idea what's wrong, but at least it found the problem before it bit us 😄

@copumpkin what are the issues with 3.8 on darwin?

@shlevy http://hydra.nixos.org/eval/1304050?compare=staging is somewhat informative for figuring that out, although I wish we could only look for red crosses

@shlevy there were some bdb incompatibilities that @LnL7 fixed here (and in similar patches for other versions): https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/db/clang-5.3.patch

I also discovered yesterday that removing the --enable-dbm flag will also fix one of the issues, that probably better then patching it.

@LnL7 don't we want dbm-like stuff though?

It's some sort of legacy interface apparently, so hopefully not. If something needs it I would assume that the current patch also breaks it.

Could someone help me find clang-wrapper-wrapper? I've build all of llvmPackages fine.

mesa doesn't seem to depend on llvm—Nix took one from the cache.

Mesa certainly depends on LLVM, but we have already been using 3.9 in mesa for a long time: https://github.com/NixOS/nixpkgs/blob/2326c8de4dd53a2829d40a7dbdf16f4dc0ebf6b6/pkgs/top-level/all-packages.nix#L8499

llvmPackagesSelf.llvm won't build for me if switched to 3.9:
/tmp/nix-build-llvm-3.9.0.drv-0/llvm/projects/compiler-rt/lib/tsan/dd/dd_interceptors.cc:226:20: error: redefinition of 'realpath'
INTERCEPTOR(char*, realpath, const char *path, char *resolved_path) {
                   ^
/nix/store/7lmqs27llkmmzd8lczjrhq805w48zp15-glibc-2.24-dev/include/bits/stdlib.h:37:8: note: previous definition is here
__NTH (realpath (const char *__restrict __name, char *__restrict __resolved))

I switched llvmPackages at least, in master directly.

obsolete


OpenSSL & compiling from depends folder Ubuntu 18

Making from depends on ubuntu 18
"bitgreen/depends$ make
Fetching protobuf-2.6.1.tar.bz2 from https://github.com/google/protobuf/releases/download/v2.6.1
/bin/sh: 1: curl: not found
Fetching protobuf-2.6.1.tar.bz2 from https://bitcoincore.org/depends-sources
/bin/sh: 1: curl: not found
funcs.mk:242: recipe for target '/home/rolfdogg/bitgreen/depends/sources/download-stamps/.stamp_fetched-native_protobuf-protobuf-2.6.1.tar.bz2.hash' failed
make: *** [/home/rolfdogg/bitgreen/depends/sources/download-stamps/.stamp_fetched-native_protobuf-protobuf-2.6.1.tar.bz2.hash] Error 127
"
Without depends
./autogen.sh
./configure
make -j4
"rc/init.cpp:1005: undefined reference to OpenSSL_version' libbitcoin_util.a(libbitcoin_util_a-util.o): In function _GLOBAL__sub_I_fMasterNode':
src/util.cpp:161: undefined reference to `OPENSSL_init_crypto'
collect2: error: ld returned 1 exit status"

Seems to me like there's something going wrong with linking either -lcrypto or -lssl. Can you post more of your logs, at least the ones generated by ./configure ?
Did you build the Openssl libraries yourself or are you using the Ubuntu 18.04 packages?
Found that a similar was reported before with bitcoin core:
https://github.com/bitcoin/bitcoin/issues/8706
As for the issue building the dependencies yourself, you're either missing the curl executable (which is provided by the 'curl' package), or your bash paths are messed up.

I just completed a build on Ubuntu 18.04 64-bit myself with the 'libssl1.0.0' and 'libssl1.0-dev' packages installed

curl is missing, probably that and some other ubuntu base packages are missing

I tried on 2 VM's and the main i use for compiling for ubuntu 18 and it gives the same errors even though other wallets compile just fine on it.

Can you check if you have installed the dependencies?
with depends
apt list curl

without depends
apt list openssl


2px border in .input-group-lg

@partizzzzzan is this stating that it should be 1px instead of 2px or something else? If you could provide a more detailed explanation with a JSBin demonstrating the problem that would be greatly appreciated. Thanks!

This is a duplicate of #14237.
It's not just .input-group-lg. I see this in Chrome (45.0.2416.0 canary 64-bit), as well, specifically on dropdown on the left side of the group.

Don't see it in Firefox or Safari.
The decision in the last issue was to wait and see what Chrome will do.

Nope.

After playing with this more, I'm pretty confident it's a pixel rounding problem. Not much to do there, and it doesn't seem like something we really need to document anywhere as pixel rounding problems happen in various ways in damned near every browser.
@cvrebert Feel free to reopen if I'm cray.

Fixed in Chrome Canary; see https://github.com/twbs/bootstrap/issues/14237#issuecomment-142512236


Add feature for enabling related products

On the my cart page, we'd like to hide related products for BC stores.

@powerwlsl this is similar to #814, feel free to remove that part from the site folder of your fork.

Hey there! Thank you for your contribution. We have decided to take Next.js Commerce in a new direction and will be closing out current PRs and issues due to this change. Please see this PR for more details: https://github.com/vercel/commerce/pull/966


Document the base64 dependency

To save other devs wondering why we use the current version add a comment to the base64 dependency.

How do we block that bitcoinfinancier bot?

No longer true.


[Enhancement] Query server response as the user types in

Currently, there's only an all or nothing way to retrieve resources from the server, which in turn can be counter productive when retrieving lots of data. Will be nice to have feature to allow to query server as the user types in so that data is returned in small chunks.

you can set data-live-server to 1 and filter the list according to the parameter being sent to the server. it's a little basic i admit but it should do the job

Let me give it a try, I'll go ahead and close in the meantime.


Main Thread Checker warning in v1.0.9

Bug Description
I just took the Iterate SDK v1.0.9 update (with custom font support), and I noticed a new warning from the Main Thread Checker when triggering a survey in-app.  This doesn't seem like a big issue as it's just a warning, but I figured I would flag it for you since this was just introduced in this recent release.
To Reproduce
Steps to reproduce the behavior:

Update to Iterate SDK v1.0.9
Preview any survey and trigger it
Note the CFNetwork warning from the Main Thread Checker on line 106 of SurveyViewController.swift:

Synchronous URL loading of [survey_url] should not occur on this application's main thread as it may lead to UI unresponsiveness. Please switch to an asynchronous networking API such as URLSession.

Expected behavior
There should be no warnings from the Main Thread Checker.
Device:

Device: iPhone 12 Pro
Xcode Version: 14.0
OS: iOS 16.0

Thank you for the report, fixed in v1.0.10


fix: ignore functional nodes

This was presenting cause: https://stackblitz.com/edit/nuxt-starter-dptnmt?file=pages/constructor.vue.

merging as a hotfix


i use ctrl+v once to copy a string into TextField,but he did it twice

"a" is in my clipboard,where i use ctrl+v once,i got "aa"

Duplicate of #314
Please read: https://github.com/go-flutter-desktop/go-flutter/issues/319#issuecomment-558557949


Cursor visual gets into a bad state in editor

Describe the bug
The cursor visual can get in a bad state when transitioning between using simulated hands/gaze and when moving from a scale manipulator to a position manipulator
To reproduce
see the attached .gif for an example scenario where the bug occurs

Root caused the issue here, it's because the animations for changing the cursor to a cross icon/scale icon/rotate icon don't explicitly disable or enable the other visuals, which can cause the "default state" of the cursor to become altered during runtime as the visuals gets toggled on and off. Will make a PR soon to fix up these animations.


Export to minecraft preview

The preview edition has just been released on windows. Its com.mojang path is:
C:\Users\USER\AppData\Local\Packages\Microsoft.MinecraftWindowsBeta_8wekyb3d8bbwe\LocalState\games\com.mojang
Would be great to have that option.

f3c95035c4e8ba7ef807152112afe27cea5fd44f


Discover Language not applying

Description
I changed my Discover Language in settings to English, but I'm still seeing items that have different original languages (e.g., Mavka/Ukrainian).
Version
1.5.0
Steps to Reproduce
Go to settings. Change Original Language. Check home page.
Screenshots
No response
Logs
No response
Platform
smartphone
Device
Samsung S22 5G
Operating System
Android
Browser
Brave
Additional Context
No response
Code of Conduct

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

Restart jellyseerr. Maybe clear browser cache too. Its just tmdb cache. Leave it applied for a while and it should only show english


非法指令

Describe the bug
hanlp Version: 2.1.0b64 ，Python Version: 3.8.20
import hanlp
tok = hanlp.load(hanlp.pretrained.tok.COARSE_ELECTRA_SMALL_ZH)
Downloading https://file.hankcs.com/hanlp/tok/coarse_electra_small_20220616_012050.zip to /root/.hanlp/tok/coarse_electra_small_20220616_012050.zip
100% 43.5 MiB 6.6 MiB/s ETA: 0 s [=============================================================]
Decompressing /root/.hanlp/tok/coarse_electra_small_20220616_012050.zip to /root/.hanlp/tok
非法指令
[root@localhost ~]# python
Python 3.8.20 (default, Dec 9 2024, 13:56:32)
import hanlp
tok = hanlp.load(hanlp.pretrained.tok.COARSE_ELECTRA_SMALL_ZH)
非法指令
Code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate the problem.

Describe the current behavior
A clear and concise description of what happened.
Expected behavior
A clear and concise description of what you expected to happen.
System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
Python version:
HanLP version:

Other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.
[x] I've completed this form and searched the web for solutions.

https://github.com/hankcs/HanLP/issues/1928

[root@localhost home]# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
用的是centos7 x86_64

可能是你的CPU太旧了，不支持torch的某些新的intel加速指令。建议把torch的版本往下降级降到能用为止。


Can't publish Updatecli policies to Dockerhub

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
We can't publish Updatecli policies to DockerHub
Expected Behavior
No response
Steps To Reproduce
Running the command:
updatecli manifest push --experimental -t "olblak/updatecli-docusaurus" --config "updatecli.d" --values "values.d/epinio.yaml" .

returns:
Command Output
Return
++++++++++++
+ REGISTRY +
++++++++++++

Pushing Updatecli policy:
	=> olblak/updatecli-docusaurus

WARNING: Pushing 0.1.0 to index.docker.io
publishing policy 0.1.0
ERROR: ✗ upload artifact to latest: PUT "https://index.docker.io/v2/olblak/updatecli-docusaurus/manifests/0.1.0": response status code 401: unauthorized: authentication required: [map[Action:pull Class: Name:olblak/updatecli-docusaurus Type:repository] map[Action:push Class: Name:olblak/updatecli-docusaurus Type:repository]]
ERROR: command failed: upload artifact to latest: PUT "https://index.docker.io/v2/olblak/updatecli-docusaurus/manifests/0.1.0": response status code 401: unauthorized: authentication required: [map[Action:pull Class: Name:olblak/updatecli-docusaurus Type:repository] map[Action:push Class: Name:olblak/updatecli-docusaurus Type:repository]

Environment
- OS: Linux
- updatecli: v0.80.0

Anything else?
I managed to publish this policy olblak/updatecli-docusaurus to DockerHub by manually defining the registry "docker.io" instead of the default "index.docker.io"

The workaround is to first run to login on index.docker.io running
docker login index.docker.io


schedule writable streams fairly

Instead of always picking the first writable stream from the streams map
(depending on the HashMap iteration order, so not necessarily the stream
with the lower ID), keep track of writable streams in a separate FIFO
queue, and round-robin them.
This preserves the order of stream writes to what the application
decides (i.e. the order of stream_send() calls), and increases stream
concurrency and significantly reduces deviation in response times
between concurrent requests.
For example, running 250 identical HTTP/3 requests concurrently using
h2load shows the following before the change:
  finished in 78.66s, 3.18 req/s, 3.12MB/s
  requests: 250 total, 250 started, 250 done, 250 succeeded, 0 failed, 0 errored, 0 timeout
  status codes: 250 2xx, 0 3xx, 0 4xx, 0 5xx
  traffic: 245.25MB (257165011) total, 4.39KB (4500) headers (space savings 58.14%), 238.42MB (250000000) data
                       min         max         mean         sd        +/- sd
  time for request:   133.99ms      78.66s      26.53s      23.46s    60.80%

and after:
  finished in 76.32s, 3.28 req/s, 3.21MB/s
  requests: 250 total, 250 started, 250 done, 250 succeeded, 0 failed, 0 errored, 0 timeout
  status codes: 250 2xx, 0 3xx, 0 4xx, 0 5xx
  traffic: 245.25MB (257166916) total, 4.39KB (4500) headers (space savings 58.14%), 238.42MB (250000000) data
                       min         max         mean         sd        +/- sd
  time for request:     75.61s      76.31s      76.10s    170.77ms    59.20%

In the future this can be adapted to implement a more sophisticated
stream prioritization scheme.
Incidentally this also shows significant improvement in the http3
benchmarks due to the fact that we don't need to loop over all streams
(including the ones that have no data to send) when deciding which
stream to schedule, but only over the ones that are actually writable:
  http3/128000            time:   [4.1817 ms 4.8528 ms 5.4428 ms]
                          change: [-52.216% -45.968% -38.798%] (p = 0.00 < 0.05)
                          Performance has improved.
  http3/256000            time:   [10.424 ms 10.667 ms 10.949 ms]
                          change: [-49.763% -48.050% -46.369%] (p = 0.00 < 0.05)
                          Performance has improved.
  http3/512000            time:   [50.051 ms 50.258 ms 50.446 ms]
                          change: [-49.695% -44.301% -38.402%] (p = 0.00 < 0.05)
                          Performance has improved.
  http3/1000000           time:   [82.858 ms 83.813 ms 84.938 ms]
                          change: [-50.842% -49.848% -48.879%] (p = 0.00 < 0.05)
                          Performance has improved.

Other benchmarks are unchanged.

BTW, something that the h2load test doesn't show is that the average and mean TTFB per-request goes down, even though total per-request time goes up, so this doesn't just make all requests go slower :)

finished in 76.32s, 3.28 req/s, 3.21MB/s
min         max         mean         sd        +/- sd
time for request:     75.61s      76.31s      76.10s    170.77ms    59.20%

This means every request took 75~76 sec? Can we get individual timing per request?
And are those requests are quic streams in a single quic connection or distributed over multiple quic connections?

@junhochoi it's 250 simultaneous requests on the same connection, each with a 1MB response body. So before this change, each response would be sent sequentially (so the first one is the fastest and then they get progressively slower until the last one which is the slowest), but with this change they get sent concurrently so the total time is higher on average, but time to first byte lower.
I don't have timing for each request right now, but I can run the h2load test to get them.

Also note that the test was run against the quiche example HTTP/3 server, I haven't done it against NGINX yet.

@LPardue I just figured out how to dismiss reviews :D


add out/production/classes as a CodeSource Path Element

derived from the
https://github.com/kazurayam/inspectus4playwright-java-sample-project/issues/2
IntelliJ IDEA builds the java classes into <projectDir>/out/production/classes if you let IDEA to be responsible for the building.

done


Can't install on HassOS 4.14 RPI3b+ 32 bit

Install will fail every time with completely system hang-up after about 10 minutes after:
[supervisor.docker.addon] Starting build for 62c7908d/armv7-addon-emulated_hue:0.0.4
After hard reboot, addon will fail to start:
20-10-21 10:24:03 ERROR (SyncWorker_1) [supervisor.docker] Image 62c7908d/armv7-addon-emulated_hue not exists for addon_62c7908d_emulated_hue
20-10-21 10:24:03 WARNING (MainThread) [supervisor.addons] Can't start Add-on 62c7908d_emulated_hue

I can press "rebiuild" button on supervisor addon page, after about 20 minutes:
20-10-21 10:31:46 ERROR (SyncWorker_1) [supervisor.docker] Image 62c7908d/armv7-addon-emulated_hue not exists for addon_62c7908d_emulated_hue
20-10-21 10:34:29 INFO (SyncWorker_2) [supervisor.docker.interface] Removeing image 62c7908d/armv7-addon-emulated_hue with latest and None
20-10-21 10:34:29 INFO (SyncWorker_6) [supervisor.docker.addon] Starting build for 62c7908d/armv7-addon-emulated_hue:0.0.4
20-10-21 11:06:25 ERROR (SyncWorker_6) [supervisor.docker.addon] Can't build 62c7908d/armv7-addon-emulated_hue:0.0.4: The command '/bin/sh -c apk add --no-cache --virtual .build-dependencies         build-base         cmake         libuv-dev         libffi-dev         python3-dev         openssl-dev         git     && apk add --no-cache         python3         openssl         supervisor     && mkdir /usr/local/app     && git clone https://github.com/marcelveldt/hass_emulated_hue.git     && pip3 install         --no-cache-dir         -r hass_emulated_hue/requirements.txt     && cp -R hass_emulated_hue/emulated_hue /usr/local/app/     && cp hass_emulated_hue/run.py /usr/local/app/run.py     && apk del --no-cache --purge .build-dependencies     && find /usr/local         \( -type d -a -name test -o -name tests -o -name '__pycache__' \)         -o \( -type f -a -name '*.pyc' -o -name '*.pyo' \)         -exec rm -rf '{}' +     && rm -f -r         /root/.cache         /root/.cmake         /tmp/*         hass_emulated_hue' returned a non-zero code: 1
20-10-21 11:06:25 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished name='Task-1517' coro=<AddonManager.rebuild() done, defined at /usr/src/supervisor/supervisor/addons/__init__.py:279> exception=AddonsError()>
Traceback (most recent call last):
  File "/usr/src/supervisor/supervisor/docker/addon.py", line 413, in _build
    image, log = self.sys_docker.images.build(
  File "/usr/local/lib/python3.8/site-packages/docker/models/images.py", line 287, in build
    raise BuildError(chunk['error'], result_stream)
docker.errors.BuildError: The command '/bin/sh -c apk add --no-cache --virtual .build-dependencies         build-base         cmake         libuv-dev         libffi-dev         python3-dev         openssl-dev         git     && apk add --no-cache         python3         openssl         supervisor     && mkdir /usr/local/app     && git clone https://github.com/marcelveldt/hass_emulated_hue.git     && pip3 install         --no-cache-dir         -r hass_emulated_hue/requirements.txt     && cp -R hass_emulated_hue/emulated_hue /usr/local/app/     && cp hass_emulated_hue/run.py /usr/local/app/run.py     && apk del --no-cache --purge .build-dependencies     && find /usr/local         \( -type d -a -name test -o -name tests -o -name '__pycache__' \)         -o \( -type f -a -name '*.pyc' -o -name '*.pyo' \)         -exec rm -rf '{}' +     && rm -f -r         /root/.cache         /root/.cmake         /tmp/*         hass_emulated_hue' returned a non-zero code: 1
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/usr/src/supervisor/supervisor/addons/__init__.py", line 303, in rebuild
    await addon.instance.install(addon.version)
  File "/usr/src/supervisor/supervisor/utils/__init__.py", line 32, in wrap_api
    return await method(api, *args, **kwargs)
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/supervisor/supervisor/docker/addon.py", line 400, in _install
    self._build(tag)
  File "/usr/src/supervisor/supervisor/docker/addon.py", line 424, in _build
    raise DockerError() from err
supervisor.exceptions.DockerError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/usr/src/supervisor/supervisor/addons/__init__.py", line 305, in rebuild
    raise AddonsError() from err
supervisor.exceptions.AddonsError

Also can't install on Raspberry Pi 3  running HassOS 4.16.
Install starts and then runs for about 10 mins before crashing HA.
Hard restart produces:
20-11-18 18:02:30 ERROR (SyncWorker_0) [supervisor.docker] Image 62c7908d/armv7-addon-emulated_hue not exists for addon_62c7908d_emulated_hue
20-11-18 18:02:30 WARNING (MainThread) [supervisor.addons] Can't start Add-on 62c7908d_emulated_hue
@marcelveldt let me know if I can help trouble shoot.

For now, the only thing to do is wait as I have to rewrite a part of the code and the docker deployment.
Currently finishing another big project and once that's done, I'll look into the Emulated Hue again.
So please be patient and I'll give an update when things are ready to test.

Any progress? I have the same moment. Complete hassio crash after i tried to install the hue emulator.

Hey guys,
maybe for some of you DiyHue will be a good alternative. Basically for me it was as it combines most hue devices and bridges into one single app. Even routines and hue entertainment is working.
For the easy use I wrote a Hassio addon. You can get it here:
https://github.com/MaxBec/diyHue-hassio

The intention of this addon is different than diyHue: bridge Home Assistant devices to a virtual Hue bridge where diyHue is a virtual bridge/hub on it's own.
My personal situation is that I like Home Assistant to be the hub/bridge for all IoT devices and have the Hue apps still working for things like Entertainment mode. Of course these requirements are personal so diyHue might be a very good fit for others. It's really feature complete while my work here is only covering the basic stuff and in early stage.
FYI: I've rebooted my work on this addon tody so expect some updates to happen this week.

This project looks great and looks to have pretty high quality code! I would be curious if the native API ESPHome provides has any sort of rate limits that would hinder its usage for entertainment mode without the throttling that you've implemented.

@alexyao2015 thanks!
The throttling should be abandoned or at least configurable per-light.
While I was testing with some lights connected to ZHA, the network got flooded by the entertainment messages (50 messages per-second) so I've put in some very basic throtttling.
I was testing with some ESPHome lights yesterday and they do not suffer of this same implementation so there's some hope. Alternative would be to implement UDP streaming to some popular platforms.
This is also true for the ZHA implementation in HomeAssistant, there's a good chance that the entertainment protocol (message for multiple lights packed into one message) can be implemented there, I already talked about that with the ZHA devs.

I second @alexyao2015 thoughts. The code in DiyHue is quite blown and chaotic. This looks like a good alternative (even when not in a general settings, but restricted to HassIo).

I've been a maintainer of diyhue for quite some time now and lately have been working on a refactor for it for the greater part of a year, only to have it kicked to the side. Looking around, it appears that this project does everything that I could have needed from diyhue.
With regards to UDP streaming, I've previously implemented UDP streaming for ESPHome as a custom component. I wonder if that would be possible to port here. Not too familiar with how this communicates with HA.
Does this properly support the hue api? I know with diyhue, there are quite a few inconsistencies with it that cause certain apps to not function. Are there any known bugs/issues? I'll have to give this a try myself!
Ps. Maybe look at creating an external chat platform or enabling GitHub's own discussions.

When I started working on this I created it as a drop-in replacement for the native emulated_hue component in Home Assistant, however that got me in trouble because of the need to bind to port 80 and 443 and the entertainment mode magic.  So I've converted it to be loosely coupled to Home Assistant over websockets which is also very low latency. I discussed this briefly with @balloob, the founder of Home Assistant and the idea is to bring it as an opt-in addon for Home Assistant for users that want the emulated Hue experience (including entertainment mode). At some point it might even replace the current built-in feature maybe. He also brought me in contact with the main dev of the ZHA component to explore if we can get the entertainment mode working with the ZHA implementation of Zigbee in Home Assistant (which would be super cool).
In the meanwhile I must say that this project got a bit lost in the freezer as I was helping out with the new Z-Wave implementation in HASS and switching jobs, Corona stuff etc.
But considered the interest in this project I'll pick it up again and great if I can get some help!
I'm sure with combined forces we can get this project flying at no-time.
BTW: I'm on discord, username marcelveldt

I don't have idea how to help you but this project is awesome! I need it an i can grateful you if you can make it work again! THANKS!

@marcelveldt
Hey again! Been a while as I've been busy with some other projects. Will definitely start to take a look at this project and see how it all works.

Version 0.0.6 has just been released which should fix the issue. It should now install fine on (almost) all hardware.
Please test with that and re-open if your issue is not yet fixed.
Thanks!


Fix host_callback when there are non-local devices.

In combination with a recent change in the outfeed_receiver in the XLA
repository:
https://github.com/tensorflow/tensorflow/commit/ed2134ae4327e1e09ed3808e748489405a845382
this allows host_callback to work correctly in a multi-host TPU setup.
In a multi-host TPU setup we have a situation where not all devices are
local.  However, it is only actually possible to obtain outfeed data
from local devices, in general. Prior to the XLA change linked above,
the presence of non-local devices would result in the outfeed_receiver
trying to obtain outfeed data for these, which would immediately error
(e.g. "Invalid argument: Device TPU_10(host=0,(1,1,0,0)) is not a local
device."). With the XLA change, this error no longer occurs, but there
is still a problem because host_callback currently assumes all devices
are listening for outfeed, rather than just the local ones - e.g.
barrier_wait would wait for more outfeeds that are actually obtainable,
in the multi-host case. This change fixes that issue and allows id_tap
and similar to work as expected.

Thank you for your contribution.

Thank you for your contribution.


changed version of haproxy

:nut_and_bolt: Description: What code changed, and why?
changed the version of core/haproxy to 2.2.29

:chains: Related Resources
https://chefio.atlassian.net/browse/CHEF-1755
:+1: Definition of Done
changed the version of core/haproxy to 2.2.29
:athletic_shoe: How to Build and Test the Change
rebuild components/automate-backend-haproxy/
:white_check_mark: Checklist
All PRs must tick these:

[ ] I have read the CONTRIBUTING document.
[ ] All commits signed-off for the Developer Certification of Origin.

With occasional exceptions, all PRs from Progress employees must tick these:

[ ] Is the code clear? (complicated code or lots of comments--subdivide and use well-named methods, meaningful variable names, etc.)
[ ] Consistency checked? (user notifications, user prompts, visual patterns, code patterns, variable names)
[ ] Repeated code blocks eliminated? (adapt and reuse existing components, blocks, functions, etc.)
[ ] Spelling, grammar, typos checked? (at a minimum use make spell in any component directory)
[ ] Code well-formatted? (indents, line breaks, etc. improve rather than hinder readability)

All PRs from Progress employees should tick these if appropriate:

[ ] Tests added/updated? (all new code needs new tests)
[ ] Docs added/updated? (all customer-facing changes)

Please add a note next to any checkbox above if you are NOT ticking it.
:camera: Screenshots, if applicable

Automate is using the upgraded package.


Feature Support create table with random distribution to avoid data skew

Proposed changes
Issue Number: close #8028
Problem Summary:
Describe the overview of changes.
Checklist(Required)

Does it affect the original behavior: (No)
Has unit tests been added: (Yes)
Has document been added or modified: (Yes)
Does it need to update dependencies: (No)
Are there any changes that cannot be rolled back: (No)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

LGTM

I have several questions and suggestions as follows:

this feature is directly user-oriented, we need to have more detailed documentation to explain how to use this feature, applicable scenarios, etc. Otherwise, it is difficult for other users to understand the meaning of Random and single_tablet_load_per_sink.

It is recommended NOT to use those RANDOM classes directly which has been deprecated before. We do not strictly check whether old versions of random tables still exist in the current version. Using it directly will cause metadata problems.

single_tablet_load_per_sink is too close to the specific implementation, suggest: load_to_single_tablet


Add proxy, register & pull packages from RedHat Satellite

Issue #, if available:
#2466, #2467, #2468
Description of changes:
Subscription module doesnt consume the proxy environment vars. This change make image-builder provide a specific proxy input for subscription module.
Change also adds support to register build vm against RedHat Satellite as opposed to reaching out to RedHat CDNs, and pull packages from the Satellite vs pulling from public repositories.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve

/lgtm
/approve


Add a VSCode Devcontainer

Added a vscode devcontainer to try to help mitigate any issues with dependency versioning and environments https://code.visualstudio.com/docs/devcontainers/containers

I should add, it still dosn't build :)

Oops, I didn't mean to break this, let's reopen it against main


wip repo cache

Change-Id: I83bd19e707382a7abfa720a834978902fa16de72

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (7bfe750) 97.22% compared to head (9f477cc) 97.22%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #20   +/-   ##
=======================================
  Coverage   97.22%   97.22%
=======================================
  Files           1        1
  Lines          36       36
  Branches        1        1
=======================================
  Hits           35       35
  Partials        1        1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Import-Excel Powershell Core 7.2.1 opening password protected workbooks exception

Import-Excel works fine for Windows PowerShell 5.1
Getting this when using PowerShell Core 7.2.10
MethodInvocationException: C:\Program Files\WindowsPowerShell\Modules\ImportExcel\7.8.5\Public\Import-Excel.ps1:124
Line |
124 |  …             if ($Password) { $ExcelPackage.Load($stream, $Password) }
|                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Exception calling "Load" with "2" argument(s): "Could not load type
| 'System.Security.Cryptography.RIPEMD160Managed' from assembly 'mscorlib, Version=<IP_ADDRESS>, Culture=neutral,
| PublicKeyToken=b77a5c561934e089'."

Yes, fails for me. Seems like a PowerShell issue.

I see a similar issue using Export-Excel with the -Password parameter in PowerShell 7. This works fine in PowerShell 5.1.

This issue seems to explain the cause, although I'm not sure what that means for a fix.

any news?

Is it still failing for you?

yes with Powershell 7 yes

As of date still failing with PowerShell version 7.4.6


server: informative listen error messages

was:
2019.05.14 17:29:47.986301 [ 1 ] {}  Application: I/O error: Permission denied
now:
2019.05.14 17:58:02.463681 [ 1 ] {}  Application: DB::Exception: Listen [::]:90 failed: 13: I/O error: Permission denied

Description for the changelog does not follow the form.


doc: change https://zephyrproject.org/doc refs

Remove extra indirection to documentation (and required
server link redirection) from https://zephyrproject.org/doc/...
to http://docs.zephyrproject.org/...
Signed-off-by: David B. Kinder<EMAIL_ADDRESS>

Codecov Report

Merging #7318 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #7318      +/-   ##
=========================================
- Coverage      55%     55%   -0.01%
=========================================
  Files         474     474
  Lines       51719   51719
  Branches     9935    9935
=========================================
- Hits        28447   28446       -1
- Misses      19310   19311       +1
  Partials     3962    3962

Impacted Files
Coverage Δ

lib/posix/pthread.c
69.34% <0%> (-0.51%)
:arrow_down:

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 dc97fc2...fca8a1f. Read the comment docs.


Updating CopyEnv checksum values and re-adding CopyEnv to repo-index.yml

Updated to the checksum values for the latest downloadable binaries. Re-added the plugin following the earlier deletion. Replaced the download URI with versioned paths.

I've just received the confirmation that my signed Corporate CLA was received. I'm closing, then re-opening this PR.

@vaughnh Thanks making a PR! It looks like there was some kind of bad search and replace - several plugins besides CopyEnv appear to have had their URLs changed as part of this PR (Brooklyn, stack changer, testuser) which, in turn, has broken the build.
Please fix the failing test(s) and we'll take another look.

Should be fixed.


fix value type: use interface{}

Change type of RawValue to fix https://github.com/Flagsmith/flagsmith-go-client/issues/59
Change type of MultivariateFeatureOptionModel.Value to support serialization of types other than string

@gagantrivedi how does this work from a user's point of view? How will they retrieve the value in the desired type?

@gagantrivedi how does this work from a user's point of view? How will they retrieve the value in the desired type?\

Exactly the way it works right now, we return interface{} for GetFeatureValue then the user can cast it to whatever value they like, e.g:
	buttonData, err := flags.GetFeatureValue("secret_button")

	// cast to string
	buttonData = buttonData.(string)


Merge from dev to main

Signed-off-by: Gary Shen<EMAIL_ADDRESS>

Need to use "Merge pull request" to keep the history.


How to enable the linter plugin?

Description of the problem or steps to reproduce

Have an open python file with horrible styling
Run lint
Nothing happens, but no 'unknown command' message

Specifications
Commit hash: 60846f5
OS: MacOS
Terminal: iTerm2

in settings.json: "linter": true
If you have that, but it's not working: do you have the Python linter installed? Micro uses linters installed on your system. I think by default it checks for pylint and mypy (it doesn't show an error if they're not installed, probably because the linter setting is across all languages). If you want to use a different linter, you may have to edit the plugin to add support for it.


Simplify import hooks

This PR avoids calling calculateUrbanDensity from importOSM and hides writeEncodingManagerToProperties.

Thanks, this looks good to me.


Dragging to scroll clears selection

On iOS (or other platforms with touch), the current selection is cleared on touch-up in SelectionContainer after dragging to scroll.
Affected platforms

iOS
(probably) Web when used with touch.

Versions

Compose Multiplatform version: 1.6.11

To Reproduce

Run the mpp demo on iOS.
In the SelectionContainer demo, in the scrollable text, select some text
Drag the scrollable. Note that on touch-up, the selection is cleared.

Expected behavior
Selection should not be cleared.
Screenshots
https://github.com/JetBrains/compose-multiplatform/assets/5230206/e41a45cc-0f42-480a-8420-5fb2230b99b0
Additional context
The selection is cleared by SelectionManager.Modifier.onClearSelectionRequested, because the scroll is not recognized as a drag, so basically it thinks it was a click (because the pointer didn't move relative to the element).

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Trusted producer should be configured via cfg and cli

Change Description

#6217
trusted-producer should be configurable via command line and configuration file.
Consensus Changes

N/A
API Changes

"trusted-producer" can now be set in the configuration file.
Documentation Additions

N/A

Should have been merged into release/1.4.x.


Enable AB testing for Levenshtein algorithm for suggestions

This PR allows us to use the Levenshtein algorithm for search
suggestions over the default Elasticsearch algorithm, which relies on
an "optimised" system that may not be too accurate for our purposes.
Trello card: https://trello.com/c/c2YUDVg3/1117-try-different-ways-of-doing-spelling-suggestions

Would one need to be removed before the other could be enabled?

Spoke to Andrew about this, as Shingles is turned off now we should be good to go, but for safety I'll remove the Shingles line before I merge.


Added Die Game

@bhaveshlohana This PR isn't getting counted for hacktober-fest, can u add the label


'meltano elt tap-spreadsheets-anywhere target-postgres' caused error log - requesting log clean up

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/2753
Originally created by @mindyng on 2021-05-13 22:41:26

ran  and error: "Executable 'target-postgres' could not be found." popped up when loader already installed

View 7 previous comments from the original issue on GitLab


Updates to Sparse MVMs

Hi, I cleaned up the interface (now the tensor / size shenanigans in the init are okay) and think I found a way forward for batch - batch MVMs.
Only a little progress on the unit tests but some are failing now due to what looks like precision so might be easy fixes.
Lmk what you think!

Thanks a lot for sending the notification here. Apperently, I've missed this update from you in the past.
Meanwhile, I was working on my own batch version while sticking to torch.sparse.mm operation. Please allow me sometime to revert back on this after comprehending your push and my recent developments.

No worries, while this is pretty low priority for me at the moment, I may have a bit of time Friday / this weekend to take another pass to try to figure out what's going on with these unit tests.

The updated commit gets down to 6/35 test failures by implementing batched sparse MVMs (still a couple of kinks in the failures).


Additional planned changes

$data can no longer be used as a prop. Replacing the component's default data is not a good pattern.

Deprecate inherit: true. This option was originally used for internal mechanisms, but in 1.0 this is no longer needed internally. As an API, when over-used it can lead to subtle bugs and make the state of components harder to understand.

Deprecate v-el. Prefer using querySelector. In 1.0.0 there may be a new method for querying the DOM, because 1. sugar 2. standard interface for normal and fragment instances.

Looking forward for v-for!
:+1: for other breaking changes.

I like them all except worried about killing off inherit: true. I agree it is not be a good pattern in general but sometimes it is useful and the easiest way to handle complex interactions/data passing in tightly coupled components.

@davidkhess I've yet to come across a situation where inherit: true is absolutely needed to make it work. Sure it can make some things "easy", but not necessarily in a good way.

I see it like the convenience of the JavaScript closure. It has visibility to everything in every parent scope when you create it but you typically only capture a couple of vars in practice.
Overuse of closures would be bad style. But they certainly come in handy in some patterns where code is tightly coupled.

@davidkhess I know it's like lexical scoping, however the difference is that in JavaScript all your functions need to be written together to get lexical scoping, so it's fairly clear to understand when you look at the file. But components are by definition a unit of isolation, and often separated in different files; how they are used together is defined in the template of the parent component. When you look at a child component with inherit:true, you can't easily reason about the context it is being used in. To make  inherit: true components maintainable, we have to rely on self discipline - i.e. only use it when you need to - but that's exactly what I want to move away from in 1.0. I want the system to be maintainable-by-default.

When I use inherit: true (which is rarely), I only do it when I have components declared within another component in the same .js file. That way, I can visually see the nesting and the implications of it – much like you can with a javascript closure.
I'm mainly playing devil's advocate – I could live without it. It is just that over the years, I've been burned a couple of times by decisions to overly restrict a system behavior and to be later forced to go back and open it back up.
I'm personally comfortable with your position as I've not got enough Vue-years under my belt yet to take a strong stance against it.

I have a base component (widget) that I'm extending with multiple variations of it (text widget, image widget etc) and use component is to select the correct widget. How do I pass props for all the different widgets that would need different props? This is currently the only place I use extend, and worries me.

I've found that using Vue.extend and mixins are usually a better way to do "subclassing" rather than nested components.

Would removing v-el and using querySelector lead to get a wrong element? For example, would the query result is .a.b? Because I am using many v-el in my components' mixins to apply some behaviors...
<template id="comp">
<content></content>

</template>

<comp>

</comp>

@TerenceZ I'm not sure if I understood your original usage. And how would the query API solve that for you?

@yyx990803 I'm sorry I haven't describe the issue clearly. The problem is how to select the element declared in the template, not including the transcluded elements. For example,
<template id="comp">
<content></content>

</template>

<comp>

</comp>

Here I want to select the element .a, not the element .a.b. Using v-el I can be easy the locate the .a, but if using querySelector, it will get the result .a.b.
The reason for ignoring that comment is that I assume this problem can be resolved the new query API provided by vue .


[FEATURE] Improvement in readme.md

⭐ Suggestion
readme.md need some contributing guidelines on how to start with it i can do this if you assign this issue to me
Thanks
💻 Use Cases
No response
❌ Related Problems
No response

Can I work on this?

i asked for this first so it should be given to me @Vishrut-Arora  you can see some other issue

i asked for this first so it should be given to me @Vishrut-Arora you can see some other issue

No problem :)

It's good that you've mutually decided who will be getting the assignment 😄
Also @shreyaansjain06, I am closing this issue as of now because there's already an issue related to the README file
Please do refer to #27


Text bound to sprite coordinates redraws much later than the sprite

This Issue is about a problem with my own code
The text attached to the sprite coordinates is being drawn mach later than the sprite. What's the problem?
The code in the sandbox
To make sprite to move we should hold left mouse button. We see that the text moves asynchronously to the sprite like it redraws some time after that.
The used technique was taken from here, but I could see no issue there while sprite is being moved.

Can you put it in https://codepen.io/pen?template=pRGPKG instead? Sandbox can't run ES6 classes.

@samme
Hello,
Here you are https://codepen.io/anon/pen/YrXNBG

@amorphine
To move graphical objects synchronously you can add them as children:
https://codepen.io/anon/pen/ZXGojY
So this probably have nothing to do with render.

Only CodePen transpiles ES6.
Please see the preRender method in https://codepen.io/samme/pen/EwjMbG.
For this case a child sprite would also work well.


Helidon Arquillian module should only depend on MP core

Description
Issue https://github.com/helidon-io/helidon/issues/6005
Documentation
None

I have updated helidon-arquillian to not require metrics in every TCK


Add data migration to remove completed cases from action

Motivation and Context

This data migration can be used to remove cases that are complete but have not been removed from the action service. This should stop people getting reminders they shouldn't when another respondent for that business has responded.
What has changed

How to test?

Links

Since the actual table updates we're doing are in action I think the scripts should sit there rather than in case


change yScale to logarithmic scale

I would change the y-scale of my discreteBarChart to avoid huge gap (here is the Plunker). On the main page of AngularJS nvd3 I saw the attribute yScale, and in several examples is set to
yScale: function i(n){return o(n)}
I don't know what means and what the function o() does. I tried to change this function with d3.scale.log but it doesn't work. Any suggestion?

Searching for the answer to this too.

@krispo still no answer?

+1

Check #406 .. that helped me.


Standardization / OpenAPI 3

Hi! I like what you are doing here!
Unfortunately, I think the complexity will grow exponentially if you want to support different UIs with different parameters.
Would it make sense to come up with & propose an API specification for sd-backends? this can them be implemented by the different repos and this UI will work out of the box.

That would be awesome but would be really hard to pull off in practice with the number of innovations taking place at different places. You'll need to synchronize all the different forks to add a feature and I don't see it happening.
What would help a lot is if each backend would try to keep their own api somewhat stable:

not changing the gradio function_id
only adding new inputs at the end of the input list and allow them to be null if the feature is not required

That way is a feature is added, it won't impact the existing frontends.


Installing code on Big Sur doesn't seem to do anything

❯ curl -sL https://github.com/karimra/gnmic/raw/master/install.sh | sudo bash
Downloading https://github.com/karimra/gnmic/releases/download/v0.4.3/gnmic_0.4.3_darwin_x86_64.tar.gz
Preparing to install gnmic 0.4.3 into /usr/local/bin
gnmic installed into /usr/local/bin/gnmic
bash: line 173:  6287 Killed: 9               $GNMIC_INSTALL_DIR/$BINARY_NAME version
When I run the command I always get this..
[1]    6356 killed     gnmic
╭─ ~/Downloads/junos-qfx ▓▒░································································································░▒▓ KILL ✘  at 23:44:31 
╰─

Hi,
gnmic was not tested on Big Sur yet.
Is the system Intel-based or Apple Silicon ?

Hi @flyerhawk
we seemed to have found the reason for this in one of the compression utilities we use to shrink gnmic size
We will have a fix for this in the next version
For now, you can clone the project and build it locally

can you give it a try with the last release? v0.5.0

That seems to have fixed the issue!  Thanks!   FTR, I am using an intel based iMac.

thanks for reporting the issue. Glad it's been an easy fix =)


Fix PMT overlap in IWCD geom

Properly set WCCapEdgeLimit such that cap PMT will not overlap with edge volume.
Also change WCPMTODPercentCoverage to keep the same number of OD PMT.

Thanks for this @kmtsui It's certainly fixed the "Optical photon is killed because of missing refractive index" issues
Before I merge, just want to confirm that you're happy with the number of PMT change
< Type 1 ID PMT number & size       7980    4.00
---
> Type 1 ID PMT number & size       7676    4.00
4c4
< OD PMT number & size               364   40.00
---
> OD PMT number & size               404   40.00


WaitForAllComputation waits for work queue

This is the minimal fraction of #729 (@ojura) to make the integration test #751 non-flaky (where a check fails in PoseGraph deletion).

@wally-the-cartographer merge

Merge requested by authorized user gaschler. Merge queue now has a length of 3.


An error when compiling the project

Hey guys, I got an error when tried to compile the program. It looks like a problem that the project cannot find the lib file, but I tried many ways still not working.

My Ubuntu version is 16.04
Quartus and Open CL SDK for FPGA  is 18.1
OpenCV is 2.x.
Does anyone can give me any suggestions？ Thank you for your help.

Do you solved the problem?

It seems you are building for ARM processor, make sure you have correct cross-compiling env set up .

It seems you are building for ARM processor, make sure you have correct cross-compiling env set up .

How to check cross-compliling env setup? Tks for your answer!


name and website changes

changed name and website from KysenPool to Ugaenn.

Please remove text element from the logo.

The new landing page has an entry for Songbird but features the Flare logo, please adjust. Also provide an explanation as to why KysenPool FTSO rebrands to Ugaenn. You may provide additional details to our company email at towolabs.com.

The new landing page has an entry for Songbird but features the Flare logo, please adjust. Also provide an explanation as to why KysenPool FTSO rebrands to Ugaenn. You may provide additional details to our company email at towolabs.com.

Email sent.
And thanks for catching the logo!  Fixed now.


update to 4.1.3

Checklist

[X] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[X] Reset the build number to 0 (if the version changed)
[X] Re-rendered with the latest conda-smithy
[ ] Ensured the license file is being packaged.

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

@conda-forge-admin please rerender


Dnn9 issues

Hotcakes does noet work with dnn9 personabar. How to fix this issue?

Hello @kurtwilbies
Thanks for asking.  Unfortunately, DNN 9 features aren't compatible with Hotcakes 3.0.  There isn't really anything to fix.  However, if someone would like to create a pull request to port the persona bar features into Hotcakes, we'd definitely be interested in talking about that.

Hello @hismightiness
It is not necessary to let dnn9 feature be compatible with hotcakes. The only thing is that I only use the personabar and not the old dnn-8 menu. Its not one od the other. They can co-existin one install. Is this true?

DNN 9 has been Improved in Performance and UI,
Let Talk about Problems of HCC 3 and DNN9 issues and solve them.


Spike: Different order of the action subcategories

Describe the bug
In expert mode for the spike system, the subcategories "Move" and "Drive" are arranged in a different order than in EV3/NXT/Edision/Thymio/etc..
To Reproduce
Steps to reproduce the behavior:

Go to 'Expert mode'
Click on 'Action'
See different order

Expected behavior

Same order as the other robot systems
Screenshots

Device information

Type Laptop/etc.
OS: Windows/etc.
Browser Chrome/etc.

@AHberta , the order is indeed different, but I think better than before, because drive blocks are much easier to use than single motors, also the drive blocks are first in the beginner toolbox.
We should have an issue for the other systems with the old order to change


MacOS reseting zoom on start

I have a MacBook Air M1, and every time I launch the app, it starts zoomed in. I need to zoom out every time I start the app again. It look like this:

After the zoom out:

Is there any configuration I need to do? I don't want to zoom out every single time I reopen the app.

Settings -> Plugins -> Scale

By the way how is your M1 display configured? What resolution, scale factor?

I like the native settings and I like to use my Mac without other displays, that's why I barely changed any display config. Even so, my resolution is 2560 x 1600 with a 16:10 ratio.

Had the same issue which was fixed by setting scale to 100%. However status bar's first message still has a wrong scale. Subsequent messages are ok. My resolution is set to 1680x1050 (16:10). No external monitors attached.
@jgmdev thank you for your work and time

However status bar's first message still has a wrong scale.

Fixed that one on #103

This one is tricky tbh... so I have a MBP M3 Pro 16" and this is what auto-detect looks like:

So fonts and other distances somehow don't fit together
Now this is with the default setting of MacOS, so it's traditional 2x retina from native resolution of 3456 × 2234

When I go to 200% zoom which should be "correct", it remains ugly:

When I attach an external monitor at work which is non-retina / HiDPI and move the window there it looks just as it should at 200%:

Although it's at native resolution and should thus be more correct at 100% but hey...

Long story short: works great on the external screen but somehow not on the local. I will retry after a reboot without any monitors attached maybe it's different at first...

Can you test if there is a different behavior building from source with the SDL hardware renderer backend disabled by editing:
meson.build
- if get_option('renderer') or host_machine.system() == 'darwin'
+ if get_option('renderer')

then build with something like:
meson setup --wrap-mode=forcefallback -Dppm=false -Drenderer=false build
meson compile -C build

and finally run it to test with:
./scripts/run-local -global build

This could help determine if a recently added change that performs internal font scaling with renderer is causing the issue.

 I do have the binary on build/src/pragtical but that then doesn't find it's start.lua

That one can be fixed by installing the realpath command provided by brew, If I recall correctly it was brew install coreutils

BUT it's no longer usable, the mouse is not detected where it actually is -- see the highlight in the following screenshot in which the mouse is actually on the configuration icon way below...but it thinks it's on the meson.build file

You actually discovered some regressions on scaling code which I didn't notice after merging newer font loading/caching mechanism. This should serve me as a reminder of how important is to test different scalings after adding code that touches the rendering engine.
Could you give #134 a try and report how it behaves with those changes?
You can download https://patch-diff.githubusercontent.com/raw/pragtical/pragtical/pull/134.diff to your local pragtical git directory and run:
git apply 134.diff

Then recompile and run, just don't forget to git restore meson.build or turn the renderer on with meson configure -Drenderer=true build before meson compile -C build
I tested on my linux machine with wayland and fractional scaling and it seems better, sadly my Mac Book Air doesn't has a retina display, so not sure how it will behave with that :(

Hej; now it's working; I'd still say that font size vs. space around it is not perfect and it starts too big.
Immediately after starting with only internal (retina) screen it starts huge, so autodetect seems to be thinking 200%:

After setting to 100% it becomes very useable (as can be seen in proportion to title bar etc...)

Regarding realpath - I did have it installed, so really it didn't find stuff; I'm now always installing into a prefix defined beforehand and then running from there with bin/pragtical but that works.

Ok, made another set of changes on #134:

Disabled the "hardware renderer" by default for macOS because the fonts on scales >=2 seems to be off (which looks ugly) with latest glyph loading optimizations (this needs to be properly inspected later to find where the calculations are off, tested lite-xl master at 2x scale and it exhibits the same issue)
Improved scale autodetection handling on the default software renderer, also improved it for the "hardware renderer" (it will now respect the internal scaling so it shouldn't start with a huge font size :smile:).
Fixed emptyview icon initialization not in place when starting with non default scale
Various improvements to scale plugin for better behavior and respecting of PRAGTICAL_SCALE environment variable. Also changed the settings a bit but, now I have to fix the numberbox widget to release clicks on scale changes :roll_eyes:

I tested locally on Linux/Wayland with fractional scaling and integral 2x scaling but now we need the macOS retina test :pleading_face:

Ok, I'll do my test on master :-)

Hej just built on master completely fresh and into an empty dir, so it's autoconfig all the way through.
meson setup --buildtype=release --wrap-mode=forcefallback -Dppm=false --prefix ~/tmp/prag build
meson compile -C build
meson install -C build
cd ~/tmp/prag
bin/pragtical

And it's just spot-on:

And here's the hardcore test

I started pragtical on the retina laptop screen -> ok (see Screenshot)
Moved it to the exteral non retina -> ok, also stable on resizing
Moved back to retina -> got supersmall

But that's really nitpicky, I don't know if you even have control around that. But font rendering and everything is just nicely centered, etc...

And it's just spot-on:

Wohoo! :partying_face: that means we can now run on software renderer on macOS which is faster than the half baked hacky "hardware renderer" which was not really hardware rendering since it is still doing software rendering and performing an extra copy of final re-scaled output surface (which needed recalculating all rects) into a texture. With the mechanism we are using now the editor is performing the scale once for us each time the scale changes on the displaychanged event, the only drawback would be if you have the editor open and change current display scale to a different one, the editor will not detect that :cry:

Moved back to retina -> got supersmall

Hope my assumptions are right and #143 fixes that one. If it does we should be on a pretty good state for a bug fix release :D, when you have the time please test it and let me know.

Sorry for not much feedback - I can do a Retina + 4K test anyday, Office currently closed for some construction work so I can really only retest in the funky MBP Retina + normal resolution external around Tuesday...

Understandable, I hope v3.4.4 should be now on a better state. I tested on Gnome Wayland/X11 at 2X scale (switching back and forward between 1X - 2X while pragtical was open), also KDE and  Wayfire + XFCE with fractional scaling. Just tested windows and discovered that needed these changes #158 to prevent OS autoscaling (which brings blurriness). Haven't tested on 4k display or second display with different scale, have the equipment to test but been lazy to move stuff around...
Hopefuly the retina test from your side goes well!


Integrate the docs repo against the main lyraproj.io site

I'm going to add a link to the documentation from lyraproj.io for now while I figure out how to get the sidebar to behave properly.


Feature: Install individual package files

Description
Install individual package files. On FreeBSD, they would be .pkg . On Debian, they are .deb, etc.
Additional information
Provide a way to let the user specify the location of the package file(s). If more than one package file needs to be specified, use a list.

To get some idea of implementation. Let me run and example by you and get your feedback.
Suppose we are talking a Debian system. We want to insteall a .deb file. With comtrya's package provider interface/system, do you see this as a package.install that specifies a provider of dpkg. So the action in a manifest would look something like this:
- action: package.install
  name: some-deb.deb
  provider: dpkg

And it will translate into running the command sudo dpkg -i some-deb.deb

do you see this as a package.install that specifies a provider of dpkg

That should be optional.

Or do you see this as adding an option to specify a file and using apt.

Two ways:

If they specify a file path, file would be assumed as true and be optional. If only a file name is provided, it might help differentiate between a package with a .deb suffix in rarest of cases were a .deb with that exact file name exists, and a package with that name exists in the package repo.

file: true is required . I like the verbosity file: true, but I don't think it makes sense to be required if a full file path is specified in name.

There is an initial PR. It just covers FreeBSD if you want to test it out and right now for the file property for the package install action to be set to true. I figure this is a good place to start and to give you something to test out.

Thanks again @martintc !

Thanks again @martintc !

No problem at all

I think this does it at least so far for this. Feel free to re-open if not.


Bluetooth: Mesh: Rework publication timer

Periodic publication would previously build and send the first
publication inside the bt_mesh_model_pub() function, before cancelling
and rescheduling the next publication. The timer handler would only
handle retransmissions, and would abandon the rest of the publication
event if one of the packets failed to send.
This design has three issues:

If the initial timer cancel fails, the publication would interfer with
the periodic publication management, which might skip an event or
send too many packets.
If any of the messages fail to publish, the full publication event
would be abandoned. This is not predictable or expected from the API.
bt_mesh_model_pub() required 384 bytes of stack to build the message,
which has to be factored into all calling threads.

This patch moves all transmission into the publication timer by
replacing k_work_cancel with a single k_work_reschedule(K_NO_WAIT). It
also changes the error recovery behavior to attempt to finish the full
publication event even if some of the transmissions fail.
Split out from #33782.
Signed-off-by: Trond Einar Snekvik<EMAIL_ADDRESS>

What about the TBDs? Is is still to be decided?

What about the TBDs? Is is still to be decided?

Yes, there's a problem there.  I'm looking at it to see how it can be clearly described and potential solutions.

Looks like I missed that TBD, sorry about that. This mod_commit function is only called as part of the settings load procedure, and I think it's fair to use schedule with that.

Edit: Sorry, just realized I missed the changes in config server and main. Will review.

@trond-snekvik here are my notes on that:
There appear to be data races with the publish state in bt_mesh_model_pub, specifically but maybe not exclusively the count bitfield and period_start field.
In mesh/access.c:

bt_mesh_model_publish sets count and other fields and reschedules the work item
[WQ] mod_publish runs on the work queue and invokes pub_period_start, publish_transmit, and pub_period_sent
[WQ] publish_transmit invokes bt_mesh_trans_send with callbacks that invoke publish_start and publish_sent.  (Are the callbacks invoked by the calling (WQ) thread?)
[WQ] pub_period_start sets count, invokes an update function(?), then sets more properties and invokes publish_sent
publish_sent reads count and schedules the work
publish_start invokes publish_sent, reads count, and updates period_start

In mesh/main.c:

model_suspend clears count and cancels the work

It's the TBD in mesh/main.c that caught my attention: AFAICT the work handler does check whether count is non-zero; but if it is zero (as will happen if the cancellation after setting count to zero fails) what might happen is the work item starts a new publish cycle.
If the publish_{start,sent} callbacks are only invoked (indirectly) by the work queue thread, then the potential races on an SMP system are:

bt_mesh_model_publish from access
model_suspend from main
the work queue thread

I'm not sure whether there are races in a single-processor with non-preemptive threads.  There could be if any of the operations invoked by mod_publish sleep, because in that situation the cancellation could fail.

@pabigot thanks for the thorough notes.

[WQ] publish_transmit invokes bt_mesh_trans_send with callbacks that invoke publish_start and publish_sent. (Are the callbacks invoked by the calling (WQ) thread?)

To answer your question - the callbacks are either called from the cooperative advertising thread (adv_legacy.c), from a work handler, or inline in the bt_mesh_trans_send() call.
I have reviewed the TBDs in main and cfg_srv, and added a check for disabled and suspended publication in the work handler to catch any cancellation failures.
You're right about the count variable, it's going to have a race condition if we call publish() from a preemptive thread, but this is far from the only SMP issue in the mesh stack. In fact, the entire Bluetooth stack is full of SMP and preemptive scheduling issues, and calling any Bluetooth API from a preemptive thread is effectively undefined behavior. Changing this would be more work than we'd be able to do for 2.6, and I'd rather prioritize the stuff we know we can fix.
Now, for the cooperative scheduling case:
If any of the cancel calls fail, we may wait for the work item to fire (and return early) before the publication state comes to rest. In the config server, I believe this is unproblematic, as the on-air interface cannot guarantee atomic control anyway.
The bt_mesh_suspend() and bt_mesh_reset() calls are a bit more questionable. In both cases, we can guarantee that the stack won't be sending anything after the calls finish, but I we can't guarantee that the work items are idle. As far as I can tell, there's no way to get any invalid behavior because of this, but it's not ideal. I don't think this is fully resolvable, as we have to make these APIs callable from the system work queue. The user can call k_work_flush outside of the stack to get around this, if necessary.


[sw/silicon_creator] Add unit tests for sw/device/silicon_creator/otbn_util

Adds unit tests for the four functions in sw/device/silicon_creator/otbn_util.
Since this file mostly just calls sw/device/silicon_creator/lib/drivers/otbn.c functions, these tests are heavily based on theirs.

Thanks all! Updated with style changes.

It would also be nice to have a test that ensures loading or executing an app fails if OTBN is not idle

I've changed OtbnLoadAppSuccess to ensure it waits for OTBN to be idle before starting, but haven't added tests to check that each idle check throughout is handled correctly.
+ // `otbn_busy_wait_for_done` - begin with busy to ensure we wait until idle.
+ EXPECT_ABS_READ32(base_ + OTBN_STATUS_REG_OFFSET, kOtbnStatusBusyExecute);
+ EXPECT_ABS_READ32(base_ + OTBN_STATUS_REG_OFFSET, kOtbnStatusBusySecWipeDmem);
+ // Read twice for hardening.
+ EXPECT_ABS_READ32(base_ + OTBN_STATUS_REG_OFFSET, kOtbnStatusIdle);
+ EXPECT_ABS_READ32(base_ + OTBN_STATUS_REG_OFFSET, kOtbnStatusIdle);

Also noticed I had tested otbn_execute by mistake instead of otbn_execute_app. Updated to use the right function and also added two cases:

OtbnExecuteBusy to test OTBN not being idle after execution finishes is handled.
OtbnExecuteNotLoaded to test otbn_execute_app being called before an otbn_load_app.

I can't find where otbn_execute_app checks for idle before sending the execute command, does it only check after?

I can't find where otbn_execute_app checks for idle before sending the execute command, does it only check after?

You're right -- looking at the code, I remember that we decided since ROM only loads one program, it's OK to just check for idle when loading the app and then check afterwards, so otbn_execute_app doesn't have a separate check.


Country and payment

China, WeChat Pay.

Hi @channingbox
I'm supporting the core and the basic features of Cezerin.
As a freelancer, I can develop any feature for the customer.

Just do a survey, main payment methods in different countries @


add language

in settings.py add two language , but in djangocms admin toolbar have one language "english"
i want default language ='fa'
(note: fa_IR)
LANGUAGE_CODE = 'fa'

LANGUAGES = [
    ("fa", _("Persian")),
    ("en", _("English")),
    # Add additional languages here
]

CMS_LANGUAGES = {
    1: [
        {
            'code': 'fa',
            'name': _('Persian'),
            'fallbacks': ['en'],
            'public': True,
            'hide_untranslated': False,
            'redirect_on_fallback': True,
        },
        {
            'code': 'en',
            'name': _('English'),
            'fallbacks': ['fa'],
            'public': True,
            'hide_untranslated': False,
            'redirect_on_fallback': True,
        },
    ],
    'default': {
        'fallbacks': ['en', 'fa'],
        'redirect_on_fallback': True,
        'public': True,
        'hide_untranslated': False,
    },
}

why not return 'fa' language ?
#My project in :
python 3.10
django 4.2.9
djangocms 4.1.0

@pooria-ghorbani I assume you are referring to the language the toolbar (i.e. menubar) itself is shown. I'm not totally sure to what extend it is translated into Persian.
A user can change their language in "User settings...". Once they've done it, it will stick, even if you change the settings.
For new users, however, the default language should be shown (if their browser does not explicitly request a different language). Can you please check what happens to the toolbar language if you create a new user (with staff status)?
Finaly thought (though I have not tested this): What happens if you swap en and fa in the default fallbacks setting?
I would love to improve support for the Persian language. Please let me know if you would be interested in adding some translations. That would be a great contribution to this community-driven project!

#7840 indicates that some translations may have gone lost in the release process. Can you try ./manage.py compilemessages to ensure that the existing translations are used by Django?

@pooria-ghorbani Is this still an issue for you or have you found a way to fix this issue? Please let us know so we can close the ticket.


Fix directives that have 0 arguments when lexing apache configs

When parsing Apache Configuration files, a Directive that has 0 arguments, e.g. the Example Directive, causes the next observed directive to lex to a Token.Text instead of a Token.Name.Builtin.
Some examples:
'Example\nServerName localhost' yields:
(Token.Name.Builtin, 'Example'),
(Token.Text, '\n'),
(Token.Text, 'ServerName'),
(Token.Text, ' '),
(Token.Text, 'localhost'),
(Token.Text, '')
(Token.Text, '\n')

Similarly this affects other elements as well, e.g. Comments,
'Example\n# Comment' yields:
(Token.Name.Builtin, 'Example'),
(Token.Text, '\n'),
(Token.Text, '#'),
(Token.Text, ' '),
(Token.Text, 'Comment'),
(Token.Text, '')
(Token.Text, '\n')

The proposed changes modify this behavior to present more accurate representation of the data.
'Example\nServerName localhost' yields:
(Token.Name.Builtin, 'Example'),
(Token.Text, ''),
(Token.Text, '\n'),
(Token.Name.Builtin, 'ServerName'),
(Token.Text, ' '),
(Token.Text, 'localhost'),
(Token.Text, ''),
(Token.Text, '\n')

And this time I was able to understand/include a unit tests as well.
Happy lexing :)

Nice catch, thanks!


[Spark] Change Scala version to match Spark 3.4

Which Delta project/connector is this regarding?

[X] Spark
[ ] Standalone
[ ] Flink
[ ] Kernel
[ ] Other (fill in here)

Description
Matches Scala version of Spark 3.4: https://github.com/apache/spark/blob/59fcecb5a59df54ecb3c675d4f3722fc72c1466e/pom.xml#L171
https://github.com/scala/scala/releases/tag/v2.12.16
https://github.com/scala/scala/releases/tag/v2.12.17
https://github.com/scala/scala/releases/tag/v2.13.6
https://github.com/scala/scala/releases/tag/v2.13.7
https://github.com/scala/scala/releases/tag/v2.13.8
Fix #1909
How was this patch tested?
Does this PR introduce any user-facing changes?
Changes Scala version, which should be compatible:
"As usual for our minor releases, Scala 2.12.17 is binary-compatible with the whole Scala 2.12 series."
"As usual for our minor releases, Scala 2.13.8 is binary-compatible with the whole Scala 2.13 series."

@allisonport-db, could you please review this?

Sorry, @felipepessoto could you fix the conflicts?

Sorry, @felipepessoto could you fix the conflicts?

Yes, done. Thanks

Can you update the connectors_test.yaml and kernel_test.yaml?

Done. Also updated some new comments added in recent commits

https://github.com/delta-io/delta/blob/011bda5b573cd3fe90975034fc578b793b941e54/connectors/build.sbt#L35-L38
and https://github.com/delta-io/delta/blob/master/connectors/examples/build.sbt
Has multiple references to Scala 2.12.8, which doesn't even match the current version in https://github.com/delta-io/delta/blob/master/build.sbt. Should we change to 2.12.17?

@allisonport-db could you review it again?

@allisonport-db I rebased it to resolve conflict, connectors/build.sbt doesn't exist anymore

Sorry @felipepessoto could you rebase one more time :)

@allisonport-db done

@allisonport-db testing are passing, could you check again please?

ping @allisonport-db. Do you plan to merge it soon? These build files constantly change and can cause new conflicts

@allisonport-db gentle ping


feat: Add SlashApplicationCommand.get_mention

Summary
Add SlashApplicationCommand.get_mention for getting the string that allows you to mention the application command
Usage:
@bot.slash_command()
async def cmd1(interaction: Interaction):
    await interaction.send(f"{interaction.application_command.get_mention()} {cmd1.get_mention()}")

@bot.slash_command(guild_ids=[TESTING_GUILD_ID])
async def cmd2(interaction: Interaction):
    guild = interaction.guild
    await interaction.send(f"{interaction.application_command.get_mention(guild)} {cmd2.get_mention(guild)}")

@bot.slash_command()
async def group(interaction: Interaction):
    ...

@group.subcommand()
async def sub1(interaction: Interaction):
    await interaction.send(
        f"{interaction.application_command.get_mention()} {sub1.get_mention()}"
    )

@group.subcommand()
async def sub2(interaction: Interaction):
    ...

@sub2.subcommand()
async def subsub1(interaction: Interaction):
    await interaction.send(
        f"{interaction.application_command.get_mention()} {subsub1.get_mention()}"
    )

Checklist

[x] If code changes were made then they have been tested.

[x] I have updated the documentation to reflect the changes.
[x] I have run task pyright and fixed the relevant issues.

[ ] This PR fixes an issue.
[x] This PR adds something new (e.g. new method or parameters).
[ ] This PR is a breaking change (e.g. methods or parameters removed/renamed)
[ ] This PR is not a code change (e.g. documentation, README, ...)

Does this add support for sub command mentions?

It does now