build: slice bounds out of range in test

go version devel +387d5b8 Sat Feb 13 17:33:22 2016 +0000 windows/amd64
It builds fine, but I got an error during test.
`##### Testing packages.
. . .
ok      math/cmplx      0.609s
ok      math/rand       0.350s
ok      mime    2.359s
ok      mime/multipart  5.000s
ok      mime/quotedprintable    2.704s
panic: runtime error: slice bounds out of range
goroutine 14 [running]:
syscall.createEnvBlock(0xc082043400, 0x55, 0x68, 0xc082a0a1f0)
C:/go/src/syscall/exec_windows.go:115 +0x5b3
syscall.StartProcess(0xc082365180, 0x4c, 0xc0829e5aa0, 0x3, 0x3,
0xc082c136d0, 0x0, 0x0, 0x0, 0x0)
C:/go/src/syscall/exec_windows.go:326 +0x8b1
os.startProcess(0xc082365180, 0x4c, 0xc0829e5aa0, 0x3, 0x3, 0xc082c13928,
0x9d2e20, 0x0, 0x0)
C:/go/src/os/exec_posix.go:45 +0x345
os.StartProcess(0xc082365180, 0x4c, 0xc0829e5aa0, 0x3, 0x3, 0xc082c13928,
0x0, 0x0, 0x0)
C:/go/src/os/doc.go:28 +0x70
os/exec.(*Cmd).Start(0xc082cd8b40, 0x0, 0x0)
C:/go/src/os/exec/exec.go:332 +0x87e
main.(*builder).runTest(0xc0820eefc0, 0xc0829765b0, 0x0, 0x0)
C:/go/src/cmd/go/test.go:1107 +0xa2b
main.(*builder).do.func1(0xc0829765b0)
C:/go/src/cmd/go/build.go:1257 +0x3b9
main.(*builder).do.func2(0xc082abe710, 0xc0820eefc0, 0xc082740ea0)
C:/go/src/cmd/go/build.go:1314 +0x15d
created by main.(*builder).do
C:/go/src/cmd/go/build.go:1320 +0x3a5
2016/02/15 15:59:10 Failed: exit status 2
`
It happened only once. I tried to reproduce, to no avail. Next build was fine

There should have been a bit more to the output that you did not include.  Which package's tests failed?

This is the full output from my terminal session:
goIssue14377.txt
panic is at line 407.
When I saw the error I opened vi to see the offending source line.
Right after, I inspected my environment variables then I tried to find a script to run tests only. Couldn't find.
Then I tried to build again (by running all.bat) and this time build & test succeeded.

Thanks for the full log.
I think I see an unlikely race condition.  In cmd/go, each test sets cmd.Env to the result of envForDir(cmd.Dir,envForDir(cmd.Dir, origEnv).  The envForDir function calls mergeEnvLists, which appends to its second argument.  Multiple tests are run in parallel.  This means that there is a race condition changing the environment used to run the tests.  On Windows, the environment is converted into a block of NUL-terminated strings by looping over the environment slice twice.  A very precisely timed race could cause the environment slice to change between the two loops, which could cause this error.
I build a version of cmd/go using -race (go build -race -o gorace cmd/go) and then ran gorace test std.  I got this, which is the race I am describing.
==================
WARNING: DATA RACE
Read by goroutine 14:
  main.mergeEnvLists()
      /home/iant/go/src/cmd/go/main.go:461 +0x1cc
  main.envForDir()
      /home/iant/go/src/cmd/go/main.go:452 +0x131
  main.(*builder).runTest()
      /home/iant/go/src/cmd/go/test.go:1077 +0x82b
  main.(*builder).do.func1()
      /home/iant/go/src/cmd/go/build.go:1257 +0x56f
  main.(*builder).do.func2()
      /home/iant/go/src/cmd/go/build.go:1314 +0x181

Previous write by goroutine 13:
  main.mergeEnvLists()
      /home/iant/go/src/cmd/go/main.go:463 +0x2aa
  main.envForDir()
      /home/iant/go/src/cmd/go/main.go:452 +0x131
  main.(*builder).runTest()
      /home/iant/go/src/cmd/go/test.go:1077 +0x82b
  main.(*builder).do.func1()
      /home/iant/go/src/cmd/go/build.go:1257 +0x56f
  main.(*builder).do.func2()
      /home/iant/go/src/cmd/go/build.go:1314 +0x181

Goroutine 14 (running) created at:
  main.(*builder).do()
      /home/iant/go/src/cmd/go/build.go:1320 +0x68e
  main.runTest()
      /home/iant/go/src/cmd/go/test.go:595 +0x33f3
  main.main()
      /home/iant/go/src/cmd/go/main.go:181 +0xa38

Goroutine 13 (running) created at:
  main.(*builder).do()
      /home/iant/go/src/cmd/go/build.go:1320 +0x68e
  main.runTest()
      /home/iant/go/src/cmd/go/test.go:595 +0x33f3
  main.main()
      /home/iant/go/src/cmd/go/main.go:181 +0xa38
==================


[1.12.2] Config settings keep reseting

Every time I start the game, regardless of what my settings were before, the ui disaplays everything. Everything is turned on and in whatever position they are by default. It is really frustrating to have to open the options menu. Every. Single. Time. Just to change the arrangements as they should be.

Yes, it's broken in the latest release, but fixed in master. A lot of stuff going on behind the scenes for the next update.


Add life of a Facebook C++ engineer status quo story

This is currently an outline, similar in style to @nikomatsakis's life of an AWS engineer story.

I'm going to merge, we can always add more details in subsequent PRs.


Implement a global browsers option

I'd like to expand the browsers option in the bundled autoprefixer package to be a global setting, so that other optimisations that may provide legacy support can all use the same settings. For example, https://github.com/ben-eb/postcss-merge-rules/pull/9.
The patch should load browserslist in its default settings, and some detection should be used to ensure that people use {browsers: 'last 3 versions'} rather than {autoprefixer: {browsers: 'last 3 versions'}}. cssnano could console log a message to say use the top level option instead.

Nice!


feat(types/jsx): support jsxImportSource, avoid global JSX conflict

Based on and supersedes #7083
Closes #1033
Closes #1034

No longer implicitly register global JSX types by default

This avoid conflict when using Vue in the same project with React
Global registration must now be done by explicitly importing / referencing vue/jsx, or listing it in compilerOptions.types.

Add vue/jsx-runtime to support jsxImportSource usage

Can enable globally by setting compilerOptions.jsxImportSource to 'vue'
Can also opt-in per-file with /** @jsxImportSource vue */

Note that global JSX types requires explicit opt-in, which is technically a breaking change, but this is a type-only change and the update path is trivial, so it aligns with the release policy if we release this in a minor (3.3).
This is also needed to land zero-config SFC Generics support in Volar https://github.com/vuejs/language-tools/issues/2546

It’s awesome to see Vue adding support for the JSX automatic runtime! :tada:
I spotted some bugs though. #7959 explains and resolves them.

This avoid conflict when using Vue in the same project with React

Glad to see this! Trying to work with Vue 2.7 (templates only; no JSX/TSX) and React in the same project and dealing with conflicting types when using vue-tsc/Volar. Would it be possible to backport this to 2.7? If not feasible, is there a workaround to have full TS support for both?

Hi, I have a package vue as dependency to @directus
└─┬<EMAIL_ADDRESS>  └─┬<EMAIL_ADDRESS>    └──<EMAIL_ADDRESS>
And I have react projects in Monorepo, currently, I am having build problems because of type conflicts.
This issue seems related to me with this merged PR is the issue resolved?
Thanks

@ubeytd Did you find a solution to this ? Having the exact same symptoms.

In our case, build problems were caused because the package imports<EMAIL_ADDRESS>was imported to our shared library and from there to the frontend by mistake, when we find that the build problem is resolved, BUT we still have red lines in the editor everywhere about ref.


docs(content/_index.md): fixed typo

Signed-off-by: Zach Rhoads<EMAIL_ADDRESS>

still fixing


fix time tag utc

Codecov Report

Merging #742 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #742      +/-   ##
==========================================
+ Coverage    52.6%   52.64%   +0.03%
==========================================
  Files          35       35
  Lines        8267     8271       +4
==========================================
+ Hits         4349     4354       +5
  Misses       3434     3434
+ Partials      484      483       -1

Impacted Files
Coverage Δ

engine.go
56.73% <100%> (+0.17%)
:arrow_up:

helpers.go
61.9% <100%> (ø)
:arrow_up:

session_delete.go
58.42% <100%> (ø)
:arrow_up:

session_update.go
51.29% <100%> (ø)
:arrow_up:

session_insert.go
57.77% <100%> (ø)
:arrow_up:

xorm.go
67.6% <0%> (+1.4%)
:arrow_up:

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 c969050...4a9423b. Read the comment docs.


PULL_REQUEST_BRANCH_NAME invalid input

Hi, I am using latest version of the file-sync github action https://github.com/marketplace/actions/file-sync
The documentation mentions that I can configure a PULL_REQUEST_BRANCH_NAME to raise a PR against on the target repository. The file-sync is working as expected, creating a new branch and pushing the changes to the target repository, though no PR is raised.
I am using the latest version of the workflow which should create pull requests judging from the changelog entry in version 2.1.0:

Instead I receive the below error:
Unexpected input(s) 'PULL_REQUEST_BRANCH_NAME', valid inputs are ['entryPoint', 'args', 'REPOSITORIES', 'FILES', 'TOKEN', 'PULL_REQUEST']

my file is as follows:
name: sdk_changelog_sync

on:
  workflow_call:
      inputs:
        node-version:
          required: true
          type: string
        ref:
          required: false
          default: ''
          type: string

jobs:
  sync_changelog:
    runs-on: ubuntu-latest
    steps:
      - name: Fetching Local Repository
        uses: actions/checkout@master
      - name: sync_changelog
        uses<EMAIL_ADDRESS>        with:
          REPOSITORIES: |
            tomdaniels/playground@changelog-sync
          PULL_REQUEST_BRANCH_NAME: master
          FILES: |
            packages/charts-embed-dom/CHANGELOG.md=CHANGELOG.md
          TOKEN: ${{ secrets.GITHUB_TOKEN }}

Any insight you can offer into why this may be happening would be greatly appreciated, I can not see any usage examples in the documentation to confirm if this is user error or in fact an issue with the workflow itself.
Thank you in advance please let me know if there's any other information that would be helpful

@kbrashears5

sorry for the delay. please use v3.0.0, my auto releases got out of order


Need an explicit way for cxxbridge to produce header/source file

The cxxbridge-cmd is not ideal:

The cxxbridge-cmd version might be different from cxx version, which can cause problems
It's hard to track file changes outside rust project, i.e. determine the best time to re-generate the header/source file

I used the side-effect from cxx_build::bridge(...) to generate the necessary files https://github.com/XiangpengHao/cxx-cmake-example/blob/27dfab58ff4888d4ede71fdad45a7d112640d2b0/rust_part/build.rs#L2 and then copy those files to desired locations https://github.com/XiangpengHao/cxx-cmake-example/blob/27dfab58ff4888d4ede71fdad45a7d112640d2b0/rust_part/CMakeLists.txt#L20
It would be great if we have some ways to explictly write the ouput file, maybe something like
// build.rs
fn main() {
    cxx_build::bridge("src/lib.rs").header("/path/lib.rs.h").source("/path/lib.rs.cpp");

    println!("cargo:rerun-if-changed=src/lib.rs");
}

I agree this would really be helpful.  The build environment always has to be in sync with the version of cxx, which might encourage locking on an outdated version.

I have recently overhauled cxx-qt's build process and stumbled over this problem. cxx-qt has its own code generation steps in addition to cxx. Initially, we had cxx-qt-builder generating C++ code from build.rs but not compiling it, instead relying on CMake to compile the generated C++ code. This was an ugly situation. cxx-qt-builder had to run at CMake's configure time so it could pass the paths of the generated files to CMake (involving a convoluted process of serializing C++ source code and file paths to JSON :dizzy_face: ).
My first attempt to improve this process was to create a CLI executable analogous to cxxbridge. I got that to work with CMake, but once I had it working, I realized it wasn't a great idea. Several issues arise with a separate CLI executable written in Rust. The CLI executable has to be distributed somehow. I initially was thinking of doing this through vcpkg (in addition to some C++ code and a CMake module specific to cxx-qt, but those parts wouldn't be needed for cxx by itself), however, vcpkg doesn't (currently) support building Rust. cargo install is an option, but that is problematic because cxx and its dependencies have to be redundantly compiled in the cargo build for the Rust library, which would slow down build times. Furthermore, with the CLI executable separated from the compilation of the Rust code, that introduces the possibility of version mismatches between the CLI executable and the cxx version used in the Rust code. That could be mitigated with version checks, but implementing that would be cumbersome (Which part of the build process would be responsible for doing the version check? The CLI tool? The C++ build system? The Rust macro?).
Instead of using a CLI tool, I refactored cxx-qt-builder to work similar to cxx-builder. Now, the build.rs not only generates the C++ code, it also compiles the C++ using the cc crate. Implementing this turned out to be tricky because Cargo does not have a canonical way for build scripts to output artifacts to a stable location. I read #949 and #229 but didn't see any good solution. I noticed that cxx-build implemented a hack to walk up the directory tree from OUT_DIR in an attempt to find the Cargo target directory and symlink headers from a cxxbridge directory at the root of CARGO_TARGET_DIR. I got something similar working in a proof-of-concept by having CMake set the CARGO_TARGET_DIR environment variable so build.rs could make use of it. However, I decided against this approach because I don't want to rely on unstable implementation details of Cargo.
The solution I came up with is to have CMake set an environment variable called CXXQT_EXPORT_DIR to explicitly tell cxx-qt-builder where to output headers. CMake sets this so cxx-qt-builder outputs the files into CMake's build directory instead of Cargo's build directory. This way, CMake can reliably add that directory to its include paths:
set(CRATE qml-minimal)
# Corrosion crates a CMake target with the same name as the crate.
corrosion_import_crate(MANIFEST_PATH src/rust/Cargo.toml CRATES ${CRATE})
# The Rust library's build script needs to be told where to output the generated headers so CMake can find them
# by setting the CXXQT_EXPORT_DIR environment variable.
set(CXXQT_EXPORT_DIR "${CMAKE_CURRENT_BINARY_DIR}/cxxqt")
corrosion_set_env_vars(${CRATE}
    "CXXQT_EXPORT_DIR=${CXXQT_EXPORT_DIR}"
    "QMAKE=${QMAKE}" # specific to cxx-qt's build process; wouldn't be need for cxx
)
# Include the headers generated by the Rust library's build script. Each crate gets its own subdirectory under
# CXXQT_EXPORT_DIR. This allows you to include headers generated by multiple crates without risk of one crate
# overwriting another's files.
target_include_directories(${CRATE} INTERFACE "${CXXQT_EXPORT_DIR}/${CRATE}")

