New concurrency warnings when building with Xcode 15.3 beta (Swift 5.10)

As a consequence of SE-0412: Strict concurrency for global variables, we're getting new concurrency warnings when building swift-protobuf. They can be narrowed down to two places:
Default instances of storage classes:
swift-protobuf/Sources/SwiftProtobuf/AnyMessageStorage.swift:144:14: error: static property 'defaultInstance'
is not concurrency-safe because it is not either conforming to 'Sendable' or isolated to a global actor; this
is an error in Swift 6
  static let defaultInstance = AnyMessageStorage()
             ^

swift-protobuf/Sources/SwiftProtobuf/descriptor.pb.swift:3111:16: error: static property 'defaultInstance' is
not concurrency-safe because it is not either conforming to 'Sendable' or isolated to a global actor; this is
an error in Swift 6
    static let defaultInstance = _StorageClass()
             ^

The _NameMap of each generated message:
swift-protobuf/Sources/SwiftProtobuf/any.pb.swift:195:21: error: static property '_protobuf_nameMap' is not
concurrency-safe because it is not either conforming to 'Sendable' or isolated to a global actor; this is an
error in Swift 6
  public static let _protobuf_nameMap: _NameMap = [
                    ^

SE-0412 added the requirements that:

Under strict concurrency checking, require every global variable to either be isolated to a global actor or be both:

immutable
of Sendable type

Neither the storage classes nor _NameMap are Sendable. I need some more eyes who are better versed with Swift concurrency than I am 🙂
Storage classes
For the storage classes, we could just drop the defaultInstance property entirely and just allocate a new empty instance. However, it is a nice optimization to defer allocation of storage until the message is actually mutated. It's not super important if you're creating a new message and then immediately parsing or mutating it, but anywhere that we return an empty message as a default value of an unset message-typed field, it's very nice to not have to allocate storage if the user is only going to read from it.
Can we just mark the storage classes as Sendable on @unchecked Sendable since the messages themselves already conform to that, and the storage types can't be accessed from outside the message?
_NameMap
_NameMap looked more challenging because of the string interning logic and storage of Unsafe*Pointers, but upon further reflection, a _NameMap can never be mutated after its been initialized, so I think we could just declare _NameMap to be @unchecked Sendable and call it a day, right?
As a follow-up, now that Swift Strings are UTF-8 backed, we could probably revisit the UTF-8 buffer interning approach and just store Strings directly. The UTF-8 buffer interning dates back to 2017, so it was when Swift native strings weren't guaranteed to be UTF-8 backed, which I believe was the original motivation for the buffer approach.

fyi - @tbkka @FranzBusch @Lukasa

I went ahead and opened #1561 for topic of revisiting _NameMap. It might make sense do the @unchecked Sendable to get pass the warnings "right now", but doing that revisit to potential remove the issue seems like it might be a good thing in general.

AnyMessageStorage definitely looks sketchy.

Ok, so I think AnyMessageStorage is probably fine, but the default instance is causing us some pain. This is because it's used to skip an allocation, as any mutation to the storage should be CoW'd away. All well and good, but it means we're hitting this. @tbkka is it possible for us to suppress this warning on a per-attribute basis, on the grounds that we're only using it safely?

Why would AnyMessageStorage be any different than an other of the _Storage classes?  The outer Message will call _uniqueStorage() before triggering any mutations within the AnyMessageStorage; so doesn't that make the usage the same as the others?
The thing being flagged about AnyMessageStorage is actually the same as the generated ones, it's the static let defaultInstance() = ... initialization. Right?

Based on my (limited) understanding, we should mark the backing class as @unchecked Sendable.  It's not an entirely satisfying answer -- we're basically just saying to the compiler "trust us, we never use this in a bad way" -- but it seems the best we can do for now.

I don't think we should make the backing class @unchecked Sendable but rather the struct holding the class. Since that struct is enforcing the CoW behaviour. If we would ever hold that backing class somewhere differently then that place also needs to make sure it implements the CoW correctly.

I don't think we should make the backing class @unchecked Sendable but rather the struct holding the class. Since that struct is enforcing the CoW behaviour. If we would ever hold that backing class somewhere differently then that place also needs to make sure it implements the CoW correctly.

What do you mean by backing class?

What do you mean by backing class?

The _Storage classes.

I don't think we should make the backing class @unchecked Sendable  ...

@FranzBusch So how do we deal with the static global that holds an empty copy of that class?   Those are the errors that @thomasvl is referring to above.

@FranzBusch suggested to me offline that

We use nonisolated(unsafe) on the global/static vars that hold the default instances
The _Storage classes remain unmarked
The CoW structs be @unchecked Sendable

Opened #1563 for some of the issues.

The module: Bundle ones are generate code by SwiftPM, anyone know if that's already tracked by for Swift in general?

I couldn't find an immediate issue, can't hurt to file a new one.

Ok, here's a test on main: https://github.com/apple/swift-protobuf/actions/runs/8344464434/job/22837023897?pr=1585
/__w/swift-protobuf/swift-protobuf/main/Sources/SwiftProtobuf/Google_Protobuf_Any+Registry.swift:20:17: error: let 'knownTypesQueue' is not concurrency-safe because it is not either conforming to 'Sendable' or isolated to a global actor; this is an error in Swift 6
fileprivate let knownTypesQueue =
                ^
/__w/swift-protobuf/swift-protobuf/main/.build/x86_64-unknown-linux-gnu/debug/SwiftProtobuf.build/DerivedSources/resource_bundle_accessor.swift:4:16: error: static property 'module' is not concurrency-safe because it is not either conforming to 'Sendable' or isolated to a global actor; this is an error in Swift 6
    static let module: Bundle = {
               ^

Aside: things get printing multiple times which makes me wonder if 5.10 has some other issue going on.
@FranzBusch @Lukasa @tbkka – given the problems with resource_bundle_accessor.swift it seems like we'll have to stop using -Xswiftc -warnings-as-errors, do you see any other way around this?

Oh no.  If I build on my Mac with Xcode 15.3, I don't get either of these.  Does that mean Linux's version of DispatchQueue might not be annotated correctly in 5.10?
Any suggestions for that then?

I guess we could hack the resource one with a #if check for Linux and not add the privacy manifest info?

For the dispatch queue issue, use @preconcurrency import to silence it on Linux.

Did you file an issue for the Module warning?

For the dispatch queue issue, use @preconcurrency import to silence it on Linux.

Ha, I'm testing that out now, I'll move that to it's own PR shortly.

Did you file an issue for the Module warning?

Haven't gotten there yet. If you'd got the time to do it, it will likely get more attention if filed by one of you.

@preconcurrency appears to be a nogo:
/__w/swift-protobuf/swift-protobuf/main/Sources/SwiftProtobuf/Google_Protobuf_Any+Registry.swift:20:17: remark: '@preconcurrency' attribute on module 'Dispatch' is unused
@preconcurrency import Dispatch
~~~~~~~~~~~~~~~~^

This warning is firing on Linux?

This warning is firing on Linux?

Yup - https://github.com/apple/swift-protobuf/actions/runs/8345218414/job/22839591811?pr=1585

I don't appear to get the CharacterSet warning when building on macOS either, so I guess that's another issue within Linux Foundation.
So I think we're down to all problems in the Swift Linux distro now.  Everything we can control should be warning free.

We should be able to fix the warning with CharacterSet by using a @preconcurrency import struct Foundation.CharacterSet. Importantly this import needs to be conditionalised on the platform by using #if canImport(Darwin). Only on Darwin we can avoid the @preconcurrency import since there it is correctly annotated.

Looking back at that code, we don't really need to use CharacterSet, I'll do a quick PR to drop it.

I happened to be looking at swift-nio, and realized they did do the conditional in Package.swift that would break cross comp for the privacy manifest, do we want to do that also?  (Our use of Dispatch for the Any registry will still prevent warnings-as-errors)

I'm going to go ahead and close this since it was specific to 5.10. We may end up revisit some things for Swift 6, but it feels like that should be a new issue.

Related: https://github.com/apple/swift-protobuf/issues/1729


Case sensitive filesystem support

Hi,
I am currently playing around with this repo under Linux.  One issue I had is that linux file systems are case sensitive. I thought maybe you want to have the "correct" names also in the main repo.
Also on some spots the <algorithm> header was missing (on linux the std::find does not work without it)
The change in MfdAlign.cpp seems to be needed because the winegcc compiler is a bit more strict.
Kind Regards
Michael

I'm curious why you did not have problems with Orbitersdk.h/orbitersdk.h?

I did not compile everything so far. Currently have some trouble with wine on my distro. So probably I did not yet stumble upon source files with the "incorrect" orbitersdk.h

Maybe someone could try enabling case sensitivity on a Windows box and see what happens. It would be easier to do a complete check this way.
Good luck with your plan. I gave up compiling with winegcc, it was easier to port the whole thing to linux^^


:bookmark: Release 3.1.1

Updates outatime version to 3.2.1

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.09%) to 75.717%

Totals

Change from base Build<PHONE_NUMBER>:
0.09%

Covered Lines:
396

Relevant Lines:
523

💛  - Coveralls


2021-11-02 equity dashboard chart data update

Equity dashboard stats updates in this PR may be reviewed on staging - here.
After reviewing, if all looks well, approve and merge this Pull Request.
If there are issues with the data:

Note concerns or issues here by commenting on this PR
Work with Triston directly to resolve data issues
Alert the COVID19 site team in Slack (in the Equity page channel)

Hi everyone - Below is my preliminary data review.
@tomasleon, off to you!
I observe no major red flags. :bulb: Noticeable highlights are in report below. Thank you!
:chart_with_downwards_trend: SUMMARY STATEMENT: Statewide & Q1 Test Positivity showing signs of increase now; Death Rates/100K & Case Rates/100K by R&E generally are stable, while Case Rates/100K by median annual household income clearly show increases. Testing Rates/100K continue to decrease.
1. Blue Box Updates:
:heavy_check_mark: All percentage values are identical to last week, and values are reasonable.
2. Death Rate/100K by R&E:
:heavy_check_mark: Statewide COVID Deaths/100K stays at 3 for three consecutive weeks. R&E Deaths/100K show distinct trends: White, Black show decreases, while Multi-Race shows increase. All changes are ≤ 0.8. Asian American continues in its second week as the lowest rate. All values are reasonable.
:bulb: After three consecutive week as the highest rate, AI/AN is now <11.
3. Case Rate/100K by R&E:
:bulb: Unlike the decreasing trend of the last five weeks, this week largely shows stability in all Case/100K rates. Any changes from last week are ≤12 and group-specific (i.e., Black increases by ~2%, while White decreases by ~2%). Statewide remains unchanged at 270. NHPI Cases/100K remains the highest rate. Multi-Race Cases/100K remains the lowest rate. All values appear reasonable.
4. Testing Rate/100K by R&E:
:heavy_check_mark:  Like last week, all Testing Rates/100K noticeably decrease. Statewide decreases from 12,802 to 12,626.
:heavy_check_mark: NHPI Testing/100K remains the highest rate, Multi-Race Testing/100K remains the lowest rate.
5. Community case rate/100K by median annual household income bracket:
:bulb: For the second consecutive week, we see increases in all income brackets’ case rates. Statewide increases from 11.4 to 12.5, a value between the $40-60K & $60-80K income brackets’ case rates. All values are reasonable.
6. HE Metric:
:bulb:  Quartile (2.1) & Statewide (2.2) positivity are nearly identical as of Oct. 24 data, with Quartile positivity being slightly smaller. Both Statewide Positivity and HE Quartile Positivity are now on an increasing trend, deviating from months of a decreasing trend.


Exiting spectating doesn't work correctly

When you stop spectating using the log out button, the user stays in the user list box and if you try to log into the same game later, it will show cards but not allow you to select or play any. You can also end up with several copies of the same username in the game.

I just experienced this issue last night.


Add new versions of h3

I've tested this package remotely and have excluded all broken builds.
Here is the links to the Travis/AppVeyor with status "All passed":

https://ci.appveyor.com/project/isaachier/hunter/build/1.0.506
https://travis-ci.org/isaachier/hunter/builds/396800156

Testing:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.4139
https://travis-ci.org/ingenue/hunter/builds/397362962?utm_source=github_status&utm_medium=notification

Uploading:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.4140
https://travis-ci.org/ingenue/hunter/builds/397376473?utm_source=github_status&utm_medium=notification

Released: https://github.com/ruslo/hunter/releases/tag/v0.22.17


Execute hot-restarter using python3

Commit Message:
Additional Description:
Risk Level:
Testing: None (research how envoy is currently running on modern systems reveals people are using hacks like the package python-is-python3)
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]
As brought up in https://github.com/envoyproxy/envoy/issues/4552#issuecomment-1224654557 I've submitted a PR. Pinging @phlax as suggested.
Note that this MR will break envoy on Platforms that are still using Python2 and don't offer Python3 at all.
I've done a quick test on what I consider the most up-2-date linux (archlinux) to see what the result was when calling /usr/bin/env python and /usr/bin/env python3. There, they point to the same file. This PR is primarily to correct the behaviour for Debian-based platforms. If you consider this PR to be wrong, you likely want to change your Debian package to require python-is-python3 for Bullseye (and up?).

