fix(deps): update module github.com/tubenhirn/dagger-ci-modules/v5 to v5.3.1

This PR contains the following updates:

Package
Type
Update
Change

github.com/tubenhirn/dagger-ci-modules/v5
require
patch
v5.3.0 -> v5.3.1

Release Notes

tubenhirn/dagger-ci-modules (github.com/tubenhirn/dagger-ci-modules/v5)
v5.3.1
Compare Source
Bug Fixes

deps: update module github.com/tubenhirn/dagger-ci-modules/v5 to v5.3.0 (7446cdd)

Continuous Integration

update go version in go.work (d577571)

Miscellaneous Chores

bump go version to v1.21 (8698d0a)
deps: update renovate/renovate docker tag to v37.53.1 (1bb025f)
deps: update renovate/renovate docker tag to v37.56.1 (548d046)
deps: update renovate/renovate docker tag to v37.59.8 (6e1a476)
deps: update renovate/renovate docker tag to v37.63.0 (e95546b)
deps: update tubenhirn/semantic-release-azdo docker tag to v4.1.3 (75aa244)
deps: update tubenhirn/semantic-release-git docker tag to v4.1.3 (3d9c6bc)
deps: update tubenhirn/semantic-release-github docker tag to v4.1.3 (2a65673)
deps: update tubenhirn/semantic-release-gitlab docker tag to v4.1.3 (1382b0e)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

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


DPL-016 Stop parsing the unconsolidated plate map data from MK, AP and GLS on date ?

User story
DPL-016 | As POC for HL Labs (Alan K) we would like to stop parsing the plate map data from MK, AP and GLS to reduce the number of duplicate entries of samples in Sanger information systems at source
Who are the primary contacts for this story
Alan K (PAM)
Cristina A (PAM)
Sonia A (PAM)
Ian W (PAM)
Rich L
Acceptance criteria
To be considered successful the solution must allow:

[ ] Agree date to action change with PAM (WIP with Rich L & Alan)
[ ] New rule? do not parse unconsolidated plate maps from Milton Keynes, Adderley Park or Glasgow file format examples MK_sanger_report_210520_0800.csv, AP_sanger_report_210520_0130.csv & GLS_sanger_report_210520_0500.csv
[ ] Log that file was rejected to Imports in http://lighthouse-ui.psd.sanger.ac.uk/imports

Additional context
Expected barcode formats and file names can be found here: https://docs.google.com/spreadsheets/d/1IQRpQiwQgUpYLxAgN-YVXU7TxSArGAczS_P25qDdFiA/edit#gid=0

On 24th discussed on 10am and Sonia G agreed we should do this.

Note briefly discussed on 26th, please leave on for Lemington


Node 22 has warning in every cli command (eslint error)

All commands include this output ....
aio report -b
(node:61566) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)

Running with --trace-deprecation flag:
node --trace-deprecation ~/.nvm/versions/node/v22.10.0/bin/aio info
(node:64405) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
    at node:punycode:3:9
    at BuiltinModule.compileForInternalLoader (node:internal/bootstrap/realm:399:7)
    at BuiltinModule.compileForPublicLoader (node:internal/bootstrap/realm:338:10)
    at loadBuiltinModule (node:internal/modules/helpers:114:7)
    at Function._load (node:internal/modules/cjs/loader:1100:17)
    at TracingChannel.traceSync (node:diagnostics_channel:315:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:218:24)
    at Module.require (node:internal/modules/cjs/loader:1340:12)
    at require (node:internal/modules/helpers:141:16)
    at Object.<anonymous> (/Users/jessem/.nvm/versions/node/v22.10.0/lib/node_modules/@adobe/aio-cli/node_modules/whatwg-url/lib/url-state-machine.js:2:18)

Environment Info
  System:
    OS: macOS 14.6.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 1.65 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.10.0 - ~/.nvm/versions/node/v22.10.0/bin/node
    Yarn: 1.22.19 - ~/.bun/bin/yarn
    npm: 10.9.0 - ~/.nvm/versions/node/v22.10.0/bin/npm
  Virtualization:
    Docker: 20.10.17 - /usr/local/bin/docker
  npmGlobalPackages:
    @adobe/aio-cli: 10.3.1

❯ npm root -g
/Users/shazron/.nvm/versions/node/v22.11.0/lib/node_modules
❯ cd /Users/shazron/.nvm/versions/node/v22.11.0/lib/node_modules
❯ cd @adobe/aio-cli
❯ npm ls punycode
<EMAIL_ADDRESS>/Users/shazron/.nvm/versions/node/v22.11.0/lib/node_modules/@adobe/aio-cli
├─┬<EMAIL_ADDRESS>│ └─┬<EMAIL_ADDRESS>│   └─┬<EMAIL_ADDRESS>│     └─┬<EMAIL_ADDRESS>│       └─┬<EMAIL_ADDRESS>│         └─┬<EMAIL_ADDRESS>│           └──<EMAIL_ADDRESS>└─┬<EMAIL_ADDRESS>  └─┬<EMAIL_ADDRESS>    └─┬<EMAIL_ADDRESS>      └─┬<EMAIL_ADDRESS>        └──<EMAIL_ADDRESS>
Unfortunately punycode is dependency of a dependency, will have to investigate whether they have been updated.

<EMAIL_ADDRESS>(the latest) does not have punycode as a dependency.
<EMAIL_ADDRESS>(the latest) still has the<EMAIL_ADDRESS>dependency.

<EMAIL_ADDRESS>has updated the ajv that has the required updates. However, webpack needs to have a new release that uses the new schema-utils, and that timeline for update is unknown. For now, I recommend the app-dev plugin do this: https://github.com/eslint/eslint/pull/18762/files
Update swagger-client for the events plugin

webpack can't update to the latest schema-utils because of node version support reasons: https://github.com/webpack/schema-utils/issues/191

PR https://github.com/adobe/aio-cli-plugin-app-dev/pull/124

PRs merged and released.


references happend Error

Your Question
package main

import (
	"gorm.io/driver/mysql"
	"gorm.io/gorm"
)

type User struct {
	gorm.Model
	Name      string
	CompanyID string
	Company   Company `gorm:"references:CompanyID"`
}

type Company struct {
	CompanyID int
	Code      string
	Name      string
}

func main() {
	dsn := "root:123456@tcp(localhost:3306)/learn-gorm?charset=utf8mb4&parseTime=True&loc=Local"
	db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})

	if err != nil {
		panic("failed to connect database")
	}

	db.AutoMigrate(&User{}, &Company{})
}

Error 1215: Cannot add foreign key constraint
[14.528ms] [rows:0] CREATE TABLE `users` (`id` bigint unsigned AUTO_INCREMENT,`created_at` datetime(3) NULL,`updated_at` datetime(3) NULL,`deleted_at` datetime(3) NULL,`name` longtext,`company_id` bigint,PRIMARY KEY (`id`),INDEX `idx_users_deleted_at` (`deleted_at`),CONSTRAINT `fk_users_company` FOREIGN KEY (`company_id`) REFERENCES `companies`(`company_id`))

mysql --version
/usr/local/mysql/bin/mysql  Ver 14.14 Distrib 5.7.19, for macos10.12 (x86_64) using  EditLine wrapper
go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/chenhailong/Library/Caches/go-build"
GOENV="/Users/chenhailong/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/chenhailong/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/chenhailong/go"
GOPRIVATE=""
GOPROXY="https://goproxy.cn,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.19.2"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/qk/bj_mbvq54zs663fjmkykq4cc0000gn/T/go-build3202474337=/tmp/go-build -gno-record-gcc-switches -fno-common"

The document you expected this should be explained
I wrote the code according to this document https://gorm.io/docs/belongs_to.html#Override-References

Expected answer
i want how to use references

did u solve this? same thing occurred to me
Error 1215 (HY000): Cannot add foreign key constraint