In https://github.com/dtolnay/cxx/issues/949#issuecomment-943735980 @dtolnay said:

The cxx-build crate is definitely intended only for pure Cargo managed builds, so plumbing its outputs into a CMake managed build is not an endorsed use case.

I would like to change this by implementing the above approach where cxx-build would output its generated headers to a path specified by an environment variable. If the environment variable is not specified, which would be the case for doing the entire build with Cargo, then use OUT_DIR instead. I propose calling the environment variable CXX_EXPORT_DIR. This way, Corrosion could automatically set this environment variable and add it to the C++ include paths. The result would be that integrating a crate which has cxx bindings into a CMake build would be as simple as using Corrosion normally:
set(CRATE crate-name)
corrosion_import_crate(MANIFEST_PATH src/rust/Cargo.toml CRATES ${CRATE})
target_link_libraries(my_application PUBLIC ${CRATE})

If this is accepted upstream by both cxx and Corrosion, that could further simplify the process for downstreams using cxx-qt. I could change cxx-qt-builder to use the same environment variable as cxx-builder. The end result would allow simplifying the CMake code required to integrate a crate using cxx-qt into a CMake build:
set(CRATE qml-minimal)
corrosion_import_crate(MANIFEST_PATH src/rust/Cargo.toml CRATES ${CRATE})

# specific to cxx-qt's build process; wouldn't be need for cxx
corrosion_set_env_vars(${CRATE} "QMAKE=${QMAKE}")
target_link_libraries(${CRATE} INTERFACE
    Qt${QT_VERSION_MAJOR}::Core
    Qt${QT_VERSION_MAJOR}::Gui
    Qt${QT_VERSION_MAJOR}::Qml
    Qt${QT_VERSION_MAJOR}::QuickControls2
)

target_link_libraries(my_application PUBLIC ${CRATE})

I have been talking about integrating cxx & cxx-qt with CMake, but this would also make it easy to integrate them with other C++ build systems. All that would be required from the C++ build system is setting the environment variable when calling cargo build and adding it to the C++ include paths.
@dtolnay what do you think of this proposal? Pinging the Corrosion maintainer @jschwe as well.

The cxx-build crate is definitely intended only for pure Cargo managed builds, so plumbing its outputs into a CMake managed build is not an endorsed use case.

This is my preference still.
At a glance, what you are doing in cxx-qt seems similar to how https://github.com/google/autocxx uses cxx (just in the superficial sense that there is something which generates input for cxx to operate on, runs cxx's C++ code generator, generates some other stuff of its own, and links them all together).
@adetaylor created https://crates.io/crates/cxx-gen specifically for this purpose. @Be-ing could you look into whether that meets your needs? The documentation is not thorough and some aspects are not fleshed out — for example in comparison with cxx-build and the cxxbridge CLI, it produces worse error messages, and it does not expose any cfg attribute support unlike the other two. Those are all things that can be fixed; cxx-build is not an appropriate interface for your use case.

Could you elaborate why that is your preference? I don't think a separate crate is a good solution. The beauty of cxx-builder handling this is that downstream users of cxx wouldn't have to do anything to support both building executables with Cargo alone and having a C++ build system invoke Cargo.

cxx-qt-build is already using cxx-gen in its code generation. That's orthogonal to the issue here about outputting the generated C++ headers somewhere a C++ build system can add them to include paths.

cxx-build is not an appropriate interface for your use case

You're right, it's not, and I agree it should not be. I'm not trying to use it in cxx-qt-build. We are using cxx-build in cxx-qt-lib's build.rs for bindings to common Qt types. cxx-qt-build is a separate crate that uses cxx-gen plus adds Qt-specific code generation steps.
The goal of my proposal is not to use cxx-build in cxx-qt-build. What I am proposing is to make cxx-build work similar to how I've implemented cxx-qt-build by outputting the C++ headers to a location specified by an environment variable (only if the environment variable exists, otherwise cxx-build will continue working as it does now using OUT_DIR). This would allow Corrosion to automatically handle setting the environment variable and C++ include paths. After that, cxx-qt-build and cxx-build could converge on using the same environment variable. In the end, using cxx-build or cxx-qt-build with Corrosion would be the same as using any other Rust library; downstream users wouldn't have to be concerned with any of this.

(By the way, cxx-qt's documentation and README are in need of updating. We've changed a lot in the past several weeks but haven't updated the documentation yet. I'll get to work on that next week.)

make cxx-build work similar to how I've implemented cxx-qt-build by outputting the C++ headers to a location specified by an environment variable (only if the environment variable exists, otherwise cxx-build will continue working as it does now using OUT_DIR). This would allow Corrosion to automatically handle setting the environment variable and C++ include paths. After that, cxx-qt-build and cxx-build could converge on using the same environment variable. In the end, using cxx-build or cxx-qt-build with Corrosion would be the same as using any other Rust library; downstream users wouldn't have to be concerned with any of this.

@dtolnay what are your thoughts on this? I'd be happy to make a PR implementing this if you're on board with the idea.

The cxxbridge-cmd is not ideal:

The cxxbridge-cmd version might be different from cxx version, which can cause problems
It's hard to track file changes outside rust project, i.e. determine the best time to re-generate the header/source file

Neither of these factors is inherent to cxxbridge-cmd, it's only in regard to how a particular build system chooses to integrate it. Done well, neither of those should occur. There's examples in https://github.com/dtolnay/cxx/blob/1.0.80/demo/BUCK and https://github.com/dtolnay/cxx/blob/1.0.80/demo/BUILD of how Buck and Bazel would do it.

Regarding (1), when someone runs bazel build //demo:demo, cxxbridge-cmd is built from source just like cxx and all the rest of the dependencies would be. There is no reliance on a (possibly incongruous version) cxxbridge command on the person's $PATH or accessed through a distro package manager. The build system hermetically builds everything necessary (or downloads from cache). You'd coordinate the cxx and cxxbridge-cmd version exactly the same as how you'd otherwise coordinate a cxx and cxx-build version.

Regarding (2), the build system has perfect knowledge of the inputs and outputs of every build step, because it's the one dispatching the cxxbridge invocation, it's not hidden in a build.rs whose behavior is opaque to the build system. The build system will rerun the cxxbridge invocation if and only if the input .rs file containing #[cxx::bridge] has changed, or the headers included by the bridge have changed, or the cxxbridge binary itself has needed to be rebuilt (because of version update or any other reason).

For build systems that aren't going to be able to accommodate a setup similar to that, I left a comment in https://github.com/dtolnay/cxx/pull/1120#pullrequestreview-1160411031 laying out a way for them to reliably integrate cxx-build instead, using an invocation of cxx-build performed by a Cargo build.rs.

There's examples in https://github.com/dtolnay/cxx/blob/1.0.80/demo/BUCK and https://github.com/dtolnay/cxx/blob/1.0.80/demo/BUILD of how Buck and Bazel would do it.

