Significant build regressions on swift:6.0-noble compared to 5.10-noble

Description
Absolutely massive Significant build regressions on linux , worsened by swift-testing
EDIT: Please also read my next comment which includes more info.
Environment

GitHub Actions
8 CPU x 16GB RAM c7x EC2 Instance (we use RunsOn)
Migrating from swift:5.10-noble to swift:6.0-noble
Tried with and without using a previous .build cache. No behavior difference noticed at all.
200K-300K LOC project
Updated to // swift-tools-version:6.0 in Package.swift
All targets still have Swift 5 language mode enabled.
No actual tests migrated to swift-testing just yet.

What Happened?

Our Tests CI started getting stuck after the toolchain update.
The CI machines were getting killed by AWS. Considering this has been a common problem specially in the Server Side Swift ecosystem, which also has been brought up for ages and numerous times, my first guess was that the machine is running out of RAM when building the Swift project.
After a lot of tries, I noticed a c7x-family machine with 64 CPU x 128 GB RAM (8x larger than before) runs the tests as well as they were being run before, on swift 5.10.
My first guess was that maybe Swift testing is causing an issue, so tried --disable-swift-testing.
After that, our tests have been running on an only 2x larger machine, and the rest of the things are back to normal in tests CI.
With this bigger machine, it still almost takes as long as before for the tests CI to complete (we run tests in parallel with 64 workers).
So this means that not only Swift 6 has a significant build regression, but also swift-testing makes it go from significant to absolutely massive.
This is borderline unusable for the Swift-Server ecosystem. I hope this problem requires more specific situations to happen that what meets the eye.
Still trying things out with the deployment CI. even 2x CPU and 4x RAM isn't proving helpful even though I did throw the --disable-swift-testing flag into the mix.

Reproduction
Not sure.
Expected behavior
No regressions. Preferably even faster than previous Swift versions.
Environment
Mentioned above.
Additional information
No response

Some notes, in no particular order (will update if I think of more):

@stmontgomery's and my initial reaction is that this is probably not related to Swift Testing since this project hasn't added any Swift Testing tests yet.
--disable-swift-testing does not affect the build. It did for a while with prerelease Swift 6 toolchains before we added Swift Testing to the toolchain, but it has no effect on the release toolchain. Only one build product is produced for a test target, and it's the same either way. It does affect whether or not a second test process is spun up after building to run Swift Testing tests.

It is normal to see text output from Swift Testing when you run swift test even if you don't have any tests using it. The output is basically just saying "didn't find any Swift Testing tests, bye now." If you pass --disable-swift-testing, it suppresses spawning the process that looks for Swift Testing tests, which is why you don't see any output from it when you pass that flag.

Swift Testing is available in Swift 5 language mode so long as you're using a Swift 6 toolchain. Language mode isn't a factor.

To be clear:

I don't think it was necessarily swift-testing doing something wrong. More-likely the compiler or SwiftPM mishandling it.
Even without swift-testing there is a significant build time regression, when the build ends at all. The benchmarks below show it properly.

It's very sad to see the [Linux] build situation constantly getting worse despite us asking for faster and less-RAM-hungry builds for ages.
Based on the lots of user reports we consistently have over on the Vapor Discord server, a lot of deployment services have blocking problems with building Swift projects since their builders run out of RAM. As you can imagine, this can be a significant obstacle in deploying server-side Swift apps.
Just ask the SSWG folks @0xTim / @gwynne if you have any doubts.

Anyways, let's head to the benchmarks I did. I likely ran 500+ CI jobs in the past 48 hours ...
Note that we do use a couple of macros. All self-served. One of them lives in an external repo.
Tests CI

Tests CI machine sizes are compared to what we had for swift:5.10-noble: 8 CPU x 16GB RAM c7x EC2 Instance.

Other than "Same", the other machines are of the m7x family which have the higher RAM ratio.

In the tests below, I tried both with and without --disable-swift-testing. Results are only marginally different.
There are 3 variables in build times. 1- usage of cache 2- build-step time  3- tests-build/run-time.

The table below contains 2 of the variables.
If cache-usage and build-step-time have not changed but the run-time has changed, It means it was because of the tests-run/build time.
We build the package, then cache .build, and then run the tests in another step.
The tests-build/run-step does also build something more. I'm not sure what, but it seems like it does.
Build-step command: swift build --explicit-target-dependency-import-check error --build-tests
Tests-build/run-step command: swift test --enable-code-coverage --parallel --num-workers 64

Image
Machine Size
w/ cache total
w/ cache build
no cache total
no cache build

5.10-noble
Same
12m 53s
3m 7s
19m 37s
7m 34s

5.10-noble
2x RAM
13m 41s
3m 16s
21m 9s
7m 55s

5.10-noble
4x RAM 2x CPU
9m 19s
2m 40s
16m 37s
6m 18s

6.0-jammy
Same
15m 21s
3m 12s
24m 8s
9m 14s

6.0-jammy
2x RAM
16m 18s
3m 25s
25m 1s
9m 36s

6.0-jammy
4x RAM 2x CPU
9m 5s
2m 17s
17m 15s
6m 15s

6.0-noble
Same
17m 21s
5m 10s
23m 31s
9m 9s

6.0-noble
2x RAM
18m 32s
5m 42s
23m 34s
9m 1s

6.0-noble
4x RAM 2x CPU
9m 47s
2m 59s
18m 42s
6m 43s