Seems fine. Can you fix DCO please? Thank you.
/wait


NullReferenceException in ShowPlacementMarkerOnPlane method

NullReferenceException: Object reference not set to an instance of an object.
  at CandyCoded.ARFoundationComponents.ARShowPlacementMarkerOnPlane.ShowPlacementMarkerOnPlane (System.Boolean planeVisible, UnityEngine.Pose pose, UnityEngine.XR.ARFoundation.ARPlane plane) [0x00000] in <00000000000000000000000000000000>:0
  at UnityEngine.Events.UnityAction`3[T0,T1,T2].Invoke (T0 arg0, T1 arg1, T2 arg2) [0x00000] in <00000000000000000000000000000000>:0
  at UnityEngine.Events.InvokableCall`3[T1,T2,T3].Invoke (T1 args0, T2 args1, T3 args2) [0x00000] in <00000000000000000000000000000000>:0
  at UnityEngine.Events.UnityEvent`3[T0,T1,T2].Invoke (T0 arg0, T1 arg1, T2 arg2) [0x00000] in <00000000000000000000000000000000>:0
  at CandyCoded.ARFoundationComponents.ARPlaneEvents.Update () [0x00000] in <00000000000000000000000000000000>:0

Fixed with https://github.com/CandyCoded/ARFoundation-Components/commit/775f7f12f528738a1c54c5d9f69be208e308c966


UX issues in Passkey based login

Describe the issue:

The "On-the-fly passkey enrollment" script is only available when a user start with the Passkey template.
Having an adaptive script for the on the fly enrollment makes it harder to understand and error prone to developers. At least there should be a mechanism to educate the user on the requirement for the adaptive script and a clear information on what happens there.
For someone who starts with default or other templates, script is not available.
It makes it harder to write event simple conditional authentication flows such as only to execute MFA for nonPasskey flow when 1st step has multiple options.

As a quick solution, we can add the relevant scripts to the docs until the issue is properly fixed.


Wait OpenStackDataplane resource instead of the deploy pod.

Till now we were waiting for the deployment of EDPM to finish by waiting for the deployment pod, that may fail and can be relaunched by the deploy job. If the pod fails to deploy we weren't aware that maybe the next pod succeed and we marked the entire run as failed.
As a pull request owner and reviewers, I checked that:

[x] Appropriate testing is done and actually running
[x] Appropriate documentation exists and/or is up-to-date

Last week I seen ntp related failures in edpm ansible playbooks, I switched to the internal NTP.
The current wait still hidden the issue, unless it happened 4+ times , otherwise it was a time increase.
It left some pods in Error state.
I wonder when thing otherwise stabilize,
should we check for errored pods and consider  the job failed if any exists even tough  tests were passing ?
Having Error -ed things is bad user facing thing.

Why should CI consider a deployment failed if the product itself was able to recover and correctly deploy EDPM?

Operators find confusing even when the service logs contains ERROR level logs,
there were approach to fail a job when any service logs anything as ERROR.
(Logs typically even did  had message for the error was solved even on Debug level)
Also this kind of ERROR /retry things are time consuming stuff. if we see
one we might either silence it or improve it.
When anybody comes to fixing/debug something first looking for "Error" ,
they may waste a lot of time on a not an error.

Operators find confusing even when the service logs contains ERROR level logs, there were approach to fail a job when any service logs anything as ERROR. (Logs typically even did had message for the error was solved even on Debug level)
Also this kind of ERROR /retry things are time consuming stuff. if we see one we might either silence it or improve it.
When anybody comes to fixing/debug something first looking for "Error" , they may waste a lot of time on a not an error.

But, shouldn't that change go into the operator condition compute itself instead of workaround it here? We saw deployments that took 2 iterations to succeed, and that's something that it's legit, why dropping that internal rety support? If there is an error condition that makes the deployment unusable, maybe is the operator itself, that is the one with enough info about the jobs it manages, the one that needs to flag it as non-ready instead of us, that are simple users.

recheck

The new wait does not cantinas internal name grepping wait, IMHO it sounds nicer, not just a "workaround".
Those "Error"  things definitely in an indicator for a potential of area of improvement.

either ci infra should be more stable
product should find a way for not having errors in a good env

recheck


ModuleNotFoundError: No module named 'utils.logger'; 'utils' is not a package

after commit a758e35 the tests broke due to the import error.

I just discovered that in the /tests directory there is a file named utils.py which, when running the pytest check, will import utils.py instead of /utils which contains the utilities module of the project.

I've fixed this error in the commit that I just pushed.


Show shadow effect if ToolTip.HasDropShadow is set to true

Added the ability to set HasDropShadow for ToolTips.
Adds new effect and color:

MahApps.DropShadowEffect.ToolTip
MahApps.Colors.ToolTipShadow

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: Tide sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@Tide your changes have been merged, thanks for your contribution 👍


[Add]3D flip button

Details
I want to add 3d flip button using html,css and javascript.
can you please assign this task under gssoc'23 contribution. @TANYA-CHAN @sp
Screenshots
No response
Type of Contribution

[ ] Update to an existing Animated Button
[X] Adding a new Button
[ ] Resolving a bug
[X] Proposal to the Repository
[ ] Changes related to documentation or README.md
[ ] Other Changes

Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue
[X] I am a GSSoC'23 contributor

Please assign this issue to me under GSSOC'23 . I want to work on this.

Please assign this issue to me under GSSOC'23 . I want to work on this.

No PRs at the moment, check discord for more updates please

Sorry for the inconvinience, but we are closing all the issues! Please open a new issue if you want to contribute anything. Also now you can create a new button from the website itself! You will get points for those too! I will add the instructions on how to create a new button soon and create an empty pr for the same to get points!


Show cutecoin version in window title

We should show the current version in mainwindow title.

Fixed in https://github.com/ucoin-io/cutecoin/commit/1769f9ce7e4e16577f11a38d589180441dc02fd7


Update install.md

Add a JDK installation command for the running of an android app.

@googlebot I signed it!


IsWindowFullscreen() should be of type bool, not void

Closed this because somehow the issue was duplicated.


Notifications

Message metadata attachment, make it look prettier
Add sound when notification is triggered
Consider in-app notifications (maybe just the sound? perhaps check document.hasFocus() to send notifications instead of the hidden system)

An addition to this could be having a temporary Do Not Disturb mode, as well as a time out where notifications won't be sent for a little bit perhaps.


Always copy item when splitting from the context menu

This updates the context menu so that splitting behaves consistently, regardless of whether the context menu is used from a text editor or not.
The current behavior comes from #7953 but, as @maxbrunsfeld pointed out when we talked about this, the purpose of that commit was to simplify the command names, so the UX change probably wasn't intentional.

Thanks for fixing this @matthewwithanm!


Files outside of basePath not imported

karma-systemjs assumes that all test files are inside the basePath directory, and will be served from somewhere under '/base'. However, Karma will serve files included outside this directory under '/absolute'.
basePath: 'test'
files: ['foo/base.js', '../bar/abs.js']
Karma will serve:
/base/foo/base.js
/absolue/path/to/bar/abs.js
karma-systemjs will create a pattern that attempts to match '/base/path/to/bar/abs.js', which does not match, so the file will not be imported.

Merged #52 and published with v0.8.1
Thanks again!


Cookies generating wrong locales

Using Laravel 5.4
This is the original Translator.php:
vendor\laravel\framework\src\Illuminate\Translation\Translator.php
public function get($key, array $replace = [], $locale = null, $fallback = true)
{
    list($namespace, $group, $item) = $this->parseKey($key);

    $locales = $fallback ? $this->localeArray($locale)
                         : [$locale ?: $this->locale];

    foreach ($locales as $locale) {                               // LINE 122
        if (! is_null($line = $this->getLine(
            $namespace, $group, $locale, $item, $replace
        ))) {
            break;
        }
    }

    if (isset($line)) {
        return $line;
    }

    return $key;
}

When debugging with the package disabled, I got the correct locales for my app using a breakpoint in line 122:

But when I activate the package it sets my app locale to the value of the cookie it generates:

With this incorrect value, it takes the fallback locale, so the translations are not working properly. I had to add
'use_cookies' => false,

in the package config file in order to avoid that error, but since this config option is not there by default, I think that adding this isn't the default package approach.

@gerardreches, I will add it to the default config and install documentation.


Grpc dep fix

Fixes #319
Had to regenerate the proto files and update the grpc library (and dependencies) under the server vendor folder.
Also added some notes on how to vendor.

LGTM


Update the public options of customform

Purpose
The requirements changed and users can publish a form via URL but they don't have to publish it for the whole organization.
Approach

I added a HStore field to provide a way to persist the public options in a combined way

Furter Info
Related ticket: https://github.com/Humanitec/ActivityAPI/issues/441

I added a HStore field to provide a way to persist the public options in a combined way
I'd say it's a JSON

At the beginning, I added HStore but it wasn't working.. that's why :sweat_smile:


Create Docker Container

Dockerize the GraphQL Golang application adding a dockerfile.
Help:
Complete Guide to Create Docker Container for Your Golang Application

I created a ready to production Dockerfile and a docker-compose to run:

Postgres dependency.
Compile Dockerfile and run guzfolio container.


Add support for dropdown border variables

Add the Bootstrap variables for the arrow of the datepicker:

:+1: for merge.

@vicocamacho can you add the variable also to the tbws2 less file? and add the parameter to the build.less & build3.less file with the color code currently in the datepicker(3).less file

Sure, will do it in the next few days

I don't know if you guys saw this, is this what was needed? thank you!

Just add the variables to the build.less and build_standalone.less. Then this PR should be ready (will review it fully then!)

is this correct? https://github.com/vicocamacho/bootstrap-datepicker/commit/6faf3b4b560988bdabc30ba198049a49608a3ecc

will look into it in the next few weeks

LGTM, thanks, merged.

Maybe we should add a styling section to the docs, where we can describe this feature


FR: a "wordcount - page (main view)" renderer that we can put in [[Contents]] that counts for the page in the main view

then it can be used like a widget like sethyuan's toc plugin, and there'll be no need to invoke the "wordcount - page" command for every page :D
Besides: i think "writing session target" needs to be added to the Readme. When we type /word to look for commands this plugin offers, that option wouldn't appear, so I doubt many users know this amazing function!

If you go into plugin settings, you can turn on the "Toolbar Wordcount" setting and the number of words will be displayed in the toolbar.
Noted on updating the README. I've lots of plugins that need their READMEs to be updated!

If you go into plugin settings, you can turn on the "Toolbar Wordcount" setting and the number of words will be displayed in the toolbar.
Noted on updating the README. I've lots of plugins that need their READMEs to be updated!

oh I posted this because I already tried that setting and nothing appeared on my toolbar when toggled. maybe a restart is what'll get it to work, I'll test again later 😂

The toolbar feature is working now, thanks!


Upgrade to Bootstrap 5

Purpose
This PR implements milestone 1 of #1338, by upgrading to Bootstrap ~v5.2.3~ v5.3 (alpha3 for now).
Changes:

checks described in the migration guide
fix form layout
fix scrollspy, since now it does not work if overflow-x is set to hidden in the body (this was quite hard to fix, since it is not documented anywhere)
fix some minor aspects that I noticed by looking at the Academic template

I did not look over the javascript yet, with the exception of the changes described in the migration guide, but this is the next step I am going to look into. In particular, I can try to remove all the jquery dependencies, since they are not required by Bootstrap 5.
Disclaimer
I am aware that Wowchemy is going towards Tailwind (see #2792) insetad of Bootstrap. However, as mentioned in Discord, this upgrade can also be beneficial for some users (in particular while  modules are being ported to Tailwind).
In addition, Bootstrap v5.3 (which is still in alpha), introduces the support for the dark mode. This may be interesting to investigate in the future.

A few comments:

You can see that the PR is failing - please resolve the Yarn error in the CI process so that it passes.
If code is disused, it should be removed rather than commenting it out
If we are going to upgrade Bootstrap, let's upgrade it directly to the latest version (v5.3) so that we can significantly simplify the code base by using Bootstrap's new official light/dark/theming feature, allowing us to remove a large amount of code which was added for our own implementation of light/dark mode in Bootstrap.
Consider asking the community in Discord to help review and test the PR on the various templates, especially the Academic, Minimal, Portfolio, Docs, and Research Group templates

Thank you for the comments:

The CI uses yarn 1.22, while I am using the latest yarn 3.5. I don't know if the failing is related to this. Can I try to update the workflow to use the latest version of yarn?
You are correct, I was just testing before deleting the code. Related to that, can you explain a bit more what the fixscrollspy function was needed for, so I can actually understand if I can remove it? What is the meaning of the comment // Make Scrollspy responsive. ?
I also agree with that. I didn't use it just because it is still in alpha, but I am going to switch to v5.3
After I make some fixes, can you create a branch for this bootstrap 5 upgrade (separate from the main), so people can clone and test it more easily?
Another last question. I also started to remove the jQuery in Wowchemy js files. Do you think I can make the changes directly on this PR, or is it better to create a new branch and a separate PR?

Thank you for the comments:

The CI uses yarn 1.22, while I am using the latest yarn 3.5. I don't know if the failing is related to this. Can I try to update the workflow to use the latest version of yarn?
You are correct, I was just testing before deleting the code. Related to that, can you explain a bit more what the fixscrollspy function was needed for, so I can actually understand if I can remove it? What is the meaning of the comment // Make Scrollspy responsive. ?
I also agree with that. I didn't use it just because it is still in alpha, but I am going to switch to v5.3
After I make some fixes, can you create a branch for this bootstrap 5 upgrade (separate from the main), so people can clone and test it more easily?
Another last question. I also started to remove the jQuery in Wowchemy js files. Do you think I can make the changes directly on this PR, or is it better to create a new branch and a separate PR?

You should be able to edit the action files in the .github folder like any other file?
At the time, Bootstrap's scroll spy did not update when resizing the browser window. So a highlighted menu item would not update based on the window resizing. That JS function fixed the lack of responsiveness in Bootstrap's scrollspy JS. I don't know if they fixed the issue yet, but you can test resizing the Academic or Docs template, for example, and check that the ScrollSpy automatically updates as necessary when the window resizes.
Great to hear :)
You can share the link to the branch in your repo (which Github displays at the top of the PR)
There are already 136 files changed in this PR that the community will need to review. I would not suggest to add any other changes that are not directly related until this PR has been merged. Any new JS required for the new Bootstrap version to work properly should just be added as vanilla JS without converting it into jQuery though.

Notes about some layout changes
I am going to list here some changes I notice with respect to Wowchemy with Bootstrap 4.
Content

now the default container max width is set to the xxl breakpoint (1320px). Previously, the default was xl, which was overwritten from 1140px to 1290px. So now the content is a bit wider. If we want to restore the previous style, we need to override the variables in wowchemy/assets/scss/bootstrap_variables.scss

Components
Buttons

in the Online Course template, the text in the buttons is black, while it should be white. This does not happen for instance in the Academic template (light or dark theme). This could be caused by the new buttons CSS variables

@Agos95 I don't know if you noticed - Github shows that the PR is still failing CI:
Start building sites …
hugo v0.111.3-5d4eb5154e1fed125ca8e9b5a0315c4180dab192+extended linux/amd64 BuildDate=2023-03-12T11:40:50Z VendorInfo=gohugoio
ERROR 2023/05/16 10:55:54 js.Build failed: Could not resolve "./_vendor/medium-zoom.esm"
ERROR 2023/05/16 10:55:54 js.Build failed: Could not resolve "./wowchemy-utils"
ERROR 2023/05/16 10:55:54 js.Build failed: Could not resolve "./wowchemy-navigation"
ERROR 2023/05/16 10:55:54 js.Build failed: Could not resolve "./wowchemy-github"
ERROR 2023/05/16 10:55:54 js.Build failed: Could not resolve "./wowchemy-theming"
Error: Error building site: JSBUILD: failed to transform "js/wowchemy.js" (text/javascript): "/home/runner/work/wowchemy-hugo-themes/wowchemy-hugo-themes/modules/wowchemy/assets/js/wowchemy.js:[8](https://github.com/wowchemy/wowchemy-hugo-themes/actions/runs/4991012080/jobs/8936945761?pr=2942#step:4:9):24": Could not resolve "bootstrap"
ERROR 2023/05/16 [10](https://github.com/wowchemy/wowchemy-hugo-themes/actions/runs/4991012080/jobs/8936945761?pr=2942#step:4:11):55:54 JSBUILD: failed to transform "en/js/wowchemy-bundle.js" (text/javascript): Could not resolve "bootstrap"

Yes, I noticed. I did not have too much time to work on this last week, and I focused on looking at the templates to find if something broke after the upgrade.
I hope to resolve it soon. However, it is a bit strange since, locally, I can do everything without any problem.

Related to this, it looks like you are trying to load the Bootstrap twice - once in https://github.com/wowchemy/wowchemy-hugo-themes/blob/2d67669ce7694d4b2f632994660ca7aeff27f0db/modules/wowchemy/layouts/partials/site_js.html#L5 and then again in wowchemy.js via ESM with import { Tooltip } from 'bootstrap';. We should only import it once and hence, should probably remove the ESM import, which is also the import causing the problem as Hugo correctly doesn't find any file with that name.

Ok, I found and fix the problem (it was quite easy actually).
I need to import Bootstrap js in wowchemy.js, otherwise the linter (yarn run lint:js) in the same github action throws an error. However, I was mispelling the import, since it is import { Tooltip } from './_vendor/bootstrap.bundle.min.js';.
This import was not required with Bootstrap 4, since in wowchemy.js tooltips were initialized with jQuery; but now, in order to avoid the unecessary use of jQuery, this is the suggested way

OK, I had a look ton all the templates, and I think almost everything works as before (here the list of layout changings: https://github.com/wowchemy/wowchemy-hugo-themes/pull/2942#issuecomment-1549439822)

@Agos95 How are we progressing fixing the remaining issues such as those mentioned in https://github.com/wowchemy/wowchemy-hugo-themes/pull/2942#issuecomment-1549439822 and removing the second loading of Boostrap JS so that it is only loaded once?

Regarding to https://github.com/wowchemy/wowchemy-hugo-themes/pull/2942#issuecomment-1596287288 :

I set back the default container width as it is now in wowchemy
in order to have the underline on hover, the only solution I found is to edit the CSS. I actually do not know why it changed
text color for buttons depends on the Bootstrap color variables. Since the theme is light, it gets dark text. I think this should be investigated with the adoption of bootstrap variables for colors

However, I found a (new?) bug with the carousel slider (eg. in research group template). I don't know if this is new beacouse I merged the recent commits in the main branch, or if I did not find it earlier (but I am preatty sure this was not happening before). Now the slider keeps on rapidly changing the slide for some reason. I need to try to revert to older commits, or look if there is a problem with my Hugo version (I am on Manjaro, with Hugo 0.111.3-1).
Next week I will be away from home for work, so I am not going to have time to look into that immediately.

Ok, I fixed the issue with the slider (it was a change in bootstrap not documented in the migration guide). I had another look at the templates, and there should not be major/breaking changes in the layouts compared to the current version with bootstrap 4.6.

@Agos95 it appears you have made changes to the Bootstrap folder? The goal is just to import Bootstrap and customise everything in the Bootstrap variables. So please update the PR so that no changes are made to the Bootstrap folder, as that should only be maintained by the Bootstrap team and not us.
Also, before this PR can be merged, we need to still resolve the other issues like importing Bootstrap once rather than importing it twice as you have done in the current PR. The Bootstrap and Hugo forum communities can help with only importing Bootstrap once.
Ideally, we should really remove the majority of the Wowchemy SCSS when we migrate to Bootstrap 5 as the modifications were largely made as workarounds to Bootstrap 4 to add the functionality which we now have in Bootstrap 5. But if no one is motivated to review the Wowchemy SCSS at this stage, perhaps we could follow up this PR with another PR to significantly review and reduce all the custom Bootstrap 4 related CSS.

@gcushen The changes in the Bootstrap folder are due to the fact that I upgraded to Bootstrap 5.3.0, while when I first submitted this PR Bootstrap was at v5.3.0-alpha2.
I removed the Bootsrtap js import from https://github.com/wowchemy/wowchemy-hugo-themes/blob/9fdadd48b880d274612ddf4723d7d79c92078f7d/modules/wowchemy/layouts/partials/site_js.html#L5
and I left the one in wowchemy.js https://github.com/wowchemy/wowchemy-hugo-themes/blob/9fdadd48b880d274612ddf4723d7d79c92078f7d/modules/wowchemy/assets/js/wowchemy.js#L8
I did so by following the example site in the official Hugo bootstrap module. Actually, should we use this Module to package Bootstrap, insead of the current method? The repo is in the official Hugo github, and it is mantained by bep himself.
As far as the SCSS, I just fix what it was reported in the Bootstrap migration guide. I think this may be to much to review in a single PR: in my opinion it is better to tackle that (and the removal of jQuery and the other unneeded js) in other PRs.
Tomorrow I am leaving for holidays, so in case other fizes are necessary, I will not be able to work on this for the next couple of weeks.


added dark mode to index.html page

Fixes #36
Description
I have added dark mode to index.html page of the website.

Close via #48


Hardcore Mode on multiplayer server doesn't drop you into one of your shells

I've tried testing this out on a multiplayer server and it seems that it doesn't drop you into one of your shells when you die. We tested this with multiple different players and all of them weren't dropped into a fully built shell. We can swap between shells easy enough, but doesn't want to work on death.

Did you switch to a built shell before dying?

yes

I didn't test hardcore servers before, but I did test survival ones and there were no problems at all
Could you use the latest dev build from GitHub Actions, please? Because I cannot reproduce the issue. Also, make sure to switch to a new shell before dying, since when your original body dies, you'll die too


cmd+I should open in the code editor instead of on top

Context
cmd+I opens on top:

but it should be like this:

This is a duplicate of https://github.com/trypear/pearai-app/issues/36


check whether static provisioning works

Is your feature request related to a problem?/Why is this needed

Describe the solution you'd like in detail

Describe alternatives you've considered

Additional context

actually it works well


Implement C and Java generation support for implicit/explicit operators

Fixes https://github.com/mono/Embeddinator-4000/issues/581.

@tritao is this work unfinished? I think the Windows build is basically timing out on the Run-C-Tests Cake target.

The work should be finished, I left it unmerged because I did not figure out why the Windows CI was not working and did not want to break anything.

Hey @akoeplinger  - Why was this re-tagged for review? Do you want it to go in or was it a misclick?
My information, which may be out dated, was that the C backend was maintained by someone on the mono side who's since moved on.
While those of us who did Obj-C/Java could look at it, there may not be a perfect content expert to review.

master was renamed to main, @chamons you can ignore if you like.


Nice is stop working with new GDK updates in arch

Hi mut-ex,
nice is not work now. The arch began to cast new spells with GTK 40. Some packages are on 40 version now. And it seems that it kills your module. This is from my both stations with awesome-git aur version which using nice module.
The stacktrace is below.

error while running function!
stack traceback:
[C]: in function 'lgi.corelgilua51.registerlock'
/usr/share/lua/5.3/lgi/override/Gdk.lua:23: in main chunk
[C]: in function 'require'
/usr/share/lua/5.3/lgi/namespace.lua:183: in function 'lgi.namespace.require'
(...tail calls...)
/home/box/.config/awesome/nice/init.lua:57: in main chunk
[C]: in function 'require'
/home/box/.config/awesome/rc.lua.test:35: in main chunk
error: /usr/share/lua/5.3/lgi/override/Gdk.lua:23: bad argument #1 to 'registerlock' (userdata expected, got nil)
error while running function!
stack traceback:
/home/box/.config/awesome/nice/init.lua:79: in main chunk
[C]: in function 'require'
/home/box/.config/awesome/rc.lua:35: in main chunk
error: /home/box/.config/awesome/nice/init.lua:79: attempt to call a nil value (field 'init')

Jump in from your post on r/awesomewm
On the awesome repo we have this PR https://github.com/awesomeWM/awesome/pull/3297 to fix the GTK 4 vs GTK 3 issue because LGI don't support GTK 4 for now. I guess something similar should be done to properly load GDK.

:+1:


body track v1.1.0 model does not load in countries that don't use ASCII; due to model_path is not wchar_t

k4abt_tracker_configuration_t.model_path is a POD const char*. Naturally, this is errant.
Azure is a world-wide service and includes Kinect. Therefore, the path must be a wide char, UTF-16, UTF-8, etc.
Setup
Body tracking v1.1.0
Repro
Look at the header file sdk\include\k4abttypes.h
Result
Line 157
const char* model_path;

Expected
const wchar_t* model_path;

or better...
const filesystem::path model_path;

Workaround
None. If there is any part of the path that has a non 8-bit ASCII/simple character, then it is impossible for body tracking to load the model.

@qm13
It is nonsense that you cannot use wide char as the product name in the name of the application. I'm having the trouble installing my application using the installer.


Dockerfile

Hey epic work!
Could you post a Dockerfile for training/inference?
Thanks!

I'll put it on my to-do list, but given that I don't personally have any experience with Docker, a community contribution here would be welcome.

I will try to do my best tomorrow!

I can do this, should i start?

please, I moved to other stuff.

Curious if anyone's made progress on this?
-- Would be quite useful...

@mblumberg See #54

Thx :+1:


bug in command-line tool "fairseq-score" when using the "--sentence-bleu" argument

🐛 Bug
bug when using command-line tool "fairseq-score" with argument "--sentence-bleu"
To Reproduce
Steps to reproduce the behavior (always include the command you ran):

Run cmd  > fairseq-score -s sys -r ref --sentence-bleu
See error

Error messages
File "fairseq\fairseq_cli\score.py", line 67, in score
scorer = bleu.Scorer(dict.pad(), dict.eos(), dict.unk())
TypeError: Scorer.init() takes 2 positional arguments but 4 were given
Additional context
the "bleu.Scorer.init()" takes "BleuConfig", but "dict.pad(), dict.eos(), dict.unk()" are given in farirseq_cli/score.py

same problem. do u solve the problem?


Fixes #38

Tests still pass after this. Might be a good idea to add a test that fails before this but succeeds afterwards. Let me know if you want that.

Ok I added unit tests.


Add payment debtor account currency validation

This PR is to fix https://github.com/wso2-enterprise/financial-open-banking/issues/7373.

This is fixed in #40.


Small data changes to get DRG and MCH updated for 5.1

Figured I'd throw this one into the pot real fast before I work on the monstrosity that will be the NIN changes.

Mentioned it on Discord but just so it's on record - MCH has no modules that worry about AoE at all, let alone looking at potency, so it should be fine.


CodeIntegrity compatible option

We need a powershell native option for environments with AppLocker / CodeIntegrity deployed. .cmd's are blocked, as they can't be signed.

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

ID: 27dbd025-8239-9847-b07e-378ca87d2d75
Version Independent ID: 4b0e4ac7-a608-7c62-dcd4-2db628b3f67a
Content: Onboard Windows 10 machines using Group Policy to Microsoft Defender ATP
Content Source: windows/security/threat-protection/microsoft-defender-atp/configure-endpoints-gp.md
Product: w10
Technology: windows
GitHub Login: @mjcaparas
Microsoft Alias: macapara

@mschrisran - Thank you for engaging with the community here for the docs.
I know the product teams are always looking for user feedback and feature requests on how to make Windows 10 better. They keep a close tab on user feedback and it would be awesome if you could add your voice via Feedback Hub.
You might find others have made a similar request that you can add to, or you can open a new one. Let us know here if you do so we can up-vote your request.
Thank you for your contribution to make the docs better! Much appreciated!


iPhone 12(s)

Gents,
Would you work your magic for the 12's?  I think they ship Oct 23rd...
The profiles are in Xcode Version 12.1 (12A7403)
TY in advance - you all are awesomeness.
:)

sure thing! will do so when I become free


Add Chain ID 1337

ChainID: 1337 ➡ chain-list
Add Chain ID 1337 (official local-net ID: geth --dev, ganache-cli) to the official registry to facilitate the usage of protocol-kit or safe-wallet-web against a local node.
singleton-factory for Chain ID 1337 already exists so deterministic deployments for this id is possible, hence adding them to the safe-deployments registry.

Chain ID added is 1137, but the issue says about 1337.

Thanks for catching the typo, it's fixed ✅


Analyze prebuilts for xliff-tasks

The following prebuilt packages are included as dependencies in source-build by xliff-tasks.  These need to be analyzed to determine how to avoid requiring packages that source-build doesn’t build.

Change to use the source-built version
Package is not critical to product and can be removed.  (i.e.test-specific, windows-specific, etc)
The package is used as reference only
The package should be built in source-build
Other – please elaborate on what you think should be done.

For more detailed usage information for these, please see the Usage Exploration tab of the SourceBuildPrebuiltReport.

PackageName
PackageVersion
SourceBuiltVersion
Category

Microsoft.Build.Framework
15.1.1012
16.0.0-preview.385
reference-only

Microsoft.Build.Utilities.Core
15.1.1012
16.0.0-preview.385
reference-only

@dseefeld Both packages are reference-only.
Note I don't seem to be able to modify this issue; otherwise I would have just updated the table myself.

@tmeschter Thanks.  I updated them.


syncthing: 1.24.0 -> 1.25.0

Description of changes
https://github.com/syncthing/syncthing/releases/tag/v1.25.0
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 258779 run on x86_64-linux 1

4 packages built:

qsyncthingtray
syncthing
syncthing-discovery
syncthing-relay


On the deprecation of issue to pull request conversion

I recently updated hub, and was dismayed to see this new warning introduced in 4f70dd126f46dec14fc341c97c18efae417743c7:
$ git pull-request -i 321
Warning: Issue to pull request conversion is deprecated and might not work in the future.
https://github.com/spring-io/sagan/pull/319

My team and I use issue-to-pull request conversion as a core part of our workflow. So useful is this feature that we call it out in our contributor guidelines, and incite developers to install hub on the merits of this functionality alone.
Issue to pull-request conversion is a great way to evolve all the way from a question to a discussion to a committed contribution, keeping everything in context in a single issue. It would be a shame to see it go. If anything, I'd hoped that this workflow might be further promoted to first class status in the web UI as well.
Can you expand on why this is being deprecated? I realize that hub is not responsible for this change, but is rather a decision being made at the API level. Whom can I lobby to reconsider that change?

I get the error:
Error creating pull request: Unprocessable Entity (HTTP 422)
Not allowed to change field "issue"

when trying to do this. How do I force hub to use the v3 API? I do not want to waste another issue no, since a single issue was created to update a URL, and a single commit is required to do so.

@alexchandel hub uses and will continue to use the v3 API. I sounds like you worked around your issue. The initial validation failure that you've got might have been a misleading message; sorry about that.

I have my main repo  and I forked it and brought it locally and then created a branch… no problems making changes locally and then committing to my own fork at github, but then I want to issue a pull request from command line for my forked branch to my main repo - getting errors on command line - every thing I have looked at online suggests that it should work - what am I missing?
git remote -v
origin   https://github.com/MYFORKEDREPO/my.git (fetch)
origin   https://github.com/MYFORKEDREPO/my.git (push)
remote    https://github.com/MAINREPO/main.git (fetch)
remote   https://github.com/MAINREPO/main.git (push)
git pull-request –m "Testing pull-request" –b MAINREPO:master -h MYFORKEDREPO:mybranch


Prototype descriptors and validation functions

Description of the changes being introduced by the pull request:
This experiment tries to help us envision how validation will look like
if we decide to use validation functions + descriptors.
What I found with this experiment is that python descriptors can't
handle dictionary keys validation as well as dictionary values.
More precisely, we can't validate that each of the "roles" in Root is
one of the 4 metadata types or that Root role keyids are unique.
The reason is that for example if we are to run this:
"root.roles = 3" this will invoke validation for root.roles, but
if we invoke: "root.roles["dwad"] = 3" then we are getting an element
of the dictionary roles and then assigning it a new value.
Please verify and check that the pull request fulfills the following
requirements:

[ ] The code follows the Code Style Guidelines
[ ] Tests have been added for the bug fix or new feature
[ ] Docs have been added for the bug fix or new feature

Writing down some thoughts on this (wall of text sorry).
The task at hand is not "write validation code" -- or if it was that I want to now change it to "1. improve security against malicious json, and 2. make API easy to use correctly and hard to use incorrectly (with least amount of most obvious code)". This is abstract but I do have practical suggestions below. The reason I say this is that I fear we are concentrating too much on adding validation when there are other solutions (like modifying the implementation) to achieve the same goals.
How should we proceed with this task? I believe we need to one by one analyze individual items in the API (starting with the small bits like strings and continuing to larger items). For each item we should consider and document

what can go wrong with this item
where is this used? where is it set? Should it be used in these places?
what can we do to improve the safety/usability?
if we choose validation, define what exactly do we want to validate

and only then implement chosen improvement, if any. Many of these improvements will include validation but we should not add validation if we can achieve the goals without it and validation may be only part of the solution to a specific issue. Also what exactly is validated should be spelled out somewhere -- otherwise it's impossible to tell if the validation implementation is correct or not.
This is hard work but I believe it's the path to better code. Trying to implement a lot validation at once will not lead to good quality.
As examples I went through analysis for _type and spec_version:

_type should not be user-settable at all (it does not make sense), and deserialization validation of _type happens in Metadata already (the fact that type is a Signed constructor argument is IMO a bug that we should fix: each Signed implementation should know its type without it being told what it is): no validation should be required here
spec_version: deserialization should be validated but there does not seem any reason for spec_version attribute to be writable: we probably want to prevent modifying that instead of validating the new value. Calling a validation function from constructor only seems fine to me (if modifying the public attribute is not possible) but other options do exist. Validation should include

value can be parsed as three ints separated by dots
maybe comparison to library supported version? -- this is implementation defined, not specified so we can choose. Updater currently raises on major version mismatch and logs on minor

I would start with individual PRs with that sort of analysis and proposed fixes. I would probably start by just adding the validation calls in constructors and maybe making the attributes properties with setters and see how it goes from there -- but I can see the value in trying other integration methods as well (descriptors/decorations)... I'm assuming a single solution is not going to cover all cases and starting simple is good (so we can change our minds).
More detail comments:

keeping validation functions outside of metadata.py seems fine to me
looking at the example, descriptors IMO hide the validation and are still magic: When I'm reading metadata.py I can't see what gets validated and when, and I think that's bad. I don't need to know details of the validation but I would like to see e.g. validate_spec_version(spec_version) in the constructor or a property setter (or maybe it's a @validate_spec_version instead) -- anything that makes it easy to see what is validated, and easy to follow through to the validation code.
I don't like the type checks -- they may be useful in specific situations but generally speaking I suggest letting the validation fail with TypeErrors or AttributeErrors instead
I do like the idea of testing how validation reacts to completely wrong types though (I suggest only covering types that json can contain) -- this should give us a good idea where we might need better type checks

I agree with the general idea to rethink how we store and operate with the different metadata fields.
I plan to follow this process for each of the metadata attributes:

research how we use it
answer what might go wrong with it
rethink how we store  it (should it be read-only? maybe class attribute? private attribute?)
If, after the 3-rd point making the necessary changes for it, there are concerns add a validation function
document my findings in a commit message and/or somewhere else
If we decide we need additional validation functionality,  propose a way to integrate it into the class/classes (decorators, descriptors, etc.)

Closing this one as it's no longer applicable.
We decided we will research each attribute individually and this decide on its validation.


[Task] Implement Bank POST Blocks Method

Task
Contributors are able to complete this task and earn thenewboston coins.  Check out the labels to learn how much you can earn for contributing by completing this task.  Please make sure to be honest if you wish to contribute by saying you can't finish this and we can just un-assign you with no harm done!  There is no point in delaying tasks from being completed for miscommunication!

Overview
Create a method named addBlocks for the Bank class which will take in the currently balanceLock (string), transactions Transaction[], and the senderAccount (Account).  Refer to the docs on this endpoint and the Account docs on creating block messages.
Behavior
This is how the shape of the function should look:
class Bank {
  /**
   * Adds new transaction blocks to the blockchain.
   * @param balanceLock the current balance lock
   * @param transactions the transactions to push to the block chain
   * @param account the account that is sending the transactions
   */
  async addBlocks(balanceLock: string, transactions: Transaction[], account: Account) {
    /* code */
  }
}

Please include the JSDoc in your code and replace the TODO for this API method with your code.

Please ask for this task to be assigned to you and earn and its sweet reward 😉
Remember to include your account number in your PR description for us to pay you 💰

working on it

working on it

Thanks, just assigned it to you 👍


Zero friction physics material does not simulate

Creating a basic rigidbody with a physics material which has a friction value of 0 causes the rigidbody to stop all movement. Other bodies with higher friction values will still simulate in the same space, and will treat the body as static.

Thanks, will look into this.


Context aware toolbar

Coverage decreased (-0.5%) to 57.822% when pulling 814e02886eb5f9be9ad9e44efbd0512d57cddfd8 on context-aware-toolbar into 607a6a4843a1142cb77b82afe3b58f5ff4a84572 on master.


Documentation unclear: what happens when there is no item in the queue

The documentation for the Peek family of methods is unclear.
What happens when there is nothing in the queue? I assume null is returned, but this should be formally documented.

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

ID: e7941efb-f3cd-99a5-cc9b-ee44365ca516
Version Independent ID: 18dc449f-76e7-cb7a-5a09-694c96e24cc1
Content: QueueClient.PeekMessageAsync(CancellationToken) Method (Azure.Storage.Queues) - Azure for .NET Developers
Content Source: xml/Azure.Storage.Queues/QueueClient.xml
Service: azure
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

@knightmeister Thanks for reaching out to us and sharing this feedback. We are looking into this issue. We will provide an update once we have more details.

@knightmeister Thanks again for this feedback. The above PR has bene filed to address this. The PR is currently under review. In the meantime if you have any questions, please feel free to ask.


Shift clicking a pearl into a furnace breaks tracking

This happens even when the furnace is already full. The pearl stays in your inventory, but /ep check will show it as being in the furnace, or in some cases, a block at the coordinates of the furnace.

makes sense; different tile entities trigger different types of event triggers. I would recommend adding some debug code to output those Enums, and match against the logic in tracking, to see what needs improving.

Is there a way to determine ahead of time if something will actually get placed into an inventory slot during a PLACE_ InventoryClickEvent? For example, attempting to place a pearl into a furnace's fuel slot temporarily breaks tracking (fixes itself when you place it in your inventory or drop it, but will get freed if you /ep locate while it's in your cursor) because it assumes that it was successfully placed, while it actually doesn't go in the slot because it's a fuel slot :/

so far in my testing of this nature... no. You basically need increasingly complex checks to decide if something will happen, or a post-check to validate that it did happen ... none of which is really supported and much of which is vulnerable to "rapid clicks" or other stupidly degenerate outcomes due to how minecraft handles things and as a consequence how spigot wraps and exposes it.
Simplest route is just prevent placement in all but a select few containers, then fully enumerating the containers you want to support.

I think it is sufficient to limit it to only inventories that can accept every item in every slot, so hoppers, chests, double chests, dispensers, droppers.

That should simply the logic a good deal.


xwayland: make sure server side decorations are possible

I don't know how server side decorations work, but we should make sure they are possible in xwayland.
Can the current xwayland api support this?
I'm making this issue because Weston seems to do ssd within xwayland itself, and I know from dealing with this in other window managers that there are potentially things that need to be done with the X11 protocol to support this.

Couldn't you just render them around the view like you'd do SSD for any other view?

Couldn't you just render them around the view like you'd do SSD for any other view?

That's what I'm trying to figure out. I think that's the case, but I don't know how SSD works in sway.

It works as I described.

It works the same way in Way Cooler. I'm unaware of any WMs that do it differently in fact

Yeah, I think this is a non-issue. We already have everything we need for this.

Ok that makes sense. That's actually quite a change from the current rootston way of doing things, which assumes that the toplevel of the view is what is positioned with x/y. But these probably aren't going to be differences that are specific to xwayland (although I am not familiar with the kde ssd protocol). So if you're confident it's possible, I am too.


Real size of the output (definition of scale and offset)

While trying to adapt DeepImageJ to the YAML file, we had some doubts about how to specify the shape of the output. Here I let you the questions we come up with:

Is there any specific definition for scale and offset when defining the shape of the output?
What is the reference for scale? Is it output_shape = input_shape * scale or input_shape = output_shape*scale?
For the offset, does it refer to difference between the shape of the input and the output? after or before the scaling? What is the main difference between halo and offset?

If we want to do tiling, we should consider both the size of input and output tiles, and the size of the final output after tiling. A good example could be doing super-resolution (the output is larger than the input) with an encoder-decoder. Is there any consensus about this? If not, I suggest the following:

Shape of the model's output:
output_shape = input_shape - offset

Shape of the receptive field of the output (of the output tile):
receptive_field_shape = output_shape - 2*halo

Shape of the resulting image:
result_shape = (tamaño_imagen)*scale

@FynnBe and @constantinpape may give clarification for these question, but I started to think is there "smarter" way of doing the shape calculation.
For example, instead of defining scale, offset, halo, how about allow a math equation, say, output_shape: 8*(input_shape*2) + 31? Or even point to a function just like the preprocessing transforms?

* What is the reference for `scale`? Is it `output_shape = input_shape * scale` or `input_shape = output_shape*scale`?

It is output_shape = input_shape * scale + offset.
Tou can think about output_shape (y) being a linear function of the input_shape (x):
y = a * x + b

Then a = scale and b = offset.

* For the `offset`, does it refer to difference between the shape of the input and the output? after or before the scaling? What is the main difference between `halo` and `offset`?

For offset see above. halo is a parameter for prediction and specifies how much if the predicted tensor should be cropped in order to avoid border artifacts.
E.g. if you have a network that returns images of size [256, 256] and you specify halo = [32, 32],
this tells the application that runs prediction to crop away 32 pixels on each side; so the output will be
[256 - 2 * 32, 256 - 2 * 32] = [192, 192].
I think this covers all the use cases you describe lower.
@oeway

For example, instead of defining scale, offset, halo, how about allow a math equation, say,

scale and offset define a linear equation and the example you give corresponds to
scale = 16 and offset = 31.
We can think about generalizing this to higher orders.
Another option would be to allow specifying a function in the native language, e.g. python that computes the output shape from the input shape; this would be the most flexible solution.

Right, my point of using equation rather than the scale, offset, halo definition is more about readability. One wouldn't need to read the documentation to understand how to calculate the output shape from the input for example.
Exactly, I think we should definitely go for a function, since we already support reading model definition, transforms from a callable function. If framework like Keras, the model object already keep track of the input shape and output relation, providing an extra function in the model definition file would be very straightforward.

Right, my point of using equation rather than the scale, offset, halo definition is more about readability. One wouldn't need to read the documentation to understand how to calculate the output shape from the input for example.

I don't think it's a good idea to allow people to allow writing arbitrary equations, because then
we need to implement a lot of parsing logic for this and there can always be corner cases.
Instead we could generalize this and give a list of values that correspond to the order of the polynomial and replace scale and offset with this. I.e. we have something like
scale_factors = [a0, a1, a2, ...] and
y = a0 + a1 * x + a2 * x^2 + ...

where y = output_shape, x = input_shape.
Also note that halo is more or less unrelated to this; it is just a hint for the consumer software how much to crop during prediction.

Exactly, I think we should definitely go for a function, since we already support reading model definition, transforms from a callable function. If framework like Keras, the model object already keep track of the input shape and output relation, providing an extra function in the model definition file would be very straightforward.

Yes, @FynnBe started implementing something like this for the pytorch side as well, but I am not quite sure what's the latest on this.

I don't think it's a good idea to allow people to allow writing arbitrary equations, because then
we need to implement a lot of parsing logic for this and there can always be corner cases.
Well, I wouldn't parse the equation myself, but use eval(expression, context={...})-like implementation, they exist already in Python, JS, and in Java there is also different script engine. You can think of this is an inline function without the need of saving it into a separate python module or script file.

Using eval in general is a bad practice, however, here we already allow executing arbitrary code for the model definition, using eval here won't make any difference in terms of security.

Well, I wouldn't parse the equation myself, but use eval(expression, context={...})-like implementation, they exist in Python, JS, and in Fiji/Java there are also different script engines. You can think of this is an inline function without the need of saving it into a separate python module or script file.
Using eval in general is a bad practice, however, here we already allow executing arbitrary code for the model definition, using eval here won't make any difference in terms of security.

Then the syntax becomes language specific and one could even evoke other dependencies.
I would much rather separate this more strictly, either it's possible to express this relation as a (potentially higher-order) polynomial or it needs to be defined in a separate function.

Then the syntax becomes language specific and one could even evoke other dependencies.
I would much rather separate this more strictly, either it's possible to express this relation as a (potentially higher-order) polynomial or it needs to be defined in a separate function.

Yes, it will be language specific. Since we have a framework and language key to specify the context for the yaml file, it seems natural to write an inline script with the syntax of current language. In terms of the complexity, if we already allow custom function for computing output_shape, supporting inline function would require minimal effort.

Yes, it will be language specific. Since we have a framework and language key to specify the context for the yaml file, it seems natural to write an inline script with the syntax of current language

Yeah, I see that point. But on the other hand it might still be confusing to see different syntax in there for new users.

In terms of the complexity, if we already allow custom function for computing output_shape, supporting inline function would require minimal effort.

Yep, if we go with a eval solution that is true.

You can think about output_shape (y) being a linear function of the input_shape (x):
y = a * x + b

Then a = scale and b = offset.

This is great. I assume then, that the offset can be either positive or negative.  Could it be possible to have it in the main description?
The previous definition solves the problem with respect to the input and output of the network, but it does not determine what is the shape of the final output image, after tiling / patch reconstruction. Should we assume that final_image = scale*input_image?
I like the idea of having a function and avoid different interpretations of scale and offset parameters, but @constantinpape is also right. Especially if you want to prepare your model to be compatible with different software.
While it might be a biased opinion, from a didactic point of view, I like to have those parameters in the YAML file (as long as they are explicitly defined). Sometimes, they support user understanding about how the processing is happening.

I assume then, that the offset can be either positive or negative.

Yes it can be negative.

Could it be possible to have it in the main description?

Yes, we should definitely update this, it is unfortunately a bit out of date now.

I like the idea of having a function and avoid different interpretations of scale and offset parameters, but @constantinpape is also right. Especially if you want to prepare your model to be compatible with different software.

Yeah, I think there are some pro's and con's here.
We will get the discussion on a next iteration of the format rolling soon and this will be a point to include.

While it might be a biased opinion, from a didactic point of view, I like to have those parameters in the YAML file (as long as they are explicitly defined). Sometimes, they support user understanding about how the processing is happening.

My preference would also be to have this in the YAML if possible, but have support for functions for use cases that are too complicated for this.

I summed up the current version in https://github.com/bioimage-io/configuration/issues/14#issuecomment-603742862
I also updated the configuration readme (https://github.com/bioimage-io/configuration/commit/bfd0ae359c3ba3fcce073bd6a800ce58ab00e726) without the dynamic parts though, as they are not that vetted yet and clearly still under discussion

please reopen if this needs further discussion

@esgomezm @FynnBe
I reopened this, seeing that there is still some need for clarification about the output shape description.
First, I think we all agree for the case halo = [0] (I am assuming 1D everywhere to keep this readible).
In that case output_shape = input_shape * scale + offset.
Now the question is what happens for halo = [32] (or some other non-zero value).
So my understanding is that this does not change how we compute output_shape, because specifying the halo does not change what the model does internally.
Instead, it means that the consumer software should crop away 32 pixels from both side in the offset to have "valid" output.

I think I remember some more of our previous discussion on this topic and agree with your statements. Following points I want to clarify:

the relative position of the output is concentric to the reference input. we do not allow for a 'shifted' output.
offset contains only even integers, thus the origin of the output lies at -offset/2 wrt to the input.*
thus offset covers all valid convolutions/postprocess croppings that change the output shape (symmetricaly).
(as @constantinpape stated: halo has no effect on output shape, but rather denotes the border region that may contain artefacts, etc.)

* maybe it is more intuitive to define the origin of the output at +offset/2 wrt to the input and output_shape = input_shape * scale - offset. Ah, both make sense in their own way. In tiktorch I refered to offset with shrinkage, so output_shape = input_shape * scale - 2 * shrinkage and output_origin is at shrinkage...

Fixed in #59.

Hi all,
While working on the definition of model's output shape and the resulting image shape we find some problems with the current formula: output_shape = input_shape * scale  + 2 * offset. This is something that we can think about for the next version, but in the case of deepImageJ at least, some use-cases may not be properly defined in the plugin or not covered.
So, we want to make the difference between the output tensor of the model and the output image that we want to finally display. Here the problem comes, especially, when defining the tiling:

There could be a case in which the output tensor shape is different from the input tensor, but the input image and the output image have the same size. For example, when we do not use padding in the convolutions of the CNN. In that case, output_shape = input_shape * scale  + 2 * offset refers to a tensor but not to the final image. And this offset is not a shift w.r.t. the input origin. In this case, the offset < 0.

What about if offset > 0?

There could be also the case, for example in super-resolution, for which scale affects both the output tensor and the output image in the same way.

The main problem we have is that sometimes this formula can be used with both the output tensor and the image, and others, not.

@esgomezm I don't quite understand what the difference between output_tensor and output_image is.

I had a call on this with @esgomezm and I will try to summarize my understanding of this issue:

first terminology: output_image = the complete output for a given input_image. output_tensor = the output for a given input_tensor = input to the network(!), e.g. corresponding to a tile to be predicted
the issue is the following: output_shape = input_shape * scale + 2 * offset tells us clearly what size the output_tensor will be for a given input tensor. BUT it's unclear if that should also apply for computing the size of the output_image from the input_image, for example given a network with valid convolutions, we will have a negative offset, so the shape will be smaller, the desired output_image (!) should still have the same size as the input image. But in other cases the output_image should have a different size, e.g. if the network downscales by a factor of 2.

I think we should discuss this in more detail in one of the next Friday meetings. For now we will leave everything as it is, we don't have any models yet where this is really an issue (but these will certainly come, because valid convolutions are a common use case)

This definitely needs a closer look...
My current understanding:

I am surprised that you expect an output_image of the same size for valid convolutions. Why is it a problem that it is smaller?
To compensate for smaller output images padding is obviously the answer, which so far we leave to the consumer software (as the model only get's tiles and how/if they overlap is only known by the consumer software using the model...).
The software thus should pad the edge tiles accordingly if it wants the output image to match the input image. (And let the inner tiles overlap with eachother)

Hi @FynnBe ,

I am surprised that you expect an output_image of the same size for valid convolutions. Why is it a problem that it is smaller?

It can be smaller, but usually, we try to provide an image of the same size so it doesn't look weird to the user. Also, making it of the same size, allows you to directly compare it with ground truth for example. It's not mandatory but in many cases, it's nice to have it like that. We can of course let this to the consumer and just take as the correct one, the smaller output_image.
The same question could be done about halo. If we have halo>0, why should the output_image be of the same shape as the input_image?

To compensate for smaller output images padding is obviously the answer, which so far we leave to the consumer software (as the model only get's tiles and how/if they overlap is only known by the consumer software using the model...).
The software thus should pad the edge tiles accordingly if it wants the output image to match the input image. (And let the inner tiles overlap with each other)

It's true that each software should take care of it but for that, it needs to know what should be the correct output_image shape. Also, another reason why maybe this should be defined in detail is the cross-compatibility feature: we are providing some test images for which sometimes, we need to make the tiling. Does cross-compatibility mean that all software should run the model and get the same (plus insignificant error) output? If so, then this should be kind of well defined. I agree that not the tiling, but at least the expected output_image size.
Can be any case in which the

The same question could be done about halo. If we have halo>0, why should the output_image be of the same shape as the input_image?

while offset != 0  results in a difference in pixels, halo only indicates the width of edge effects that are included in the output image, but should preferably cut off...
so common use cases are:

output tensor/image has same size and a halo specifies what area may suffer from edge effects (no offset)
output tensor/image is smaller (specified by offset), but no halo is zero as all output is valid

It's true that each software should take care of it but for that, it needs to know what should be the correct output_image shape. Also, another reason why maybe this should be defined in detail is the cross-compatibility feature: we are providing some test images for which sometimes, we need to make the tiling. Does cross-compatibility mean that all software should run the model and get the same (plus insignificant error) output? If so, then this should be kind of well defined. I agree that not the tiling, but at least the expected output_image size.
output image (size) should definitely be the same across different consumers, but how to tile should be considered an implementation detail and with suitable offset/halo settings not influence the output by overlapping the tiles appropriately.
With some concrete examples on the table we should define this more precicely and have tests for it as well 👍

Can be any case in which there's offset or scale (not for channels) and the output_image is of the same size?

I suppose you can construct it with scaling up a fixed input size and offsetting the size increase with the offset... but practially, no

while offset != 0 results in a difference in pixels, halo only indicates the width of edge effects that are included in the output image, but should preferably cut off...

Yes but the artifacts in the edges of the output_image are overcome by doing some mirroring for example. That's why I say that someone could think that those pixels should be discarded as well, making the output_image smaller. I wouldn't do it but I could understand if anyone does.

so common use cases are:

output tensor/image has same size and a halo specifies what area may suffer from edge effects (no offset)
output tensor/image is smaller (specified by offset), but no halo is zero as all output is valid

And scale can be whatever, no?

output image (size) should definitely be the same across different consumers, but how to tile should be considered an implementation detail and with suitable offset/halo settings not influence the output by overlapping the tiles appropriately.
With some concrete examples on the table we should define this more precicely and have tests for it as well :+1:

Yes, I think that having some examples will be very helpful.

Yes but the artifacts in the edges of the output_image are overcome by doing some mirroring for example.

I would say the edge effects can be reduced, not overcome in a sense of eliminated. so cutting a halo or not is left to the consumer software. The consumer also determines how to pad additionally, (as we have not added padding in any way to the spec  (yet)), while the model itself may of course also deploy padding....

And scale can be whatever, no?

in these common use-cases I assume scale is often 1, but sure it could be anything.

I think this has been adressed with the 0.5 release, but please reopen or better yet, create a new issue, if there is anything left unclear.


deps: bump cometbft to 0.38.4 in modules.

Description

closes: #XXXX
Commit Message / Changelog Entry
type: commit message

see the guidelines for commit messages. (view raw markdown for examples)

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against the correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

seems cometbft 0.38.3 changed an interface that made the cosmossdk version we depend on not compilable:
cosmos-sdk@v0.50.3/server/cmt_cmds.go:443:7: cannot use blockStoreDB (variable of type "github.com/cometbft/cometbft-db".DB) as "github.com/cometbft/cometbft-db".Batch value in argument to store.SaveBlockStoreState: "github.com/cometbft/cometbft-db".DB does not implement "github.com/cometbft/cometbft-db".Batch (missing method Write)) (typecheck)

might need to hold off on this one.

yes, it looks like... Let's wait for an SDK release that upgrades to it. Thanks for bundling the upgrade in a single PR, though.

bumping to 0.38.4 works out fine!


Wrong output with delay less than 1s

If i set delay less than 1000 in loop, for example:
void loop() {
    readDHT22();
    Serial.printf("%.1f\t %.1f\n", temperature, humidity);
    delay(100);
}

plot displays this:

Is it how it supposed to work, or is it a bug?

Nope, it's not the way designed. On my Mac, it is working fine like this even with 10 ms.

I haven't tired it with this short interval on Windows, so I am not sure with the Windows python environment.

That's interesting. I'm using linux, not windows. I will try to debug this. If I find out something I will let you know.

That will be great. Thanks

@semka95
I'm closing this for now. If you need, please re-open it. Thanks.


Work on a test notebook to identify the problem step by step and visualize each step of the pre-processing.

(in progress, will update soon...)

[x] Create a test subset with a few samples of different patients and contrasts.
[ ] Create a test notebook to visualize and do the pre-processing step by step

not relevant anymore --> closing


edtr-io: exercise improvements

This is done, right? This issue is not needed any more, right? Reopen it, when it is necessary...


improved-base wrapping problems

When returning an unboxed tuple in the javascript FFI, wrapping is expected from the JS code, even for JSRef. This is not done correctly everywhere, and is a source for confusion.
I'd like to change the convention to the following:

Allow unboxed tuple returns of all ccall types, JSRef and Any
wrapping is performed like for non-tuple returns
Any is to be wrapped by the callee, it's safe to unsafeCoerce to the actual type (including pre-wrapped JSRef)

This will probably lead to temporary breakage between ghcjs and ghcjs-base, but the current implementation is also buggy so it's better to make the change now, rather then when unboxed tuples are used more in the wild.

All changes are in.


three_d_secure_action_result_token_mismatch

Whenever there is a 3-D secure action i keep getting three_d_secure_action_result_token_mismatch error code, this happens when i try to create subscription or an account that has three_d_secure_action_result_token_id, i am doing exactly like this example.

Recurly pushed a fix for that

Thanks for posting back 👍


Add JNI-based Fuse support

Replace https://github.com/Alluxio/alluxio/pull/12072/

@LuQQiu @gpang  PTAL

alluxio-bot, merge this please

alluxio-bot, feature-merge this please.


[BEAM-8665] Add test suites to run Beam tests on Linux/Windows/Mac platforms.

Test suite to be run during nightly build and on push to master and release branches.
TODO before merging
Requires adding DataFlow admin permissions to GCP Service Account before merging
Prevew of runs
Runs can be previewd on my fork.
I changed workflow slightly to be able to run it  (GCP credentials, paths, repo owner)

run https://github.com/TobKed/beam/actions/runs/175897028 reflects the state for commit ae8b78c

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

Fails on MacOS runner are related to the GitHub virtual environments problems: https://github.com/actions/virtual-environments/issues/841

R: @damgad @kamilwu @mwalenia @aaltay @tysonjh

Is 'cross-platform' test suite a 'windows' or there are some cross-platform aspects in the suites that we are adding?

Is 'cross-platform' test suite a 'windows' or there are some cross-platform aspects in the suites that we are adding?

@tvalentyn I renamed to follow Jira: Add test suites to run Beam tests on Linux/Windows/Mac platforms

@aaltay @tvalentyn thank you for reviews.
I thought it over and decided to divide it into two PRs, separate for python and for java.
Also keeping these workflows in separate files seems to have more sense (better customization for specific language e.g. different triggering paths,  + it will not block building python wheels).
Here is PR for python, I am still working on Java:
https://github.com/apache/beam/pull/12452


help: Document Do Not Disturb feature in Desktop app.

This is an update on #24193.
Fixes #24169.
Screenshots and screen captures:

@drrosa I took a revision pass on your PR -- let me know what you think!

Thanks! Fixed and updated the screenshot in the PR description.

The test failure seems unrelated to this PR?

The test failure seems unrelated to this PR?

Yes, it's due to PR #24089 which just got merged into main. I've updated PR #24091 which should fix this test failure.

I pushed a change to standardize on calling this "Do Not Disturb", since that's what the desktop app calls it, even though that violates our project naming conventions; it looks nicer.
I think the CI failure was fixed in main weeks ago, so this should pass CI and merge automatically when CI finishes.
Thanks @drrosa and @alya!


Usability fixes

Fixed error where the UI does not start if the config.json one currently has does not have a width, height, xPosition, and yPosition field. This checks for that and also updates the default config.json
Fixed a long standing sidebar bug where one could select multiple views
Gives option to save wallet password

@DavidVorick @lukechampine boop

LGTM
though, the lack of a test suite makes me nervous


Renaming package to address #2038

Rename Microsoft.AspNet.PageExecutionInstrumentation to Microsoft.AspNet.PageExecutionInstrumentation.Instrumentation
Fixes #2038

Need to update https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNet.Mvc.Razor/project.json#L12

Looks good otherwise  :shipit:

bb31e2aec5030ea52a27e2ffa391d152b43f8225


Running confluence behind reverse proxy

I have just updated my on prem Jira server which is accessed via a reverse proxy. This issue solved the problem with Jira: https://github.com/MicrosoftDocs/azure-docs/issues/13282
Confluence seems to have the same issue with its version of the connector Jira used to have - it doesn't work in a reverse proxy environment.
When will the confluence SSO connector be updated in line with the Jira one?

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

ID: a45acbc6-caae-be6c-939e-55451831d03e
Version Independent ID: 0d88f4ee-2ac5-1ad4-245b-b8c0752a7303
Content: Tutorial: Azure Active Directory integration with Confluence SAML SSO by Microsoft
Content Source: articles/active-directory/saas-apps/confluencemicrosoft-tutorial.md
Service: active-directory
GitHub Login: @jeevansd
Microsoft Alias: jeedes

@srishtiparakh and @dougcain Thanks for the confirmation on JIRA part. We are working on the Confluence plugin to fix this issue. It should be done around the year end and we will keep you posted.

@chetansriv Can you please track this issue?

Hi there, I'm facing the same issue over there.
Looking forward to seeing some update

Please let us know about the schedule of this update. We're really waiting for it.
Thanks.

@dougcain @Clebam We have fixed this issue. I am pushing the Confluence plugin updates to our Microsoft Download Center. So that you can download the new version of the plugin from there. It should be up by next week. If you to try this out early then please reach out to us on this alias<EMAIL_ADDRESS>

It should be fixed by now.
#please-close

@dougcain
Thanks for bringing this to our attention. We will now close this issue. If there are further questions regarding this matter, please tag me in a comment. I will reopen it and we will gladly continue the discussion.


Add space between Archive and Search field

When archives is selected, there is no space between its border and the search field

Merged into #429


Embedding generation is slow

When using /api/embeddings, large documents can take up to second

I have the same issue, I am not limited by the CPU or the memory. Not sure what the issue is.

@jmorganca can this be resolved now that bert models are supported? Moving forward generating embeddings bert models should be used rather than llama-family models.

Closing as bert models are now supported such as https://ollama.com/library/all-minilm


Visual and illustrative updates of the Canvas Shadow and UnityUI sample scenes

Overview
Canvas Shadow scene
The CanvasShadow scene felt a little lifeless and lacked decriptive content. Adding samples, a brief description and uncommon visuals to increase clarity.

expanding the numbers of examples for shadow variations
illustrating texture usage for buttons and their shadows
adding a description panel

textures added:

UnityUI
Adding functionality to the displayed UI tools in order to illustrate interactivity and haptics.

added lightbulb model, animation and shaders
added script to hook up slider and button interaction to lightbulb shader

Changes

Fixes: # .

Verification

This optional section is a place where you can detail the specific type of verification
you want from reviewers. For example, if you want reviewers to checkout the PR locally
and validate the functionality of specific scenarios, provide instructions
on the specific scenarios and what you want verified.
If there are specific areas of concern or question feel free to highlight them here so
that reviewers can watch out for those issues.
As a reviewer, it is possible to check out this change locally by using the following
commands (substituting {PR_ID} with the ID of this pull request):
git fetch origin pull/{PR_ID}/head:name_of_local_branch
git checkout name_of_local_branch

Also, I see two conflicts:

com.microsoft.mrtk.graphicstools.unity/Samples~/Experimental/CanvasShadow/CanvasShadow.unity
com.microsoft.mrtk.graphicstools.unity/Samples~/UnityUI/UnityUI.unity

Those are from me making very minor changes, so please feel free to take your changes and I will re-make mine.


[FEATURE] add xdp support

Is your feature request related to a problem? Please describe.
support attach xdp progs, and add a xdp example.

Completed.


Limit the number of breadcrumbs displayed by VS Code

I am wondering if it's possible to limit the number of ancestors shown in the breadcrumbs bar. At this point, if you have a large file with a more complex structure, you will see all ancestors of the currently selected element. I don't know if the current setup has an impact on performance, but from a design point of view, it seems to be add more complexity than necessary.

As you already have the possibility to see all ancestors in a tree-like dropdown by clicking on a breadcrumb, I think the ability to limit the number of breadcrumbs might clean up the interface and help users find the things they need faster.

I've added a couple of screenshots with an example structure for this issue. Please ignore the large amount of divs. :smile:
Thanks!

Well, it's the mirror view of your sources ;-) Not sure what you wanna do here? What items you want to hide? Cut off at the end? Remove some from the middle?

Well, it's the mirror view of your sources ;-) Not sure what you wanna do here? What items you want to hide? Cut off at the end? Remove some from the middle?

I understand that it's a mirror view of my sources. But I was wondering if the breadcrumb line could be limited to a certain amount of elements. Right now you can see both code and file ancestors of a given element. All of them until the first one. I don't know how this affects Code's performance, but from a visual standpoint, it adds clutter to the workspace.
So for a code item, would it be possible to limit the number of ancestors and children of this element in the breadcrumbs bar to something like 5 - random number here - elements before it and 5 after it?
Thanks.


fix(default_adapi): subscribe planning factor

Description
New factor msgs were defined in https://github.com/tier4/tier4_autoware_msgs/pull/155 to output various information of module running state. And, each planning module will use them.
In this PR, I fixed adapi node to convert msg type from tier4_planning_msgs/PlanningFactorArray to autoware_adapi_v1_msgs/VelocityFactorArray(SteeringFactorArray).
Related links
Parent Issue:

https://github.com/autowarefoundation/autoware.universe/pull/9676
https://github.com/tier4/tier4_autoware_msgs/pull/155

How was this PR tested?

launch psim.
put ego and goal.
put object on ego path.
check the topic /api/planning/velocity_factors by echo command.
confirm that the node outputs factor like following one.

header:
  stamp:
    sec:<PHONE_NUMBER>
    nanosec: 610628888
  frame_id: map
factors:
- pose:
    position:
      x: 61578.199978951016
      y: 56213.78579257302
      z: 78.16299873101634
    orientation:
      x: -3.6191521078641166e-05
      y: -0.0006830251435586911
      z: -0.052912858993544
      w: 0.9985988992182779
  distance: 14.520707130432129
  status: 1
  behavior: route-obstacle
  sequence: ''
  detail: ''
  cooperation: []

Notes for reviewers
None.
Interface changes

Version
Topic Type
Topic Name
Message Type
Description

Old
Sub
/planing/planning_factors/xxx
tier4_planning_msgs/PlanningFactorArray
Topic description

New
Sub
/planing/velocity(steering)_factors/xxx
autoware_adapi_v1_msgs/VelocityFactorArray(SteeringFactorArray)
Topic description

Effects on system behavior
None.

The velocity/steering factor has a status, but planning factor does not. The status of velocity factor will be automatically completed. However, the status of steering factor will not be assigned.

Thanks for your comment. You're right.
I fixed logic in https://github.com/tier4/autoware.universe/pull/1734/commits/5d55a4b03f37e16e0e23d14a02e08c272cbf0022 to fill status automatically.
status: SteeringFactor::APPROACHING

status: SteeringFactor::TURNING