That is a special situation because it's within this repository where cxxbridge and the cxx proc_macro are maintained together. That is not the case downstream, where the cxx macro comes from Cargo via crates.io and cxxbridge comes from... well, it's not clear where it's supposed to come from. You could do cargo install --version, but then you'd have to get the version from somewhere. You could manually duplicate the version to whatever part of the build process does cargo install, but that would easily get out of sync with the macro crate whenever cargo update is run. Plus, the build artifacts wouldn't be shared between cargo install and the crate using the cxx macro, which would build cxx-gen and its dependencies twice. That could be alleviated by caching the built cxxbridge binary on CI, but you'd have to ensure that cache gets invalidated whenever the cxx macro is updated.
All of this would be much easier to setup, less error-prone to maintain, and build faster by keeping the versions of cxx and cxx-build together in Cargo.toml, where they would both be updated together with cargo update.

For build systems that aren't going to be able to accommodate a setup similar to that, I left a comment in https://github.com/dtolnay/cxx/pull/1120#pullrequestreview-1160411031 laying out a way for them to reliably integrate cxx-build instead, using an invocation of cxx-build performed by a Cargo build.rs.

That suggestion would be even more complex than using cxxbridge and doesn't address any of the concerns raised in this issue.

The cxx-build crate is definitely intended only for pure Cargo managed builds, so plumbing its outputs into a CMake managed build is not an endorsed use case... This is my preference still.

Why? I haven't seen any technical reasons explained why cxx-build shouldn't have some way to output its generated headers somewhere an external C++ build system knows where they are. You raised some concerns with the specific implementation in #1120, but as far as I can tell, those could be easily addressed.

That is a special situation because it's within this repository where cxxbridge and the cxx proc_macro are maintained together.

It isn't really, the Bazel rules look substantially identical to my link regardless of whether they're in this repo or a different one. For example, here is one using rust_cxx_bridge via Bazel in a different repo: anysphere-messaging/client/daemon/BUILD. Similarly, this repo's Bazel rules build clap and plenty of other crates.io libraries which I am not author of and are not maintained in this repo. Controlling versions of them is not any different from usual, they are determined by third-party/Cargo.lock and updated by cargo update.

All of this would be much easier to setup, less error-prone to maintain, and build faster by keeping the versions of cxx and cxx-build together in Cargo.toml, where they would both be updated together with cargo update.

If you like that workflow, a non-Cargo build system that nevertheless involves Cargo can do exactly the same thing for cxxbridge-cmd. You can list it in Cargo.toml. It will appear in Cargo.lock and you can update it using cargo update. That aspect is not different from cxx-build.

You could do cargo install --version, but then you'd have to get the version from somewhere. You could manually duplicate the version to whatever part of the build process does cargo install, but that would easily get out of sync with the macro crate whenever cargo update is run.

It sounds like you're desiring for it to appear in Cargo.lock. You can read it from there using e.g. cargo tree -i cxxbridge-cmd --depth 0.

Plus, the build artifacts wouldn't be shared between cargo install and the crate using the cxx macro, which would build cxx-gen and its dependencies twice.