(Side note: I didn't know using higher RAM could hurt?! I don't think it's a machine-type problem since the deployment builds below show the expected behavior of some performance improvements when having access to more RAM.)
Analyzing the results (Excluding the bigger 4x RAM 2x CPU machine):

30% worse tests-build/run-step performance on 5.10-noble compared to 6.0-jammy.

The exact tests-build/run-step numbers are not in the table. It would hover around 7-11 minutes.

60+% worse build performance in the build-step w/ cache, on 6.0-noble compared to 6.0-jammy.
Overall ~40% worse build performance when moving from 5.10-noble to 6.0-noble.
A bit of the regressions (which is not included in the comparisons above, but visible in the total time) goes back to our "cache .build" step which uses the actions/cache which apparently doesn't properly handle the big 2GB .build directories.

Deployment CI

Deployment CI machine sizes are compared to what we had for swift:5.10-noble: 4 CPU x 8GB RAM c7x EC2 Instance.

Other than "Same", the other machines are of the m7x family which have the higher RAM ratio.

Compared to the tests builds, deployment builds lack --build-tests, use jemalloc, and only build the certain product that will be deployed.

jemalloc might be why the behavior is worse than test builds?!

Image
Machine Size
w/ cache total
w/ cache build
no cache total
no cache build

5.10-noble
Same
4m 19s
2m 37s
13m 27s
9m 1s

5.10-noble
2x RAM
3m 31s
1m 49s
12m 29s
9m 12s

5.10-noble
4x RAM 2x CPU
4m 7s
2m 14s
9m 47s
6m 9s

6.0-jammy
Same
6m 25s
3m 7s
OOM
OOM

6.0-jammy
2x RAM
3m 40s
2m 0s
13m 57s
10m 14s

6.0-jammy
4x RAM 2x CPU
4m 39s
2m 39s
10m 7s
6m 32s

6.0-noble
Same
OOM
OOM
OOM
OOM

6.0-noble
2x RAM
OOM
OOM
OOM
OOM

6.0-noble
4x RAM 2x CPU
6m 12s
4m 10s
11m 6s
7m 21s

Only notable change when I moved our app to Swift 6 compiler, is that we have 3 executable targets which Swift was throwing errors about e.g. using @testable on those, so what I did is that I added 3 more .executableTarget targets, marked existing targets as just .target, and the .executableTargets only have like 5 lines in each to call the original target's entry-point.
This way we can still @testable import the original target.
You may ask: "Didn't you say you needed 8x larger machine to run the tests? How come this time they ran even on the same machine as you had before when using swift:5.10-jammy?!"
That's a good question.
I tried multiple times yesterday, result of which is still available in GitHub Actions. I was even live-texting the results over on the Vapor Discord Server in a thread. I also sent a sample of such failing logs to @grynspan.
I also did check and the swift:6.0-noble images from yesterday and today are the same (have matching hashes).
I know there hasn't been any other changes since yesterday to the project, so not exactly sure why the tests are going with no getting-stuck today. I have no complaints about that. Though the deployment CI does still get stuck.
So:
Yesterday I reported that there seem to be 2 problems, one a general build time regression, second one a massive regression when not using --disable-swift-testing. Today I'm unable to reproduce the latter.
Something's really up. And It definitely isn't the Swift code since that hasn't changed.
I don't think it's the AWS machines we use either, those are just standard EC2 instances.
The only thing I can think of is our cache usage. Maybe Swift 6 was using Swift 5's caches and didn't like that at all. But even then, I remember testing both with and without cache. I've set the CI to disable usage of caching when you rerun a job, so it was trivial to test both scenarios.
Worth mentioning, when the build is stuck, I consistently see a sequence of logs like this, containing Write Objects.LinkFileList around the end:
[6944/6948] Wrapping AST for MyLib for debugging
[6946/6950] Compiling MyExec Entrypoint.swift
[6947/6950] Emitting module MyExec
[6948/6951] Wrapping AST for MyExec for debugging
[6949/6951] Write Objects.LinkFileList

This almost starts to sound like a recurrence of the infamous linker RAM usage problem due to huge command lines with repeated libraries. @al45tair Is there any chance we're still failing to deduplicate linker command lines fully?

Is there any chance we're still failing to deduplicate linker command lines fully?

Yes, I pinged you on that last month, but never got a response. A fix was just merged into release/6.0 in #76504, so it will not be released until 6.0.2 or 6.0.3.
@jmschonfeld or @shahmishal, can that fix be prioritized to get into the next patch release?

@MahdiBM, thanks for all the build info. Do you do any CI builds of the 6.0 snapshot toolchains before the final release? That would help find and stop build regressions like this when they happen, rather than being surprised on the final release.
If you can, I'd like to know how an earlier 6.0 July 19 snapshot toolchain build for jammy does on these same CI runs of yours. That might help figure out the regression, particularly if you compare it to the next July 21 build of the 6.0 toolchain.

@MahdiBM, thanks for all the build info. Do you do any CI builds of the 6.0 snapshot toolchains before the final release? That would help find and stop build regressions like this when they happen, rather than being surprised on the final release.

@finagolfin this is an "executable" work project, not a public library, so we don't test on multiple image versions.
I think it would be possible for us though to do such a thing on the next nightly images. Not a bad idea to catch these kinds of issues.
The only problem is that how reliable the nightly images are? Do they not have assertions and such enabled which makes the build slower? How can I trust the results? Do I need to run current-nightly and next-ver-nightly and compare those?
I can set up a weekly job perhaps 🤔

If you can, I'd like to know how an earlier 6.0 July 19 snapshot toolchain build for jammy does on these same CI runs of yours. That might help figure out the regression, particularly if you compare it to the next July 21 build of the 6.0 toolchain.

We just use docker images in CI. To be clear, the image names above are exact Docker image names that we use (added this explanation to the comment). I haven't tried or figured out manually using nightly images, although I imagine I could just use swiftly to set up the machine with the specific nightly toolchain and there should be little problems. It will make the different benchmarks diverge a bit though in terms of environment / setup and all.
Preferably, I should be able to just try a nightly image if you think that'll be helpful, just let me know what exact nightly image (the image identifier (hash) and tag ?).
Or I can try a newer 6.0 nightly image that does contain the linker RAM usage fix? If such already exists.

Another visible issue is the noble vs jammy difference ... I don't think I could have caught that even if we were running CIs on nightly images, considering Swift 6 just very recently got a noble image.
Not sure where that comes from. Any ideas?

I would guess that even on 5.10, the jammy images would behave better than the nobles. Though haven't tested that.

My guess is that difference comes from the updated glibc in noble; when going from bionic to jammy we saw a significant improvement in malloc behavior for that reason, I wouldn't be too surprised if noble regressed some.

The only problem is that how reliable the nightly images are? Do they not have assertions and such enabled which makes the build slower? How can I trust the results?

I don't know. In my Android CI, the latest Swift release builds the same code about 70-80% faster than the development snapshot toolchains. But you'd be looking for regressions in relative build time, so those branch differences shouldn't matter.

Do I need to run current-nightly and next-ver-nightly and compare those?

I'd simply build with the snapshots of the next release, eg 6.1 once that's branched, and look for regressions in build time with the almost-daily snapshots.

I can set up a weekly job perhaps

The CI tags snapshots and provides official builds a couple times a week: I'd set it up to run whenever one of those drops.

Preferably, I should be able to just try a nightly image if you think that'll be helpful, just let me know what exact nightly image (the image identifier (hash) and tag ?).

I don't use Docker, so don't know anything about its identifiers, but I presume the 6.0 snapshot tag dates I listed should identify the right images.

Or I can try a newer 6.0 nightly image that does contain the linker RAM usage fix? If such already exists.

Not yet. The fix was added to trunk a couple weeks ago, so you could try the Sep. 4 or latest 6.1 snapshot build with it and compare to the Aug. 29 build without it.
You may also want to talk to @ktoso and the SSWG about what kind of toolchain benchmarking exists to catch these issues on linux and what needs to be done to either start or augment it.

If you can log into the build machine and watch memory usage with top, it should be a lot clearer what's going on.  There's a big difference between linker and compiler, as noted above.  There's also a big difference between "the compiler uses too much memory" and "the build system is running too many compilers at the same time."

@tbkka I can ssh into the containers since RunsOn provides such a feature, but as you already noticed, I'm not well-versed in compiler/build-system workings. I can use top but not sure what or how to derive conclusions about where the problem is.
It does appear @gwynne was on point though, about linker issues.

You may also want to talk to @ktoso and the SSWG about what kind of toolchain benchmarking exists to catch these issues on linux and what needs to be done to either start or augment it.

@finagolfin I imagine SSWG is already aware of these long standing problems and I expect they have already communicated their concerns in the past few years, just probably haven't managed to get it up in the priority list of the Swift team. I've seen some discussions in the public places.
Even if there were no regressions, Swift's build system looks to me - purely from a user's perspective with no knowledge of the inner workings - pretty behind (dare I say, bad), and one of the biggest pain points of the language. We've just gotten used to our M-series devices build things fast enough before we get way too bored.
Though I'm open to help in benchmarking things. I think one problem is that we need a real, big, and messy project like what most corporate projects are, so we can test things on real environments.
There is the Vapor's penny-bot project that shouldn't a bad start though. Not small, also with a fine amount of complexity.

@MahdiBM, I have submitted that linker fix for the next 6.0.1 patch release, but the branch managers would like some confirmation from you that this is fixed in trunk first. Specifically, you should compare the Aug. 29 trunk 6.1 snapshot build from last month to the Sep. 4 or subsequent trunk builds.

Moving the thread about benchmarking the linker fix here, since it adds nothing to the review of that pull. I was off the internet for the last seven hours, so only seeing your messages now.

Complains about CompilerPluginSupport or whatever

Maybe you can give some error info on that.

there was a recent release and our dependencies were not up to date

Ideally, you'd build against the same commit of your codebase as the test runs you measured above.

.build/aarch64-unknown-linux-gnu/debug/CNIODarwin-tool.build/module.modulemap:1:8: error: redefinition of module 'CNIODarwin'

Hmm, this is building inside the linux image? A quick fix might be to remove that CNIODarwin dependency from the targets you're building in the NIO package manifest, as it is unused on linux.
However, this seems entirely unrelated to the toolchain used: I'd try first to build the same working commit of your codebase that you used for the test runs you measured above.

@finagolfin

Ideally, you'd build against the same commit of your codebase as the test runs you measured above.

That's not possible for multiple reasons. Such as the fact that normally i use Swift Docker images, but here i need to install specific toolchains which means i need to use the ubuntu image.

Hmm, this is building inside the linux image?

Yes. That's how GitHub Actions works.

I'd try first to build the same working commit of your codebase that you used for the test runs you measured above.

Not sure how that'd be helpful. Current commit is close enough though.
Those tests above were made in a different environment (Swift Docker images, release images only) so while i trust that you know better than me about these stuff, i don't understand how you're going to be able to properly compare the numbers considering i had to make some adjustments.

Not sure how that'd be helpful.

I figure you know it builds to completion at least, without hitting all these build errors.

Those tests above were made in a different environment (Swift Docker images, release images only)

There are Swift Docker images for all these snapshot toolchains too, why not use those?
Basically, you can't compare snapshot build timings if you keep hitting compilation errors, so I'm saying you should try to reproduce the known-good environment where you measured the runs above, but only change one ingredient, ie swapping the 6.0 Docker image for the snapshot Docker images.
If these build errors are because other factors, like your Swift project, are changing too, that should fix it. If that still doesn't build, I suggest you use the 6.0 snapshot toolchain tags given, as they will be most similar to the 6.0 release, and show any build error output for those.
If you can't get anything but the final release builds to compile your codebase, you're stuck simply observing the build with some process monitor or file timestamps. If linking seems to be the problem, you could get the linker command from the verbose -v output and manually deduplicate the linker flags to see how much of a difference it makes.
I took a look at some linux CI build times of swift-docc between the 6.0.0 and 6.0 branches, ie with and without the linker fix, and didn't see a big difference. I don't know if that's because they have a lot of RAM, unlike your baseline config that showed the most regression.

@finagolfin but how do i figure out the hash of the exact image that relates to the specific main snapshots?
I tried a bunch to fix the nio errors with no luck: https://github.com/MahdiBM/swift-nio/tree/mmbm-no-cniodarwin-on-linux
This is not normal, and not a fault of the project. This is not the first time i'm building the app in a linux environment.

It also complained about CNIOWASI, as well as CNIOLinux.
I deleted those alongside CNIOWindows and now I'm getting this:
error: exhausted attempts to resolve the dependencies graph, with the following dependencies unresolved:
* 'swift-nio' from https://github.com/mahdibm/swift-nio.git

how do i figure out the hash of the exact image that relates to the specific main snapshots?

Hmm, looking it up now, I guess you can't. As I said, I don't use Docker, so I was unaware of that.
My suggestion is that you get the 6.0 Docker image and make sure it builds some known-stable commit of your codebase. Then, use that same docker image to download the 6.0 snapshots given above, like the one I linked yesterday, and after unpacking them in the Docker image, use them to build your code instead. That way, you have a known-good Docker environment and source commit, with the only difference being the Swift 6.0 toolchain build date.
The Docker files almost never change, so only swapping out the toolchain used inside the 6.0 image should minimize the differences.

The Docker files almost never change, so only swapping out the toolchain used inside the 6.0 image should minimize the differences.

@finagolfin  Good idea, didn't think of that, but still didn't work.
For the reference:

 CI File
name: test build

on:
  pull_request: { types: [opened, reopened, synchronize] }

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  unit-tests:
    strategy:
      fail-fast: false
      matrix:
        snapshot:
          - swift-DEVELOPMENT-SNAPSHOT-2024-09-04-a
          - swift-DEVELOPMENT-SNAPSHOT-2024-08-29-a
        machine:
          - name: "medium" # 16gb 8cpu c7i-flex
            arch: amd64
          - name: "large" # 32gb 16cpu c7i-flex
            arch: amd64
          - name: "huge-stable-arm" # 128gb 64cpu bare metal c7g
            arch: arm64

    runs-on:
      labels:
        - runs-on
        - runner=${{ matrix.machine.name }}
        - run-id=${{ github.run_id }}

    timeout-minutes: 60

    steps:
      - name: Configure git to deploy ${{ inputs.executable_name }}
        run: |
          git config --global --add url."https://${{ env.GH_PAT<EMAIL_ADDRESS>"https://github.com/"
          git config --global --add url."https://${{ env.GH_PAT<EMAIL_ADDRESS>"git@github.com:"
          git config --global --add safe.directory '*'

      - name: Check out ${{ github.event.repository.name }}
        uses: actions/checkout@v4

      - name: Install Docker
        run: |
          # Docker installation steps, from their own website:

          # Add Docker's official GPG key:
          sudo apt-get update -y
          sudo apt-get install ca-certificates curl gnupg -y
          sudo install -m 0755 -d /etc/apt/keyrings
          sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
          sudo chmod a+r /etc/apt/keyrings/docker.gpg

          # Add the repository to Apt sources:
          echo \
            "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
            "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
          sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
          sudo apt-get update -y

          # Install Docker:
          sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

      - name: Build Docker Image
        run: |
          docker build \
            --network=host \
            --memory=128g \
            -f SwiftDockerfile \
            -t custom-swift:1 . \
            --build-arg DOWNLOAD_DIR="${{ matrix.snapshot }}" \
            --build-arg TARGETARCH="${{ matrix.machine.arch }}"

      - name: Prepare
        run: |
          docker run --name swift-container custom-swift:1 bash -c 'apt-get update -y && apt-get install -y libjemalloc-dev && git config --global --add url."https://${{ secrets.GH_PAT<EMAIL_ADDRESS>"https://github.com/" && git clone https://github.com/${{ github.repository }} && cd ${{ github.event.repository.name }} && git checkout mmbm-test && swift package update'
          docker commit swift-container prepared-container:1

      - name: Build ${{ matrix.snapshot }}
        run: |
          docker run prepared-container:1 bash -c 'cd ${{ github.event.repository.name }} && swift build --build-tests'

 Modified Dockerfile
FROM ubuntu:22.04 AS base
LABEL maintainer="Swift Infrastructure<EMAIL_ADDRESS>LABEL description="Docker Container for the Swift programming language"

RUN export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true && apt-get -q update && \
    apt-get -q install -y \
    binutils \
    git \
    gnupg2 \
    libc6-dev \
    libcurl4-openssl-dev \
    libedit2 \
    libgcc-11-dev \
    libpython3-dev \
    libsqlite3-0 \
    libstdc++-11-dev \
    libxml2-dev \
    libz3-dev \
    pkg-config \
    tzdata \
    zip \
    zlib1g-dev \
    && rm -r /var/lib/apt/lists/*

# Everything up to here should cache nicely between Swift versions, assuming dev dependencies change little

# gpg --keyid-format LONG -k FAF6989E1BC16FEA
# pub   rsa4096/FAF6989E1BC16FEA 2019-11-07 [SC] [expires: 2021-11-06]
#       8A7495662C3CD4AE18D95637FAF6989E1BC16FEA
# uid                 [ unknown] Swift Automatic Signing Key #3<EMAIL_ADDRESS>ARG SWIFT_SIGNING_KEY=8A7495662C3CD4AE18D95637FAF6989E1BC16FEA
ARG SWIFT_PLATFORM=ubuntu
ARG OS_MAJOR_VER=22
ARG OS_MIN_VER=04
ARG SWIFT_WEBROOT=https://download.swift.org/development
ARG DOWNLOAD_DIR

# This is a small trick to enable if/else for arm64 and amd64.
# Because of https://bugs.swift.org/browse/SR-14872 we need adjust tar options.
FROM base AS base-amd64
ARG OS_ARCH_SUFFIX=

FROM base AS base-arm64
ARG OS_ARCH_SUFFIX=-aarch64

FROM base-$TARGETARCH AS final

ARG OS_VER=$SWIFT_PLATFORM$OS_MAJOR_VER.$OS_MIN_VER$OS_ARCH_SUFFIX
ARG PLATFORM_WEBROOT="$SWIFT_WEBROOT/$SWIFT_PLATFORM$OS_MAJOR_VER$OS_MIN_VER$OS_ARCH_SUFFIX"

RUN echo "${PLATFORM_WEBROOT}/latest-build.yml"

ARG download="$DOWNLOAD_DIR-$SWIFT_PLATFORM$OS_MAJOR_VER.$OS_MIN_VER$OS_ARCH_SUFFIX.tar.gz"

RUN echo "DOWNLOAD IS THIS: ${download} ; ${DOWNLOAD_DIR}"

RUN set -e; \
    # - Grab curl here so we cache better up above
    export DEBIAN_FRONTEND=noninteractive \
    && apt-get -q update && apt-get -q install -y curl && rm -rf /var/lib/apt/lists/* \
    # - Latest Toolchain info
    && echo $DOWNLOAD_DIR > .swift_tag \
    # - Download the GPG keys, Swift toolchain, and toolchain signature, and verify.
    && export GNUPGHOME="$(mktemp -d)" \
    && curl -fsSL ${PLATFORM_WEBROOT}/${DOWNLOAD_DIR}/${download} -o latest_toolchain.tar.gz \
        ${PLATFORM_WEBROOT}/${DOWNLOAD_DIR}/${download}.sig -o latest_toolchain.tar.gz.sig \
    && curl -fSsL https://swift.org/keys/all-keys.asc | gpg --import -  \
    && gpg --batch --verify latest_toolchain.tar.gz.sig latest_toolchain.tar.gz \
    # - Unpack the toolchain, set libs permissions, and clean up.
    && tar -xzf latest_toolchain.tar.gz --directory / --strip-components=1 \
    && chmod -R o+r /usr/lib/swift \
    && rm -rf "$GNUPGHOME" latest_toolchain.tar.gz.sig latest_toolchain.tar.gz \
    && apt-get purge --auto-remove -y curl

# Print Installed Swift Version
RUN swift --version

RUN echo "[ -n \"\${TERM:-}\" -a -r /etc/motd ] && cat /etc/motd" >> /etc/bash.bashrc; \
    ( \
      printf "################################################################\n"; \
      printf "# %-60s #\n" ""; \
      printf "# %-60s #\n" "Swift Nightly Docker Image"; \
      printf "# %-60s #\n" "Tag: $(cat .swift_tag)"; \
      printf "# %-60s #\n" ""; \
      printf "################################################################\n" \
    ) > /etc/motd

To be clear, by "didn't work" I mean that I'm getting exactly the same errors.

Tried the 6.0 snapshots, they complain about usage of swiftLanguageMode in dependencies.

Does simply building your code with the Swift 6.0 release still work? If so, I'd try to instrument  the build to figure out the bottlenecks, as I suggested before. In particular, if you're building a large executable at the end, that might be taking the most time.
As I said yesterday, you could try dumping all the commands that swift build is running with the -v flag, check if the final linker command is repeating -lFoundationEssentials -l_FoundationICU over and over again, then manually run that link alone twice to measure the timing: once exactly as it was to get the baseline, then a second time with those library flags de-duplicated to see if that helps. Ideally, you'd do this on the same lower-RAM hardware where you were seeing the largest build-time regressions before.

Of course there is no problem on the released Swift 6 😅. This whole issue is about CI slowness. We run CI on push, PR, etc... and they've all passed.

@finagolfin
Finally got the build working with some dependency downgrades.
        snapshot:
          - swift-6.0-DEVELOPMENT-SNAPSHOT-2024-07-19-a
          - swift-6.0-DEVELOPMENT-SNAPSHOT-2024-07-21-a
        machine:
          - name: "medium" # 16gb 8cpu c7i-flex
            arch: amd64
          - name: "large" # 32gb 16cpu c7i-flex
            arch: amd64
          - name: "huge-stable-arm" # 128gb 64cpu bare metal c7g
            arch: arm64

The results are only marginally different:

It's not the same low-RAM scenarios though, right? You initially gave data for 8 and 16 GB RAM servers that showed regressions, whereas this is from 16, 32, and 128 GB runners, with the smallest showing the biggest regression albeit less than with the final 6.0 release.
Why don't you wait for the next 6.0 snapshot toolchain with the linker patch? That should be a good comparison to the 6.0 release.

@finagolfin sorry you're right, i just wrote my conclusions here before looking at the smallest machine.
Trying on a 8-ram 4-cpu machine now.
For the record, 07-19's w/ "medium" machine took 9m 46s, and for 07-21 it took 10m 29s.

@finagolfin this is not exactly the same scenario as before, these numbers are not comparable to the older number.
We should look at them compared to themselves.
With a smaller machine (half the "medium" machine) 07-19 takes 17m 3s and 07-21 takes 18m 5s (not the whole job run, only the build step).
So yeah, this does indicate a part of the regressions, although definitely not the whole of it.
In the comparisons above, 6.0 jammy was 20% slower than 5.10 noble on the same machine (look at Tests CI, build-step time w/ no cache, which uses the same command basically).
Here it's 7% difference on the same machine (9m 46s vs 10m 29s).

@finagolfin this is not exactly the same scenario as before, these numbers are not comparable to the older number.
We should look at them compared to themselves.
With a smaller machine (half the "medium" machine) 07-19 takes 17m 3s and 07-21 takes 18m 5s (not the whole job run, only the build step).
So yeah, this does indicate a part of the regressions, although definitely not the whole of it.
In the comparisons above, 6.0 jammy was 22% slower than 5.10 noble on the same machine (look at Tests CI, build-step time w/ no cache, which uses the same command basically, 9m 14s vs 7m 34s).
Here it's 7% difference on the same machine (9m 46s vs 10m 29s).
So like a third of the regression? I guess there can also be other factors here as well, so let me know what you think.

You initially gave data for 8 and 16 GB RAM servers that showed regressions, whereas this is from 16, 32, and 128 GB runners,

The medium machine is the same as the "Same" machines in "Test CI" section.
There are 3 machines in the image, not 2.

It seems to indicate the Foundation re-core in July definitely contributed to the slowdown, but wasn't all of it. Are you able to also compare the trunk snapshot toolchains from a couple weeks ago? That might be a better benchmark.

The medium machine is the same as the "Same" machines in "Test CI" section.
There are 3 machines in the image, not 2.

I was talking about your original test and deployment runs from a couple days ago, the smallest from each were 8 and 16 GB.

Are you able to also compare the trunk snapshot toolchains from a couple weeks ago?

Just let me know what the toolchain names are.

I was talking about https://github.com/swiftlang/swift/issues/76555#issuecomment-2362522356, the smallest from each were 8 and 16 GB.

The deployment CI uses a smaller base machine because it only builds a specific product. Not everything including tests.
The comparisons i mentioned above are the closest we have to compare, and should be reliable enough considering they have 3x difference.

Just let me know what the snapshot names are.

See above: "you could try the Sep. 4 or latest 6.1 snapshot build with it and compare to the Aug. 29 build without it."

@finagolfin ah i did try those already, the error situation was less solvable.

It was the CNIO errors. Couldn't get them fixed although i made some decent effort.

First victim:
Heroku can't build Swift apps that it previously could: https://github.com/vapor-community/heroku-buildpack/issues/78#issuecomment-2371993763

Ever since the last comment, I've seen 2 more users encountering this problem on Heroku (so a total of 3).
Interesting bit is that one person was consistently having problems on Swift 6 jammy, but their project would consistently build fine on Swift 6 noble, in Heroku buildpack builders.
This is unexpected to me, but shows that the regressions are even more complicated and have happened on multiple different fronts.
So:

Swift noble, even on 5.10 has build-time regressions.
Swift 6 itself contains some regressions as well.
Swift 6 noble sometimes builds an app where Swift 6 jammy fails to.
Swift 6 jammy sometimes builds an app where Swift 6 noble fails to.

I was unable to find specs of Heroku builders (also asked around, no luck) to see if anything has changed between their Ubuntu 22 and 24 stacks.

Alright, @MahdiBM, got something for you to try: a new Swift 6.0 Oct. 8 snapshot tag was just released with the linker deduplication change for Foundation. Compare it with the last 6.0 Sep. 17 snapshot tag and see how much it improves your build. Comparing it to the 6.0.1 release may not help, as that has other stuff turned off for release builds.

@finagolfin There are some improvements in the more-constrained environments:

Reminder:
          - name: "medium" # 16gb 8cpu c7x
            arch: amd64
          - name: "large" # 32gb 16cpu c7x
            arch: amd64


cdr event is not emitted properly

Hi Dave,
When i use the drachtio-server v0.8.6, cdr events are not emitted properly. (Only the cdr event which contains application source is emitted on cdr:attempt and so on.)
I think this is related with your recent commit(e717558ce).
Please check this out. Thanks.

I don;t see that commit in the repo, can you give me a link to it?

Sorry, i was mistaken. My drachtio-server version is v0.8.6-rc1-5-g45e27e14.
Anyway, when i use v<IP_ADDRESS>, cdr event emitted properly ie, network and application source cdr attemp events were all emitted as expected.

right, thanks, I think I see the problem and just committed a fix on the develop branch.  When you have a chance could you test  it?

CDR events are emitted as expected after rebuilding(drachtio-server v0.8.6-rc1-6-g70308411)
Thank you so much and i close this issue right now.


refactoring jp.co.yahoo.yosegi.util

What is the necessity of this update?  (Not required for updating documents)
Path through maven test

LGTM


feat: 🚧 expanded compiler::parse::read::context

Added more to context.rs only thing missing is the last return statement which relies on rustle-code-red being implemented also heads up I think the AST swc uses is swc_ecma_ast while swc_estree_ast is there for defining types that will allow you to implement ways to convert between both ASTs.

I was going with swc_estree_ast as it's the most similar to the AST svelte uses.  For now I think it'll be easier if we stick with swc_estree_ast and deal with the conversion.


[Popper] Extra render found

Exactly, we don't need this line code
https://github.com/mui-org/material-ui/blob/a1018937b3df5aaa1c6f11bfcafc662a8249f7e2/packages/material-ui/src/Popper/Popper.js#L174-L177
Because we have handleRef which call handleOpen
https://github.com/mui-org/material-ui/blob/a1018937b3df5aaa1c6f11bfcafc662a8249f7e2/packages/material-ui/src/Popper/Popper.js#L148-L154

@inomdzhon Did you try without? Which tests does it break?

@oliviertassinari sure, tests passed
Screenshot of remove lines 174 to 177

Screenshot of test result

I create demo in codesandbox.
Look to console – when handleOpen will updated, handleRef will triggered again.

@inomdzhon Cool, this sounds fair. Do you want to open a pull request? :D

@oliviertassinari sure 😄I will do it this week 👌


Use distutils in duplicate_utilitycode test

See https://github.com/conda-forge/cython-feedstock/pull/75#issuecomment-848521485
Avoids unneeded dependency of setuptools for the testsuite

Fair enough. There looks to be a special setuptools tag in runtests - I don't know if that's relevant.
I'm going to claim ignorance on how distutils/setuptools/runtests dependencies work and leave it for someone else to fix (if they're inclined to).


Implement Unschedule command and functionality

Implemented in https://github.com/AY1920S1-CS2103T-T09-1/main/pull/79 pull request.


Dev

Project requirements
Logic

Each class from the UML class diagram should be created in a separate .rb file.
All associations (1-to-many relationships) and aggregations (parent-child relationships) between classes should be implemented.
All properties visible in the diagram should be defined and set up in the constructor method. Exception: properties for the 1-to-many relationships should NOT be set in the constructor method. Instead, they should have a custom setter method created.
All methods visible in the diagram should be implemented:

add_item method (in all classes that have that method)

should take an instance of the Item class as an input.
should add the input item to the collection of items.
should add self as a property of the item object (by using the correct setter from the item object).

can_be_archived?() in the Item class

should return true if published_date is older than 10 years.
otherwise, it should return false.

move_to_archive() in the Item class

should reuse can_be_archived?() method.
should change the archived property to true if the result of the can_be_archived?() method is true.
should do nothing if the result of the can_be_archived?() method is false.

can_be_archived?() in the Book class

should override the method from the parent class.
should return true if parent's method returns true OR if cover_state equals to "bad".
otherwise, it should return false.

can_be_archived?() in the MusicAlbum class

should override the method from the parent class.
should return true if parent's method returns true AND if on_spotify equals true.
otherwise, it should return false.

can_be_archived?() in the Movie class

should override the method from the parent class.
should return true if the parent's method returns true OR if silent equals true.
otherwise, it should return false.

can_be_archived?() in the Game class

should override the method from the parent class.
should return true if the parent's method returns true AND if last_played_at is older than 2 years.
otherwise, it should return false.

Add unit tests for all implemented methods.

User interface

Create a main.rb file that will serve as your console app entry-point.
Your console app, at the start, should:

Present the user with a list of options to perform.
Let users choose an option.
If needed, ask for parameters for the option.
Have a way to quit the app.

The following options should be available:

List all books
List all music albums
List all movies
List of games
List all genres (e.g 'Comedy', 'Thriller')
List all labels (e.g. 'Gift', 'New')
List all authors (e.g. 'Stephen King')
List all sources (e.g. 'From a friend', 'Online shop')
Add a book
Add a music album
Add a movie
Add a game

All data should be preserved by saving collections in .json files.

Database

Create a schema.sql file with tables that will be analogical to the structure of the classes in your app. As you cannot implement inheritance in the database tables - add all properties and associations from the parent Item class as table columns to all tables based on the child classes. Thanks to that it can be used to store data in the future.

STATUS: APPROVED ♻♻
Hi Team 👋🏽,
Your project is complete! There is nothing else to say other than... it's time to merge it 🚀 Congratulations! 🎉

Optional suggestions
Every comment with the [OPTIONAL] prefix is not crucial enough to stop the approval of this PR. However, I strongly recommend you take them into account as they can make your code better.

I suggest you shorten your video to 5 minutes as the previous reviewer mentioned.

Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear. Please, remember to tag me in your question so I can receive the notification.

Hi @Ghiftee, I will do so, my coding partners will not be available I will catch up with them later, ☺


Added gitter chat

@KarthikBangaloreVenkatarama Added gitter chat badge in the Readme.md you can go there and type your thoughts.

ok done.

Stop merging to master, just create the pull request and we can go through a review process

yeh...green button was very tempting to be pressed :)

You're fired. lol

Did you add anything apart from package.json?

no not yet...will update the code with express.


add: add link

:tada: This PR is included in version 6.26.15 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


breadcrumb not working properly with lazyloading

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request

Current behavior

In my project most of my routes are lazy loaded, when I try to load the website for the first time the breadcrumb element displays nothing. but, after navigating to next page the breadcrumb element displays routes normally as usual.
Expected behavior

breadcrumb element should display route breadcrumb data on website load even if route is lazy loaded
Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

Angular version: X.Y.Z

Browser:
- [x] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX

For Tooling issues:
- Node version:  v10.13.0
- Platform:   Windows

Others:

Hi Hasan, thanks for reporting this.
angular-crumbs is a labor of love done completely in my spare time. Unfortunately I don't have the luxury of spending time reproducing issues reported, which is why I've included the section "Minimal reproduction of the problem with instructions" in the issue template.
Closing issue as it doesn't follow the issue template. Please feel free to resubmit including a minimal reproduction in something like plunkr or stackblitz.

There is a simple solution to this.
Track the last index in the *ngfor loop of the breadCrumb component.
Angular exposes local variables for ngfor to track elements of the loop.
https://angular.io/api/common/NgForOf
Replace the customizable code mentioned in the angular-crumbs customizable code. I am demonstrating below using a bootstrap example.
From:
<breadcrumb #parent>

{{ route.displayName }}

            {{ route.displayName }}

 }
Change To:
<breadcrumb #parent>

{{ route.displayName }}

            {{ route.displayName }}

 }
The value of lastIndex will be a boolean value. Here, when we know the breadcrumb ngfor loop is at last value, mark it as active.
That is how you usethe @emilol 's fantastic angular-crumbs library  with Lazy Loading. Let me know if you need an example.

There is a simple Solution  to this.
Track the last index in the *ngfor loop of the breadCrumb component.
Angular exposes local variables for ngfor to track elements of the loop.
https://angular.io/api/common/NgForOf
Replace the customizable code mentioned in the angular-crumbs npm page. I am demonstrating below using a bootstrap example. Once you implemented lazy loading, just change the below code in the customizable bootstrap example.
  <ng-template ngFor let-route [ngForOf]="parent.breadcrumbs" let-lastIndex="last">
    <li *ngIf="!lastIndex" class="breadcrumb-item">
      <a [routerLink]="[route.url]">{{ route.displayName }}</a>
   </li>
   <li *ngIf="lastIndex" class="breadcrumb-item active" aria-current="page"> route.displayName </li>
 </ng-template>

The value of lastIndex will be a boolean value. Here, when we know the breadcrumb ngfor loop is at last value, mark it as active.
That is how you solve @emilol 's fantastic angular-crumbs library compatibility with Lazy Loading. Let me know if you need an example.


Give option to hide Update IMDB Metadata and Upload torrent elements

I find these 2 elements unnecessary. Can you add option to hide these elements and make them optional.

You need to disable "Contribution Streams" under the catalogs.


DocsArchive-<IP_ADDRESS>Auto archive content

Auto archive content from https://github.com/OPS-E2E-PPE/docs-archive-test-source

Docs Build status updates of commit 03f758d:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error]

Cannot sync git repo to specified commit because branch Archive_master_2019-10-14-06-17-43 has been deleted or has been force pushed: fatal: Couldn't find remote ref Archive_master_2019-10-14-06-17-43

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.


模型加载

您好，我想加载模型尝试一下生成效果，但是会出现如下错误：
2020-12-08 03:39:34.031317: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.10.1
Some weights of GPT2LMHeadModel were not initialized from the model checkpoint at /content/drive/MyDrive/Text_Generation/mega-clue-tok and are newly initialized: ['lm_head.weight']
You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
transformers==3.1.0 使用的模型是mega-clue-tok sha256值也比对过是一致的。
麻烦您了

Some weights of GPT2LMHeadModel were not initialized from the model checkpoint at /content/drive/MyDrive/Text_Generation/mega-clue-tok and are newly initialized: ['lm_head.weight']
lm_head层和嵌入层是共享层，没有独立的权重，所以有这个提示是正常的，没有问题。加载后你试过生成效果吗？还是生成有什么其他错误提示？

我是在colab中实验的，加载模型出现这个提示之后执行就被自动中断了。
2020-12-08 10:32:02.367037: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.10.1
Some weights of GPT2LMHeadModel were not initialized from the model checkpoint at /content/drive/MyDrive/Text_Generation/mega-clue-tok and are newly initialized: ['lm_head.weight']
You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
^C

可能和colab环境有关，我不能翻墙用colab没办法调试，你可以用下面的代码调试看是具体哪里中断了：
from gpt2_ml_torch.generate import build_model

from transformers import pipeline

model, tokenizer, info = build_model('/content/drive/MyDrive/Text_Generation/mega-clue-tok')

# cpu: -1, gpu: 0
device = 0
nlp = pipeline('text-generation', model=model, tokenizer=tokenizer, device=device)
nlp(
    '中国人',
    num_return_sequences=1,
    max_length=100,
    do_sample=True,
    return_dict=False
)

可能和colab环境有关，我不能翻墙用colab没办法调试，你可以用下面的代码调试看是具体哪里中断了：
from gpt2_ml_torch.generate import build_model

from transformers import pipeline

model, tokenizer, info = build_model('/content/drive/MyDrive/Text_Generation/mega-clue-tok')

# cpu: -1, gpu: 0
device = 0
nlp = pipeline('text-generation', model=model, tokenizer=tokenizer, device=device)
nlp(
    '中国人',
    num_return_sequences=1,
    max_length=100,
    do_sample=True,
    return_dict=False
)

使用这个代码时，会出现如下信息：
2020-12-08 11:41:21.296594: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.10.1
Traceback (most recent call last):
File "/usr/local/lib/python3.6/dist-packages/torch/serialization.py", line 595, in load
return _legacy_load(opened_file, map_location, pickle_module, **pickle_load_args)
File "/usr/local/lib/python3.6/dist-packages/torch/serialization.py", line 781, in _legacy_load
deserialized_objects[key]._set_from_file(f, offset, f_should_read_directly)
RuntimeError: read(): fd 4 failed with Transport endpoint is not connected
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/dist-packages/transformers/modeling_utils.py", line 856, in from_pretrained
state_dict = torch.load(resolved_archive_file, map_location="cpu")
File "/usr/local/lib/python3.6/dist-packages/torch/serialization.py", line 595, in load
return _legacy_load(opened_file, map_location, pickle_module, **pickle_load_args)
File "/usr/local/lib/python3.6/dist-packages/torch/serialization.py", line 214, in exit
self.file_like.close()
OSError: [Errno 107] Transport endpoint is not connected
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/content/gpt2-ml-torch/run.py", line 5, in
model, tokenizer, info = build_model('/content/drive/MyDrive/Text_Generation/mega-clue-tok')
File "/content/gpt2-ml-torch/gpt2_ml_torch/generate.py", line 18, in build_model
model, info = GPT2LMHeadModel.from_pretrained(model_path, output_loading_info=True)
File "/usr/local/lib/python3.6/dist-packages/transformers/modeling_utils.py", line 859, in from_pretrained
"Unable to load weights from pytorch checkpoint file. "
OSError: Unable to load weights from pytorch checkpoint file. If you tried to load a PyTorch model from a TF 2.0 checkpoint, please set from_tf=True.

应该是这个模型地址'/content/drive/MyDrive/Text_Generation/mega-clue-tok'不对或没有读取权限。

谢谢您的回复，之前没有注意到RAM大小不够，我换了个大一些的RAM就可以了。
现在错误信息如下，是需要生成前缀加什么吗？ 谢谢
2020-12-08 12:49:53.931044: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.10.1
Some weights of GPT2LMHeadModel were not initialized from the model checkpoint at /content/gpt2-ml-torch/models/mega-clue-tok and are newly initialized: ['lm_head.weight']
You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
Setting pad_token_id to 50256 (first eos_token_id) to generate sequence

用之前的generate.py可以生成，太感谢您了～


Update GPIO page to reflect reserved GPIO4/GPIO5.

These are reserved due to the one-wire protocol (GPIO4 is explained by this,
GPIO5 is more of a mystery, but may be related to only being present on the B+
or rpi2.)
Additionally this commit references the rpi2 in the B+ pinout diagram.

lgtm


feat: Add min_backend_version decorator

Description
Add a minimum version decorator to allow checking if methods are compatible with the current backend.
Issue linked
#1004
Checklist

[x] I have tested my changes locally.
[x] I have added necessary documentation or updated existing documentation.
[x] I have followed the coding style guidelines of this project.
[x] I have added appropriate unit tests.
[x] I have reviewed my changes before submitting this pull request.
[x] I have linked the issue or issues that are solved to the PR if any.
[x] I have assigned this PR to myself.
[x] I have made sure that the title of my PR follows Conventional commits style (e.g. feat: extrude circle to cylinder)

Added the test, and fixed some issues that arose from it. Also, it seems that is only working on the unstable version, I guess that is due to the feature not being available in the stable version?

Added the test, and fixed some issues that arose from it. Also, it seems that is only working on the unstable version, I guess that is due to the feature not being available in the stable version?

Yep - precisely. This will require a new stable release. Let me trigger it

Rerunning all jobs - images have been published

Thanks for the reviews @PipKat @RobPasMue 😄
Enabling automerge.


Cannot vote - keep getting error message 3050003 producer_is_not_currently_registered

Trying to vote and below error message keeps popping up and stopping the vote process. How do I resolve? Thanks S
Error
producer_is_not_currently_registered
{
"code":500
"message":"Internal Service Error"
"error":{
"code":3050003
"name":"eosio_assert_message_exception"
"what":"eosio_assert_message assertion failure"
"details":[...]
}
}

I just tried it by eos toolkit and got this:
Failure
Transaction has failed
Details:
{
"code": 500,
"message": "Internal Service Error",
"error": {
"code": 3050003,
"name": "eosio_assert_message_exception",
"what": "eosio_assert_message assertion failure",
"details": [
{
"message": "assertion failure with message: producer is not currently registered",
"file": "wasm_interface.cpp",
"line_number": 934,
"method": "eosio_assert"
},
{
"message": "pending console output: ",
"file": "apply_context.cpp",
"line_number": 72,
"method": "exec_one"
}
]
}
}

Hey, it sounds like one of the producers you are trying to vote for has unregistered themselves as a producer. This means the TX will fail.
We're working on a better way to handle this error, but in the meantime you can simply identify which producer no longer exists (or just unselect everyone) and then re-select producers.


appium: init at 2.4.1

Description of changes

https://appium.io
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Awesome work! I'll hopefully have time to check this out tomorrow! :)

thanks! this still needs some work on buildNpmPackage for missing lockfile fields

thanks! this still needs some work on buildNpmPackage for missing lockfile fields

I was just sitting around, trying to get it to compile using nix on my own system, and I wanted to use yarn2nix. Have you considered if that could be a option for this? A yarn.lock can be generated by just doing yarn install or whatever.
But I didn't get further, because then I stumbled upon this. But maybe it could be a option, if you're dealing with pesky workspace/npm/whatever errors.
I really admire your patience for packaging this :p

Made a branch of it here https://github.com/eyJhb/nixpkgs/tree/appium :) @NyCodeGHG not enough time to complete it?

@eyJhb I deleted the wrong branch while cleaning stuff up, but until there is a way of getting around the npm lockfile bug, I don't see this getting packaged soon :(

Wouldn't it be fine to just vendor it for now? :)

@NyCodeGHG can you explain what you did in the lockfile, to create the patch?


[SPIKE] Explore UI automation suites

Explore viable UI automation test suites to be used for mimock UI. Once the framework is finalized, a new pipeline will be created to run the automation tests.
The automation tests will use mimock itself to mimick the rest endpoints to simulate various scenarios

@Nageswari-droid This needs to be prioritised as the UI is evolving now

Puppeteer paired with Jest is finalised to be used as the framework for running automation tests in the pipeline


4.5 Release Checklist

The following need to be signed-off on before the Emulator can publish a new stable build.
NOTE: Make sure to do a clean install before attempting to go through the checklist: Clear out @bfemulator folder in app data (%APPDATA% on Windows, ~/Library/Application Support on Mac~/.config on Linux)
.bot files

[ ] create a new .bot file with keys encrypted
[ ] edit existing .bot file providing secret to decrypt keys for .bot file not created by the Emulator
[ ] load a .bot file to start conversation

starting conversations

[ ] start conversation via .bot file
[ ] start conversation via url
[ ] restart .bot file conversation (same user id, new user id, overridden user id)
[ ] restart url conversation (same user id, new user id, overridden user id)

chat control

[ ] rendered activity types are clickable and load in the inspector

log panel

[ ] see appropriate status codes (200, 201, 401, 400, etc)
[ ] all clickable elements load appropriate inspectors (Message, protocol events, LUIS traces, etc)

inspectors

[ ] LUIS train/publish via a LUIS trace

bot inspector

[ ] rendered activity types are clickable and load in the inspector (message, bot state)
[ ] log items render appropriately and are clickable

transcripts

[ ] emulator mode save
- [ ] inspector mode save removed until we can distinguish between regular & inspector transcripts
[ ] load into conversation in transcript mode

service connections

[ ] log in to Azure
[ ] navigate discovered resources/subscriptions
[ ] add LUIS/QnA/Dispatch services to .bot file
[ ] add new service manually

samples

[ ] core-bot
[ ] welcome users
[ ] bot authentication
[ ] nlp-with-dispatch
[ ] qnamaker

protocols/schemes

[ ] using bfemulator:// can start the emulator with the appropriate context

platforms

[ ] macOS
[ ] Windows
[ ] Linux

auto-update

[ ] macOS
[ ] Windows
[ ] Linux

Checking for an update on 4.4.1-59264 (must be in administrator mode) enables Restart to auto update, which updates to 4.4.1. Is this behavior we want?

@corinagum If you don't have the "Use pre-release versions" checkbox checked in Settings, then yes, it is expected to update to the latest stable release. The new patch, 4.4.2, will not require admin privileges though.

Signing off for:

[X] Windows
[X] Linux

4.5 is live!
https://github.com/microsoft/BotFramework-Emulator/releases/tag/v4.5.0

To add to checklist for next release:
Ensure that adaptive cards function properly (clicking within input fields focuses, postbacks are sent, etc.)


iOS - Discussions - Closed post functionality do not work

Closed functionality is implemented, however ACCESS CONTROL (cases where a previllaged role can override the closed status) is pending.
Posts Screen

Responses Screen

Comments Screen

@mikekatz Pl review


Does traccar support UPD connection from AVL05?

Hi Tananaev,
The AVL05 supported UPD connection and I would likd to reduce a cost of data usage by using it.
So I would like to ask you that, does traccar server support UPD connection from AVL05?
Thanks,

What protocol does AVL05 use?

I'm not sure. May be totem v1.0 protocol.

Totem protocol doesn't support UDP yet, but if you don't know which protocol your device uses, I would recommend to find it out first.

Thank you so much for your prompt reply.


Is there any way to support XIP(execute in place)?

Currently, the mode of aot code's relocation is LLVMRelocStatic mode.
/* Create the target machine */
        if (!(comp_ctx->target_machine =
                    LLVMCreateTargetMachine(target, triple_norm, cpu, features,
                                            opt_level, LLVMRelocStatic,
                                            code_model))) {
            aot_set_last_error("create LLVM target machine failed.");
            goto fail;
        }

Because this mode will modify the code when loading, it cannot support XIP. If I want to support XIP, is there any good way? If I want to generate PIC code by LLVMRelocPIC mode, I think I should change some code to support that. Is there any suggestion about that?

@kk8916 using LLVMRelocPIC mode generates position independent code, but normally it creates GOT related sections and requires the loader to apply address relocation in GOT table, which isn't supported by WAMR currently.
A possible way is to develop a tool to apply relocation to the AOT file previously, meaning that changing the relocation addresses in the machine code of AOT file to the pre-known addresses according to relocation info in AOT file, save the AOT file, and then flash it to ROM.  You might also need to create the plt table, and append it to end of code section of AOT file. And then try to disable or rewrite the executable memory allocation and address relocation in AOT loader. You can have a try, but it might be complex. Thanks.


Using Off-heap Storage for Sink Messages

Hello there.
I need to enable this feature, to keep snmp traps during disconnection from the Broker.
I followed this link: https://docs.opennms.org/opennms/branches/develop/guide-admin/guide-admin.html#_using_off_heap_storage_for_sink_messages but not luck because it seems requested feature is not available.
Thanks
My environment is: opennms-horizon-22.0.4-1 and docker-minion/22.0.4-1
ps: if you have another hint to keep traps during disconnection, I'm open to evaluate.

@vincenzodnp can we move this topic to https://opennms.discourse.group/c/community-support? I'll look into this issue, but would like make sure others in the community who have a similar issue can keep track of it.
Thanks a lot for your contribution.


asDuration() produce wrong plural form when using russian locale

What steps will reproduce the problem?
echo Yii::$app->formatter->asDuration(780);

What is the expected result?
13 минут

What do you get instead?
13 минуты

Additional info

Q
A

Yii version
<IP_ADDRESS>

PHP version
8.3.3

Operating system
Linux

I'm sure the version is latest, but the thing is it was disabled ^_^
Now it works. Thanks!


Proper way to label quantities in Roots model

In the soil model, we have sources and boundary_conditions, while here we have fields for what seem to be specific processes (transpiration, root extraction). Does it make sense to group these processes in a sources tuple that is stored in the model?
followup questions:
is a single term on the RHS of an ODE called a source?
is this the terminology they use in that field, regardless of what mathematicians think?
the two "sources" appear in different ODEs - would we then need to specify which variable the source terms apply to (in the tuple)? we may need to do this with soil anyways when we add in heat, so not an issue really...
is it clearer to group by physical concept, rather than function (they are both added in to RHS's)?

closing this for now; can return to once we get input from biophysics team? @jb-mackay


ESP32-S3 communication over usb is not possible after wifi controller starts

Hello,
I have a issue with the wifi and embassy. As soon as the wifi controller get started the communication over usb stops working. I am not able to use the serial monitor nor flash the controller. Flash works only with starting the controller with the boot button. Any idea why this is happening?
Controller: WROOM-1-N16R8 ESP32-S3-DevKitC-1
Target: xtensa-esp32s3-none-el
Rustc: v1.75.0-nightly
Repository to reproduce the issue: https://github.com/rpisarew/esp32-s3-wifi/tree/main
Output of the serial monitor:
I (45) boot: ESP-IDF v5.1-beta1-378-gea5e0ff298-dirt 2nd stage bootloader
I (46) boot: compile time Jun  7 2023 08:07:32
I (47) boot: Multicore bootloader
I (51) boot: chip revision: v0.2
I (55) boot.esp32s3: Boot SPI Speed : 40MHz
I (59) boot.esp32s3: SPI Mode       : DIO
I (64) boot.esp32s3: SPI Flash Size : 16MB
I (69) boot: Enabling RNG early entropy source...
I (74) boot: Partition Table:
I (78) boot: ## Label            Usage          Type ST Offset   Length
I (85) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (93) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (100) boot:  2 factory          factory app      00 00 00010000 00fa0000
I (108) boot: End of partition table
I (112) esp_image: segment 0: paddr=00010020 vaddr=3c0d0020 size=21174h (135540) map
I (154) esp_image: segment 1: paddr=0003119c vaddr=3fc8e020 size=0102ch (  4140) load
I (156) esp_image: segment 2: paddr=000321d0 vaddr=3fcc8168 size=00168h (   360) load
I (160) esp_image: segment 3: paddr=00032340 vaddr=40378000 size=0601ch ( 24604) load
I (176) esp_image: segment 4: paddr=00038364 vaddr=00000000 size=07cb4h ( 31924)
I (185) esp_image: segment 5: paddr=00040020 vaddr=42000020 size=c05d4h (787924) map
I (383) boot: Loaded app from partition at offset 0x10000
I (384) boot: Disabling RNG early entropy source...
embassy::init embassy-time-timg0
INFO - esp-wifi configuration Config { rx_queue_size: 5, tx_queue_size: 3, static_rx_buf_num: 10, dynamic_rx_buf_num: 32, static_tx_buf_num: 0, dynamic_tx_buf_num: 32, ampdu_rx_enable: 0, ampdu_tx_enable: 0, amsdu_tx_enable: 0, rx_ba_win: 6, max_burst_size: 1, country_code: "CN", country_code_operating_class: 0, mtu: 1492, heap_size: 65536, tick_rate_hz: 50, listen_interval: 3, beacon_timeout: 6, ap_beacon_timeout: 300, failure_retry_cnt: 1, scan_method: 0 }
DEBUG - wifi init
DEBUG - spawning task wifi: 0x4037a400 param 0x0 prio 253
DEBUG - task started: 0x4037a400 0x0
DEBUG - timer_disarm 3fcc7a78 not found
DEBUG - timer_setfn 3fcc7a04 0x420a83f4 0x0
DEBUG - timer_setfn 3fcc7a18 0x420a83e4 0x0
DEBUG - timer_setfn 3fcc7a54 0x420a83d4 0x0
DEBUG - timer_setfn 3fcc7a40 0x420a83c4 0x0
DEBUG - timer_setfn 3fcc7a78 0x420a83b4 0x0
DEBUG - timer_setfn 3fcc7a8c 0x420a83a4 0x0
DEBUG - timer_setfn 3fcc7aa0 0x420a8394 0x0
DEBUG - timer_setfn 3fcc7abc 0x420a8384 0x3fcc7950
DEBUG - timer_setfn 3fcc65f8 0x42096ee0 0x0
DEBUG - timer_setfn 3fcc660c 0x42096ed0 0x0
DEBUG - timer_disarm 3fcc7a78
DEBUG - timer_disarm 3fcc7d7c not found
DEBUG - timer_setfn 3fcc7d7c 0x420b1e08 0x0
DEBUG - timer_disarm 3fcc7a78
DEBUG - timer_disarm 3fcc7a78
DEBUG - timer_disarm 3fcc7a78
DEBUG - timer_disarm 3fcc7a78
DEBUG - Wifi mode Sta set
DEBUG - timer_disarm 3fcc7a78
INFO - wait for link
WARN - esp_wifi_internal_tx 12290
INFO - [WC] device capabilities: Ok(EnumSet(Client))
DEBUG - timer_disarm 3fcc7a78
INFO - [WC] starting..
INFO - wait for link
INFO - wait for link
INFO - wait for link
INFO - wait for link
INFO - wait for link
DEBUG - timer_disarm 3fcc7a78

this is an issue with esp-hal, you should ask in https://github.com/esp-rs/esp-hal


Agency footer - CONTRIBUTORS and CHANGELOG

Added contributors.md
I think we should remove test:visual since it's not as useful as preview is now.

Good point. The CSS change happened last Friday in https://github.com/cagov/design-system/pull/409/files It was kind of a hot fix situation.


sudo make install cannot install due to what seems to be a missing directory

When installing, it gives me an error saying xcb/xcb_ewmh.h: No such file or directory
It seems to be completely missing so maybe I am missing something? I have tried redoing it but I cannot find anything.

Yes that's a dependency issue. I will update the readme file tonight and specify all the dependencies. In the meantime, you can install libxcb to resolve this.

From the make file, those are the dependencies '-lxcb -lxcb-util -lxcb-keysyms -lxcb-ewmh -lxcb-icccm' needed to build zwm

@lDEVinux The readme file now includes the dependencies!

I've installed all the dependencies yet it gives me the error:
In file included from src/zwm.c:32: src/zwm.h:33:10: fatal error: xcb/xcb_icccm.h: No such file or directory    33 | #include <xcb/xcb_icccm.h>       |          ^~~~~~~~~~~~~~~~~ compilation terminated. make: *** [Makefile:19: src/zwm.o] Error 1
I'm on an Ubuntu-based distro. It seems the packages you provided are in the Arch repos. I've installed all the packages, including libxcb-icccm4. Any ideas?

Yeah it's clearly not recognizing xcb-icccm in your machine. Maybe libxcb-icccm4-dev is required too? Try installing this package and see if it resolves your issue. https://packages.ubuntu.com/search?searchon=sourcenames&keywords=xcb-util-wm. If not, make sure those packages reside in accessible directory.

I am getting the same error on NixOS:
In file included from src/zwm.h:32,
from src/zwm.c:32:
src/type.h:35:10: fatal error: xcb/xcb.h: No such file or directory
35 | #include <xcb/xcb.h>

Yeah it's clearly not recognizing xcb-icccm in your machine. Maybe libxcb-icccm4-dev is required too? Try installing this package and see if it resolves your issue. https://packages.ubuntu.com/search?searchon=sourcenames&keywords=xcb-util-wm. If not, make sure those packages reside in accessible directory.

Yeah I've installed libxcb-icccm4-dev but now it seems it can't find:
src/zwm.c:47:10: fatal error: xcb/xcb_keysyms.h: No such file or directory    47 | #include <xcb/xcb_keysyms.h>       |          ^~~~~~~~~~~~~~~~~~~ compilation terminated. make: *** [Makefile:19: src/zwm.o] Error 1
Any ideas? I do have all the packages there installed.


add chat button to own profile

tested new/existing self conversation flows. Did we want different button styling here?
cc @keybase/hotpotatosquad @cecileboucheron @malgorithms

lgtm!


Merged all components into one main file.

@lcaggio I have implemented @ludoo requests.
let me know if I missed anything.

/gcbrun

@lcaggio, I'm done with the changes. Let me know what you think.

Let me do a review tonight ;)


Add hexmaps to Employment dashboard by local authority

We decided to stick with constituency geography - closing this as won't do


Camera rotates on z axis in playmode

Describe the bug
When holding down the right mouse button in playmode, the camera slowly rotates on the z axis.
To reproduce
Steps to reproduce the behavior:

open scene in playmode
select main camera in inspector
switch to game window and press and hold right mouse button
observe z axis rotation

Expected behavior
no rotation while pressing and holding the right mouse button
Your Setup

Unity Version 2018.4.0f1
MRTK Version v2.1

Target Platform
Editor (hololens 1 default profil)

I cannot reproduce this problem with the latest mrtk_development branch

I tested it as well and i cannot repoduce it with the dev branch. Maybe it was an error in my application.


button-group - Output message does not follow widget value configuration type

The widget button-group does not send data upon button click as defined on the widget config panel.
If the value is defined as Number in the output message the payload is a string, same thing in case we want to inject a new state for the button group, the value injected in payload also needs to be a string regarding the type configured.

Debug messages from Node Debug47 is the output of the button-group.

Thanks for raising @arturv2000


Expose primitives in GhostAdminAPI

In our @tryghost/admin-api package we only expose direct methods for calling specific endpoints. The auth, url building, data processing, etc aspects all exist but are hidden as internal implementation details.
We'd like to expose as many primitives as possible for SDK users to build their own implementations around in case the provided all-in-one wrapper is insufficient.
The first real-world use-case that's been identified is when using the package inside of Zapier. Zapier provides its own request library which comes with benefits like logging of all requests for easier external debugging.
TODO:

[ ] expose internals as separately usable APIs

[ ] authentication
[ ] url generation
[ ] data processing

[x] allow the networking side of the all-in-one wrapper be overridden/injected

I've run into this bug in axios when using GhostAdminAPI inside our Zapier app https://github.com/axios/axios/pull/1625. Unfortunately the fix has only been released in a beta that is currently failing tests so it's not something we can upgrade to fix but it does add some more urgency to allowing the request method to over overridden/injected.

@kevinansfield What is the state of this issue?

Going to close this as we have some improvements planned, but so far this hasn't really been an issue.


Roll Flutter Engine from 342fb003b11f to 0e160b5d1f12 (4 revisions)

https://github.com/flutter/engine/compare/342fb003b11f...0e160b5d1f12
2023-11-22<EMAIL_ADDRESS>Roll Skia from 9086788fc341 to 994558cd1fae (1 revision) (flutter/engine#48322)
2023-11-22<EMAIL_ADDRESS>Expose a few more glyph apis from ui.Paragraph (flutter/engine#47698)
2023-11-22<EMAIL_ADDRESS>Roll Skia from efdec1f459ce to 9086788fc341 (2 revisions) (flutter/engine#48317)
2023-11-22<EMAIL_ADDRESS>Manual roll Dart SDK from f1fd14505782 to df958dc1ca7b (6 revisions) (flutter/engine#48316)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jacksongardner@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


[CH-416] support function regexp_extract_all

Changelog category (leave one):

New Feature

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
support function regexp_extract_all. close https://github.com/Kyligence/ClickHouse/issues/416

Can one of the admins verify this patch?

test this please with 1324


Wrong Task Mentioned in Text

This repository is focused on the Hub experience and documentation. If you're facing an issue with a specific library, please open an issue in the corresponding GitHub repo. If you're facing an issue with a specific model or dataset, please open an issue in the corresponding HF repo.
Bug description.
I notice the task mentioned is wrong in the line 185 of docs/source/en/tasks_explained.md
Describe the expected behaviour
The task should be image segmentation instead of object detection
Additional context
Ready to try your hand at object detection? Check out our complete [image segmentation guide](tasks/semantic_segmentation) to learn how to finetune SegFormer and use it for inference!

should be
Ready to try your hand at image segmentation? Check out our complete [image segmentation guide](tasks/semantic_segmentation) to learn how to finetune SegFormer and use it for inference!

cc @merveenoyan

@ecyht2 would you like to open a PR?


Registry.DIMENSION -> Registry.WORLD

As of 20w22a, there are two registries related to the different dimensions: Registry.DIMENSION_TYPE and Registry.DIMENSION. Since the latter stores actual World instances, I propose this be renamed to Registry.WORLD.

In fact, to make it absolutely clear, how about Registry.SERVER_WORLD? From what I understand so far, the registry appears to have replaced MinecraftServer.worlds.

i always tried writing Registry.WORLD instead of Registry.DIMENSION. i like this idea

I think Registry.WORLD makes sense and we can use that to help differentiate between the two registry entries.

yeah we might call what has always been a "world" before a world

@Earthcomputer What do you recommend for the DIMENSION_OPTIONS one? That field's value == to the DIMENSION one's value, even though they don't appear so (for the dummy generics used). Related #2151, maybe we can call one WORLD and the other one WORLD_SPEC

Are those new registries? Can't say I've looked at them so I don't know.

Those are old ones that were added back when the data pack registry custom dimensions were first added.

renamed to WORLD_KEY in #2253.


Background color overflows rounded corners

Can anyone advise regarding how to prevent a background color from overflowing rounded corners?

        Header

        Content

Add overflow-hidden to the parent element.

Problem solved. Thanks Adam!


Node Deregistration Failed if Archive Data Present

Based on our testing if we run a node deregistration ansible module node was successfully deregister if no archive data is present. But in case archive data associated with the node deregistration process failed.
Upon checking server side log we noticed degistration called a "dsmadmc delete node" command but to achieve correct response we should use "dsmadmc decommission node" sub command and that should taken care of situations for both scenarios. Please review and advice.

Thanks! @dhrony for your feedback. Will make the necessary changes.


Add support to .brand schemas

Branded types in zod are very helpful in ensuring that a function argument or a value has been validated through a zod schema.
Today when using .brand in a schema, the zodToOpenAPI function doesn't generate the correct type at OpenAPI schema

Hi there,
I also stumbled upon this issue in our project. Branded types will just resolve to empty objects in the openAPI spec, which is a pity.
Afaik, it's really just three lines of production code to support branded types.
I would have opened a PR with a fix, but don't have the permissions.
Therefore, just posting a patch here:
0001-fix-add-support-for-branded-zod-types.patch
I would be glad if one of the maintainers could take a look and add the support for branded types. 🙏


Unsure which mod is causing the issue (1.16.5)

I really want to use Dungeons Gear, Valkyrien Skies, and Eureka! Airships. I have all the dependents that are required by each mod. I have ran each mod independently without issue. The issue arises when starting an instance of minecraft with Dungeons Gears and Valkyrien Skies, though Eureka! Airships is dependent on Valkyrien Skies, it causes the game to crash without creating a crash log. I have enabled the game output to see what is causes the wrench being thrown. I am curious as to if these mods will possibly be compatible in the future or if your mod relies on a mix-in that is being modified by the other mod.
Here is the game output that states the issues:

[11:58:18] [main/WARN] [mixin/]: @Redirect conflict. Skipping dungeons_gear.mixins.json:GameRendererMixin->@Redirect::getModifiedDistance1(Lnet/minecraft/util/math/vector/Vector3d;Lnet/minecraft/util/math/vector/Vector3d;)D with priority 1000, already redirected by valkyrienskies-common.mixins.json:client.renderer.MixinGameRenderer->@Redirect::correctDistanceChecks(Lnet/minecraft/util/math/vector/Vector3d;Lnet/minecraft/util/math/vector/Vector3d;)D with priority 1000

[11:58:18] [main/WARN] [mixin/]: @Redirect conflict. Skipping dungeons_gear.mixins.json:GameRendererMixin->@Redirect::getModifiedDistance2(Lnet/minecraft/util/math/vector/Vector3d;Lnet/minecraft/util/math/vector/Vector3d;)D with priority 1000, already redirected by valkyrienskies-common.mixins.json:client.renderer.MixinGameRenderer->@Redirect::correctDistanceChecks(Lnet/minecraft/util/math/vector/Vector3d;Lnet/minecraft/util/math/vector/Vector3d;)D with priority 1000

[11:58:18] [main/INFO] [STDERR/]: [java.lang.Throwable:printStackTrace:667]: Caused by: org.spongepowered.asm.mixin.injection.throwables.InjectionError: Critical injection failure: Redirector getModifiedDistance1(Lnet/minecraft/util/math/vector/Vector3d;Lnet/minecraft/util/math/vector/Vector3d;)D in dungeons_gear.mixins.json:GameRendererMixin failed injection check, (0/1) succeeded. Scanned 1 target(s). Using refmap dungeons_gear.refmap.json

Based on what I see here, Valkyrian Skies and Dungeons gear are literally incompatible.
I will take a look to see if I can rework this piece of code.

Thank you, I've also posted this post to the other GitHub for the other mod. Here is the link so you can see what is going on other other side from the other mod user. Here is a link so these mods can (hopefully) one day be compatible, https://github.com/ValkyrienSkies/Valkyrien-Skies-2/issues/232.
Thank you again!

Any updates for the resolution or eta on it?

This is a result of some hackery we did to get Attack Reach working, since there was no Forge-provided Attack Reach attribute until 1.18. Anyone else attempting to perform similar hacks as us to get their versions of Attack Reach working will inevitably cause incompatibility, unless we start using a library called MixinExtras as a part of our projects. Development is currently focused on the unstable 1.19.2 version, but in the long term we will look into backporting fixes as well as addressing version-specific issues such as this one.

Any updates? I know its been a year, and that development on 1.16.5 may no longer in the thoughts your development team's mind. I would like to know so I can consider if I just need to update my minecraft version which I am going to say took me a while since I went from 1.7.10 to 1.16.5 when all mod support for 1.7.10 disappeared and 1.16.5 was the latest version of minecraft at the time. I just have a hard time adjusting to a newer version for an unreasonable mental thing I still can't figure out.

We are currently focused on 1.20+, and do not expect to backport anything/fix older versions in the near future.

1.16.5 is no longer supported.


Reduce instances where strip color assignments reset

Right now strip colors reset every time the user goes back to tile view or plays with extension length, which is a bit unnecessary.

Possibly also more performance caching of the tile -> strip conversion if the configuration isn't changed in tileview.


Need to change the command to match the output

File: engine/swarm/swarm-tutorial/inspect-service.md
docker service inspect --pretty helloworld command and its output isn't correct. Remove the --pretty in the command. The --pretty command json output is mentioned in the subsequent section

Thanks for reporting, but I don't see a mistake on that page; it describes:

Run docker service inspect --pretty <SERVICE-ID> to display the details about a service in an easily readable format.

(followed by an example of the "pretty" output), then:

Tip: To return the service details in json format, run the same command without the --pretty flag.

followed by an example of the JSON output format
I'm closing this issue, because of the above, but feel free to continue the conversation in case I didn't understand your report


wrapper.attributes(attribute) does not return the same thing as wrapper.attributes().attribute

Version
1.0.0-beta.24
Reproduction link
https://github.com/kb-coder/vue-test-utils-bug
Steps to reproduce

Pull down repro.
Run "npm  run test:unit"

The two tests in HelloWorld.spec.js will fail.
What is expected?
Both tests should succeed. According to the docs (https://vue-test-utils.vuejs.org/api/wrapper/#attributes-key), I should be able to check the attribute using this syntax:
expect(element.attributes('for'), 'label for attribute').to.equal('myInput')
For example:
it('label for attribute should be "myInput"', mochaAsync(async () => {
    const msg = 'new message'
    const wrapper = await shallowMount(HelloWorld, {
      attachToDocument: true,
      propsData: { msg }
    })

    const element = wrapper.find('label')

    expect(element.attributes('for'), 'label for attribute').to.equal('myInput') // fails
  }))

What is actually happening?
The element.attributes('for') returns the entire element object and not the value of the 'for' attribute.
However, the following line does work:
expect(element.attributes().for, 'label for attribute').to.equal('myInput')

According to the documentation, both ways of getting to the attribute should work.

Console shows:
element.attributes('for')
{data-v-.....: "", for: "myInput" .....}

elements.attributes().for
"myInput"

I tried this on both an input using the "type" attribute and a label using the "for" attribute. Both are included in the repro.

attributes([key]) is added at #941.
It is 2 days ago.
This is not included in 1.0.0-beta.24.
https://github.com/vuejs/vue-test-utils/releases/tag/v1.0.0-beta.24

The latest version is released now, so this feature will be working as intended


Bash code highlighting treating # as a comment

(Original issue 898 created by None on 2013-08-30T03:26:33.667208+00:00)
There are certain cases where # does not mean a comment in Bash. One case is when changing base in arithmetic expressions: http://www.gnu.org/software/bash/manual/bashref.html#Shell-Arithmetic
In this case, the code should not be highlighted as a comment. You can see this bug here on line 30: http://pygments.org/demo/105122/

(Original issue 898 last updated on 2014-04-22T08:17:10.183511+00:00)
(Issue automaticaly closed due to status in Bitbucket: resolved)

(Original comment by birkenfeld on 2014-01-09T19:04:46.517807+00:00)
True, but probably very hard to fix :(

(Original comment by birkenfeld on 2014-04-22T08:17:10.213592+00:00)
fixed by pull request #332


Hosting SignalR Hub along Server Side Blazor

Is it still possible to host Server Blazor and SignalR Hub in the same system and then connect to the SignaR Hub via a Blazor Component?
I used to be able to do it in Preview 3 but now it simply creates '
[2019-04-27T08:55:23.085Z] Error: Microsoft.AspNetCore.SignalR.HubException: Unable to complete handshake with the server due to an error: The protocol 'json' is not supported.

https://github.com/dodyg/practical-aspnetcore/tree/master/projects/blazor-ss/ChatR

It is definitely possible - I have a project working that does just that.  Unfortunately I've moved to preview5 so my code won't necessarily look like yours.  However I can tell you that in preview 5, json is supported without the need for the .AddNewtonsoftJsonProtocol(); - what happens if you remove that?

Hi @glent1, I'll be needing to do this on preview5 in the coming days. A cheeky question: do you have a sample project you can share? Thanks!

There was an issue in preview4 that broke this, it is fixed in preview5, for now you can apply the workaround detailed here: https://github.com/aspnet/AspNetCore/issues/9627#issuecomment-485500176


Rust language services complains about code being unsafe

I'm using the hello world example from the Readme and my IDE (aka. the rust language service) is complaining about alert() being unsafe.

without unsafe the IDE complaines, but build works
with unsafe the IDE ist okay, but the build warns about unnecessary unsafe

Is there anything I forgot to adjust?
Or should I just use unsafe an ignore it?

I wonder if perhaps your IDE isn't expanding macros? The expansion of #[wasm_bindgen] is needed to show how it's not an unsafe function.

This is a bug in the RLS where it is not looking at the macro-expanded code. Extern functions are always unsafe, but wasm-bindgen expands the alert into a safe, non-external function that handles the raw unsafe call for you.

Jinx ;)
I'd recommend filing a bug upstream in the RLS issue tracker.

Oh yes, it actually seems like the IntelliJ plugin doesn't even use rls, despite the fact that the was a note somewhere that this is used by the IDE plugins.
Found a matching bug.
Sorry I'm still new to rust and normally use scripting languages.

But I guess this additional unsafe doesn't break anything?


Meeting time. [11 April, ?]

When is the today's meeting exact time? (Remember because of the exams, we could not arrange it in its regular time.)

9pm sharp.


change usage of username to something else (to help bug 1131717)

r+ (change the PR name to reflect the commit name)


Upgrading debian package replaces the config file

Upgrading debian package replaces the config file with a new one even if changed locally by the user.
Any way around this?
I've see some package installers ask the user to leave the config files intact.

there is a way for debian packages to check if the file in the update packet was changed and differ from the version that is installed.

For a quick fix the default filename is now settings.json.example and this file will be replace when update.
After an installation you must copy that to settings.json and customise it.

Changed the instructions in the wiki to that.

https://www.debian.org/doc/manuals/maint-guide/dother.de.html#conffiles

postinst scipt now uses ucf to compare configfiles


Wrap lines doesn't actually wrap lines

What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):

Go to a pod in a workload
Click 3 dots menu
Click View Logs
Check Wrap Lines

Result:
The lines aren't actually wrapped, but a horizontal scrollbar is introduced.
Other details that may be helpful:
This may not happen with short lines. Java applications are great to trigger this with.
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): 2.3.1
Installation option (single install/HA): Unknown

Tested with Rancher server rancher\rancher:master-head version abd6f58c6
View pod in workload
View logs

Check Wrap Lines


Uknown error during pdf export

Describe the bug
Hi all, during pdf export of a book with many pages (177 in my example) the process exit with an error
Steps To Reproduce
Steps to reproduce the behavior:

Go to the desired book
Click on PDF Export
wait
See error

Expected behavior
prompt pdf download/open
Screenshots

Your Configuration (please complete the following information):

Exact BookStack Version (Found in settings): v0.25.5
PHP Version: PHP 7.2.19-0ubuntu<IP_ADDRESS>
Hosting Method (Nginx/Apache/Docker): Apache2

Additional context
I tried:

switch to wkhtmltopdf (https://www.bookstackapp.com/docs/admin/pdf-rendering/) with no results. Same error but I see that wkhtmltopdf  was called.
Increase php memory_limit and max_execution_time

With a small book (< 10 pages) pdf export is fine.
Any suggestions ?

What did you change memory limit and execution time to?
After you made the changes, did you run:
sudo systemctl restart php7.2.19-fpm.service

memory_limit = 256M max_execution_time = 300
I restarted apache2 service directly as works in prefork not via FPM

When you check phpinfo do you see the right limit and execution time?

Yes

which version of wkhtmltopdf do you have?

root@usermanual:~# wkhtmltopdf -V
wkhtmltopdf 0.12.5 (with patched qt)

What happens if you un-restrict the execution time by entering it as -1? Does it work then?
Also, are your pages primarily made up of text?

Tried with max_execution_time = 0 and -1 and there are same error:
[Fri Aug 30 09:26:41.881842 2019] [php7:error] [pid 13038] [client <IP_ADDRESS>:43413] PHP Fatal error:  Maximum execution time of 0 seconds exceeded in /var/www/html/bookstack/vendor/symfony/polyfill-mbstring/Mbstring.php on line 500
Fatal error: Maximum execution time of -1+2 seconds exceeded (terminated) in /var/www/html/bookstack/vendor/symfony/polyfill-mbstring/Mbstring.php on line 500
Pages is primarily text but there are also images, not in all pages but they may have it.
Server with 1 GB RAM.
Thank you

@denisdal When you set max_execution_time to 300 was the browse loading for 5 minutes and did you see 300 in the resulting error log or were the experience/logged times different?

Well, no.
Browser return unknown error way before then 300 seconds.

Any help figuring out how to solve this ?
Thanks

Any update ?

I have met the same issue while exporting a large file which will cause mentioned error,
production.ERROR: Maximum execution time of 30 seconds exceeded
If the result file is smaller than around 5MB, it can export normally, otherwise, the error will be a trigger.
@denisdal May I know if you have figure out any possible solution for it?

No I'm still having this issue so far

Hello, i have the same problem. I do this change :
memory_limit = 256M
max_execution_time = 300
and restart the server but i have always this error.
Can you help me ?
Thanks

Since the last comment on this issue is relatively old I'm going to close this. If the issue remains and is something you still require to be fixed please open a new issue, referencing this one.


feat: support defineExpose

Not exactly the same as Vue 3 since you're not setting strict exports. If we did that, template variables wouldn't work. And this plugin is already adding extra stuff to the Vue 2 instance which wouldn't happen in Vue 3 (because it has to).

What if we don't use expose in literal? For example:
const ctx = {b}
expose(ctx)

I would think maybe we could have it generated like:
return Object.assign({ a }, ctx)

Good point, updated.

Thanks!


Project unmaintained

@nickmccurdy
@CarsonMcKinstry
@aduth
@fbring
is this library dead/unmaintained?
As far as I can see there is renderHook in the newer version of preact-testing-library
is this one still needed?

Not all our repositories have active maintainers, but organization maintainers (myself included) will occasionally review them.
As for whether we still need this package, let's continue the discussion in #17.


OpenCVSharp in Visual Basic 6 How to findout if it found something?

Hi there,
Im using OpenCVSharp in Visual Basic 6 and just getting into it.
All i want is to compare what is under my webcam with a picture i have on my computer and if it finds it it will bring a messagebox saying "Found it!"
Is there some kind of Tutorial somewhere?
What i dont get is how I find out if it found something?
Thanks!
The code i have so far is that it gets my camera to show whats up and then giving out all kinds of numbers, but i cant figure out what those numbers mean..
and somehow it shows the same number if i put my hand under the camera or just a piece of paper, so in my eyes the computer thinks its the same thing ^^
My code so far
       Dim cap As CvCapture = CvCapture.FromCamera(0)
        Dim w As CvWindow = New CvWindow("Template Matching")
        Dim Img, Res As IplImage

        Dim tpl As IplImage

        Dim i As Integer = 0

        Dim minloc, maxloc As CvPoint
        Dim minval, maxval As Double

        Dim Array() As String =
        {
            "File1",
            "File2"
        }

        tpl = Cv.LoadImage(Array(0), LoadMode.Color)
        While CvWindow.WaitKey(10) < 0

            Img = cap.QueryFrame()
            Res = Cv.CreateImage(Cv.Size(Img.Width - tpl.Width + 1, Img.Height - tpl.Height + 1), BitDepth.F32, 1)
            Cv.MatchTemplate(Img, tpl, Res, MatchTemplateMethod.CCoeff)

            Cv.MinMaxLoc(res, minval, maxval, minloc, maxloc)
            Cv.Rectangle(img, Cv.Point(minloc.X, minloc.Y), Cv.Point(minloc.X + tpl.Width, minloc.Y + tpl.Height), CvColor.Blue, 1, 0, 0)
            If TextBox1.Text = "" Then TextBox1.Text = 50
            System.Threading.Thread.Sleep(TextBox1.Text)
            If maxval > 100000000 Then
                Output.Text = Array(0) + "minval: " + minval.ToString + " maxval: " + maxval.ToString + " minloc: " + minloc.ToString + " maxloc: " + maxloc.ToString
            Else
                Output.Text = "NOT Found " + "minval: " + minval.ToString + " maxval: " + maxval.ToString + " minloc: " + minloc.ToString + " maxloc: " + maxloc.ToString
            End If

            w.Image = Img

            Cv.ReleaseImage(res)
            Cv.ReleaseImage(img)

        End While

You should look at #176.  You need to use Kaze in OpenCvSharp3 or SURF in OpenCvSharp 2 to match images.


Explicitly import from chai instead of using a global

PR checklist

[X] Addresses an existing issue: #938
[ ] New feature, bugfix, or enhancement

[ ] Includes tests

[ ] Documentation update

Overview of change:
Use import { assert } from "chai" everywhere instead of relying on globals.
This makes it possible to run a single test file using the mocha CLI.

Don't forget to close #938.


Create shared functions between the frontend and alerting

The frontend and alerting parts of the application are independent but share many functionalities.
We need to extract shared knowledge, types and functions into a common package to avoid duplication and allow us to re-use functionalities developed for the frontend, to alerts.

This task should likely take care of the following :

move the frontend code into a website folder
create a common folder (or a better name) for shared functionalities and utils between the frontend the alert module
remove duplicate code