code
type Device struct {
  ID
  DeviceSN
  DeviceName
  ...
}
type Alarm struct {
  ID
  DeviceSN
  ...
  Device Device `gorm:"foreignKey:DeviceSN;references:DeviceSN"
}

failed with Error 1215 (HY000): Cannot add foreign key constraint
code test success using<EMAIL_ADDRESS>failed using gorm.io/gorm v1.24.7-0.20230306060331-85eaf9eeda11
when success the create sql is
xxxxxxxxxx, CONSTRAINT `fk_alarms_device` FOREIGN KEY (`device_sn`) REFERENCES `devices`(`device_sn`))

when fail the create sql is
xxxxxxxxxx, CONSTRAINT `fk_alarms_device` FOREIGN KEY (`device_sn`) REFERENCES `alarms`(`device_sn`))

is this a new bug?

never mind, I finally find a solution to make it right at v1.24.7 or later
use code bellow
Device Device `gorm:"foreignKey:DeviceSN;references:DeviceSN;belongsTo"

anyway, I think this belongsTo tag should be mentioned in DOC

When the associated model has the same field name, the specified (otherwise it will be determined by guessing) association relationship.
Welcome physical examination PR to help us improve the document.


how to train my own data?

Hello, I need help. Any guide or tutorial there available for training custom dataset?

Hello, I need help. Any guide or tutorial there available for training custom dataset?

hello, have you solved this problem?


Broken Discord link

Dear Multiverse,
I been wanting to join the discord group as I host a community server with a friend, but it seems like the main discord link isn't working regardless how its posted on the wiki. Seems like there isn't really a way to contact anyone, from the outside, to report this.
Hope this gets fixed so more people can join the Multiverse discord, thanks.

Apparently It was only broken because I hit the server limit. Not sure why Discord didn't just tell me, instead of giving me a error of a broken link.


Clearing cache

Should not clear on every instance. Clearing also needs to go through every cache option.

Hi
My team wants to use Rendertron to perform SSR for several of our sites.
We'd like to see an endpoint that we can hit and clear the cache for all the pages of a site.
if we can clear a specific page on a specific site that will be even better.
Thanks!

Does the endpoint need to be secure at all?

We'd like to have it secured.
Anyone outside my company should not be able to use the endpoint.
We are using AWS at the moment, I'd like to know your opinion on how to implement the security.

HI, anyone here update or follow this?

The fundamental function is present, but there is currently no way to get to it.
This would require a PR to set up a route to it.
I would leave the authentication out of Rendertron as that's something that is best dealt with on the level of whatever infrastructure is making the calls to Rendertron (i.e. the reverse proxy or whatever other server is in front of Rendertron)

Right now, Rendertron 3.0.0 provides the /invalidate/<url> endpoint to remove individual URLs from a cache.
I think having an endpoint to clear the entire cache would be useful.
Are you interested in implementing this feature?

This landed in 3.1.0


Update defs for GO:0070461 SAGA-type complex and GO:0000124 SAGA complex

References:
PMID:33864814 (yeast)
PMID:32616828, 33004486, 34112237 (human)
GO:0070461 SAGA-type complex

A histone acetyltransferase complex that acetylates nucleosomal H3 and H2B and is required for the expression of a subset of Pol II-transcribed genes. The budding yeast complex includes the acetyltransferase Gcn5p, several proteins of the Spt and Ada families, and several TBP-associate proteins (TAFs); analogous complexes in other species have analogous compositions, and usually contain homologs of the yeast proteins.

A histone acetyltransferase complex that acetylates nucleosomal histones H2B, H3 or H4 and may deubiquitinate H2A or H2B and is required for the expression of a subset of Pol II-transcribed genes. Includes the acetyltransferases GCN5/KAT2A or PCAF/KAT2B, several proteins of the ADA, SGF and SPT families, and several TBP-associate proteins (TAFs).

NB: Considering SAGA-type complexes are found in all organisms the def shouldn't be yeast-specific and then referring to potential homologues.
GO:0000124 SAGA complex

A SAGA-type histone acetyltransferase complex that contains Spt8 (in budding yeast) or a homolog thereof; additional polypeptides include Spt group, consisting of Spt7, Spt3, and Spt20/Ada5, which interact with the TATA-binding protein (TBP); the Ada group, consisting of Ada1, Ada2, Ada3, Ada4/Gcn5, and Ada5/Spt20, which is functionally linked to the nucleosomal HAT activity; Tra1, an ATM/PI-3 kinase-related protein that targets DNA-bound activators for recruitment to promoters; the TBP-associated factor (TAF) proteins, consisting of Taf5, Taf6, Taf9, Taf10, and Taf12, which mediate nucleosomal HAT activity and are thought to help recruit the basal transcription machinery; the ubiquitin specifc protease Ubp-8.

A SAGA-type histone acetyltransferase complex that acetylates nucleosomal histones H3 and/or H4 and deubiquitinates H2A and/or H2B and is required for the expression of a subset of Pol II-transcribed genes. Organized into several functional submodules: a structural core including the activator binding module and consisting of ADA1 or a homolog, members of the SPT and TAF protein families as well as promotor recruitment factor TRRAP/TRA1, a histone acetyltransferase (HAT) module consisting of GCN5/KAT2A or PCAF/KAT2B, ADA2, ADA3/NGG1, and SGF29 or homologues thereof, a histone deubiquitinase (DUB) module consisting of ATXN7/SGF73, ATXN7L3/SGF11, ENY2/SUS1 and USP22/UBP8 or homologues thereof, and in some taxa a splicing module consisting of SF3B3 and SF3B5 or homologues thereof (not in fungi). In budding yeast also contains Spt8 which distinguishes it from SAGA-like (SLIK) complex (GO:0046695).

GO:0070461 SAGA-type complex
A histone acetyltransferase complex that acetylates nucleosomal histones H2B, H3 or H4 and may deubiquitinate H2A or H2B and is required for the expression of a subset of Pol II-transcribed genes, and includes the acetyltransferases GCN5/KAT2A or PCAF/KAT2B, several proteins of the ADA, SGF and SPT families, and several TBP-associate proteins (TAFs).

GO:0000124 SAGA complex
Is there a clear differentia that makes it different from all other SAGA-type complexes?

Fixed the the original post as the MD removes the - and + from the old and new def lines and turns them into paragraphs :(

They only share the HAT module. They all have different structural core modules, SAGA also has a DUB module and in some taxa (not fungi) a splicing module.

@bmeldal
What I'm getting at is the definitions of SAGA-type complex and SAGA complex look rather similar, for the first sentence. A definition needs to be necessary and sufficient to specify that class. If deubiquitylation (DUB function) is not a necessary function of SAGA-type complex, it should not be in the definition. In general, the word 'may' is a red flag.
"that acetylates nucleosomal histones H2B, H3 or H4 and may deubiquitinate H2A or H2B and is required for the expression of a subset of Pol II-transcribed genes."
vs.
"that acetylates nucleosomal histones H3 and/or H4 and deubiquitinates H2A and/or H2B and is required for the expression of a subset of Pol II-transcribed genes."
Thanks for the help.

Ok can we use this for SAGA-type:
"that acetylates nucleosomal histones H2B, H3 or H4 and is required for the expression of a subset of Pol II-transcribed genes."
The def for the grouping term is always going to be a part of that of its children.


Prepare fo 3.2.0 release

https://github.com/ignitionrobotics/ign-sensors/compare/ignition-sensors3_3.1.0...ign-sensors3
Signed-off-by: Nate Koenig<EMAIL_ADDRESS>

update base branch to ign-sensors3?


Allow to specify multiple layers for services

Currently we can specify multiple layers for the init image, but not for onboot or services images. Would be great to allow this as well.

Could you elaborate on the use case?

On 21 Jun 2017, at 12:39, Thomas Gazagnaire<EMAIL_ADDRESS>wrote:
Currently we can specify multiple layers for the init image, but not for onboot or services images. Would be great to allow this as well.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

My use case is adding binaries to an existing container without having to rebuild/modify the whole image. For Docker for Mac we need transfused to talk to osxfs, vpnkit-expose-port as a userland proxy and an iptables binary to workaround a swarm issue inside docker-ce. We added vpnkit-expose-port to the docker-ce image directly, but the other binaries are DfM specific and osxfs is not open source yet so this doesn't seem like a possible option.
Currently I think the only alternative way to do this is to use init-containers to put the binaries in a temporary location and then bind mount them into the target service - or bind mount them from a different service using the path (which is not really supported and will break soon).

There is basically no way we can do this once we switch over to image store, as you just get to unpack one image, and then add bind mounts. As Docker build has perfectly good ways of adding layers to images I would use that, and simply extend the existing base images, although the bind mount thing is also possible.
We do want to make a build tool (to replace the package Makefiles) and this could be a feature for that in future, but its not really possible now, so closing.


kata-deploy: Fix to test locally changes and rename vmlinuz or vmlinux for virtiofs

This will allow to test local changes to the kernel as well it will allow
us to have vmlinuz or vmlinux with virtiofs.
Depends-on: github.com/kata-containers/runtime#2078
Fixes #717
Signed-off-by: Gabriela Cervantes<EMAIL_ADDRESS>

/test

/AzurePipelines run

/test

/AzurePipelines run


Clean up 'critical' code smells from sonarcloud

Issue description / feature objectives
Now we have deployed sonarcloud there remains the issue of what to do with legacy 'CODE SMELLS'.
With the current volume my expectation would be that we target the critical code smells as a background activity to gradually clean up the code base:
https://sonarcloud.io/project/issues?id=compliance-trestle&resolved=false&severities=CRITICAL&types=CODE_SMELL
Caveats / Assumptions

Everyone hacks away at this slowly when the have time

Completion Criteria

No of 'critical' code smells is < 5.

FYI: CognitiveComplexity (1).pdf

Done


could not find a package configuration file provided by "mrt_cmake_modules"

i debug with clion ，when i load lanelet2_core cmakelists ,find this error , how i can i load mrt_cmake_modules?

Well, as the message states, you have to make sure that the path where mrt_cmake_modules is installed is in your CMAKE_PREFIX_PATH variable.
If you are using catkin, you should make sure that clion sets this variable in a similar way as sourcing setup.bash would set it.


Documentation rearrange-improvements

Improved documentation with a new tree of sections and some improvements
in text for better readability

I'm closing this as we decided to use another approach for documentation in repo.


module

Your lib is awesome but it's a pain to use in any modern setup. Can you consider using JS module (es6 native + babel or simple UMD header) so it can be easily import and not just limited to script node.

We'd be happy to accept a PR with that feature!

Ok will look at it


add get_account_sizes

Problem
clean is inefficient and can be very slow.
A big offender is remove_dead_accounts.
Summary of Changes
Add get_account_sizes to storage so that we can efficiently get sizes of many sorted offsets. The overall reduction for remove_dead_accounts_remove_us is from ~90s to ~70s on the ledger-tool clean on a mnb snapshot I've been testing. The creation of the apis and structure allows tiered storage to satisfy these requests more efficiently. The changes also allow us to stop mmapping the append vecs and satisfy the various scanning and random access requests efficiently.
Fixes #

Codecov Report
Attention: Patch coverage is 95.45455% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 81.8%. Comparing base (0025ecd) to head (2621d92).
Report is 6 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##           master     #661     +/-   ##
=========================================
- Coverage    81.8%    81.8%   -0.1%
=========================================
  Files         851      851
  Lines      230370   230387     +17
=========================================
- Hits       188669   188654     -15
- Misses      41701    41733     +32


Latents from latents.npy file

Hi! I am trying to use the latent vectors  (I need to do some interpolations) from the "latents.npy" file in the stylegan3 pkl model and it does not work, I have  tried with several latent vectors and always got the same imagen. I trained the model with Market-1501 dataset.
This is the image I got from the inference when the latents.npy is created.

And this is the imagen when I use  latents.npy

This is my code, I have modified the  gen_images.py   from stylegan3 github project.
    x = np.load("/content/latents.npy", allow_pickle=True)
    for i in x.flat:
        print(i.keys())
        latent_numpy = i["1_1003_00002.jpg"][4] # get latents from image 1_1003_00002.jpg

    latent_tensor =  torch.from_numpy(latent_numpy).to(device)

    # this is from the Stylegan3 github, file  gen_images.py
    img = G(latent_tensor, label, truncation_psi=truncation_psi, noise_mode=noise_mode)
    img = (img.permute(0, 2, 3, 1) * 127.5 + 128).clamp(0, 255).to(torch.uint8)
    PIL.Image.fromarray(img[0].cpu().numpy(), "RGB").save(f"{outdir}/seed{seed:04d}.png")

I do not know if I am missing something. Thanks in advance.

Thanks for the response.
I used the same truncation_psi, equal to 1, but I also had tried with different truncation_psi and always got the same image with
small differences finishing  at truncation_psi = 0 showing the average image.
This example is what is showing with different truncation_psi values, from truncation_psi [0, 1]

I also had tried with different latents vectors from differents images and always got the same with aslile
I am using google colab to test this code with the pt model.
https://colab.research.google.com/drive/1vPF7zz8Rsc6D8_TBUFDRxsslHagebmr9?usp=sharing


string should be flash.media.sound

Describe your problem here.
source/editors/ChartingState.hx:1443: characters 27-54 : String should be flash.media.Sound
source/editors/ChartingState.hx:1461: characters 27-56 : String should be flash.media.Sound
source/editors/ChartingState.hx:946: characters 22-51 : String should be flash.media.Sound
source/editors/ChartingState.hx:959: characters 24-51 : String should be flash.media.Sound
source/editors/EditorPlayState.hx:89: characters 41-74 : String should be flash.media.Sound
source/editors/EditorPlayState.hx:153: characters 24-55 : String should be flash.media.Sound
source/LoadingState.hx:140: characters 10-41 : String should be flash.media.Sound
source/LoadingState.hx:145: characters 10-43 : String should be flash.media.Sound
source/PlayState.hx:1478: characters 41-74 : String should be flash.media.Sound
source/PlayState.hx:1483: characters 51-82 : String should be flash.media.Sound
source/FreeplayState.hx:258: characters 42-75 : String should be flash.media.Sound
source/FreeplayState.hx:263: characters 25-56 : String should be flash.media.Sound
source/PlayState.hx:1441: characters 24-55 : String should be flash.media.Sound
i got this since 2023 bruh
on 0.4.2
Are you modding a build from source or with Lua?
Source
What is your build target?
Linux
Did you edit anything in this build?  Man, the version is outdated like 2-3 years since Shadow Mario did a lot of changes of Psych, so please use the latest stable build


Representing model relationships

Are you planning to add support for attributes that are models?
I'm not sure if the use case is general enough, but I was looking for the following:

A model is returned when calling get for that attribute on the model
The attribute is only marked as changed when a different models is set for the attribute (the related model's attributes can change without marking this attribute as changed)
The id of that model is passed for that attribute when saving

This might be along the lines of the feature you mention in Issue #39.

Are you planning to add support for attributes that are models?

Once we work out those kinks in #39 I think so.
There are a couple of extra questions that might need answering in terms of things like, do we want to allow a nested model to be locked to one type - like how a collection has a defined model which it has a collection of - or would we want to look at a polymorphic possible solution?
There are a few options which are already supporting model nesting. E.g. validateRecursively which if you look through the validateAttribute checks each attribute within the model and, if it has a validate method will validate itself.
The way I've been nesting models is by using Vue.set() then a standard getter to allow the nested model to be fully reactive, but I'm honestly unsure if it's even the safest way to push data onto the model.
    set method( billing_method ) {
        Vue.set(this, 'billing_method', billing_method);
    }

    get method() {
        return this.billing_method || null;
    }

I'm closing this after adding some comments on #39 with what you've said. Comment there if you have anything else to add about this. Super valuable though, thanks @burningbman.


latest black

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Closes #179
Type of change
Please delete options that are not relevant.

[ ]  Bug fix (non-breaking change which fixes an issue)
[ ]  New feature (non-breaking change which adds functionality)
[ ]  Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ]  Performance (if you touched existing code run asv to detect performance changes)
[ ]  refactoring

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. This could point to a cell in the updated notebooks. Or a snippet of code with accompanying figures here.
Checklist (while developing)

[ ]  I have added docstrings to all new functions.
[ ]  I have commented my code, particularly in hard-to-understand areas
[ ]  Tests added for pytest, if necessary.

Pre-Merge Checklist (final steps)

[ ]  I have rebased onto master or develop (wherever I am merging) and dealt with any conflicts.
[ ]  I have squashed commits to a reasonable amount, and force-pushed the squashed commits.

References
Please add any references to manuscripts, textbooks, etc.

@aaronspring @bradyrx hope you don't mind me merging. Everyone was +0 on this.


Logical Theme System - custom route: auth not working, user is always guest

Attempted Debugging

[X] I have read the debugging page

Searched GitHub Issues

[X] I have searched GitHub for the issue.

Describe the Scenario
I'm trying to create a custom page via the logical theme system. (https://bookstack.example.org/test)
But when I load my custom page, the user isn't authenticated anymore.
The output of auth()->guest() is always 1.
Contents of functions.php:
<?php

use BookStack\Facades\Theme;
use BookStack\Theming\ThemeEvents;

Theme::listen(ThemeEvents::APP_BOOT, function($app) {
    \Route::get('test', function () {
        dd(auth()->guest());
    });
});

When I include the middleware auth, I get redirected to /login and then immediatly to the index page where I am still logged in without entering my credentials again.
<?php

use BookStack\Facades\Theme;
use BookStack\Theming\ThemeEvents;

Theme::listen(ThemeEvents::APP_BOOT, function($app) {
    \Route::middleware('auth')->get('test', function () {
        dd(auth()->guest());
    });
});

I am using the oidc as auth_method, but the same problem occurs when using standard as auth_method.
This problem only occurs on the custom route. Everything else in BookStack is working fine.
Exact BookStack Version
v23.12.1
Log Content
no errors in /app/www/storage/logs/laravel.log
Hosting Environment
Docker Image: lscr.io/linuxserver/bookstack:v23.12.1-ls124 on linux/ubuntu host
part of docker-compose.yml

[...]

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack:v23.12.1-ls124
    container_name: bookstack
    environment:
      - PUID=1000
      - PGID=1000
      - APP_URL=https://bookstack.example.org
      - DB_HOST=bookstack_db
      - DB_PORT=3306
      - DB_USER=bookstack
      - DB_PASS=xxxxxxxxxxxxxxxxxxxxxxxxxxx
      - DB_DATABASE=bookstackapp
      - AUTH_METHOD=oidc
      - AUTH_AUTO_INITIATE=true
      - OIDC_NAME=SSO
      - OIDC_DISPLAY_NAME_CLAIMS=name
      - OIDC_CLIENT_ID=bookstackapp
      - OIDC_CLIENT_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxx
      - OIDC_ISSUER=https://auth.example.org/xxx
      - OIDC_END_SESSION_ENDPOINT=true
      - OIDC_ISSUER_DISCOVER=true
      - OIDC_USER_TO_GROUPS=true
      - OIDC_GROUPS_CLAIM=resource_access.bookstackapp.roles
      - OIDC_ADDITIONAL_SCOPES=roles
      - OIDC_REMOVE_FROM_GROUPS=true
      - APP_PROXIES=*
      - APP_LANG=en
      - ALLOWED_IFRAME_SOURCES="https://*.draw.io https://*.youtube.com https://*.youtube-nocookie.com https://*.vimeo.com"
      - APP_THEME=mytheme
    volumes:
      - bookstack_data:/config
    ports:
      - 80:80
    restart: unless-stopped
    depends_on:
      - bookstack_db

[...]

Hi @dreiekk, you'd also need the web middleware, and for the middlware to be loaded in the right order.
In the last feature release I made this easier with a new ROUTES_REGISTER_WEB_AUTH event.
See the relevant part of the release blogpost for an example of how this can be used:
https://www.bookstackapp.com/blog/bookstack-release-v23-12/#logical-theme-system-events-to-register-routes

Thanks!
Using ROUTES_REGISTER_WEB_AUTH solved this.


Infinite loop writing an empty buffer in write::BzDecoder

This minimal example is never returning with the current master (3032f3790742bffda521e54d14429f459e078eba).
extern crate bzip2;

use bzip2::write::BzDecoder;
use std::io::prelude::*;

fn main() {
    let mut d = BzDecoder::new(Vec::new());
    d.write(b"").unwrap();
    d.finish().unwrap();
}

With a similar test case cargo test was stuck:
    #[test]
    fn write_empty() {
        let d = BzDecoder::new(Vec::new());
        let mut c = BzEncoder::new(d, ::Compression::default());
        c.write(b"").unwrap();
        let data = c.finish().unwrap().finish().unwrap();
        assert_eq!(&data[..], b"");
    }

Diving into the simpler example traceback the problem seems related to try_finish in write.rs, where we are writing an empty buffer forever:
    pub fn try_finish(&mut self) -> io::Result<()> {
        while !self.done {
            self.write(&[])?;
        }
        self.dump()
    }

Maybe it is sufficient to check if we received some input? Like:
    pub fn try_finish(&mut self) -> io::Result<()> {
        // If nothing entered, there is no need to loop
        while !self.done && self.total_in() != 0 {
            self.write(&[])?;
        }
        self.dump()
    }

That done cargo test works with the added test too.
Let me know if you'd like a Pull Request, it's ready on my disk.

fixed by https://github.com/trifectatechfoundation/bzip2-rs/pull/118


SignInManager incompatible with Blazor?

At the top of this documentation it implies that "using ASP.NET Core's Identity system" is a viable option.  The Identity scaffold generates Razor pages (.cshtml & .cs) but not Blazor pages (.razor, which is damn confusing, but a different topic).  However, in my testing, SignInManager will always throw an exception: "The response headers cannot be modified because the response has already started."  SignInManager is incompatible with Blazor's underlying SignalR technology.  The work-arounds are either API  call to the Server, or implementing JWT Identity Server.
Is SignInManager incompatible?

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

ID: c9942b0a-a7fb-0d34-9201-af0963affa9e
Version Independent ID: 19770710-5225-a1ea-e082-65da6ba4a49a
Content: ASP.NET Core Blazor authentication and authorization
Content Source: aspnetcore/security/blazor/index.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @guardrex
Microsoft Alias: riande

@bdnts ... ASP.NET Core Identity is working under the covers in these scenarios. I'm working on these topics right now to improve them, so I'm glad you called out your confusion here.
In a component, use either or both ...

AuthenticationStateProvider
AuthorizeView component

... and yes! ... SignInManger/UserManager are incompatible.
Leave this open. I'll make some updates to improve the guidance.

btw @bdnts ... I threw up a quick example that mirrors the guidance in the topic over on https://github.com/dotnet/AspNetCore.Docs/issues/17402#issuecomment-602184048.
We're discussing something a different on that issue, but that comment shows the AuthenticationStateProvider and AuthorizeView component in use.

Whew!  Thought I was going crazy cause it should work, but wasn't!  Thanks.
I created a project called BlazorIdentity (https://github.com/bdnts/BlazorIdentity) that documents the steps I took (readme.md), and the dead end I hit with SignInManager.  The project was a personal lab, but happy to share.  Blazor actions are on the Index page, while Asp.Net scaffolded pages are on the Header.
However, the problem with Blazor A&A is just the "last mile" of Authentication.   Authorization works great.  I'll break it down:
Authentication:

I have a working Blazor Registration page available on the home page

-You can also do the traditional asp.net registration from the header:

--I have a hard coded Blazor login with the Login button, using the default account<EMAIL_ADDRESS>"P@ssword1234".  This will trap the exception thrown by SignInManager.

Here is the interesting part
--Use the Asp.Net Login in the header, with the admin account and login succeeds.

Authorization
Once past the problem with SignInManager, Authorization works as documented.

AuthorizeView used in NavMenu.razor to enable the Administration menu items.
AuthorizeView in Index.razor, depending on role, 3 different messages will appear.
CascadingAuthenicationState in App.razor allows auth state to flow down to all pages.
AuthenticationStateProvider will get the current user state within the app.  Click on the button
 and the user plus authenticationstate will display.
--Cascading Auth State, Administration only authorizes Admin Roles to use.  Logout, access Administration directly, and error "42" pops up.
(Administration page from Michael Washington)

The only problem I couldn't overcome was SignInManager, which I now know cannot be overcome.  However, call the Asp.Net page, that SignInManager works, and then the rest of Blazor A&A works  as documented.
I never got time to experiment with Claims, but I'm guessing they will work as advertised.  (Oops, said the same thing about SignInManager for Blazor.  lol)
If I can be of further assistance, happy to oblige.

Thanks @bdnts ... that just about mirrors the updates on the recent PRs, including the new one that seeks to make sure that the Overview coverage applies to both Blazor WebAssembly and Blazor Server apps. I checked most of the scenarios here this morning, and they all worked. :tada:
I also added a NOTE at the top calling out that SignInManager and UserManager aren't Razor component concepts.

AuthorizeView used in NavMenu.razor to enable the Administration menu items.

:heart: that one ... that's someting that I'll keep in mind as I continue to work these. It would make a nice example in the Overview topic.

Cool.  Glad to be of help.


[MATLAB] Initialize the Type property of arrow.array.Array subclasses from existing proxy ids

Describe the enhancement requested
Now that the issue #36363 is closed via PR #36419, we can initialize the Type property of arrow.array.Array subclasses from existing proxy ids. Currently, we create a new proxy Type object whose underlying arrow::DataType are semantically equal to  - but not the same as - the arrow::DataType owned by the Array proxy. It would be preferable if the Type and Array proxy classes refer to the same arrow::DataType object (i.e. the same object on the heap).
Component(s)
MATLAB

take


ElasticsearchService dummy Index cannot have uppercase letters

Executing :
curl -X PUT "http://localhost:3003/core-model-1-4:control-construct/logical-termination-point=eatl-2-0-1-es-c-es-1-0-0-000/layer-protocol=0/elasticsearch-client-interface-1-0:elasticsearch-client-interface-pac/elasticsearch-client-interface-configuration/index-alias" -H  "accept: application/json" -H  "Content-Type: application/json" -d "{\"elasticsearch-client-interface-1-0:index-alias\":\"veryDummyIndex\"}"
returns error from Elasticsearch:
Elasticsearch error occurred: {"error":{"root_cause":[{"type":"invalid_index_name_exception","reason":"Invalid index name [veryDummyIndex], must be lowercase","index_uuid":"_na_","index":"veryDummyIndex"},"status":400}
Please adjust test dummy es-c/index-alias in ApplicationPattern to not include uppercase letters.
Similarly also ServiceLayer / BasicPart / /v1/list-ltps-and-fcs / Acceptance / vs oam put fails because of uppercase letters.
Provides expected index-alias 'hizVAOLRmLDE' | expected 'eatl-2-0-1' to equal 'hizVAOLRmLDE'

Since it's a small fix and related to ES, I am not going to open another issue:
Elasticsearch service actually changes operational state, see comment .
Right now a test is failing: Expected ../elasticsearch-client-interface-status/operational-state
Provides the expected operational-state '"elasticsearch-client-interface-1-0:OPERATIONAL_STATE_TYPE_NOT_YET_DEFINED"' : expected '"elasticsearch-client-interface-1-0:OPERATIONAL_STATE_TYPE_AVAILABLE"' to equal '"elasticsearch-client-interface-1-0:OPERATIONAL_STATE_TYPE_NOT_YET_DEFINED"'
OPERATIONAL_STATE_TYPE_AVAILABLE is the correct value.

For https://github.com/openBackhaul/ApplicationPattern/issues/694#issue-1719675106, updated the following paths to generate dummy es-c/index-alias with only lowercase letters

ServiceLayer / /v1/list-ltps-and-fcs /Acceptance / vs oam put
ServiceLayer / /v1/redirect-topology-change-information /Acceptance / vs oam put
OamLayer / Core / core-model-1-4:control-construct / Acceptance /vs oam put
OamLayer / BasicPart / elastic-search / PUT / Acceptance / vs oam put


Error 500 changeThreadEmoji

I am getting this error pls help

Is this on a phone?

I'm trying to change thread emoji in the browser right now and getting a 500 there too... might be a facebook bug.

This seems to work in the browser now... wanna check again?

It seems to throw this error when you try to set it to an unsupported emoji (at least as far as I can tell).

Ah, thanks for letting us know @AstroCB.  @tokelpl can you try setting it to one that you can set it to in the browser?  I'm going to consider this resolved as I managed to get it to work on my end.  Please follow up if you have any more problems :)

Just as a note, setting it to %F0%9F%85%B0(🅰) as well as %F0%9F%85%B1(🅱) gives a 500, but they do show up as supported in the browser (messenger.com)


[Bug] Random bobbing

See video
Get random twitching/bobbing with camera with this mod installed

Fixed camera twitching and look at offsets being applied at 50% value


[ISSUE-851][REFACTOR] Migrate quota configruation to Celeborn Configuration System

What changes were proposed in this pull request?
Why are the changes needed?

What are the items that need reviewer attention?
Related issues.
Related pull requests.
How was this patch tested?
/cc @related-reviewer
/assign @main-reviewer

@pan3793 @waitinfuture

In future we might have quota on other resource types such as memory and network. I think we'd better use quota.storage.xxx, quota.memory.xxx

All done, how about current


feat: add automatic fee currency selection to walletconnect viem flow

Description
This PR:

always create prepared transactions on receiving an action request from walletconnect, pass the prepared transactions to the ActionRequest display component. always calculate the gas and feeCurrency for celo network transactions.
if using viem, use the prepared transaction to show a warning if the user does not have enough balance to pay for gas. we can also use the prepared transaction to show the gas fees later.
on accepting the action request, both the walletconnect payload and prepared transactions are passed to the saga that handles submitting the transactions to the network. if using viem, it is expected that the prepared transactions are there and can be directly sent to the network. if not using viem, the prepared transactions are ignored.

Test plan
I am able to make a dapp transaction on Celo and the fee currency is paid in a non native currency.
https://github.com/valora-inc/wallet/assets/20150449/41086562-6ba3-49ad-829d-d9d7a184b634
Related issues

Fixes RET-905

Backwards compatibility
Y

TY for the reviews @bakoushin @jeanregisser !! i've addressed comments and i think the changes are minor enough where i'll just merge. i verified again this morning that we're able to use a non native fee currency for sending tx's using the current solution, but i still intend to dig into the viem sendTransaction feeCurrency topic. so if there are any lingering comments i can also address as follow ups. i'll merge to unblock the other WC tasks


feat: option to skip hiring an engineer  with implement=False

This PR provides additional customizations on what steps to perform with setup.py.

NEW: Do not hire an engineer to write code --implement False (default True)
Hire an engineer and perform code review --code_review True (will also hire an engineer)

Additionally, there are some subjective readability improvements to the README. Glad to remove those from the diff if needed.

LGTM


Add tests for Name class, draft PPP.

Codecov Report

Merging #244 (7b6e445) into master (837a572) will increase coverage by 0.03%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #244      +/-   ##
============================================
+ Coverage     49.51%   49.55%   +0.03%
- Complexity      558      559       +1
============================================
  Files           124      124
  Lines          2565     2565
  Branches        355      355
============================================
+ Hits           1270     1271       +1
  Misses         1214     1214
+ Partials         81       80       -1

Impacted Files
Coverage Δ

src/main/java/seedu/address/model/module/Name.java
100.00% <0.00%> (+9.09%)
:arrow_up:

Continue to review full report at Codecov.

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


Implement Patternfly / Carbon view build time switching.

Carbon and PatternFly build time switching should be implemented to allow the team build either view for strimzi-ui.

Isn't this implemented (and integrated)? https://github.com/strimzi/strimzi-ui/blob/4a5d063b0a894541eed60c2de716e17467db5007/build/webpack.common.js#L61


Improve developer workflow and docs

This PR tries to address some of the major pain points of setting up a development workflow with this theme.
It does a few major things:

Overhauls our developer documentation to be easier to follow and quickly jump between sections.
It also tries to add more explicit steps install various things and invoke them properly
Adds a noxfile.py so that developers can use nox if they wish
Adds instructions about nox as an "automatic setup" step in the dev docs
Updates some of our setup.py dependencies to include developer tooling, and references these in our dev docs.

I would love to hear from @drammock in particular whether these instructions would have reduced the setup time for working on the theme.
closes #487
new developer docs are here: https://pydata-sphinx-theme--490.org.readthedocs.build/en/490/contributing.html

ahhh gotcha - we should definitely fix this!


Add simplified actor runtime

A.K.A. backstage-lite

Closing this for now. We may want to reference it in the future to re-implement shared resources after #33 is merged.


fix[UI]: change the color and contents for reset data

Signed-off-by: bhavyastar<EMAIL_ADDRESS>Description
-- As given in the issue, I replaced PROCEED with RESET
-- Change the background color of PROCEED which is now RESET to dark red color (#ff3333)
Changes :

This PR fixes #5825
Notes for Reviewers
Thanks in advance for reviewing my PR. Happy to contribute to this and looking forward to contributing more.
Signed commits
Yes, I signed my commits.

Yay, @bhavyastar! 🎈

Thanks, Lee, Actually earlier I used this color but then used the color of the Undeploy button. From now, I will definitely confirm with you in order to proceed with PR.
Yay!! 🎈🎉 Thanks a lot @leecalcote.
__
  Summary: :trophy: This code is awesome

You’re right - the colors are a bit mixed up in different places. I looked again after merging and I think you made the right call.
We really need to be consistently referencing a theme. There is an active effort to overhaul Meshery UI that might be of interest to you. See @YashKamboj or MeshMate @Chadha93 for details, if so.


Add eslint-plugin-node

Fixes #123
Add the following rules:

Rule ID
Description

no-unpublished-bin
Disallow 'bin' files which are ignored by npm

no-unpublished-import
Disallow import declarations of private things

no-unpublished-require
Disallow require() expressions of private things

process-exit-as-throw
Make process.exit() expressions the same code path as throw

no-deprecated-api
Disallow unsupported ECMAScript features on the specified version

exports-style
Enforce either module.exports or exports

The other rules provided are disabled for the following reasons:

Rule ID
Reason for disabling

no-extraneous-import
Redundant with import/no-extraneous-dependencies

no-extraneous-require
Redundant with import/no-extraneous-dependencies

no-missing-import
Redundant with import/no-unresolved

no-missing-require
Redundant with import/no-unresolved

no-unsupported-features
Doesn't allow to exclude compiled sources

shebang
Doesn't exclude scripts executed with node but not referenced in "bin" (i.e main.js)

exports-style
Too restrictive, forces to use either modules.exports or exports but not both

Let me know if I should make changes in the rules enabled/disabled or in the configuration.

>  no-unsupported-features
Doesn't allow to exclude compiled sources

Can you open an issue on eslint-plugin-node about supporting this?

> shebang
Doesn't exclude scripts executed with node but not referenced in "bin" (i.e main.js)

This too.

> exports-style
Too restrictive, forces to use either modules.exports or exports but not both

And this.

no-unsupported-features | Doesn't allow to exclude compiled sources

mysticatea/eslint-plugin-node#97

shebang | Doesn't exclude scripts executed with node but not referenced in "bin" (i.e main.js)

mysticatea/eslint-plugin-node#96

exports-style | Too restrictive, forces to use either modules.exports or exports but not both

I first though it was possible to use both modules.exports and exports in the same project as long as it's consistent in the same js file. After more tests it turns out I was wrong.
Using export style that are consistent within each file but inconsistent across the project does create the issue described in the rule.
So I went ahead and enabled the rule

@sindresorhus per this comment we could use the override feature to disable those rules for certain files.
In xo we could by default enable the shebang rule only for the files in the bin property of the package.json.
Regarding no-unsupported-features we could enable it only for certain files, but I don't know if there is a good default setting. We can either:

keep it disabled and let users enable it if they want to
Enable it and exclude ava files by default and let the users configure the overrides property to exclude more
Add a new property in xo called something like compiledSources that will allow to define an Array of globs. And we could use it to disable certain rules for files that match.

What's your thoughts ?
Also I'm not sure that should be part of this PR or if it should be implemented in a following one.

In xo we could by default enable the shebang rule only for the files in the bin property of the package.json.

Yes, let's wait an see the outcome of https://github.com/mysticatea/eslint-plugin-node/issues/96

Regarding no-unsupported-features we could enable it only for certain files, but I don't know if there is a good default setting. We can either:

Let's keep it disabled. I don't want lots of complication for something that is not super useful with latest Node.js, as there are not that many commonly used unsupported features.

Let's keep it disabled. I don't want lots of complication for something that is not super useful with latest Node.js, as there are not that many commonly used unsupported features.

This is something we can implement within the scope of #266

This is something we can implement within the scope of #266

Agreed :)

Great! Thank you 🙌
Would you be interested in joining the project? You done some high-quality contributions :)

I'll take a stab at #266 sometime (in a weeks I guess).

Would you be interested in joining the project? You done some high-quality contributions :)

Absolutely !


Feature/add validation flag

:tada: This PR is included in version 1.0.0-beta.22 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Removing timeFactor Property Invalidates Token

I tried to remove the deprecated timeFactor property from my ENV['ember-simple-auth-token'] object. I'm using the CookieStore to store my session information.
I am able to successfully login to the application and navigate. However, if a page is manually refreshed, the token is invalidated, and the user is logged out.
If I re-enable the timeFactor property, everything works just fine.

This was due to an outdated version of the package. Sorry for the confusion.


Convert ShadedJar task to use constructor arguments

Note that on master the task is quite different - so maybe you only want to change the code on master and not on release.

@lptr & I had talked about putting this against release initially, but now that I see how different ShadedJar is on master, I'm also inclined to kill this one.

OK, let's kill this.


[FLINK-5412] Enable RocksDB tests on Windows OS

This PR re-enables several RocksDB tests.
Furthermore, the RocksDBStateBackendConfigTest#testSetDbPath was modified to ensure that hte same normalization is applied to both the expected and actual paths.

merging.


Use test data from current bark scale generator

Our current test bark scale is from an old generator. This PR will likely "break" tests that were using bad data.

I'm scared that these tests passed... Don't merge plz, this requires further investigation.

Turns out I misread, all is well, this PR doesn't actually do anything.


fix(MavenSupport): Correct querying of artifact repos declared in POMs

Please have a look at the individual commit messages for the details.

Approved, but it looks like there are more expected test results you need to update.

The failing test pass for me locally (also see my message on Slack). Would you mind checking whether GradleKotlinScriptFunTest and SbtFunTest pass locally for you, too?

On CI, I for example see
https://repo.maven.apache.org/maven2/org/jetbrains/annotations/13.0/annotations-13.0.jar

being used instead of
https://jcenter.bintray.com/org/jetbrains/annotations/13.0/annotations-13.0.jar

The failing test pass for me locally (also see my message on Slack). Would you mind checking whether GradleKotlinScriptFunTest and SbtFunTest pass locally for you, too?

Yes, tests pass locally.

Yes, tests pass locally.

As I'm totally clueless by now, I've filed https://github.com/actions/setup-java/issues/454.

As I'm totally clueless by now, I've filed actions/setup-java#454.

Did you already try to clear the settings.xml after the setup-java task?

Did you already try to clear the settings.xml after the setup-java task?

Not after setup-java, but I instructed setup-java to not overwrite it (after I created an empty one).


Job dependency on output variables is not working

Hi. With the following yaml, my expected result would be only running the job TypeScript but not DotNet, but end up both jobs have run. Did I make anything wrong?
trigger: none
resources: [{ repo: self }]

jobs:
- job: PRDifferences
  displayName: Get PR Differences

  steps:
  - powershell: |
       $diff_frontend = 10
       $diff_backend = 0

       Write-Host "##vso[task.setvariable variable=difffrontend;isOutput=true]$diff_frontend"
       Write-Host "##vso[task.setvariable variable=diffbackend;isOutput=true]$diff_backend"
    displayName: 'Detect front/back end changes'

- job: DotNet
  dependsOn: PRDifferences
  condition: ne(dependencies.PRDifferences.outputs['diffbackend'], '0')

  steps:
  - script: "back end as changed, do back end build"

- job: TypeScript
  dependsOn: PRDifferences
  condition: ne(dependencies.PRDifferences.outputs['difffrontend'], '0')

  steps:
  - script: "front end as changed, do front end build"

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

ID: 3f151218-9a11-0078-e038-f96198a76143
Version Independent ID: 09c4d032-62f3-d97c-79d7-6fbfd89910e9
Content: Conditional tasks - Azure Pipelines
Content Source: docs/pipelines/process/conditions.md
Product: devops
Technology: devops-cicd
GitHub Login: @andyjlewis
Microsoft Alias: alewis

The way this works for me is by giving the powershell task a name and referencing it by it's name in the other jobs:
trigger: none
resources: [{ repo: self }]

jobs:
- job: PRDifferences
  displayName: Get PR Differences

  steps:
  - task: PowerShell@2
    inputs:
    script: |
       $diff_frontend = 10
       $diff_backend = 0

       Write-Host "##vso[task.setvariable variable=difffrontend;isOutput=true]$diff_frontend"
       Write-Host "##vso[task.setvariable variable=diffbackend;isOutput=true]$diff_backend"
    displayName: 'Detect front/back end changes'
    name: 'detectChanges'

- job: DotNet
  dependsOn: PRDifferences
  condition: ne(dependencies.PRDifferences.outputs['detectChanges.diffbackend'], '0')

  steps:
  - script: "back end as changed, do back end build"

- job: TypeScript
  dependsOn: PRDifferences
  condition: ne(dependencies.PRDifferences.outputs['detectChanges.difffrontend'], '0')

  steps:
  - script: "front end as changed, do front end build"

It works, thanks.


The synthesized speech has the problem that the time changes and the phrase speech become faster

I use the fragmentvc.pt and vocoder.pt in the Releases, and then feed the VCTK data with sample rate 48000 to generate conversion result. But the phrase of generated result become more faster, whether this is related to the sample rate or the hop_size?

Hello. Have you solved the problem?


fix/Duration/running time display from the Hummingbot

Before submitting this PR, please make sure:

[x] Your code builds clean without any errors or warnings
[x] You are using approved title ("feat/", "fix/", "docs/", "refactor/")

A description of the changes proposed in the pull request:
When the Hummingbot runs for more than 1 day, the bottom status on the left, displaying the running time, gets messed up.
It fixes the issue described in https://github.com/hummingbot/hummingbot/issues/5497, also makes the elapsed time more Linux Uptime like
Before:

After:

Tests performed by the developer:
Waited 1 day
Tips for QA testing:
Wait 1 day ;)

Yes, they are added in the opened issue, but will add them here too

@theomaniac Could you please fix failing tests? thanks

Have asked multiple times and multiple peoiple, about how those can be fixed.
Got no usable answer.
The test it is failing it should be redone.

Have anybody looked at the tests it is failing and why ?

Hi @theomaniac. As I told you before, when you make a change in the code you have to also adapt the test for that.
If you don't know how to do it, another dev can pick the bounty.

@theomaniac Please, change:
/test/hummingbot/client/ui/test_interface_utils.py - lines 48-49 withthe updated display you are proposing (Uptime: ...days...)
        self.assertEqual('Duration: 0:00:02', mock_timer.log.call_args_list[0].args[0])
        self.assertEqual('Duration: 0:00:03', mock_timer.log.call_args_list[1].args[0])

It is necessary and very helpful to reviewers and co-developers to implement the appropriate tests to validate the changes made in the PR - modifying existing tests, adding extra tests, removing obsolete tests, etc...
Tests and coverage (which ensure that new code have test evaluating them) can be run with make test before Commit&Push
Hope this helps, thank you for your contribution (I am just a community beginner dev)

Hi @theomaniac Would you please answer if you're able update the PR with tests advised above and be assigned for the bounty here?

Yeah, will look at the tests

it seems that managed to fix the test, take a look

it seems that managed to fix the test, take a look

fixed


Support Bzlmod and add rules_scala to bazel-central-registry

Greetings!
It looks like rules_scala isn't part of the Bzlmod effort or added to bazel-central-registry yet. I've opened an issue both here and in https://github.com/bazelbuild/bazel-central-registry to request it: https://github.com/bazelbuild/bazel-central-registry/issues/522

@chrislovecnm it's still available here no? https://bazel.build/rules/lib/globals/module#register_toolchains

@sluongng When I last tried it, it did not work when using it inside an extension. In rules_python we are skipping that native call:
https://github.com/bazelbuild/rules_python/blob/36082079b514529d4009a2b104475fde1cdd5b30/python/repositories.bzl#L569
We build the toolchains and use:
https://github.com/bazelbuild/rules_python/blob/36082079b514529d4009a2b104475fde1cdd5b30/MODULE.bazel#L49
And build the toolchains here:
https://github.com/bazelbuild/rules_python/blob/36082079b514529d4009a2b104475fde1cdd5b30/python/extensions/private/pythons_hub.bzl#L56

Yeah you would only want to prepare the toolchain (as a new repository) inside the extension I think. Registering it must be called from the MODULE.bazel file.
So native.register_toolchains call from the extension's starlark does not work, but having the extension create @pythons_hub//:all and then MODULE.bazel calling register_toolchains("@pythons_hub//:all") worked. 👍

Did anyone manage to set up rules_scala in MODULE.bazel with non_module_deps.bzl?

I prepared a minimal bzlmod support here and gonna split it into a few PRs
TODOs after merging it:

write documentation on how to use rules_scala with bzlmod (some properties like SCALA_VERSION will probably be configurable via repo-env)
prepare release notes
contribute repo to the Bazel Central Registry
add tests that the project builds using both WORKSPACE and MODULE.bazel
migrate test/external workspaces to blzmod too

@mateuszkuta256 thanks for getting this started?  Any progress updates or blockers?

@mateuszkuta256 thanks for getting this started! Any progress updates or blockers?

hi, unfortunately I'm working on other things now and won't continue with this PR in the foreseeable future
I remember this migration was on hold because interfered with 'cross compilation support'
It looks like great progress was done it this area, so maybe someone can already take over the PR

I'd like to take on the task of Bzlmodifying this repo through a series of pull requests.
I've already created a (mostly) working branch in my own fork. Though I saw a couple draft pull requests here, I ended up taking a different approach and got it mostly working. In fact, I did exactly what @sluongng suggested in https://github.com/bazelbuild/rules_scala/issues/1482#issuecomment-1631069483. (I didn't notice this comment before just now—I might've read it, but not understood it at the time—but I did study rules_python and rules_go, and ended up doing exactly that.)
There are still issues I need help to address (recorded in some of the commit messages), I didn't strictly maintain WORKSPACE compatibility (fixable), and I only tested against Scala 2.13. But I can start teasing chunks out of it in a methodical fashion, to ensure that I maintain WORKSPACE and cross-version compatibility.
For an example of what it looks like from a client perspective, here's what the MODULE.bazel stanza from my local EngFlow/example repo looks like (as opposed to the current stanza, explanatory comment notwithstanding):
bazel_dep(name = "rules_scala", repo_name = "io_bazel_rules_scala")
local_path_override(
    module_name = "rules_scala",
    path = "../../bazelbuild/rules_scala"
)

scala_dev_deps = use_extension(
    "@io_bazel_rules_scala//scala/extensions:deps.bzl",
    "scala_deps",
    dev_dependency = True,
)
scala_dev_deps.toolchains(
    scalatest = True,
)

So if folks are game for me to do this, I'll start carving off pieces as separate pull requests, and we can resolve any outstanding problems in the process.
cc: @BillyAutrey @jayconrod @benjaminp @TheGrizzlyDev

A quick update for visibility: I'm very close to having the Bzlmodified rules_scala passing 100% of the tests, down to the last couple of failures:

I need to replace the bind() calls from twitter_scrooge with alias() or some such to get test_version.sh to pass.
I need to fix the Scala 3.1.2 and Scala 3.3.3 failures for the Scalafmt targets from test/shell/test_cross_build.sh (corresponding to the test3 and library3 test cases in test_scalafmt()).

I also need to get test_lint.sh working again, and update the dt_patches repos for Bzlmod. But the following all pass:

test_rules_scala.sh
test_reproducibility.sh
test_examples.sh
test_coverage.sh

Hopefully I can get these fixed up today, and I'll start peeling off the next pull request or two. And thanks to @simuons and @liucijus for reviewing and merging #1619 and #1620 already.

I need to replace the bind() calls from twitter_scrooge with alias() or some such to get test_version.sh to pass.

If I recall correctly, scrooge rules support dep configuration via toolchain. I think we should purge the outdated use of bind() in favor of using toolchains. alias() creates new label in the current workspace, it won't allow to replace external names.

After that, I think it's just the bind() and Scala 3 + Scalafmt issues I mentioned earlier that are standing in the way. Hoping to tackle those this weekend.

Let me know if this becomes an issue, I'm coincidentally dealing with related fun for other crossbuild reasons.

Got everything working now except the test/shell/test_cross_build.sh failures for Scala 3 + Scalafmt.
I also fixed the test_compiler_patch 2.13.0 case from dt_patches/dt_test_patches.sh, FWIW.
@liucijus I can see a path to ripping out the bind() calls while maintaining WORKSPACE compatibility, if you'd like me to try that. I'm not currently planning to do it in my bzlmod working branch, but could do it when I create a pull request to Bzlmodify twitter_scrooge specifically.

Btw I really enjoy reading your commit messages in https://github.com/mbland/rules_scala/commits/bzlmod/ :)

Heh, I just explained to someone recently that that my choice for the top line format started as me thinking that I'd only have a few commits that I'd squash. Then after I realized what I got myself into, I kept the gag going to maintain my sanity. I'm definitely going to have top line descriptions when I send the actual pull requests.

OK, got Scalafmt working with Scala 3. So that's it; everything's working now and all the tests pass.
I'll start pulling off pieces and cleaning them up for separate pull requests. I'm expecting a bit of discussion and refactoring around several pieces, but at least I've got a working branch in hand.

@liucijus I can see a path to ripping out the bind() calls while maintaining WORKSPACE compatibility, if you'd like me to try that. I'm not currently planning to do it in my bzlmod working branch, but could do it when I create a pull request to Bzlmodify twitter_scrooge specifically.

I guess it's not worth spending a lot of time on scrooge - I'm not even sure how many users we have, it feels outdated.

I guess it's not worth spending a lot of time on scrooge - I'm not even sure how many users we have, it feels outdated.

Imho yes, let's not block bzlmodification on niche features:)

I guess it's not worth spending a lot of time on scrooge - I'm not even sure how many users we have, it feels outdated.

Imho yes, let's not block bzlmodification on niche features:)

Well, I do have it working under Bzlmod already. I just didn't plan on ripping out bind() entirely until I migrate that piece in its own PR.

@liucijus @simuons Let me know if I'm sending too many PRs too quickly and if I should start holding some back. Up to this point, they're largely orthogonal and can go in in any order, but I'm getting to the point where some changes will depend on earlier PRs. (I can always rebase the future PRs, if you don't mind me running ahead.)
Also, please check out #1625 that I filed today. We're kind of stuck with the "Bazel green head" job failing in a way that breaks our builds due to the problem I described there.

More updates! Thanks to @simuons merging #1627, my currently outstanding PRs all pass (#1621, #1622, #1623, #1624, #1626), including the "Bazel latest" job (currently 7.3.2).
I'll hold off on sending new PRs until those are merged, but I've got quite a few lined up. Here are my branches containing more orthogonal changes that can land in any order:

bzlmod-sync-bazelversion: Contains a script to generate and update .bazelversion files in nested repos. Not so much an issue in CI, but can be surprising when developing locally.
bzlmod-extraprotobufgenerator-catch-throwable: Updates ExtraProtobufGenerator to log errors that would previously crash a protoc-bridge worker and hang the build. This led to a fix, included in the bzlmod-fix-proto-hanging below.
bzlmod-update-scalafmt-deps: Bumps Scalafmt to 3.8.3 to avoid breakage on Scala 2.13 and up, matched with the proper Scalameta version 4.9.9 to resolve Scala 3 hilarity. Also adds a ScalafmtAdapter for API diffs with Scalafmt 2.7.5, required for Scala 2.11.

After those, I'd like to land the following (after some more work and cleaning up) in order to update gRPC dependencies and enable Bzlmod clients to use protobuf > v21.7:

bzlmod-update-protocbridge-and-grpc: Contains changes to accommodate some minor API updates.
bzlmod-fix-proto-hanging: Building on #1623 and bzlmod-extraprotobufgenerator-catch-throwable, this currently bumps abseil-cpp, protobuf, and rules_cc to latest to reproduce/diagnose the previous ProtoScalaPBRule aspect worker hang. Then bumps ScalaPB JARs to 1.0.0-alpha.1 to fix it. Since we want to maintain Bazel 6 compatibility for now, though, I won't commit the actual protobuf and abseil-cpp updates until later.

I'll start breaking off the actual toolchainization pieces now, since I think I've got a handle on all of the other problems with these other PRs and branches.
While I'm going through, I'm also replacing @io_bazel_rules_scala references with either //... paths or Label("//...") instances (in legacy macros— the new symbolic macros coming in Bazel 8 look like a lot of fun!), so Bzlmod consumers won't need to specify repo_name = "io_bazel_rules_scala" in their bazel_dep() directives. This may require a dedicated cleanup PR at some point.
As I've mentioned before, I'm being methodical about solving all the problems I can before landing the actual MODULE.bazel file and module extensions to ensure WORKSPACE and Bazel 6 compatibility. While I'm doing this, I'm building locally with the latest mainline Bazel and patching things into my Bzlmod working branch. Then the Bzlmod parts will essentially land as a thin layer on top.

I've managed to extract //scala:toolchain_type toolchains into a new repo as a separate, WORKSPACE compatible change from the rest of my bzlmod working branch. The other toolchains should be even easier to break off, after this first change is in place.
Right now, that commit and the bzlmod-toolchain-scala branch are based on all the open PRs and changes from other pending branches, but it's otherwise self-contained. I can try rebasing it directly on master in the morning.

@mbland, let me repeat that: you're THE hero!

@mbland, let me repeat that: you're THE hero!

Heh, I appreciate the sentiment, but I don't believe there's any heroics in programming. 🙂 On the contrary, I'm fortunate to be able to work on a problem that's interesting to me, and to get paid to do it.

I updated #1633 to create a new scala_toolchains() macro to provide a common mechanism between WORKSPACE and Bzlmod for configuring and generating a toolchains repo. The other macros are still in place, and compatible with existing WORKSPACE usage, for folks that don't want to switch to scala_toolchains(). But they'll have to add scala_toolchains_repo() to their existing WORKSPACE config in that case.
I've got both WORKSPACE and Bzlmod builds working in my bzlmod working branch now with the changes from #1633 merged in, at least under Bazel 7.4.0. Will try 6.5.0 tomorrow. (I'll use scripts/sync-bazelversion.sh for that. And I had fun hacking together a nifty script for switching between WORKSPACE and Bzlmod to make this process easier.)
I've ripped out the native.bind() calls from twitter_scrooge/twitter_scrooge.bzl. Everything passes, even under WORKSPACE.
Thanks to @simuons for all the thoughtful code reviews and improvements over the past week or so, and @WojciechMazur for jumping in and suggesting improvements as well.