Neither cxx nor cxxbridge-cmd depends on cxx-gen (other than as a dev-dependency for use in the example code in docs, which isn't relevant here). For sharing the rest of the dependencies like syn, that's a matter of using the same target directory for both builds, either via CARGO_TARGET_DIR in the environment, or Cargo's --target-dir command line flag.
To be clear, in a non-Cargo build system that involves performing Cargo invocations as part of the build, this is not what you should use. The command-line code generator is primarily intended for build systems that wouldn't involve Cargo at build time (Buck and Bazel are examples of this). For setups that already use Cargo and run cxx-build from a build.rs, https://github.com/dtolnay/cxx/pull/1120#pullrequestreview-1160411031 is the recommended approach and you don't need to worry about how a cxxbridge-cmd gets installed.

I haven't seen any technical reasons explained why cxx-build shouldn't have some way to output its generated headers somewhere an external C++ build system knows where they are.

The technical reason is that I get to not support CMake which continues to give me the impression of being a disaster of a build system from everything that I have seen, at least as far as the integration of Cargo packages has been pursued to date. By following the approach in https://github.com/dtolnay/cxx/pull/1120#pullrequestreview-1160411031, whenever there is a CMake-specific way that CMake is unable to deliver the cxx-build functionality explained in https://cxx.rs/build/cargo.html, it's clear it needs to be fixed in corrosion/CMake. In the other way, whenever there is a CMake-specific way that something does not work, I become responsible for code changes in cxx-build to accommodating CMake, which is not appealing to me.

The command-line code generator is primarily intended for build systems that wouldn't involve Cargo at build time (Buck and Bazel are examples of this).

Ah, thank you for explaining this. The documentation does not communicate this. I think this has been a big point of confusion.
CMake does not have any facilities for invoking rustc on its own. That is not necessary to incorporate Rust into a CMake build, nor am I aware of anyone attempting or asking for that. I searched the CMake issue tracker and the web with DuckDuckGo and don't see anybody asking for that. Judging from this comment from a CMake developer, I highly doubt CMake will ever take up the maintenance burden of calling rustc itself. Instead, I see on the web various attempts at having CMake call Cargo. Of these, Corrosion seems to be the most mature, and in my experience it works quite well. What Corrosion does is create CMake targets that call Cargo to build a library and link it into the library/executable that CMake builds.
For the case of build systems that bypass Cargo and call rustc themselves so build.rs isn't available, yes, the cxxbridge CLI tool makes sense. Now I understand why you thought my suggestion to deprecate cxxbridge was ridiculous. However, I still think using cxxbridge is far from an ideal solution for C++ build systems that don't have any features to build Rust on their own without Cargo.

If you like that workflow, a non-Cargo build system that nevertheless involves Cargo can do exactly the same thing for cxxbridge-cmd. You can list it in Cargo.toml. It will appear in Cargo.lock and you can update it using cargo update. That aspect is not different from cxx-build.

I tested this, and yes you can keep track of the cxxbridge version that way... but that still doesn't solve the problem because Cargo won't build the cxxbridge binary target when it's listed as a dependency of another crate.

It sounds like you're desiring for it to appear in Cargo.lock. You can read it from there using e.g. cargo tree -i cxxbridge-cmd --depth 0.

That's neat, thanks for sharing that.

For setups that already use Cargo and run cxx-build from a build.rs, https://github.com/dtolnay/cxx/pull/1120#pullrequestreview-1160411031 is the recommended approach and you don't need to worry about how a cxxbridge-cmd gets installed.

That addresses a nonexistent problem. There is no need for the C++ build system to get all of the include paths that cxx-build uses. If the crate using cxx needs include paths for some C++ library, the C++ build system already needs to find that library because the C++ build system does the final link.
The only thing that is missing for cxx-build to work well with any C++ build system to provide a means for the C++ build system to tell cxx-build where to put the generated headers so the C++ build system can add them to its include paths.

The technical reason is that I get to not support CMake which continues to give me the impression of being a disaster of a build system from everything that I have seen, at least as far as the integration of Cargo packages has been pursued to date.

I have Opinions about build systems as well and I've intentionally left that out of this discussion. I have plenty of gripes about CMake myself, but like it or not, CMake and lots of other build systems that aren't Bazel are widely used in lots of contexts. We could bikeshed forever about the pros and cons of various C++ build systems. The issues raised here apply to any C++ build system that invokes Cargo to build a library as part of a C++ application or library.
If the first step to incorporating Rust into an existing C++ project is replacing the whole build system... well, that's just not going to happen in most cases. More likely, C++ developers considering adding Rust into their application would give up on the idea of using Rust at all. In order for it to be practical to incrementally introduce Rust into a C++ codebase, it must be practical to integrate with the C++ build systems people are already using.

whenever there is a CMake-specific way that something does not work, I become responsible for code changes in cxx-build to accommodating CMake, which is not appealing to me.

I understand your concern with this. Feel free to ping me whenever such issues are reported. That said, I anticipate people will bug you less about using CXX with CMake when there's an easy to use solution that is documented well. As #1120 demonstrates, all that is needed is adding about 10 lines of code to cxx-build which can be written such that it has no effect on how cxx-build works unless a C++ build system explicitly opts into using it. That's all I'm asking to change about cxx-build. I don't anticipate that being a large maintenance burden.

If corrosion would like to stick non-Cargo build steps downstream of a Cargo-based invocation of cxx-build, the only correct way to implement that is by sufficiently accurately pretending to be Cargo in the rest of the build as well.

This is something that Corrosion definitely does not want to support. Corrosion supports two scenarios:

Let linking be handled by CMake
Let linking be handled by Rust

If someone wants to let Rust invoke the linker, then the build.rs cxx approach already works today, since it is all handled by cargo. If you want linking to be handled by CMake, then in my opinion the command-linecxx-bridge tool would be the preferred approach, since CMake is then aware of what happens.
@Be-ing's suggestion is to support using the build.rs approach, but still handle the linking on the CMake side. I think @dtolnay has given good reasons why this is problematic (mainly that CMake is completely oblivious of all the println!() commands given from the build.rs to cargo).

If you want linking to be handled by CMake, then in my opinion the command-linecxx-bridge tool would be the preferred approach, since CMake is then aware of what happens.
@Be-ing's suggestion is to support using the build.rs approach, but still handle the linking on the CMake side. I think @dtolnay has given good reasons why this is problematic (mainly that CMake is completely oblivious of all the println!() commands given from the build.rs to cargo).

You're correct that generating the C++ code in build.rs and having a C++ build system do the final link requires both build.rs and the C++ build system to find external C++ libraries used by the crate which uses cxx. However, in my experience, this is required regardless, otherwise cargo test won't work for the crate that uses cxx. Also, for the crate using cxx to be usable in both cases (building with only Cargo or invoking Cargo from a C++ build system), build.rs needs to locate the external C++ library.

If corrosion would like to stick non-Cargo build steps downstream of a Cargo-based invocation of cxx-build, the only correct way to implement that is by sufficiently accurately pretending to be Cargo in the rest of the build as well.

This is something that Corrosion definitely does not want to support.

I guess I don't mean Corrosion here, but "person using Corrosion". This thread exists because if you have C++ calling Rust, and the Rust library built using Cargo exposes a C++ API using cxx, your C++ code needs to have cxx's generated header on its include path. That's what I mean by a person sticking a non-Cargo build step (the C++ code, which calls Rust) downstream of a Cargo-based build.
I think this falls under "Let linking be handled by CMake" in your characterization, but linking is really orthogonal to all of this about headers and include paths, which @Be-ing's last comment also indicates. You could just as easily have C++ call Rust but still have the final link handled by Rust.
If Corrosion is the one building the Rust code (which is depended on by (obviously non-Corrosion) C++ code), then I think the author would want Corrosion to be able to expose an include path through which their C++ code becomes able to access the appropriate headers that their Rust code implements, which is what https://github.com/dtolnay/cxx/pull/1120#pullrequestreview-1160411031 gets at.

Corrosion supports two scenarios:

Let linking be handled by CMake
Let linking be handled by Rust

What do you mean by Corrosion supporting linking being handled by Rust? If Rust does the final link, why use CMake at all?

linking is really orthogonal to all of this about headers and include paths

Kinda, but it is related. When I tried the CLI tool approach, MSVC's linker failed to link Cargo's tests with a bunch of errors like this:
          qml_minimal-fed87d1c9e36c7ca.1ac972c8m5b6xrub.rcgu.o : error LNK2019: unresolved external symbol cxx_qt$my_object$cxxbridge1$MyObject$set_number referenced in function _ZN11qml_minimal9my_object8MyObject10set_number17h0180ea11ac71a14aE
          qml_minimal-fed87d1c9e36c7ca.1ac972c8m5b6xrub.rcgu.o : error LNK2019: unresolved external symbol cxx_qt$my_object$cxxbridge1$MyObject$set_string referenced in function _ZN11qml_minimal9my_object8MyObject10set_string17hb5108fc7fb9215adE
          libcxx_qt_lib-c5c11005f6c39e76.rlib(cxx_qt_lib-c5c11005f6c39e76.38ljfw97mgteislm.rcgu.o) : error LNK2019: unresolved external symbol rust$cxxqtlib1$cxxbridge1$qstring_init_from_rust_string referenced in function _ZN10cxx_qt_lib5types7qstring3ffi29qstring_init_from_rust_string17h8f75fa133531d4bdE
          libcxx_qt_lib-c5c11005f6c39e76.rlib(cxx_qt_lib-c5c11005f6c39e76.38ljfw97mgteislm.rcgu.o) : error LNK2019: unresolved external symbol rust$cxxqtlib1$cxxbridge1$qstring_to_rust_string referenced in function _ZN10cxx_qt_lib5types7qstring3ffi22qstring_to_rust_string17h12bc99a963e8e90bE
          libcxx_qt_lib-c5c11005f6c39e76.rlib(cxx_qt_lib-c5c11005f6c39e76.38ljfw97mgteislm.rcgu.o) : error LNK2019: unresolved external symbol cxxbridge1$unique_ptr$QString$null referenced in function _ZN93_$LT$cxx_qt_lib..types..qstring..ffi..QString$u20$as$u20$cxx..unique_ptr..UniquePtrTarget$GT$6__null17hd9ed30e5994f00b1E

I didn't investigate exactly what caused these errors, but they went away when switching to compiling the generated C++ in build.rs.

@Be-ing asked me to comment here.
From my experience (packaging 1000-2000 Rust crates for Fedora Linux), the way bindgen supports this has proven to be very flexible and robust. While it provides a bindgen executable that can be run "manually", its library interface is often preferred, as it can be called in build.rs scripts, and is hence automatically integrated into the cargo build process. Additionally, bindgen provides an API for specifying the output directory for any generated files. I know it's not an exact comparison (cxx generates C++ files, bindgen generates Rust files), but both are code generators, and being able to tell them where to actually put their output is kind of an important feature / setting.


Why does cause need to be an instance of error?

Javascript allows any object to be thrown so I'm curious why the VError constructor is so strict on cause being an instance of Error. If, unbeknownst to me, some third-party code throws an arbitrary object then when I see that error for the first time I don't want my error handing to break because "cause is not an Error".

Interesting!  While technically possible, and I remember doing that in the pre-Node days (e.g., using Spidermonkey on the server), I haven't run into code that throws non-Errors in quite some time.  As I recall, it doesn't work well because there's no way to figure out where it was thrown from.
VError itself relies on the name, message, and stack properties that are provided by Error objects.  It also exposes cause objects directly via VError.cause().  It's pretty useful that callers of that function know they're going to get back a valid Error.  I think most callers would be surprised to get back a non-null, non-Error object, and it would be a bunch of work for callers to have to check what they got back.

Yes 100% agree. If cause is not an Error I think VError should do it's best to preserve what ever context it has available. A best-effort attempt to create a new Error might look like:

If it's a string then use that as the message.
try JSON.stringify
fall back to build a message by stringifying the top level properties.

I see.  I think you're describing a "DWIM" (do-what-I-mean) approach -- i.e., have the software try to guess what was probably wanted for this particular case.  I know a lot of people prefer that, but I often don't because I find it makes the software less predictable.  In my case, if a VError gets a cause that's something other than an Error, I want to fix that right away (and I want the program to crash so that I get a core file that shows unambiguously where that object came from).  I don't want to find out later, long after the problem happened, by finding an error message that was incomplete or misleading, without much ability to figure out where it came from.  I realize this is a preference.  We've largely avoided DWIM with VError.  In some cases, we've created alternate constructors that are more or less strict in ways like this, and we could do that here if this case seems important.


DMN viewer

@jessevanmuijden can you check the dist folder? After the merge 2 characters of file and folder names are missing?
index.html --> dex.html

@jessevanmuijden can you also check te merge conflicts in this PR?

@arjangeertsema this PR fixes it (globSync) https://github.com/biz-dev-ops/web-components/pull/115


A problem about training

Hello, I ran the training script of BERT-BERT architecture in the example, but a poor simplification result is obtained. Is this a program error？

For how many epochs did you train your model?

About 10-15 Epochs. Strangely, the system cannot output meaningful sentences. I also tried the BERT-GPT2 structure, which is better than BERT-BERT, but the SARI score is still not very good.

If your SARI is not good, the output sentences won't make much sense.
I got a good SARI in 10-15 epochs. Are you using the Wikilarge dataset or the smaller one given in the repo? I would also suggest you to investigate the input sentences and label coming out of the data generator to verify if they are correct.

Thanks for the warm help. I downloaded the GitHub version code, and run the code according to the method on GitHub. I just set the Epoch to 15 and I used the training set which is in the dataset folder. I additionally checked the code of datagen.py and utils.py of the project, I think the code is OK.

Check your loss, is it still decreasing when you reach 15 epochs or getting plateaued? You can try training it further.


Always use the latest docker image

What changes were proposed in this pull request?
Always using the latest docker image when starting from dockler.sh
Is this related to an already existing issue on sparkler?
No
Will it close an existing issue?
No
How was this patch tested?
Ran dockler.sh and it pulled and started the latest image.
Please review
https://github.com/USCDataScience/sparkler/blob/master/.github/CONTRIBUTING.md before opening a pull request.

Thanks @prowave  🙏🏼


Manifest apply output is overly verbose/misleading

What I get:
Component Citadel installed successfully:
=========================================

serviceaccount/istio-citadel-service-account unchanged
clusterrole.rbac.authorization.k8s.io/istio-citadel-istio-system unchanged
clusterrolebinding.rbac.authorization.k8s.io/istio-citadel-istio-system unchanged
deployment.apps/istio-citadel configured
poddisruptionbudget.policy/istio-citadel unchanged
service/istio-citadel unchanged

Component PrometheusOperator installed successfully:
====================================================
No resources found

Component NodeAgent installed successfully:
===========================================
No resources found

Component Galley installed successfully:
========================================

serviceaccount/istio-galley-service-account unchanged
clusterrole.rbac.authorization.k8s.io/istio-galley-istio-system unchanged
clusterrolebinding.rbac.authorization.k8s.io/istio-galley-admin-role-binding-istio-system unchanged
configmap/galley-envoy-config unchanged
configmap/istio-galley-configuration unchanged
configmap/istio-mesh-galley unchanged
deployment.apps/istio-galley configured
poddisruptionbudget.policy/istio-galley unchanged
service/istio-galley unchanged

What I expect:
Component Citadel installed successfully:
=========================================
serviceaccount/istio-citadel-service-account unchanged
clusterrole.rbac.authorization.k8s.io/istio-citadel-istio-system unchanged
clusterrolebinding.rbac.authorization.k8s.io/istio-citadel-istio-system unchanged
deployment.apps/istio-citadel configured
poddisruptionbudget.policy/istio-citadel unchanged
service/istio-citadel unchanged

Component Galley installed successfully:
========================================
serviceaccount/istio-galley-service-account unchanged
clusterrole.rbac.authorization.k8s.io/istio-galley-istio-system unchanged
clusterrolebinding.rbac.authorization.k8s.io/istio-galley-admin-role-binding-istio-system unchanged
configmap/galley-envoy-config unchanged
configmap/istio-galley-configuration unchanged
configmap/istio-mesh-galley unchanged
deployment.apps/istio-galley configured
poddisruptionbudget.policy/istio-galley unchanged
service/istio-galley unchanged

No extra spaces everywhere, and remove the components that are not actually created

@howardjohn the requirement here is to remove outputs of disabled components if no resource is pruned?

Yeah there are tons of logs about components that are disabled which is confusing. In my opinion, if I only enable Pilot (for example) I should only see logs about pilot. At most, the only time I should see the other things is "Skipping xyz"

I will create a PR today.

This is the same thing as https://github.com/istio/istio/issues/18534, right?

This is the same thing as #18534, right?

Yes.

@ostromart seems like https://github.com/istio/operator/pull/625 has been overridden by https://github.com/istio/operator/pull/628.


Remove phpunit from symfony file

PHPUnit configuration files are essential to run continuous integration tests on platforms like travis.

Thanks for this. Can you provide an example or documentation just so we have something to refer to if this comes up again in the future?

@altaris unfortunately this isn't mergeable currently, and there are some questions outstanding which we'd like to clarify before merging :cry:
I need to clean up stale pull requests at some stage, and will close this out if I don't hear anything before Friday 26th February.


Default redirection to Blog article

It should be possible to redirect without any further configuration (via shotcuts) from robert-brands.com/title to robert-brands.com/blog/artikel/title to reference an article.

Redirection is implemented


[Event Request] codeunit 7324 "Whse.-Activity-Post" - OnAfterSetSalesLineFilters

We would like to add a new event OnAfterSetSalesLineFilters in the following procedure:
local procedure InitSourceDocument()

.
.
.
                begin
                    SalesHeader.Get("Source Subtype", "Source No.");
                    SalesLine.SetRange("Document Type", "Source Subtype");
                    SalesLine.SetRange("Document No.", "Source No.");
                    if SalesHeader."Shipping Advice" = SalesHeader."Shipping Advice"::Complete then
                        SalesLine.SetRange(Type, SalesLine.Type::Item);
                    OnAfterSetSalesLineFilters(SalesLine, SalesHeader, WhseActivHeader); //A108B0056.Event
                    if SalesLine.Find('-') then
                        repeat
                            IsHandled := false;
                            OnInitSourceDocumentOnBeforeSalesLineLoopIteration(SalesHeader, SalesLine, WhseActivHeader, IsHandled);
                            if not IsHandled then begin
                                if "Source Document" = "Source Document"::"Sales Order" then
                                    SalesLine.Validate("Qty. to Ship", 0)
                                else
                                    SalesLine.Validate("Return Qty. to Receive", 0);
                                SalesLine.Validate("Qty. to Invoice", 0);
                                ModifySalesLine(SalesLine);
                                OnAfterSalesLineModify(SalesLine);
                            end;

Event Signature:
[IntegrationEvent(false, false)]
local procedure OnAfterSetSalesLineFilters(var SalesLine: Record "Sales Line"; SalesHeader: Record "Sales Header"; WarehouseActivityHeader: Record "Warehouse Activity Header");
begin
    //A108B0056.Event
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Provide gio::File::get_path()

I need to extract the path from a gio::File, i.e. a wrapper method around g_file_get_path().
impl File {
    pub fn get_path(&self) -> std::path::PathBuf {
    }
}

Use case: gtk:4::prelude::FileChooserExt only returns the selection as gio::File. So, I can't use it with any API that requires a std::path::Path.

Such method already exists https://gtk-rs.org/gtk-rs/git/docs/gio/prelude/trait.FileExt.html#tymethod.path ?

You're right, I totally missed that, sorry for the noise! Closing


AustralianPrisonPopulation.ipynb's base predictions difference vs hts example

The fable/hts replication 2 notebook, has different base predictions compared to the
Australian Prison Population example from this hts example.
Two ideas come to my mind:

Different data sources
Different ETS model execution.

The latter (different AutoETS model execution) causes this. As overall the results for the example are satisfyingly comparable (and in fact our bottom predictions with AutoETS are slightly better than fpp3), I'm ok with the difference.


Release gtctl binary to S3

To solve some network issues, we will not only release gtctl to GitHub Artifacts but also to the S3 bucket(China region).

resolved https://github.com/GreptimeTeam/gtctl/pull/131


Return detailed error responses for Table API errors

Currently, when an invalid table config is posted, the message with the 400 error response does not indicate what the error is. This change provides the error message where applicable.
Testing done:
Before this change, having a non-numeric value for the "replication" field resulted in this response for curl:
{"code":400,"error":"Invalid table config for table: audience_OFFLINE"}
With the change, we now see:
{"code":400,"error":"Invalid table config for table audience_OFFLINE: Invalid replication number"}
I updated a unit test for this scenario, but the response string in the unit tests don't capture the error detail.
TODO:
Review the same for other APIs as well.

Codecov Report

Merging #2897 into master will increase coverage by 9.79%.
The diff coverage is 20%.

@@            Coverage Diff             @@
##           master    #2897      +/-   ##
==========================================
+ Coverage   59.23%   69.03%   +9.79%
==========================================
  Files         912      912
  Lines       43598    43599       +1
  Branches     5926     5926
==========================================
+ Hits        25827    30099    +4272
+ Misses      15863    11481    -4382
- Partials     1908     2019     +111

Impacted Files
Coverage Δ

...oller/api/resources/PinotTableRestletResource.java
40.9% <20%> (+5.48%)
:arrow_up:

...ore/query/scheduler/resources/ResourceManager.java
87.09% <0%> (-9.68%)
:arrow_down:

.../pinot/core/query/scheduler/PriorityScheduler.java
78.08% <0%> (-2.74%)
:arrow_down:

...regation/function/customobject/QuantileDigest.java
47.81% <0%> (-0.42%)
:arrow_down:

...linkedin/pinot/common/utils/helix/HelixHelper.java
49.03% <0%> (+0.64%)
:arrow_up:

.../pinot/core/segment/index/SegmentMetadataImpl.java
81.56% <0%> (+0.7%)
:arrow_up:

...ment/creator/impl/SegmentColumnarIndexCreator.java
88.72% <0%> (+0.75%)
:arrow_up:

...r/transform/function/ValueInTransformFunction.java
39.2% <0%> (+0.8%)
:arrow_up:

.../helix/core/realtime/SegmentCompletionManager.java
69.68% <0%> (+0.9%)
:arrow_up:

...din/pinot/core/realtime/stream/StreamMetadata.java
67.88% <0%> (+0.91%)
:arrow_up:

... and 276 more

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 e22e1ce...e3c10ad. Read the comment docs.


Auth command for redis instances?

Great software, Does corvus support redis AUTH for instances or does it just accept a master like twemporxy? i.e.
myredis.com:6379 - AUTH mypass
myredis2.com:6379 - AUTH mypass2

Unlike twemproxy, corvus is based on the official redis cluster. It acts as a stateless proxy and clients can treat the whole redis cluster as a single redis instance by sending redis request to corvus.
In fact corvus doesn't even support AUTH for redis. That means when forwarding requests to redis corvus can't send a AUTH command to redis first.
However, corvus do have its own AUTH command. You can set the requirepass in corvus config file to force client connection to send a AUTH first.

@doyoubi thanks for getting back to me. My app does not send it to corvus, however my ec2 instance running redis needs the auth command.
Im trying to use corvus as a redis cache for Google PageSpeed. Google PageSpeed does not support AUTH, so my idea was to use corvus, without auth to connect my Redis instances that require auth.
#Corvus without Auth
pagespeed RedisServer "<IP_ADDRESS>: 12345";

I was thinking that I could then receive the command via corvus and then auth into my ec2 instance.
corvus --> AUTH --> REDIS_EC2

Is this possible? Thanks for your help

Sorry to say that corvus can't send AUTH to redis.

Ok, Thanks fro you help

Hello @doyoubi , Do you have any plans to support AUTH in corvus? This would be strictly needed if we need to use Corvus in front of password protected DBs...
Thanks,
Tolis

@georgasa Sorry there's no plan for that.

@doyoubi Thanks for the fast response. And may I ask why this excellent software doesn't support this trivial command? Is there any specific complexity to send Auth command right after the cluster is known to Corvus by the cluster nodes command? The lack of this command makes Corvus unusable for the info password protected Redis. In my case, corvus is on application VM while the Redis cluster is located on totally different VMs.
Thank you,
Tolis

@georgasa Well, I have to say that we will not add any feature to corvus any more.
This project is mainly maintained by eleme infrastructure team and there' no enough resource to keep implementing new features currently even though we're still massively using it.
For me the C language is super hard and time consuming to add new stuff without breaking existing code compared to some other modern system programming languages. And the backend connection on corvus does not have any existing context or state which AUTH will need. We would like to leave corvus in the current stable state.
So, sorry for that. And I recommand disabling the password if possible because it's just not that safe to rely on password if some one is able to access your redis directly.


Swift Compiler Error (Xcode): Definition conflicts with previous value

I'm receiving the following errors while trying to build with Flutter 2.10.3, XCode 12.3:
Could not build the precompiled application for the device.
Uncategorized (Xcode): Command CompileSwift failed with a nonzero exit code

Swift Compiler Error (Xcode): Definition conflicts with previous value
[/Users/TheManuz/.pub-cache/hosted/pub.dartlang.org/ably_flutter-1.2.12/ios/Classes/handlers/PushHandlers.swift:203:18]()
2

Swift Compiler Error (Xcode): Definition conflicts with previous value
[/Users/TheManuz/.pub-cache/hosted/pub.dartlang.org/ably_flutter-1.2.12/ios/Classes/handlers/PushHandlers.swift:207:18]()
2

Swift Compiler Error (Xcode): Unable to infer closure type in the current context
[/Users/TheManuz/.pub-cache/hosted/pub.dartlang.org/ably_flutter-1.2.12/ios/Classes/handlers/PushHandlers.swift:27:152]()
2

Swift Compiler Error (Xcode): Value of optional type 'NSNumber?' must be unwrapped to a value of type 'NSNumber'
[/Users/TheManuz/.pub-cache/hosted/pub.dartlang.org/ably_flutter-1.2.12/ios/Classes/handlers/PushHandlers.swift:212:52]()
2

Swift Compiler Error (Xcode): Value of optional type 'NSNumber?' must be unwrapped to a value of type 'NSNumber'
[/Users/TheManuz/.pub-cache/hosted/pub.dartlang.org/ably_flutter-1.2.12/ios/Classes/handlers/PushHandlers.swift:215:54]()
3

Is there something I can to to try to fix it?

Hi @TheManuz 👋 - we're keen to ensure this is resolved for you. 😁
Did @ikurek's suggestion help you resolve the issue?
Is there anything else we can do to help unblock you?

Hello @QuintinWillison,
I tried the steps suggested by @ikurek , but they didn't work.
It's probably the XCode version, but I cannot install XCode 13 because it needs Mac OS 12+, and I cannot upgrade my machine because Apple ended the support on it.
A new Mac is on the way, I'll check if the problem is XCode version as suspected.
I suggest to add the minimum requirement in the package description.

@TheManuz Please let us know if updating the XCode version solves the issue - if not, we will investigate further

I am getting this error with Flutter version 2.8.1 and Xcode 13.2.

@heshanka @TheManuz I'm not entirely sure what causes the issue, since I can't reproduce it on my devices. I've issued a potential fix here: https://github.com/ably/ably-flutter/pull/373, but I'd like to get some more information from your side. Can you please provide a list of development tools versions (MacOS, XCode, Swift, etc) and some information about build configuration of your projects?

Sure, here is my configuration:
MacOS Catalina 10.15.7
Xcode 12.3 (12C33)
Swift: version 5.3.2 (swiftlang-1200.0.45 clang-1<IP_ADDRESS>), Target: x86_64-apple-darwin19.6.0

some information about build configuration of your projects

minimum iOS version: 10
target iOS version: 12
@ikurek, feel free to ask any other information might be useful.
Sidenote: I'd like to report if everything is ok on Xcode 13, but sadly the shipping of the new Mac was delayed. I don't know when I'll be able to test this.
Meanwhile I'll try the potential fix.

@ikurek, I copied PushHandlers.swift from your commit, and I didn't work, BUT I received a different error than before, so that's not a bad news.

Command CompileSwift failed with a nonzero exit code
/Users/TheManuz/.pub-cache/hosted/pub.dartlang.org/ably_flutter-1.2.13/ios/Classes/handlers/PushHandlers.swift:29:71: error: failed to produce diagnostic for expression; please file a bug report
UNUserNotificationCenter.current().getNotificationSettings { [result] settings in
^
note: Using new build system
note: Building targets in parallel
note: Planning build
note: Constructing build description
Result bundle written to path:
/var/folders/h4/w21m7nm91qs6fq7w_tzyzrpr0000gn/T/flutter_tools.P7fvGO/flutter_ios_build_temp_dir1ysP8k/temporary_xcresult_bundle
Uncategorized (Xcode): Command CompileSwift failed with a nonzero exit code

Swift Compiler Error (Xcode): Failed to produce diagnostic for expression; please file a bug report
/Users/TheManuz/.pub-cache/hosted/pub.dartlang.org/ably_flutter-1.2.13/ios/Classes/handlers/PushHandlers.swift:28:70

@TheManuz Can you maybe add import UserNotifications at the beginning of PushHandlers.swift file? It's not directly imported into the file, maybe that's the case?

@TheManuz @lawrence-forooghian I've investigated the issue further, and managed to reproduce it with a few virtual environments. Here are some more complete error logs, before changes my PR introduced in the latest commit:
    /Users/vagrant/ably-flutter/ios/Classes/handlers/PushHandlers.swift:188:19: error: definition conflicts with previous value
            guard let handle = handle else {
                      ^
    /Users/vagrant/ably-flutter/ios/Classes/handlers/PushHandlers.swift:182:13: note: previous definition of 'handle' is here
            let handle: NSNumber? = ablyMessage.handle
                ^
    /Users/vagrant/ably-flutter/ios/Classes/handlers/PushHandlers.swift:192:19: error: definition conflicts with previous value
            guard let channelName = channelName else {
                      ^
    /Users/vagrant/ably-flutter/ios/Classes/handlers/PushHandlers.swift:183:13: note: previous definition of 'channelName' is here
            var channelName: String? = nil
                ^
    /Users/vagrant/ably-flutter/ios/Classes/handlers/PushHandlers.swift:28:153: error: unable to infer closure type in the current context
        public static let getNotificationSettings: (_ ably: AblyFlutter, _ call: FlutterMethodCall, _ result: @escaping (_ result: Any?) -> Void) -> Void = { ably, call, result in
                                                                                ^~~~~~~~~~~~~~~~~~~~~~~
    /Users/vagrant/ably-flutter/ios/Classes/handlers/PushHandlers.swift:198:53: error: value of optional type 'NSNumber?' must be unwrapped to a value of type 'NSNumber'
            let realtime = instanceStore.realtime(from: handle)
                                                        ^
    /Users/vagrant/ably-flutter/ios/Classes/handlers/PushHandlers.swift:198:53: note: coalesce using '??' to provide a default when the optional value contains 'nil'
            let realtime = instanceStore.realtime(from: handle)
                                                        ^
                                                               ?? <#default value#>
    /Users/vagrant/ably-flutter/ios/Classes/handlers/PushHandlers.swift:198:53: note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
            let realtime = instanceStore.realtime(from: handle)
                                                        ^
                                                              !
    /Users/vagrant/ably-flutter/ios/Classes/handlers/PushHandlers.swift:201:55: error: value of optional type 'NSNumber?' must be unwrapped to a value of type 'NSNumber'
            } else if let rest = instanceStore.rest(from: handle) {
                                                          ^
    /Users/vagrant/ably-flutter/ios/Classes/handlers/PushHandlers.swift:201:55: note: coalesce using '??' to provide a default when the optional value contains 'nil'
            } else if let rest = instanceStore.rest(from: handle) {
                                                          ^
                                                                 ?? <#default value#>
    /Users/vagrant/ably-flutter/ios/Classes/handlers/PushHandlers.swift:201:55: note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
            } else if let rest = instanceStore.rest(from: handle) {

and after the changes it introduced:
    /Users/vagrant/ably-flutter/ios/Classes/handlers/PushHandlers.swift:29:71: error: failed to produce diagnostic for expression; please file a bug report
            UNUserNotificationCenter.current().getNotificationSettings { [result] settings in
                                                                          ^

As far as I can tell, specific combination of XCode/MacOS/Swift versions has some sort of bug or undefined behavior, that causes compilation to fail due to those two reasons:

guard let handle = handle else { ... } structure, which was implemented in Swift a while ago, but it doesn't seem to be recognized correctly by the compiler
the catch of [result] in getNotificationSettings method

I am not able to figure out why the compilation fails, but I can proposed a solution that worked on all test environments that I was able to reproduce this issue on and updated https://github.com/ably/ably-flutter/pull/373.

@ikurek you did it! 🥳 It works!
Thank you very much!

@TheManuz Glad to hear that, and many thanks to @fredyshox for the virtual environments and debugging help 🙂

Closing this, since https://github.com/ably/ably-flutter/pull/373 is already merged 🙂


[SPARK-41200][CORE] BytesToBytesMap's longArray size can be up to MAX_CAPACITY

What changes were proposed in this pull request?
In BytesToBytesMap, the longArray size can be up to MAX_CAPACITY instead MAX_CAPACITY/2 since MAX_CAPACITY already take two array entries per key into account.
Why are the changes needed?
Fix bug to handle larger dataset in BytestoBytesMap
Does this PR introduce any user-facing change?
No
How was this patch tested?
Existings UT

cc @JoshRosen @cloud-fan

Can one of the admins verify this patch?


Can access user media. May be it is an error about https

When I used Npm Start Command, and use my computer to be the server. My phone can access the page at http://<IP_ADDRESS>:3000 (for examle) by Chrome, but When I choose one drawing or use raw drawings, the page says 'Can access user media'. I searched it online, It may be about https, However, I cannot solve it, can you help?

@ikaroscc  you should deploy your static files on https site. Only localhost and https sites can access user media.


Use \p{...} in Word Character Regex option

Hello,
First, thank you for you plugin, I can stop using Visual Studio Code for writing notes now 😄 !
The only thing is that there are a lot a diacritics in my words (such as é, ū, ṛ etc.) so I don't really want to type every single one of them in the Word Character Regex option.
But the problem is, the regex expression \p{...} doesn't seem to work here: I tried \p{L} and \p{Latin}, which should select all unicode latin letters, but it doesn't work.
Thank you for your help

I'm sorry. Unicode mode wasn't enabled for the character regex. You should now be able to use \p{L} or \p{Script=Latin} :)
Fix 34f2e3a0b2f622580b6609323a6b5f9658bbe523


[ENG-174] Feature/draft node api create reg

Purpose
Adding in functionality for the POST /registrations/ endpoint.
Changes
Various files picked from the feature/registries_submission_backend branch, and Uday's model changes.
QA Notes
Test that v2/nodes/<node_id>/draft_registration POST is still functional.
Test v2/registrations POST is functional
Documentation
Add documentation of the new endpoint.
Side Effects
There shouldn't be.
Ticket
https://openscience.atlassian.net/browse/ENG-174

subsumed by #9278


Nick: Watch 3mMTFIX(?#bit.ly)

Nick requests the watch of the watch_keyword 3mMTFIX(?#bit.ly). See the MS search here and the Stack Exchange search in text, in URLs, and in code.

3mMTFIX(?#bit.ly) has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Fix a typo

Thanks for the fixes!
Merging the PR requires signing Google's CLA, since this is a Google repository. Could you do that?

@abvbv Beep boop - is it possible for you to sign the CLA?

comment on this?
Could you sign the cla?


List reconstruction aggregate too much if no units or other quantities present in between

When we built the initial model we assumed that a unit was following a list.
Unfortunately there are cases where the list of item is just composed by numbers. In that case, the parse of the tagged data aggregate everything in the same list.
This could lead to have one big list containing all the elements of all the lists that appears consecutively in the text.

I'm thinking patch this to cut the list if the current item is more than 10 characters from the previous one.

Another mechanism to add is run the sentence segmentation and split the unit at the end of the sentence.

For the record it's implemented to cut the list if the current item is more than 8 tokens from the previous one. 8 is just an arbitrary number, which seems to work well enough


[PyGrid-0.4.0] Unable to a user to a group

Description
Any attempt to add a group to a user via POST /users/:user_id/groups is failing.
How to Reproduce
Attempt to post, for example:
{
  "groups": [1]
}

Expected Behavior
Add a user to the group.

Fixed.


TypeError: _extensionLink.default.configure is not a function (it is undefined), js engine: hermes

When trying to check the operation with a minimal implementation, a TypeError is output and cannot be checked.
I was struggling with the implementation of the editor and would love to use this library.
Thank you for your contribution to React Native!
dependencies
"@10play/tentap-editor": "^0.5.0",
"expo": "~50.0.17",
"react-native": "0.73.6",
"react-native-web": "~0.19.10",
"react-native-webview": "13.6.4",

Minimal implementation
import React from 'react';
import { KeyboardAvoidingView, Platform, StyleSheet } from 'react-native';
import { RichText, Toolbar, useEditorBridge } from '@10play/tentap-editor';
import { AppView } from '@/components/Themed';

export const ExampleScreen = () => {
  const editor = useEditorBridge();

  return (
    <AppView style={exampleStyles.fullScreen}>
      <RichText editor={editor} />
      <KeyboardAvoidingView
        behavior={Platform.OS === 'ios' ? 'padding' : 'height'}
        style={exampleStyles.keyboardAvoidingView}
      >
        <Toolbar editor={editor} />
      </KeyboardAvoidingView>
    </AppView>
  );
};

const exampleStyles = StyleSheet.create({
  fullScreen: {
    flex: 1,
  },
  keyboardAvoidingView: {
    position: 'absolute',
    width: '100%',
    bottom: 0,
  },
});

Error
 ERROR  TypeError: _extensionLink.default.configure is not a function (it is undefined), js engine: hermes
 ERROR  Invariant Violation: "main" has not been registered. This can happen if:
* Metro (the local dev server) is run from the wrong folder. Check if Metro is running, stop it and restart it in the current project.
* A module failed to load due to an error and `AppRegistry.registerComponent` wasn't called., js engine: hermes

Hey!
I just tried running your code with the same deps, and havn't gotten this error.
Perhaps you could share the repo with me and I'll try see if it reproduces for me.
Also I'm not sure how your project is structures, but if this is your app.js you'd want to
export const ExampleScreen = () => {
...
}

export default ExampleScreen;


When transferring BTC, fee doesn't match confirmation screen fee.

On the transaction screen it lists fee 0.0001 BTC
On the confirmation screen it lists fee 0.0000001 BTC
I have no clue how much fee was actually charged now.

Not fixed on rc04


Add signup_closed, for when adaptor disallows signup

Super helpful project, thanks for sharing!
This template comes into play if a custom adaptor is used to disallow manual signup, e.g.
# adapters.py
from allauth.account.adapter import DefaultAccountAdapter
from allauth.socialaccount.adapter import DefaultSocialAccountAdapter

class CustomAccountAdapter(DefaultAccountAdapter):
    def is_open_for_signup(self, request):
        return False

class CustomSocialAccountAdapter(DefaultSocialAccountAdapter):
    def is_open_for_signup(self, request, sociallogin):
        return True

# settings.py
ACCOUNT_ADAPTER = 'myproject.myapp.adapter.CustomAccountAdapter'
SOCIALACCOUNT_ADAPTER = 'myproject.myapp.adapter.CustomSocialAccountAdapter'

For the above, signup using configured social accounts would be allowed, but manual signup would be disallowed and clicking 'signup' on any page would display the template included in this pull request (handled by django-allauth automatically based on the return value of is_open_for_signup).

Released as 0.2.2


feature: Lazy always reclones itself with git

Did you check the docs?

[X] I have read all the lazy docs

Is your feature request related to a problem? Please describe.
It's impossible to manage Lazy with something like Nix because it always reclones itself.
Describe the solution you'd like
A way to disable this functionality.
Describe alternatives you've considered
Not sure what else could be done with this.
Additional context
No response

This might be similar to a problem I am trying to solve. I would prefer to check lazy.nvim into source control rather than have an arbitrary version sourced from github. (think lockfile support, but for lazy.nvim itself)
I simply copied the contents of the lua directory into my own .config/nvim/lua/lazy directory and checked it in. This generally works ok.
However I had to modify the code due to the :Lazy install attempting to parse the help docs which don't exist.
i.e I had to stub out https://github.com/folke/lazy.nvim/blob/main/lua/lazy/help.lua#L41
Despite being a different approach I believe the problem is the same - wanting to use a deterministic revision of lazy.nvim for repeatable / predictable environment creation.
Would be good if either the docs and/or the code supported this, with the same justification as the lockfile support for all other plugins.

@smhc you could just specify the commit or version you want lazy to be in your spec? No need to copy the code

You can now add the following to your specs, to disable the lazy plugin.  No need to copy the code.

@folke I guess so, but isn't this a chicken-and-egg situation? What revision of lazy.nvim is reading this spec? Presumably it is the revision that is cloned via the bootstrapping:
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    "--branch=v7.9.0",
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

But if you specify a tag to clone (for stability and avoiding regressions) why do you need to specify it again in the spec file? I guess using 'enabled=false' is the way to go to avoid this self-management of lazy.nvim.
I find the self-management a bit awkward due to the chicken-and-egg situation described above. The initial installation for a bootstrapped environment will use whatever branch is cloned at startup, not what is specified in the spec.
Anyway, thanks for the great plugin, it's very slick.

You obviously should both add the same for both the bootstrap code and the spec for lazy itself. {"folke/lazy.nvim", version = "*"}.
You need to add it in the spec for updates.

Personally, I use the following snippet for bootstrapping.
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.notify("Installing package manager...")
  vim.fn.system { "git", "clone", "--single-branch", "https://github.com/folke/lazy.nvim.git", lazypath }
  local f = io.open(vim.fn.stdpath("config") .. "/lazy-lock.json", "r")
  if f then
    local data = f:read("*a")
    local lock = vim.json.decode(data)
    vim.fn.system { "git", "-C", lazypath, "checkout", lock["lazy.nvim"].commit }
  end
end

The idea is to clone lazy directly with the version from lockfile, so you won't need to maintain the version twice in your config.
And everything will work as expected, including update, sync, restore, etc.

Yep thanks @WilliamHsieh , this is kind of what I was getting at. Having lazy.nvim maintain it is kind of pointless if you have to update the "locked commit" yourself in the bootstrapping logic anyway to keep it in sync and the config sane. Your solution resolves that.
I'm ok to stick with a single git clone --branch x and using 'enabled=false' in the spec for now, but may look at using your bootstrapping later.


rkt/image_gc: don't fail hard when unable to get some treestore IDs

If we can't get some treestoreIDs from the pods, those pods are in a
broken state and we can remove the treestore (if not referenced by some
other healthy pods).
This avoids cases where treestores can't be removed because of damaged
pods.
Fixes https://github.com/coreos/rkt/issues/2180

In this version, walkErr is never assigned, so testing walkErr != nil is not needed.

In this version, walkErr is never assigned, so testing walkErr != nil is not needed.

I should remember not to push code when I'm about to leave :)

LGTM


[GSSoC'23] Leap Years In the given Range Project Ready

Title and Issue number

Title - Leap Years In The Range
Issue Number - 2446
Close #2446

Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md

@pranjay-poddar @MohitGupta121 @Saurabh-kumar09 Sirs, please review this pull request and requested to merge it into the main branch for a successful contribution under GSSoC'23 program


Update how-to-cluster-the-master-secret-server1.md

Fixed the register key adding a separator

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

biztalk/core/how-to-cluster-the-master-secret-server1.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


able to run on windows OS?

Hello, great job there.
I was just wondering if the project is able to run on windows and what are the necessary additional installation required if I want to apply it on windows.
I faced this error when I tried to run infererence.py

C:\Users\PycharmProjects\vocal-remover-master>python inference.py --input C:\Users\Downloads\GreenhouseGirl.wav
loading model... Traceback (most recent call last):
File "inference.py", line 91, in
main()
File "inference.py", line 30, in main
model.load_state_dict(torch.load(args.model))
File "C:\Python35-64\lib\site-packages\torch\serialization.py", line 419, in load
f = open(f, 'rb')
FileNotFoundError: [Errno 2] No such file or directory: 'models/baseline.pth'


fix: client tests

Will take care of #132 when merged to main.
To test:
cd client
npm run coverage
Ensure successful test run and that the coverage report prints to the console.

nice, thank you


Add lang attribute to contents list

What
Add a function to Whitehall TranslationHelper which detects whether a translation is using the current locale or falling back to the default locale. Use this method to add the lang attribute to contents list items when appropriate.
Why
We have some cases where a translated page contains links that are still in English, because we do not have the translations for that particular langauge (example here). These currently don't have the lang attribute, meaning a screenreader thinks the text is in the same language as the page. This PR adds`lang="en" when the text is falling back to English.
Before (no lang present)

After

Notes
There doesn't seem to be a built-in I18n method for detecting which locale is serving the translation. The closest they have is the I18n.exists? method. This doesn't work for our use case as it takes fallbacks into account, so it will return true for I18n.exists?(:de, "people.biography") even if that translation doesn't exist, as long as an English translation exists.
Other approaches considered:

Removing the ability to translate these strings and always marking the section as english. This means we wouldn't have mixed languages on the page, but ideally we want to make the most of the translations we have, especially if we may add more in the future.

Trello: https://trello.com/c/Uq7gAzCu/13-3-mark-language-as-english-on-subscription-links

 (3) Mark language as English on subscription links

 Mark contents list for mixed language pages


Doesnt removed unsubscribed mods

I've unsubscribed from a few mods but they still show in the mod list and there's no way I can see that will recheck subscribed list against Steam.
So now the mod manager sees 99 mods when I only have 92 subscribed in Steam.
The official mod manager sees the 92 correctly.

I have the same problem

Yes these mods constantly get added for me when TWW3 decides to validate or do an update daily. I am not subscribed to them, but for some reason they keep being re-downloaded.

I've realised that this might be one mod that I'm subscribed to bringing in the other mods when it installs.
In my case I use SFO which brings in a few other mods internally which get downloaded to the workshop steam folder without me being subscribed to them directly.
This mod manager reads that workshop folder so it finds those mods and lists them.

I assume they're in content (SteamLibrary\steamapps\workshop\content\1142710\xxx). Steam should be doing cleanup after you unsubscribe from a mod and delete those folders. The mod manager works by looking at all the packs that exist there, it's possible the CA launcher checks what mods you are subscribed to as well, but that's not really something I think should be done.

@Shazbot I don't have any mods in content, yet they all show up in the mod manager.😕
Mod Manager screenshot:

Content folder:

Yes this keeps happening to me too but I'm not convinced it's Mod Managers fault to be honest. It could easily be an internal history of mod subscriptions that CA keeps that makes those mods to be downloaded - not sure.
The pattern I've notice is that this happens when I subscribe to a mod that I used to have on a previous mod list and it will bring in a group of other mods from that past list and add them as I had subscribe to them.
Going to the Subscribed items on Steam I don't see them there as subscribed nor I see them in the CA's Mod Manager but they are indeed downloaded in the content workshop folder.
It recently just happen to me where 24 extra mods that I never subscribed but had in the past reappeared and I had to Unsubscribe the mods that came in incorrectly one by one in the WH3 Mod Manager and then restart the application for them not to be listed.
This is the Subscribed Items in Steam - 110 mods

This is the Subscribed Items and Enabled (I have all enabled) in WH3 Mod Manager after unsubscribing manually the extra incorrect ones that appeared (it was showing 134 before - so 24 more that I never subscribed)

This is the CA Mod Manager showing the correct 110 mods and it never showed 134 mods

This is the content workshop folder which as you can see still has the 134 folders which WH3 Mod Manager was listing but the CA Mod Manager wasn't.

Notice that his content folder should always clear unsubscribed mods/folders so the folder count should be 110 to match the subscribed items on Steam.
I'm going to close all mod managers and delete all the folders in the content folder.

Opening the CA Mod Manager I can see the 110 Mods and starting updating all the mods as expected

The WH3 Mod Manager is showing empty as expected

And now after the update is done (not even fully) it already shows 134 mods in the content folder

And now the WH3 Mod Manager reads the full 134 mods that exists in the content folder even though I'm subscribed to 110 mods

This makes me think it's CA Mod Manager that has an internal cache of past subscribed mods that is not clearing correctly when we unsubscribe even though the CA Mod Manager is able not to list them it still requests to Steam to be downloaded somehow.
I've tried to find any file that would potentially hold this old list but I think it's not exposed and it's internal to the their mod manager.
I've checked the file in the steamaspp used_mods.txt but it lists correctly the 110 mods

I've event deleted the launcher cache folder before doing this and I had the same behaviour happening

@Shazbot If this gives you some clue of what could be happening and potential solutions we would all really appreciate it 🙏


Update release_docker_container.yaml

Add Conditional Build and Push: Enable optional image testing before pushing. This would help verify that images build correctly before being pushed to Docker Hub.
Enhanced Error Handling: Add fail-safe mechanisms, such as notifications or continue-on-error, for non-critical steps like cleanup. Also, explicitly handle errors in steps where failures should be alerted.
Caching for Faster Builds: Use a cache from Docker Hub to speed up builds, particularly useful when dependencies or base images remain the same across builds.

I will check


Stop double-checking priority queue inserts

Description
There are several occurrences in our code where we check that an incoming value can be inserted in a priority queue and then call insertWithOverflow, which re-does the check. Let's stop checking before calling insertWithOverflow.
Credit to @epotyom for noticing this in AbstractSortedSetDocValueFacetCounts.

Maybe we can also extract out a common function from all the Facets inserting into a priority queue, as @Shradha26 suggests.


contains-string-failed-output.eo:29-31: Enable the tests...

The puzzle 218-b18d8585 from #218 has to be resolved:
https://github.com/objectionary/eo-hamcrest/blob/298bd4884878fbdcd1bac2a2aa35b22603bf18e4/src/test/eo/org/eolang/hamcrest/failed-output/contains-string-failed-output.eo#L29-L31
The puzzle was created by levBagryansky on 17-Oct-23.
Estimate: 90 minutes,  role: DEV.
If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

@graur please pay attention to this new issue.


Issue Building With Bazel

Fully Homomorphic Library with Bazel in Container Environment.
Created a new example in Fully Homomorphic Library using openfhe  https://github.com/openfheorg/ library.
The example I am trying to run is https://github.com/openfheorg/openfhe-development/blob/main/src/pke/examples/simple-integers-serial-bgvrns.cpp
The example runs fine when I compile and execute openfhe as a standalone project (independent of Fully Homomorphic Library).
When I try to run the same example using bazel as part of Fully Homomorphic Library, I get a compilation error, show below

My steps:
A. I had cloned the repo
B. Created a new folder in examples to host my example code and made a new BUILD file
C. The build file is

Everything else in the project is constant, and not been altered.
Trying to understand why the openfhe example is not working within the Fully Homomorphic encryption Library.

I would recommend re-running with --sandbox_debug and --verbose_failures to get more information about the source of the issue.
Also, please try running an existing openfhe example first to confirm the build issue is not specific to your example.

The dependent library (OpenFHE) has been updated a lot since this issue was first filed, and I've been taking some time to clean up external usability issues. I would recommend trying the build again, and in the mean time I will close this issue and you can reopen if you see further issues.


Added a hello world example to the OpenGL guide

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Congrats @PucklaMotzer09 on your first pull request (PR)! 🎉
Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝


[5782] Amended so that the csv is downloaded as a stream

Context
Return csv as a stream
Changes proposed in this pull request
Amended to return csv as a stream
Guidance to review
There is a wider deliberation for the whole csv ecosystem that has been implemented.
All the current one does the calculation and generation before the file can be saved.
Important business

[ ] Does this PR introduce any PII fields that need to be overwritten or deleted in db/scripts/sanitise.sql?
[ ] Does this PR change the database schema? If so, have you updated the config/analytics.yml file and considered whether you need to send 'import_entity' events?
[ ] Do we need to send any updates to DQT as part of the work in this PR?
[ ] Does this PR need an ADR?

NB: Please notify the #twd_data_insights team and ask for a review if new fields are being added to analytics.yml

 Spike: Test exporting large number of trainees on Report page

Looks good, I've tested this out locally and it's defo the best way to go forward (vs scenic alternative). The file download is kicked off asynchronously by the browser so the user isn't waiting for the app to respond.

 Stream large number of trainees on Report page


Disable Ruff lint

Is there anyway to disable ruff  linting completely and leave it only for formattiong? I'm using a NeoVim configuration with Mason. What I have is a double display for linting in basedpyright and ruff:

My previous attemts to set up configuration using help from #12514 and #12778 had no effect.

Have you tried setting lint.enable
I'm not really familiar with neovim

Sent request. My config is used by AstroNvim. I tried to put the code at different places, but still nothing seems to work.

Can you share your Neovim config? I'm specifically interested in how you've setup basedpyright and Ruff. Which plugins are you using to set them up? Is it just nvim-lspconfig or do you have any other plugins as well?

Basically,  basedpyright and ruff installed via Mason, and it configures using AstroNmiv nested structure. Unfortunately, I haven't been able to find the same configuration for ruff, because it implies that user would be using it as a main linter, instead of  basedpyright. Here is an example: https://github.com/astral-sh/ruff-lsp/issues/384#issuecomment-2038623937
ruff works from the package, and I can't manage to configure it inside my nvim-config.
My basedpyright_config.lua:
-- if true then return {} end -- INFO: REMOVE THIS LINE TO ACTIVATE THIS FILE
return {
  "AstroNvim/astrolsp",
  opts = {

    servers = {
      "basedpyright",
    },

    ---@diagnostic disable: missing-fields
    config = {
      basedpyright = {
        before_init = function(_, c)
          if not c.settings then c.settings = {} end
          if not c.settings.python then c.settings.python = {} end
          c.settings.python.pythonPath = vim.fn.exepath "python"
        end,
        settings = {
          basedpyright = {
            analysis = {
              -- ignore = { "*" },
              -- autoImportCompletions = true,
              -- autoSearchPaths = true,
              diagnosticMode = "openFilesOnly",
              useLibraryCodeForTypes = true,
              -- reportMissingImports = true,
              typeCheckingMode = "standard",
            },
          },
        },
      },
    },
  },
}

Unfortunately, I haven't been able to find the same configuration for ruff, because it implies that user would be using it as a main linter, instead of basedpyright.

I'm not familiar with AstroNvim but are you saying that Ruff is configured to be the default linter in that framework and you're interested in using Ruff only as a formatter? I couldn't find any references to "ruff" in the repository (https://github.com/search?q=repo:AstroNvim/AstroNvim ruff&type=code). It's a bit difficult to help without knowing the way you've configured Ruff in your editor 😅

That's the point, it isn't configured at all, but still works. I will ask in a forum of AstroNvim for this.

Have you tried setting lint.enable
If you need more help, please share your neovim configuration.
Here how you, presumably, can configure the same code in AstroNvim:

.../plugins/ruff_config.lua:
return {
  "AstroNvim/astrolsp",
  opts = {
    ruff_lsp = {
      settings = {
        ruff = {
          lint = {
            enable = false,
          },
        },
      },
    },
  },
}

But still I get the same double-linting. Will be waiting for the reply from AstroTeam.

Can you confirm (via docs?) the name of the Ruff server as defined in the plugin? Is it ruff_lsp or ruff (native server)? Either way, it should be init_options instead of settings if these are the server settings.

Yeah, it's true.


mod_eventful

We are using Ubuntu 14.04.5 LTS on which we have installed ejabbered 2.1 but given plugin is not working the issue was also initiate by other developer  They have mentioned that in Ubuntu 12.04 os its working fine but not in Ubuntu 14.04.5.
Can you please look into this issue ?
Any Help would be appreciated.

We have checked error log under
var/www/ejabbered/ejabberd.log and found that..
{'module could not be loaded',
[{http,request,
[post,
{"http://<IP_ADDRESS>/messages",
[{"Authorization",
"Basic SFRUUCBCQVNJQyBVU0VSTkFNRTpIVFRQIEJBU0lDIFBBU1NXT1JE"}],
"application/x-www-form-urlencoded",
"from=kandhal%40<IP_ADDRESS>/15310114851488363705601144&to=hitesh%40<IP_ADDRESS>&type=chat&subject=&body=%7B%22isdownload%22:false%2C%22issent%22:false%2C%22fromuserid%22:%22kandhal%40<IP_ADDRESS>%22%2C%22ptopid%22:%22%22%2C%22messageid%22:%221488363577548%22%2C%22message_time%22:%221488363577911%22%2C%22mediathumb%22:%22%22%2C%22is_read%22:false%2C%22isseen%22:false%2C%22fromprofilepic%22:%22%22%2C%22isread%22:false%2C%22messagesource%22:%22VGhlIG9ubHkgcHJvYmxlbSBJIGhhZCB3YXM%3D%22%2C%22messagetype%22:%22text%22%2C%22fromusername%22:%22Kandhal%20AB%22%7D&thread="},
[],
[{sync,false},{stream,self}]],
[]},
{mod_eventful,handle_call,3,
[{file,"src/web/mod_eventful.erl"},{line,188}]},
{gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,585}]},
{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]}
This log may help to get more into it.

Hi,
This project is deprecated. I can no longer offer any support on it.
Thanks,
Theo


Feature: fallback to swapping lines if not in a list

I think it just makes sense, and I have found myself wanted to swap lines of code sometimes.
Could also fallback ISwap -> ISwapNode and ISwapWith -> ISwapNodeWith instead but I think this has much less utility.

hmm.... why can't the user just call the right function? Also iswapnode would work with expressions spanning multiple lines while naively swapping lines wouldn't, and I'm not sure if the latter is in the scope of my plugin

Maybe it's just my preference, I like having just one keybinding or as few keybindings as I can for similar functions. It's why ive moved from 10 hop keybindings with treesitter stuff to just using leap.nvim to go anywhere. The thought process then simplifies from "I want to swap these things, they are lines, click the right key sequence and then labels" to "I want to swap these things, click the key sequences and then labels"
My idea was to add that as a fallback when we're not in the list, so not changing anyone's workflow just trying to make a guess at what the user might want, they can always Esc and cancel it.
I might try and code it up as a user configurable fallback function, or even user configurable target selection, and see how it fits in my workflow


Add Acouslic-AI dataset

This is the dataset for segmentation of fetal abdominal circumference in US scans. This could potentially be another OOD dataset.

This dataset is GTG from my side!


File Explorer tab

📝 Provide a description of the new feature
What is the expected behavior of the proposed feature?  What is the scenario this would be used?
A File Explorer tab like Chrome tab. There's already some software, but it's not smooth enough.
If you'd like to see this feature implemented, add a 👍 reaction to this post.

same like #10
closed.

same like #10
closed.

Duplicate of #10

Duplicate of #10


Logger methods should take multiple arguments?

I just finally realized that the Appender.debug interface is much more flexible than the Logger.debug interface.
Logger.debug() accepts only a single string parameter, whereas the Appender is capable of supporting multiple parameters. The way it stands, I don't see how Appender.debug() will ever see anything more than a single string parameter if used via well-behaved (type honoring) Loggers?
I need this variadic function behavior supported at the Logger interface level (In my specific use case I have a custom appender that uses a log  title:string and details:string for each log message (two params) and end users should be able to specify both a title and a string through the Logger interface)
Am I missing something here or must we redefine Logger to accept variable params on the main debug,info,warn,error methods?

We just need to fix up the typing. Would you be interested to submit a PR to make that correction?

#22 Link To PR

Merged PR. Thanks!


Env map is reversed

I didn't see this one mentioned.
Seems like env maps are mirrored from how they appear in Cycles.  I don't see a way of flipping the texture
examples:

PRMan render

Cycles render

This may sound hackish but you can scale the environment light to negative one X. This produces a flipped texture. Not the best solution but effective

That hack didn't work for me.  Even tried checking 'always recompile textures' in the options tab.

Hold up, might have been user error.  I think I made a mistake with the hemi lamp settings.  I deleted the existing one, added a new one and rendered.  Now it's matching up with Cycles after a 90 degree rotation along the Z axis.  Sorry for the false issue.

Yes i should be flippig by default...


[OpenCV3] fix protobuf linking

Fix required to properly build the opencv[dnn] feature.
Many other features still broken, see #4808 for my findings while trying to use the current port.

@cenit
I just tested to build opencv 3.4.3 x64-windows  with protobuf v3.6.1-4, and on VS2017 v15.9.2. The build succeeded without error. Can you show me what the error was for your linking problem?

There is no problem while building opencv[dnn], you can experience them while using the library in a downstream project ;)
This PR also simplify the port, so I don't see any problem in adopting it

Confirmed this fixes opencv[dnn] -- thanks a bunch for the PR!


Frontend Project "Sudoku Solver" Buttons Hover Effect Addition

Title and Issue number
Frontend Project "Sudoku Solver" Buttons Hover Effect Addition
Close #3450
Output
Before

After

Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have created a helpful and easy to understand README.md

@MohitGupta121 Kindly review this pr.


In OpenFin, windows no longer snap dock after leaving a group that was previously docked

Steps to reproduce:

Start example OpenFin app
Create child window
Snap two windows together
Click leave group from one of the windows

Reproducible in runtime <IP_ADDRESS> but not <IP_ADDRESS>.  Current workaround is to downgrade referenced runtime to <IP_ADDRESS>.

As windows leave groups the frame is re-enabled.  The snap layout manager will need to listen for windows leaving groups and re-enable the disabled frame api.