@mbland Not all heroes wear capes 🦸 ! Can't thank you enough for reviving this issue and leading the effort to support Bzlmod.
I'm not a long-standing Bazel user and Bzlmod is so much simpler to use IMO. That said, lack of Scala support is literally the only thing keeping me from making the switch from sbt, and now my hope is restored.
Any ETA on a final release? 🙏

Again, I deeply appreciate the appreciation, but these have been helpful contributions, not heroism. 🙂 I'm compelled to push back politely on such characterizations, however honored I am to receive them.
To answer your question, though, I'm hoping we can land the remaining Bzlmodification changes quite soon.

That said, it's up to the time and bandwidth @simuons and @liucijus have to review the pull requests, whether they have any concerns and/or suggestions, and when they're comfortable cutting a release after that. They've been incredibly helpful and responsive to date, and I'm not trying to rush them. Several of the changes have benefitted substantially from review feedback, including several receiving serendipitous feedback from @WojciechMazur. (Plus, I indirectly roped @fmeum into effectively reviewing #1621 via bazelbuild/bazel-skylib#548. I'm so glad I did, because the end result was so much better.)
As I've been fond of telling people recently, this is Open Source at its best, working as intended. 🙂
Once #1633 gets reviewed, possibly updated, approved, and merged, that will clear the way for the rest of the essential Bzlmodification/toolchainization changes. My comments in #1633 explain what I'm shooting for, and link to the working prototype in my Bzlmod working branch—which now also maintains WORKSPACE compatibility. So hopefully the complete Bzlmodification itself will land quickly.

While I'm at it, let me recap the other activity related to this effort.
Most of the changes so far have been in preparation for landing the essential Bzlmodification/toolchainification changes, the first of which being #1633. Some have been essential prerequisites, fixing things that outright break under Bzlmod, such as #1621 or #1626. But with those fixed, now we're talking about providing a proper Bzlmod API that doesn't put the burden on users to import dozens of repos required by rules_scala toolchains (such as I had to do in the current MODULE.bazel from EngFlow/example). Technically, #1635 falls in this API design category as well.
Other pull requests have addressed small compatibility issues I've encountered along the way, like Bazel 7 compatibility in #1619 and #1620; Bzlmod compatible testing in #1622; and Scala version compatibility in #1628, #1632, and #1634. I've included a couple of helpful utilities I've written as well in #1629 and #1638. All of these should make maintaining the implementation and switching to Bzlmod even smoother, by resolving existing problems before anyone else encounters them.
I've also been identifying and making changes to ensure users aren't version locked on any dependencies thanks to rules_scala, such as #1631 (which was borderline essential, because Scalafmt 3.0.0 threw java.util.NoSuchElementException: last of empty IndexedSeq under Scala 2.13). I'm now focusing on trying to ensure more recent Protobuf module versions work with the scala_proto toolchain and with aspects implemented using protobuf/gRPC/ScalaPB/protoc-bridge (including the Scalafmt aspect). This is where changes like #1623, #1624, #1630, and #1637 come from. Much of that effort involves coordinating version bumps in the jar dictionaries from the third_party/repository/scala_*.bzl files and adding API adapters for specific Scala and/or dependency versions as needed. (Updating those dictionaries manually is why I'm also investing in updating scripts/create_repository.py in #1639, because doing all that work by hand in #1631 was the most time consuming part of this effort to date.)

Anywho, there's a few more changes to come, for Bzlmodification itself, for Protobuf upgradability, and for internal test and tooling updates. But as I've told friends and colleagues, I'm beyond seeing the light at the end of the tunnel. I'm out of the tunnel, off of the highway, and in the neighborhood, around the corner from the destination, turning the radio down so I can focus on where to park. 😛

For my $0.02, I've checked out your mbland/bzlmod scala branch, and used it to build some scala programs - it works great! Thank you very much for pushing this code upstream.
The only issue I had, and I don't think this was related to your changes in particular, was figuring out how to set it up to use the scala3 toolchain- I ended up using --repo_env=SCALA_VERSION=3.4.3 in the build command to set it, but couldn't figure out how to set it in the MODULE.bazel or BUILD.bazel with the new configuration.

For my $0.02, I've checked out your mbland/bzlmod scala branch, and used it to build some scala programs - it works great! Thank you very much for pushing this code upstream.

My pleasure!

The only issue I had, and I don't think this was related to your changes in particular, was figuring out how to set it up to use the scala3 toolchain- I ended up using --repo_env=SCALA_VERSION=3.4.3 in the build command to set it, but couldn't figure out how to set it in the MODULE.bazel or BUILD.bazel with the new configuration.

Ah—my MODULE.bazel from EngFlow.example has an example of what this will look like. The only difference is the extension path will be @rules_scala//scala/extensions:config.bzl:
# This constant matches the default Scala version from rules_scala for now.
SCALA_VERSION = "2.13.12"
SCALA_VERSIONS = [SCALA_VERSION]

scala_config = use_extension("//scala/extensions:config.bzl", "scala_config")
scala_config.settings(
    scala_version = SCALA_VERSION,
    scala_versions = SCALA_VERSIONS,
)

Using named constants is optional, of course. Also, in this case, the SCALA_VERSIONS definition isn't necessary, because rules_scala will do the right thing without it. But if you do use SCALA_VERSIONS, it must contain SCALA_VERSION. Check out the relevant stanza from scala_config.bzl.
There's a similar, but slightly more detailed example in the MODULE.bazel file from my bzlmod working branch. The key difference there is the dev_dependency = True argument to use_extension. That's there because that configuration is only for developing rules_scala, not for its consumers.

@mbland  Totally get it! My comment was mostly intended to show support for this issue and vested interest outside of the normal contributors. This work is really important if Scala is to join many other languages already up-to-speed in the Bazel registry.
Also, although I'm not familiar with development for bazel rules such as this, I'd be happy to help contribute in my spare time if any additional help is needed!

Another quick update...
@zcking I appreciate the offer for help. I feel like the actual code changes are essentially complete, modulo adjustments based on review feedback. Feel free to look at the outstanding and upcoming PRs and offer any feedback or questions if you have any.
@simuons provided some feedback on #1633 that prompted me to make some adjustments and to ask for confirmation on whether to make certain other changes. This one will establish the direction for pulling other changes from my Bzlmod working branch. Though it will remain compatible with WORKSPACE, there will be small yet breaking changes from the existing WORKSPACE API, so it's worth taking the time to get it right.
I've reached some conclusions with regard to my Protobuf compatibility and upgradeability side quest, which I've written up in #1647. I found that rules_scala can either support up to Protobuf v25.5 when building with both Bazel 6 and 7 (with C++ compiler flags set for Bazel 6), or can leap to supporting only Protobuf v28.2 and above. My suggestion is to support v25.5, since the current v21.7 seems too old, but I'd fear switching straight to v28.2 might break too many users right now.
I've opened some new PRs to make a few improvements to the build and test scripts along the way:

#1642
#1644
#1646

The first and last of these, in particular, turbocharged my Protobuf investigation:

The create_repository.py script is now super fast, does more to ensure the entries in the generated third_party/repository/scala_*.bzl files are accurate, and updates more core artifacts (including ScalaPB in my bzlmod-update-protocbridge-and-grpc and bzlmod-update-abseil-cpp-and-protobuf working branches).
The new RULES_SCALA_TEST_ONLY and RULES_SCALA_TEST_VERBOSE env vars made it easier to iterate on specific test cases or files from test_all.sh, test_version.sh, etc., and to see what was happening. (The default is to only emit output on failure, after the command finishes, which proves especially problematic if a test hangs.)

I also figured out how to put a nail in the coffin of the generators-hanging-on-Protobuf-upgrade issue by wrapping ScalaPbCodeGenerator to catch and report previously uncaught exceptions.
At this point, it's just a matter of taking the time to land things properly. No need to rush, and now that I've got all my tools and investigations and proofs of concept working, I plan to take it easy for a while. 🙂

OK, here's my latest weekly update. 🙂 The executive summary is that we're in the home stretch here.
#1633 is super close to going in. And now that I think about it, I think there aren't any WORKSPACE API-breaking changes after all. All the old macros should continue to work with existing builds with no changes (though scala_toolchains is nicer and can shrink existing WORKSPACE files substantially). So technically, the only "breaking" change so far (or bugfix, depending how you look at it) comes from removing external/$REPO)_NAME path prefixes from embedded resources, from #1621.
Speaking of #1621, I've superseded the apparent_repo_name utility from that pull request in the new #1650. Not critical, but it's the right thing to do; I've also closed bazelbuild/bazel-skylib#548 as a result. And an update as of this morning: The Bazel maintainers may be considering a new repository_ctx field to render this workaround unnecessary (eventually).
Integrating the changes from #1648 broke my bzlmod-rebuilding working branch, because instantiating scala_proto toolchain repos collided with instantiating ScalaPB repos for scalafmt and Guava repos for twitter_scrooge under Bzlmod. The WORKSPACE implementation doesn't care, but it's an error to instantiate the same repo multiple times from a module extension:
$ bazel build //src/...

ERROR: .../scala/scala_maven_import_external.bzl:299:24:
  Traceback (most recent call last):
    File ".../scala/extensions/deps.bzl",
      line 140, column 21, in _scala_deps_impl
        scala_toolchains(
    File ".../scala/private/macros/toolchains.bzl",
      line 140, column 17, in scala_toolchains
        _scrooge(
    File ".../twitter_scrooge/twitter_scrooge.bzl",
      line 96, column 17, in twitter_scrooge
        repositories(
    File ".../third_party/repositories/repositories.bzl",
      line 113, column 37, in repositories
        _scala_maven_import_external(
    File ".../scala/scala_maven_import_external.bzl",
      line 263, column 30, in scala_maven_import_external
        jvm_maven_import_external(
    File ".../scala/scala_maven_import_external.bzl",
      line 299, column 24, in jvm_maven_import_external
        jvm_import_external(jar_urls = jar_urls, srcjar_urls = srcjar_urls, coordinates = artifact, **kwargs)

Error in repository_rule: A repo named
  io_bazel_rules_scala_guava_2_13_15
  is already generated by this module extension at
  .../scala/scala_maven_import_external.bzl:299:24

ERROR: Analysis of target
  '//src/java/io/bazel/rulesscala/worker:worker_test'
  failed; build aborted:
  error evaluating module extension scala_deps in
  //scala/extensions:deps.bzl

This led me to develop a schema whereby the toolchains declare their Maven artifact dependencies in a separate macro from the one that calls repositories to instantiate them. (The Scalafmt toolchain had defined a similar macro before, to accommodate different artifact sets for different Scala versions, which I've since updated.) This allows the new scala_toolchains macro from #1633 to collect all the artifact IDs, de-dupe them, and call repositories itself. You can see the final result in scala/private/macros/toolchains.bzl from my bzlmod working branch.
I've prepared commits for the testing toolchains and the Scalafmt toolchain already, to land in that order after #1633. I've started one for the scala_proto toolchain, but want to wait for #1648 to land before going further with it, since that PR introduces scala_proto_artifact_ids, which I'd used to accommodate differences between Scala 2.11 and other versions.
After that, there'll be:

either one or two pull requests to add the jmh and twitter_scrooge toolchains; I do have twitter_scrooge building under Bzlmod already, with all native.bind calls removed and all tests passing
a pull request to prepare the dt_patches repos for Bzlmodification. as well as remove duplication
maybe one pull request to remove all remaining uses of @io_bazel_rules_scala, so that Bzlmod users can usebazel_dep(name = "rules_scala", version = "7.0.0") without a repo_name = "io_bazel_rules_scala" parameter
at least one more pull request to drop in MODULE.bazel files, module extensions, and remove --noenable_bzlmod from .bazelrc; this could be more than one, depending on the maintainers' appetite to migrate all internal repos at once, or one at a time, or in batches
either in the above pull request or in a separate one, turn the Bazel last green head build back on using Bzlmod to close #1625

We could also bump the default .bazelversion to 7.4.1 (or whatever the latest is by that point) and/or bump Protobuf to v25.5, per #1647, but that's not strictly critical. (It would technically break Bazel 6 users, because they'd have to add C++ compiler flags to their .bazelrc to build Protobuf v22 and later.)
At some point I'll look into adding the Publish to the Bazel Central Registry tool, probably after the official 7.0.0 release, unless the maintainers would prefer to do it themselves. After that, and when https://registry.bazel.build/modules/rules_scala goes live, I think we could close this issue!

Weekly update!
#1633 and #1650 are approved and hopefully landing soon. Then I'll fire up the pull request factory again.
But in related news, it's all Protobuf + ScalaPB, all the time, with Bazel 8 and rules_java 8 starting to join in on the fun. #1647 has all the links to all the details, but here's the high level recap.
Upstream ScalaPB and protoc-bridge changes to avoid rules_scala ProtoScalaPBRule build hangs
I filed scalapb/ScalaPB#1771 to volunteer to contribute scalapb.ScalaPbCodeGenerator changes upstream to avoid build hangs due to Protobuf + ScalaPB incompatibilities. Right after that, I noticed the latest protoc-bridge implementation of PluginFrontend.runWithInputStream(). It apparently landed as part of https://github.com/scalapb/protoc-bridge/pull/367, without being specifically called out in the pull request description or discussion. It's not in the latest protoc-bridge 0.9.7 release, however.
Ideally a new protoc-bridge release will come out soon, which might obviate the need to contribute to ScalaPB or maintain the scalapb.ScalaPbCodeGenerator changes from #1648 indefinitely. But I have no idea if or when that might happen.
Bazel 8 and rules_java 8 compatibility requires breaking WORKSPACE builds
Just this morning, I noticed #1652, and experimented with local changes to build using Bazel 8.0.0rc4 on top of my bzlmod working branch. I found (copying from my summarization on the related bazelbuild/bazel#24235) that most of the Bazel 8 and rules_java 8 incompatibilities can be easily addressed once Bzlmodification lands. What I think is the only remaining one may be resolved by a protobuf-java:4.29.0 release (without -RC2). (Granted, I didn't run the full test suite, but bazel build //src/... //test/... //third_party/... //scala_proto/... is a decent smoke test.)
The tradeoffs are that users will be forced to upgrade to Protobuf v28.3 under Bazel 6 and 7 (thanks to ScalaPB 1.0.0-alpha.1), and Protobuf v29 under Bazel 8, and the load("@rules_java") statements required by Bazel 8 to define JavaInfo and java_common.JavaToolchainInfo will break WORKSPACE users for good. Then again, that may be all the more reason to suggest folks migrate to Bzlmod sooner than later.
Versioning for Bzlmod and Bazel 8 compatibility
I'm thinking, if the maintainers are OK with it, it might be worth including Bzlmodification in the next major release (7.x), and then building up to Bazel 8 compatibility in another major release (8.x). The Bazel 8 compatibility release could happen very soon after, since it won't require that many changes. rules_scala 7.x would give existing WORKSPACE users a chance to migrate to Bzlmod first, using either Bazel 6 or 7. Then rules_scala 8.x would enable them to build using Bazel 8, but only under Bzlmod.
Or maybe one could argue for Bzlmodification being released as rules_scala 6.7.0, since I think the only confirmed breaking change is possibly the "bugfix" from removing external/$REPO_NAME path prefixes from embedded resources in 1621. Or, if we bump Protobuf up to v25.5 (or v24.4, since that's the highest compatible version of the protobuf module in the Bazel Central Registry), we'd have to tell Bazel 6 users to add some compiler flags. But then Bazel 8 compatibility would be a truly breaking change, requiring a major 7.0.0 release.
I'm particularly interested in what @simuons and @liucijus think of sacrificing WORKSPACE users for Bazel 8 compatibility, and when. Curious what others think of the possibility as well.

Hi, @mbland, If I understood you correctly I'm leaning towards your first proposal:

Bzlmodification in the next major release (7.x), and then building up to Bazel 8 compatibility in another major release (8.x). The Bazel 8 compatibility release could happen very soon after, since it won't require that many changes. rules_scala 7.x would give existing WORKSPACE users a chance to migrate to Bzlmod first, using either Bazel 6 or 7. Then rules_scala 8.x would enable them to build using Bazel 8.

@liucijus I can see a path to ripping out the bind() calls while maintaining WORKSPACE compatibility, if you'd like me to try that. I'm not currently planning to do it in my bzlmod working branch, but could do it when I create a pull request to Bzlmodify twitter_scrooge specifically.

I guess it's not worth spending a lot of time on scrooge - I'm not even sure how many users we have, it feels outdated.

Can I ask what the significance would be of "not spending a lot of time on scrooge" as part of this effort? We do use that feature + rules_scala and are currently looking into a bzlmod migration as well. CC @mbland.

@liucijus I can see a path to ripping out the bind() calls while maintaining WORKSPACE compatibility, if you'd like me to try that. I'm not currently planning to do it in my bzlmod working branch, but could do it when I create a pull request to Bzlmodify twitter_scrooge specifically.

I guess it's not worth spending a lot of time on scrooge - I'm not even sure how many users we have, it feels outdated.

Can I ask what the significance would be of "not spending a lot of time on scrooge" as part of this effort? We do use that feature + rules_scala and are currently looking into a bzlmod migration as well. CC @mbland.

@FrankPortman It's easy to have lost this in the noise, but I've already gotten twitter_scrooge passing under WORKSPACE and Bzlmod.

Weekly updates!
I'm a little late, but I've been busy making improvements to my branches and pull requests in the wake of the Bazel 8.0.0 release.
Merged

#1654
#1655
#1656

Open

#1653
#1660
#1671

Bazel 8
These latter two pull requests, #1653 and #1660, are related to #1652, which is especially relevant given the brand new Bazel 8.0.0 release. I've rebased both of those pull requests onto #1671 to get them to pass for now.
As I mentioned in an update to the previous update, I already had rules_scala building successfully with Bazel 8.0.0rc6 and rules_java 7.12.2, as well as the less strict 8.0.0rc7 and rules_java 7.12.3. But since the 8.0.0 release, I've updated the following branches, cleaning them up and ensuring they build with Bazel 8.0.0:

bazel-8-compatibility-split-files
bzlmod-bazel-8

With these changes:

WORKSPACE builds succeed under Bazel 6.5.0 (with C++ compiler flags from #1647), 7.4.1, and 8.0.0.
Bzlmod builds succeed under Bazel 7.4.1 under 8.0.0.

These branches bump these dependencies to these very recent versions:

ScalaPB jars: 0.11.17 => 1.0.0-alpha.1
rules_python: 0.38.0 => 1.0.0
rules_cc: 0.0.9 => 0.1.0
abseil-cpp: 20220623.1 => 20240722.0
rules_java: 7.12.3 => 8.6.2
protobuf: 21.7 => 29.1
rules_proto: 6.0.2 => 7.0.2

Bzlmod
I've also updated my bzlmod working branch quite a bit. This is the branch that still supports Bazel 6.5.0 and 7.4.1, but not 8.0.0.
To see the differences between what will be the next major version with Bzlmod and the following major version with Bazel 8 compatibility (though .bazelversion may well remain 7.4.1): git diff bzlmod bzlmod-bazel-8
Amongst the changes, which I've also merged into the bzlmod-bazel-8 branch:

Refactored module extension code for (hopefully) improved readability.
Forced rules_cc to version 0.0.9 for Bazel 6 compatibility, as explained in the top level MODULE.bazel file.
Fixed a few tests that broke under 6.5.0 using a regex from #1622 for optional canonical repo name prefixes appearing in the expected output.
Added compatibility_level and bazel_compatibility to explicitly specify and enforce Bazel version compatibility and to alert users to potential breakage when upgrading. See also: bazelbuild/bazel#24302.
Added WORKSPACE.bzlmod files to ensure that no Bzlmod builds load any WORKSPACE content.

I've also got these branches ready to go after #1653 and #1660, as mentioned previously:

bzlmod-toolchain-scalafmt: based on https://github.com/bazelbuild/rules_scala/pull/1653
bzlmod-toolchain-scala-proto: based on bzlmod-toolchain-scalafmt
bzlmod-toolchain-jmh: based on bzlmod-toolchain-scala-proto
bzlmod-toolchain-twitter-scrooge: based on bzlmod-toolchain-jmh, and the last of the toolchainization changes

I'll also likely split the following commits into pull requests to land before the next major release:

Bazel 6 + Bzlmod test fixes (from the bzlmod branch)
Remove @io_bazel_rules_scala or replace with Label (from bazel-8-compatibility-split-files)
Fix //third_party tests with $(rootpath) (from bazel-8-compatibility-split-files)

Weekly updates!
Things haven't changed much from last week. Both Bzlmod and Bazel 8 compatibility are in good shape, and we're all collectively slowing down for the holidays. See last week's update for details regarding the state of these changes.
Note that I'm taking care to keep my bzlmod working branch and my bzlmod-bazel-8 working branch in a working state. You may choose to use one of these branches to prepare your own migration, weeding out potential issues ahead of time, until the changes land here in bazelbuild/rules_scala. For example, @meteorcloudy is using the bzlmod branch to migrate rules_webtesting in bazelbuild/rules_webtesting#478.
I'm also occasionally checking to ensure the bzlmod-bazel-8 branch remains compatible with the latest Bazel rolling release and Bazel last_green build.
Merged

#1671

Open

#1653 (Bzlmod)
#1660 (Bazel 8)

Bzlmod pending changes

Bazel 6 + Bzlmod test fixes (from the bzlmod branch)
bzlmod-toolchain-scalafmt: based on https://github.com/bazelbuild/rules_scala/pull/1653
bzlmod-toolchain-scala-proto: based on bzlmod-toolchain-scalafmt
bzlmod-toolchain-jmh: based on bzlmod-toolchain-scala-proto
bzlmod-toolchain-twitter-scrooge: based on bzlmod-toolchain-jmh, and the last of the toolchainization changes
bzlmod: contains MODULE.bazel files, module extensions, etc.

Bazel 8 pending changes

Fix //third_party tests with $(rootpath) (from bazel-8-compatibility-split-files)
Remove @io_bazel_rules_scala or replace with Label (from bazel-8-compatibility-split-files)
bazel-8-compatibility-split-files (WORKSPACE only)
bzlmod-bazel-8 (WORKSPACE and Bzlmod, created from merging the bzlmod and bazel-8-compatibility-split-files branches)


Add round trip time metric to compat client

Summary

Renames mtc_client to mtc_client_count
Introduces mtc_client_rtt

Provides cumulative milliseconds spent waiting for each type of request to return from APIserver.
Closes #606

@jortel any further thoughts on this? OK with merging?

One question though - Why 2 separate Reporters instead of 1 Reporter w/ 2 counters and add the elapsed to each Method?

@jortel a single prometheus metric can only have one counter, not sure if that answers your question

@jortel I combined the reporters into one as you suggested, I think it made for a good improvement.