I can't build an apk

I try to build it shows these error :

Build for Android
The following actions uses node12 which is deprecated and will be forced to run on node16: actions/checkout@v2. For more info: https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/

Build for Android
Failed to remove 'http.https://github.com/.extraheader' from the git config
main.yml code is :
name: Build

on: [push, pull_request]

jobs:

  # Build job. Builds app for Android with Buildozer

  build-android:

    name: Build for Android

    runs-on: ubuntu-latest

    steps:

      - name: Checkout

        uses: actions/checkout@v2

      - name: Build with Buildozer

        uses: ArtemSBulgakov/buildozer-action@v1

        id: buildozer

        with:

          workdir: .

          buildozer_version: stable

      - name: Upload artifacts

        uses: actions/upload-artifact@v2

        with:

          name: package

          path: ${{ steps.buildozer.outputs.filename }}

Please help me to fix this

Problems solved!
🎉 Exciting News! 🎉
I'm thrilled to announce that my APK build process for the SAMPLE-KIVYMD-APP repository has been successfully completed on GitHub! 🚀
It took some frustrating build failures but still I managed to succeed.
After resolving several challenges, my GitHub Actions workflow now reliably builds the APK for my KivyMD application, thanks to the latest updates and optimizations. This achievement marks a significant milestone for my project, bringing us one step closer to delivering an enhanced mobile experience.
🔧 Key Highlights:

Automated APK Building: Our workflow now efficiently handles the APK build process without manual intervention.
Optimized Dependencies: We’ve integrated all necessary dependencies, ensuring a smooth build environment.
Seamless Deployment: The build process is fully automated, making it easier to deploy updates and improvements.

For more details, you can check out the repository here. I am looking forward to your feedback.
Stay tuned for more updates and happy coding!


WIP: [ON HOLD] PAT-1567 Update Notification Status Colors

Objective
Update Status bar color when user is having a call otherwise the Status bar color will show the default, refer to this
How To Test:
Branches:

PAT: task/PAT-1567_update_Notification_topbar_colors

Axon: task/PAT-1567_update_Notification_topbar_colors

Cortex: development

RS: task/PAT-1567_update_Notification_topbar_colors

Get the FCM token and Twilio token and send fcm request using postman, while FLASK is closed in your device, you will be able to see the call

Accept the call you will be directed to OngoingCallActivity, hit back or home screen, then go back to the app, you will be able to see the green status bar in the app, you can end the call from the notification or from the OngoingCallActivity, the status bar color will change to the default in the app

It's working perfectly for me

Closing this MR since the counter part in the rest of the projects are closed already. It look like this was left behind.


No staging repository with name sonatype created

I've been following a guide I found here on how to use this plugin (have tried 1.0.0 and 1.1.0) and can upload to staging successfully to mavenCentral however closeAndReleaseSonatypeStagingRepository never resolves. Changing the name of the repository from sonatype to anything else seems to resolve in the same error with that name.
See gradle file for the project below.
apply plugin: "java-library"
apply plugin: "com.google.protobuf"
apply plugin: "maven-publish"
apply plugin: "signing"
apply plugin: "io.github.gradle-nexus.publish-plugin"

buildscript {
    repositories {
        maven { url "https://plugins.gradle.org/m2/" }
        google()
        mavenCentral()
    }
    dependencies {
        classpath 'com.google.protobuf:protobuf-gradle-plugin:0.8.14'
        classpath 'io.github.gradle-nexus:publish-plugin:1.1.0'
    }
}

version = '0.25.0'
group = 'org.kin.agora.gen'

// Create variables with empty default values
ext["ossrhUsername"] = ''
ext["ossrhPassword"] = ''
ext["sonatypeStagingProfileId"] = ''
ext["signing.keyId"] = ''
ext["signing.password"] = ''
ext["signing.secretKeyRingFile"] = ''

File secretPropsFile = project.rootProject.file('local.properties')
if (secretPropsFile.exists()) {
    Properties p = new Properties()
    new FileInputStream(secretPropsFile).withCloseable { is ->
        p.load(is)
    }
    p.each { name, value ->
        ext[name] = value
    }
} else {
    ext["signing.keyId"] = System.getenv('SIGNING_KEY_ID')
    ext["signing.password"] = System.getenv('SIGNING_PASSWORD')
    ext["signing.secretKeyRingFile"] = System.getenv('SIGNING_SECRET_KEY_RING_FILE')
    ext["ossrhUsername"] = System.getenv('OSSRH_USERNAME')
    ext["ossrhPassword"] = System.getenv('OSSRH_PASSWORD')
    ext["sonatypeStagingProfileId"] = System.getenv('SONATYPE_STAGING_PROFILE_ID')
}

// Set up Sonatype repository
nexusPublishing {
    repositories {
        sonatype {
            stagingProfileId = sonatypeStagingProfileId
            username = ossrhUsername
            password = ossrhPassword
            nexusUrl.set(uri("https://s01.oss.sonatype.org/service/local/"))
            snapshotRepositoryUrl.set(uri("https://s01.oss.sonatype.org/content/repositories/snapshots/"))
        }
    }
}

repositories {
    google()
    mavenCentral()
    maven {
        url 'https://jitpack.io'
    }
}

// We want to strip proto validation because it doesn't support protobuf-lite atm
// which we want for mobile usage to reduce dependencies and size
task removeProtoValidation(type: Exec) {
    workingDir "${projectDir}"
    commandLine './remove_proto_validation.sh'
}

tasks.whenTaskAdded { task ->
    if (task.name == 'extractIncludeProto') {
        task.dependsOn removeProtoValidation
    }
}

def grpcVersion = "1.33.1"
def protocVersion = "3.12.0"
dependencies {
    implementation "io.grpc:grpc-protobuf-lite:${grpcVersion}"
    implementation "io.grpc:grpc-stub:${grpcVersion}"
}

def generatedSrcRoot = file("${buildDir}/generated/source/proto/main/java/")
sourceSets.main {
    proto {
        srcDir "${rootDir}/../../proto"
    }
    java {
        srcDirs = ["${generatedSrcRoot}"]
    }
}

compileJava {
    options.annotationProcessorGeneratedSourcesDirectory generatedSrcRoot
}

protobuf {
    protoc {
        artifact = "com.google.protobuf:protoc:${protocVersion}"
    }
    plugins {
        grpc {
            artifact = "io.grpc:protoc-gen-grpc-java:${grpcVersion}"
        }
    }
    generateProtoTasks {
        all().each { task ->
            task.builtins {
                java {
                    option "lite"
                }
            }
        }
        all()*.plugins {
            grpc {
                option 'lite'
            }
        }
    }
}

jar {
    manifest {
        attributes('agora-api': project.name,
                'Version': project.version)
    }
}

task sourcesJar(type: Jar) {
    from sourceSets.main.allSource
    classifier = 'sources'
}

artifacts {
    archives sourcesJar
}

publishing {
    publications {
        release(MavenPublication) {
            from project.components.java
            artifact sourcesJar

            pom {
                name = 'agora-api'
                description = ''
                url = 'https://github.com/kinecosystem/agora-api'
                licenses {
                    license {
                        name = 'MIT License'
                        url = 'https://github.com/kinecosystem/agora-api/blob/master/LICENSE.md'
                    }
                }

                // Version control info - if you're using GitHub, follow the format as seen here
                scm {
                    connection = 'scm:git:github.com/kinecosystem/agora-api.git'
                    developerConnection = 'scm:git:ssh://github.com/kinecosystem/agora-api.git'
                    url = 'https://github.com/kinecosystem/agora-api/tree/main'
                }

                withXml {
                    def depNode
                    def depNodes = asNode().get('dependencies')
                    if (depNodes.size() == 0) {
                        depNode = asNode().appendNode('dependencies')
                    } else {
                        depNode = depNodes.get(0)
                    }

                    // Iterate over the implementation dependencies (we don't want the test ones), adding a <dependency> node for each
                    configurations.implementation.allDependencies.each {
                        // Ensure dependencies such as fileTree are not included in the pom.
                        if (it.name != 'unspecified') {
                            def dependencyNode = depNode.appendNode('dependency')
                            dependencyNode.appendNode('groupId', it.group)
                            dependencyNode.appendNode('artifactId', it.name)
                            dependencyNode.appendNode('version', it.version)
                        }
                    }
                }
            }
        }
    }
}

signing {
    sign publishing.publications
}

We do not support Android projects (and monorepos). Probably you use a standard layout for Android projects and have a subproject with code. Your problem seems to be similar to https://github.com/gradle-nexus/publish-plugin/issues/74#issuecomment-789370339. If yes, you could subscribe to https://github.com/gradle-nexus/publish-plugin/issues/75 to get notified when it is implemented.
Anyway, the guide you mentioned seems to use our plugin. Do you know what differs your project and that in the article (where it seems to work fine)?

It's not an android project though, just a plain java library; or do you mean any monorepo project?
The only different seems to be that there isn't a base project.

It's not an android project though, just a plain java library

Right, I was confused by the article you linked. You build.gradle looks very generic :-)

The only difference seems to be that there isn't a base project

What do you mean? The configuration you pasted is from a subproject?
Do you have any staging repository related tasks when executed ./gradlew tasks --group publishing?

I had the same problem. I solved it by executing both tasks in the same Gradle call:
./gradlew publishAllPublicationsToSonatypeRepository closeAndReleaseSonatypeStagingRepository
If I execute the tasks in two separate Gradle calls, the second task fails with No staging repository with name sonatype created. I think this is a problem that needs to be fixed in the publish plugin.

@pemistahl Yes, you are right, they have to be called in the same Gradle call (until #19 is implemented) as publish* triggers staging repository creation. Maybe we could improve the error message, but in the meantime, @pemistahl maybe you would like to provide a PR with README enhancement to emphasis that both commands have to be used in the same Gradle call?

@pemistahl Yes, you are right, they have to be called in the same Gradle call (until #19 is implemented) as publish* triggers staging repository creation. Maybe we could improve the error message, but in the meantime, @pemistahl maybe you would like to provide a PR with README enhancement to emphasis that both commands have to be used in the same Gradle call?

Has this changed recently ? This used to work, I had this configured in my CI script and did multiple releases in that way around July 2020.
Today I had to fix something in that project I hadn't touched for a long time, and the CI broke with the exact same issue as the OP.


Switch to io.grpc.Grpc.* factory methods

Description in https://github.com/typelevel/fs2-grpc/issues/734

Closing because I couldn't make implicit work without changing the API / breaking backwards compatibility.


Fix CI builds

Currently in master C# tests and build fail for package AngouriMath.Experimental for macOS. Since generic math is not implemented, we need to make AngouriMath.Experimental target .NET 7, add installing the corresponding runtime in yml files, and make it work:

Change AngouriMath.Experimental's target to .NET 7
Fix CSharpBuild.yml and CSharpTest.yml by adding .NET 7
Fix CI (it will run on opened draft PR)

Hi @WhiteBlackGoose, Can I work on this ?

Hi, assigned you. Good luck!


Can we send message with multiple phone numbers?

Hi, I have following issue, pls take a look
Base on my research, Whatsapp let us add maximum 2 phone numbers to an Whatsapp business account.
So now if I have an system with multiple users register as a business (ex: user1 is owner of flower company, user2 is owner of food company...) and I want to integrate Whatsapp API (send messages, reply, get messages...) for each their customers. The whole system with a lot of 'business users' (user1, user2...) will be use same phone numbers as registered to Whatsapp developer app before when they send messages to their customers, right ? So when customer receive messages, they will see same name of business with same phone number.
Can we use each phone number of users when they registered to system when send messages through Whatsapp ?

Hey!

Whatsapp let us add maximum 2 phone numbers to an Whatsapp business account.

Where does it say that? I found this:
There is no limit to the amount of business phone numbers that can be onboarded to the Cloud API. https://developers.facebook.com/docs/whatsapp/cloud-api/get-started-for-bsps

Hi @ignacio-chiazzo tks for your response, yes, I saw we can send multiple request with different sender numbers, but can we add sender by api or need add manual first then verify after that?

Oh I see! thanks for letting me know.
I noticed that whatsapp released a new API register. I created a ticket for that https://github.com/ignacio-chiazzo/ruby_whatsapp_sdk/issues/64.
Note that after it's implemented, the user must validate the register through 2FA with a SMS.

@ignacio-chiazzo yes, that great !

Hey the API has been released. I will close this issue. Thanks!


The pods numer is not correctly.

In GitLab by @luotian-github on Sep 28, 2018, 20:14
I have configured the autoscale correctly, but it is still failure to autoscale service instance.

In GitLab by @luotian-github on Nov 8, 2019, 08:00
still is the pod number issue

In GitLab by @tmon546596046 on Nov 8, 2019, 08:00
grafana will collect all pods.
using command 'kubectl get pods --all-namespaces  -a | wc -l ' minus 1.
the grafana will show the result with a bit delay.

In GitLab by @yhua123 on Nov 8, 2019, 08:00
step1 Mrli filter some protected namespace.
step2 Robin follow number issue.
step3 modify collector to filter or setting a switch.

In GitLab by @liyanq528 on Nov 8, 2019, 08:00
fixed step1 by #1763

In GitLab by @luotian-github on Nov 8, 2019, 08:00
PR1764

In GitLab by @tmon546596046 on Nov 8, 2019, 08:00
collector ignore namespace kube-system and istio-system. PR is #1765

In GitLab by @luotian-github on Nov 8, 2019, 08:00
No problem

In GitLab by @wknet123 on Nov 8, 2019, 08:00
fixed issue #1754

In GitLab by @sokril on Nov 8, 2019, 08:28
closed

In GitLab by @sokril on Nov 8, 2019, 08:28
assigned to @Robin-Mao

In GitLab by @liyanq528 on Nov 13, 2019, 05:08
mentioned in merge request !927

In GitLab by @liyanq528 on Nov 13, 2019, 08:03
mentioned in merge request !790

In GitLab by @liyanq528 on Nov 13, 2019, 09:27
mentioned in merge request !1360

In GitLab by @liyanq528 on Nov 13, 2019, 11:26
mentioned in merge request !1073


Claim drop modals and flow

Abstract

the flow that we have now has some bugs and does not work how I expected
here are 2 modals - reused styles from all the modals we already have
important is to solve the bugs that were happening with the current version

the major ones:

not disabling the mint button when you have already minted, then showing the notif that one per address limit
mint success notif usually closed all the modals
The redirect was quite random as well

new colors from neutral color changes used

Design
updated in confirmation modals page: https://www.figma.com/file/JXNtryaNYhY0XJNArzvPQx/Handoff?type=design&node-id=1458%3A19091&mode=design&t=yg8JpK4u8LeaLaP8-1
Loading modal

this one is new, shares some features with the loading modal
copy, context, loading, estimate
will probably also design error state, we can probably use a similar state as in the auto teleport - instead of trying again there will be a close.

Congrats

this one is new, lets test this one out. My only concern is that the preview won't load in 30 seconds when the nft is getting minted, is my concern valid? cc @vikiival
if it would work nicely, I will slowly push this style to all the congrats messages

top to bottom:
transaction

transaction completed, then link to the block explorer, copy button - copies tx link

Preview

biggest part

Context text

for the drops, this will be this
under it is name of the nft and artist

Socials

icons - when hovering over they change to opposite of background color (in light mode its black)
copy link copies link to the nft

Buttons

these are new as well, I believe its good for the flow
you can quickly list or view the nft

list opens list modal, view nft gallery item
Drop page changes

I would like to change the cta button copy a bit:
"Claim NFT Now"
it's more informative about what would happen

needs #8061

My only concern is that the preview won't load in 30 seconds when the nft is getting minted, is my concern valid? cc @vikiival
I have the data in the database so I can send them in response :). therefore you can see the art before it is on-chain

Can we make it till the next gen drop? 👀 Its on Friday afaik

Can we make it till the next gen drop? 👀 Its on Friday afaik

Updated :)

list opens list modal,

here will be [Add Funds] options for first timers?

@yangwao add funds option is in listing modal

@hassnian if you want to take this one, can give you extra bount for this, like $$

@hassnian if you want to take this one, can give you extra bount for this, like $$

got no issue,

@yangwao I can try to do it, do you have deadline?

@shashkovdanil seems want to take it
@yangwao already talked with @exezbcz regarding this issue , I think I'd be great if we had a "testnet" like api for drops or a mocked api or even docs, maybe response api on the issue would even work, but again we can't test , since those workers are private and external contributors have no way of knowing what the api returns , and developing some drop issues becomes and issue
cc @vikiival

I made a testing collection. Please mind that you need few addresses to test it out.
Sadly I cannot disable unique address constrain from D1

👋


Test Dispatchers of Events and Commands in testutil module

This PR brings some new test utilities for dispatching Events and Commands to entities.
AggregateCommandDispatcher
/**
 * Dispatches the CommandEnvelope and applies the resulting events
 * to the specified Aggregate instance.
 *
 * Returns the list of Event messages.
 */
final List<? extends Message> events =
             AggregateCommandDispatcher.dispatch(myProcessManager, commandEnvelope);

ProcessManagerDispatcher
/**
 * Dispatches the  CommandEnvelope to the given ProcessManager.
 *
 * Returns the list of events, being the command output.
 */
final List<Event> events =
             ProcessManagerDispatcher.dispatch(myProcessManager, commandEnvelope);

/**
 * Dispatches the Event to the given ProcessManager.
 */
final Event myEvent = ...;
ProcessManagerDispatcher.dispatch(myProcessManager, myEvent);

/**
 * Dispatches the Event message along with its to the given ProcessManager.
 *
 * Returns the list of events, being the command output.
 */
final Message myEventMessage = ...;
final EventContext context = ...;
ProcessManagerDispatcher.dispatch(myProcessManager, myEventMessage, context);

ProjectionEventDispatcher
/**
 * Dispatches the Event to the given Projection.
 */
final Event myEvent = ...;
ProjectionEventDispatcher.dispatch(myProjection, myEvent);

/**
 * Dispatches the Event message along with its to the given ProcessManager.
 *
 * Returns the list of events, being the command output.
 */
final Message myEventMessage = ...;
final EventContext context = ...;
ProjectionEventDispatcher.dispatch(myProjection, myEventMessage, context);

The framework version has been increased to 0.9.14-SNAPSHOT.

@alexander-yevsyukov PTAL.

@alexander-yevsyukov the issue is addressed. The coverage is now improved. PTAL again.


xioctl(UVCIOC_CTRL_QUERY) failed Last Error: Connection timed out on D435

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
D400

Firmware Version
<IP_ADDRESS>

Operating System & Version
Ubuntu 20.04

Kernel Version (Linux Only)
5.4.0-52-generic

Platform
PC

SDK Version
{ 2.39.0-0 }

Language
{C++ }

Segment
{Robot}

Issue Description
I get an error similar to this issue #6041, on a multi camera setup. The error is inconsistent and thus hard to reproduce.
By reading the other issues on this error, I understood that this error may come from my kernel version not yet supported but I wanted to know if anyone found a fix to this problem

Hi @Patrick-Lascombe   Although 5.4 generic is not officially validated for use with librealsense at the time of writing this, it is generally stable and numerous RealSense users have used 5.4 successfully.
If you are using a C++ application that you have written and the problem is hard to reproduce, it may be worth implementing an error catch into your program.  The error handling documentation page of librealsense has an example error-handling script at the bottom of it.
https://dev.intelrealsense.com/docs/librealsense-error-handling-scheme

Hi @Patrick-Lascombe  Do you still require assistance with this case, please?   Thanks!

Case closed due to no further comments received.


gitsubmodule core/general-client/pybind11 seems to be broken

I encountered an error when building PaddleServing in CLIENT_ONLY mode:
[root@my_host_name build_client]# cmake -DCLIENT_ONLY=ON ..
-- Found Paddle host system: centos, version: 6.10
-- Found Paddle host system's CPU: 12 cores
-- CXX compiler: /opt/rh/devtoolset-2/root/usr/bin/c++, version: GNU 4.8.2
-- C compiler: /opt/rh/devtoolset-2/root/usr/bin/cc, version: GNU 4.8.2
-- Do not have AVX2 intrinsics and disabled MKL-DNN
-- BOOST_TAR: boost_1_41_0, BOOST_URL: http://paddlepaddledeps.cdn.bcebos.com/boost_1_41_0.tar.gz
-- Protobuf protoc executable: /home/Serving/build_client/third_party/install/protobuf/bin/protoc
-- Protobuf-lite library: /home/Serving/build_client/third_party/install/protobuf/lib/libprotobuf-lite.a
-- Protobuf library: /home/Serving/build_client/third_party/install/protobuf/lib/libprotobuf.a
-- Protoc library: /home/Serving/build_client/third_party/install/protobuf/lib/libprotoc.a
-- Protobuf version: 3.1
-- ssl:/usr/lib64/libssl.so
-- crypto:/usr/lib64/libcrypto.so
paddle serving source dir: /home/Serving
CMake Error at core/general-client/CMakeLists.txt:2 (add_subdirectory):
  The source directory

    /home/Serving/core/general-client/pybind11

  does not contain a CMakeLists.txt file.

CMake Error at core/general-client/CMakeLists.txt:3 (pybind11_add_module):
  Unknown CMake command "pybind11_add_module".

The error message says that /home/Serving/core/general-client/pybind11 directory does not contain a CMakeLists.txt file, and it turns out to be an empty directory. pybind11 has been changed to a git submodule in commit 546f164088dd5bd8d7d8597af7195b56fba16f03 , but this submodule is not properly configured, which makes git submodule update command fail.
The folder icon of pybind11 submodule on github is also grey, which indicates that the submodule points to an unreachable location.

Thanks for your pointing, we will fix

fixed. https://github.com/PaddlePaddle/Serving/pull/180, will close this issue.


Explain how to set the HttpClient's BaseAddress

In previous patterns, we would explicitly set the HttpClient's BaseAddress property. This makes the subsequent method calls a lot easier/simpler, by not having to concatenate URL string parts. You don't mention how we do that with this new factory pattern or if it's different at all.
In fact, your example shows a base address (_remoteServiceBaseUrl), but glosses over where/how it gets a value.
public class CatalogService : ICatalogService
{
    private readonly HttpClient _httpClient;
    private readonly string _remoteServiceBaseUrl;

    public CatalogService(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task<Catalog> GetCatalogItems(int page, int take,
                                               int? brand, int? type)
    {
        var uri = API.Catalog.GetAllCatalogItems(_remoteServiceBaseUrl,
                                                 page, take, brand, type);

        var responseString = await _httpClient.GetStringAsync(uri);

        var catalog = JsonConvert.DeserializeObject<Catalog>(responseString);
        return catalog;
    }
}

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

ID: 7b506236-b211-eb9d-b571-5efecdde76c8
Version Independent ID: 1bb011dd-a559-c0d7-b0cf-984fbb2d4bd3
Content: Use HttpClientFactory to implement resilient HTTP requests
Content Source: docs/standard/microservices-architecture/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests.md
Product: dotnet
Technology: dotnet-ebooks
GitHub Login: @nishanil
Microsoft Alias: nanil

Actually, I see the explicit BaseAddress handling in another linked page: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-2.1#typed-clients


Eliminated rule info

Tested it end to end.
@ashutosh-mishra  @YogeshRajmane

Changes are fine. Unit tests will break. Unit tests will be fixed in next PR.


true aspect ratios

Reported by Jonathan S Callahan on 23 Nov 2004 23:44 UTC
It turns out to be surprisingly difficult to get Ferret to make 'true' apsect
plots programmatically.  It would be very nice to have 'set win/aspect=*:ax'
accept *='true' (or perhaps *='0') to mean:  "use the aspect ratio defined by
the region".
To understand the difficulty of determing the aspect ratio, try writing a script
that will accept the arguments "20e" "100e" "0s" "40s" "15-jan"
"coads_climatology" "sst" and create a plot with an axis aspect ratio of
latitude/longitude (=0.5).
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/1101

Comment by<EMAIL_ADDRESS>on 24 Nov 2004 20:10 UTC
The difficulty with this suggestion is that the window is not in any sense
"owned" by the current region, variable or dataset.  It is a blank piece of
paper on which you wish to plot.  One could envision a command of the style
yes? SET MODE ASPECT:auto-axis
whose effect would be to reset the aspect ratio for each plot, based upon the
axis ranges of the requested data.  This would achieve the goal that Jon has
suggested.
It is unclear why a script that extracts the desired information from the
current region poses a major difficulty.  Below is an example.  What are the
limitations of this approach?  (The example could and perhaps should use the
grid from SST instead of the new axes, xfine & yfine.  That might be necessary
in order to get the aspect ration completely exact, because of grid-cell
roundoffs.  Is that where the complications lie?
example script:
! set the stage
use coads_climatology
set region/x=20e:100e/y=40s:0/t=15-jan
! set the aspect ratio
canc mode lat
canc mode lon
define axis/x=0e:360e:.01/edges/modulo xfine
define axis/y=90s:90n:.01/edges/modulo yfine
let aspect =
((Y[WINDOW/ASPECT=aspect`:ax
! clean up
set mode/last lat
set mode/last lon
cancel variable aspect
! do a sample plot
shade sstl=1-(Y[gy=yfine],return=ystart))/((X[gx=xfine],retur n=xend)-(X[gx=xfine],return=xstart))
SET)

Comment by<EMAIL_ADDRESS>on 29 Nov 2004 17:15 UTC
Using the script below with the xfine and yfine axes returns an aspect ratio of
0.49994 instead of 0.5.  If we use the original coads axes in the script we end
up with 0.4872.  This is because RETURN=*start/*end returns the location of the
nearest grid point rather than the actual region defined.  The documentation
states that each of these functions:  "Returns start/end of specified world
coordinate region" so either the documentation or the functionality needs to be
changed for them to match.

Comment by<EMAIL_ADDRESS>on 29 Nov 2004 20:26 UTC
can solve this if the output of SHOW REGION were available as symbols.  See bug
783.
*** This bug has been marked as a duplicate of 783 ***


Playlist class documentation broken

https://github.com/jasonhaxstuff/popyt/blob/e49236a888b24720868212aac3e794aa09a0cae6/docs/docs/classes/playlist.html#L228
Looks like a tag that wasn't escaped. It breaks the rest of the page and makes it not visible.

I assumed that typedoc would escape that for me. Guess I'll have to do it manually. Thanks for the issue!

Fixed by a3ad5e3


ENH: Allow to configure step size for iterative recon using Cuda ray-based projectors

This commit fixes the issue #564.

Looks good, thanks. The commit message is a bit long, it should be 72 characters see here. Maybe "ENH: Step size accessors for Cuda ray tracing in iterative recon"

Fixes #564.


SCU Update: Update broken markdown links

🗣 Description

💭 Motivation and context
Updated the broken markdown links that were causing 404 errors.
Closes #1341
🧪 Testing
validate that the broken links listed in the issue have been updated and no 404 issues occur.
✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] PR targets the correct parent branch (e.g., main or release-name) for merge.
[x] Changes are limited to a single goal - eschew scope creep!
[x] Changes are sized such that they do not touch excessive number of files.
[x] Related issues these changes resolve are linked preferably via closing keywords.
[x] All relevant type-of-change labels added.
[x] All relevant project fields are set.
[x] All relevant repo and/or project documentation updated to reflect these changes.
[x] All relevant functional tests passed.
[x] All automated checks (e.g., linting, static analysis, unit/smoke tests) passed.

✅ Pre-merge checklist

[ ] PR passed smoke test check.

[ ] Feature branch has been rebased against changes from parent branch, as needed
Use Rebase branch button below or use this reference to rebase from the command line.

[ ] Resolved all merge conflicts on branch

[ ] Notified merge coordinator that PR is ready for merge via comment mention

✅ Post-merge checklist

[ ] Feature branch deleted after merge to clean up repository.
[ ] Verified that all checks pass on parent branch (e.g., main or release-name) after merge.

This corrects all but the last link listed in issue #1341, "https://playbooks.idmanagement.gov/piv/network/group/" in "/PowerShell/ScubaGear/Testing/Unit/PowerShell/CreateReport/CreateReportStubs/aad.md". @ahuynhMITRE I'm assuming you'd rather scope this PR to just baseline changes? If so, I'd recommend opening a second issue to track that final link. It's a low priority thing, I just don't want to lose track of it.

yep will separate into a a new issue so it doesn't get lost! thanks for the reminder @adhilto!

@nanda-katikaneni good to merge!

This corrects all but the last link listed in issue #1341, "https://playbooks.idmanagement.gov/piv/network/group/" in "/PowerShell/ScubaGear/Testing/Unit/PowerShell/CreateReport/CreateReportStubs/aad.md". @ahuynhMITRE I'm assuming you'd rather scope this PR to just baseline changes? If so, I'd recommend opening a second issue to track that final link. It's a low priority thing, I just don't want to lose track of it.

yep will separate into a a new issue so it doesn't get lost! thanks for the reminder @adhilto!

new issue #1421 created to capture the remaining link certificate error!


Remove return from single-expression closure

As single-expression closures implicitly return their result, I've removed a couple of redundant return keywords.

merged in 82696d9de5c3221b2a51cbf59b8979c41d4eabe1
Thanks for the PR!


Microsoft.AspNetCore.Mvc.NewtonsoftJson Net6.0 on Net5.0

Description
Paket is not resolving Microsoft.AspNetCore.Mvc.NewtonsoftJson according to the target framework. Its resolving to Net6.0 which is wrong.
error NU1202: Package Microsoft.AspNetCore.Mvc.NewtonsoftJson 6.0.0 is not compatible with net5.0 (.NETCoreApp,Version=v5.0). Package Microsoft.AspNetCore.Mvc.NewtonsoftJson 6.0.0 supports: net6.0 (.NETCoreApp,Version=v6.0)

Thanks

I'm having the same issue, Paket is installing net6.0 versions of some packages and then my application fails to build because it targets net5.0. I've tried both framework: net5.0 and framework: auto-detect, same issue with both.

I just ran into this same issue, with Microsoft.EntityFrameworkCore in our case. Did you find a workaound in the meantime?

Pinned to nuget Microsoft.AspNetCore.Mvc.NewtonsoftJson == 5.0.11 as we are currently targeting net5.0 ony!

Same here, I had to pin the version in paket.dependencies for any package that was pulling in the incorrect framework.

My team is being haunted by this problem lately. I'm not sure whether this really is an issue but I don't want Paket to pull .net6 dependencies when my project is targeting .net5.
Pinning dependencies gets old quickly when we are talking about transitive dependencies.

I'm having the same problem in one of my projects. framework: auto-detect is ignored, along with framework: 5.0. I also have a problem in this project where every time I run paket update it adds <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> to my csproj file, even if I have redirects: off in my paket.dependencies. That makes me wonder if there's a deeper problem that's causing the "ignoring framework restrictions" behavior and other undesired behavior.
I've tried cleaning, rebuilding, deleting obj and bin folders, deleting and reinstalling paket. Nothing seems to work and it keeps installing framework 6 packages into the framework 5 project.

Kind of a lame workaround, but you could use strategy: min in paket.dependencies to use the default nuget resolution strategy instead of the default paket resolution strategy.  Might be better than needing to pin all of the transitive dependencies (though you still need to pin the primary dependencies when you add them to get a .net5 compatible version)

I would also like to say this is occurring to our team as well. So, bump!

I would note that this is now happening again with the recent release of .NET 8.
I had thought that using framework: auto-detect in the paket.dependencies file would prevent this behavior, but it's trying to install .NET 8 packages that are incompatible with my net7 targeted project. Trying framework: net7 doesn't seem to prevent it either.

For the benefit of anybody coming across this issue.
As suggested in another issue. This issue can be alleviated by using paket update --keep-major.

Bumping because I'm also encountering this issue. It seems that that transitive dependencies don't respect the framework restriction


[RFC] Allow different mount points or path to read from vault

Is your feature request related to a problem? Please describe.
Dynaconf offers only one mount point, default is secret. Many enterprises have multiple mount points for departments and different teams and different subpaths for different apps.
Describe the solution you'd like
Vault approle itself offers different mount points and allows to read only specific path. Please expose those features of allowing us to specify the mount point and path to CRUD.
Describe alternatives you've considered
Skip dynaconf and use vault approles directly
Additional context
None

I have answered similar in other question.
There's VAULT_MOUNT_POINT_FOR_DYNACONF that can be used for changing the Mount Point from secret to given_name.
This is a present feature for a long time now, but it's not clearly documented.
https://github.com/dynaconf/dynaconf/blob/master/dynaconf/default_settings.py#L181C6-L181C36


How big is Tiny CLR?

Approx how much memory does Tiny CLR take up when installed with a running app? How big could it grow to (if features were added) before size became a serious problem for the devices it currently targets?
Is there any document or details about a typical memory map when a C# app is loaded and running? Just to get an idea of the bits n pieces that are needed and their approx size.

There isn't really a good number we can give at the moment. We're currently hard at work on the next version and a lot of features are being added, so the size is in flux.  As we get closer to that release we can certainly release some size numbers.
For a rough estimate that can change: For a firmware with all features in it, expect it to be in the range of 1-4MB. RAM usage will depend on what your app does but a good minimum is 50-100KB. On top of all of that add your actual application.


JSON Schema for checking docs when adding

Should update of the schema doc trigger check of existing docs? What to do if fail?

No, out of scope.


vendor/autoload.php missing

Hi, I could not find the vendor dir. containing in autoload.php in zip

Hi @ibrism, dependencies are managed through Composer so you'll need to run composer install from the root of the repository to install any additional dependencies, which creates and populates the vendor directory


feat: add k8s cronjob for rabbitmq backup, and re-factor repo [migration]

PLATFORM-4953

Add src/rabbitmq_export. It exports broker definitions from staging/production RabbitMQ. Remove old Bash script. Add a k8s cronjob for each environment.
The old Bash script only kept one backup - each backup overwrites the previous. The new script does not overwrite, therefore pruning is required. src/kubernetes_backup already has pruning code which can be re-used. Therefore:

Extract src/kubernetes_backup/prune.py into an independent script src/s3_prune_backups which prunes for both k8s and RabbitMQ backups. Add k8s cronjobs.
Rename src/kubernetes_backup to src/kubernetes_export because now it does export only.

About the k8s-related scripts (src/kubernetes_...), they must be aware of whether they are running inside the target k8s cluster. Currently they infer that from two vars: K8S_CLUSTER, KUBECTL_CONTEXT var. K8S_CLUSTER being set means in cluster, KUBECTL_CONTEXT means outside cluster. I find this approach too confusing. Re-factor as follows:

Add an in_cluster cmdline boolean option. True means script is running inside cluster. False otherwise.
Add a required artsy_env cmdline arg with two possible values: staging, production.

Simplify src/kubernetes_cleanup_jobs. It supports cleaning all pods, pods by name, pods by completed status. We only clean up all jobs and I don't foresee us using the other two, so delete them.
Re-factor src/kubernetes_cleanup_pods. It supports cleaning up pods by name or by completed status, in separate functions. However, the two criteria are not mutually exclusive. For example, I may be interested in pods that are named foo and  are completed. Replace the functions with a single function that provides the flexibility.
Refactor Kctl#_run. Currently it raises exception when the kubectl commands returns non-zero. That is not always desirable for commands such as kubectl delete pod ... for which we may want to tolerate 'pod not found' (possibly it exited on its own, or was deleted by another job or by a human). Add an expect_success flag to give this clients option on whether exception should be raised.
Lots of miscellaneous changes on: naming, styling, consistency, moving code into src/lib, simplification, etc.

Migration:
Pre-merge

[ ] Update shared env.
[ ] Delete Staging cronjobs (due to changes in job names, cmdline args, ...)kubectl --context staging delete cronjob opstools-cleanup-completed-pods
kubectl --context staging delete cronjob opstools-cleanup-hokusai-run-pods
kubectl --context staging delete cronjob opstools-cleanup-jobs
kubectl --context staging delete cronjob opstools-cleanup-review-apps
kubectl --context staging delete cronjob opstools-k8s-create-backup
kubectl --context staging delete cronjob opstools-k8s-prune-backup
kubectl --context staging delete cronjob opstools-terraform-drift-detection

[ ]  Update Staging env.
[ ] Move s3://artsy-backup/k8s/staging/ backup files to s3://artsy-backup/k8s/archive/staging/. This is because of change in file naming - timezone info will be added to filenames.

Staging QA
Mostly running the jobs and check output. Jobs are safe to run.
kubectl --context staging create job opstools-cleanup-completed-pods-test --from=cronjob/opstools-cleanup-completed-pods
kubectl --context staging get pod | grep opstools-cleanup-completed-pods-test
kubectl --context staging logs -f <pod name>

kubectl --context staging create job opstools-cleanup-hokusai-run-pods-test --from=cronjob/opstools-cleanup-hokusai-run-pods
kubectl --context staging get pod | grep opstools-cleanup-hokusai-run-pods-test
kubectl --context staging logs -f <pod name>

kubectl --context staging create job opstools-cleanup-jobs-test --from=cronjob/opstools-cleanup-jobs
kubectl --context staging get pod | grep opstools-cleanup-jobs-test
kubectl --context staging logs -f <pod name>

kubectl --context staging create job opstools-cleanup-review-apps-test --from=cronjob/opstools-cleanup-review-apps
kubectl --context staging get pod | grep opstools-cleanup-review-apps
kubectl --context staging logs -f <pod name>

kubectl --context staging create job opstools-k8s-export-test --from=cronjob/opstools-k8s-export
kubectl --context staging get pod | grep opstools-k8s-export-test
kubectl --context staging logs -f <pod name>
...look for an S3 location in logs output, and confirm the location has a .tar.gz file
...confirm the filename has a 'Z' which denotes UTC timezone

kubectl --context staging create job opstools-rabbitmq-export-test --from=cronjob/opstools-rabbitmq-export
kubectl --context staging get pod | grep opstools-rabbitmq-export-test
kubectl --context staging logs -f <pod name>
...look for the S3 location in logs and confirm it has a .json file

kubectl --context staging create job opstools-s3-prune-backups-k8s-test --from=cronjob/opstools-s3-prune-backups-k8s
kubectl --context staging get pod | grep opstools-s3-prune-backups-k8s-test
kubectl --context staging logs -f <pod name>

kubectl --context staging create job opstools-s3-prune-backups-rabbitmq-test --from=cronjob/opstools-s3-prune-backups-rabbitmq
kubectl --context staging get pod | grep opstools-s3-prune-backups-rabbitmq-test
kubectl --context staging logs -f <pod name>

kubectl --context staging create job opstools-terraform-drift-detection-test --from=cronjob/opstools-terraform-drift-detection
kubectl --context staging get pod | grep opstools-terraform-drift-detection-test
kubectl --context staging logs -f <pod name>

Pre-merge-Deploy-PR

[ ] Delete Production cronjobs (due to changes in job names, cmdline args, ...)kubectl --context staging delete cronjob opstools-cleanup-completed-pods
kubectl --context staging delete cronjob opstools-cleanup-hokusai-run-pods
kubectl --context staging delete cronjob opstools-cleanup-jobs
kubectl --context staging delete cronjob opstools-ecr-check-repos-for-terraform
kubectl --context staging delete cronjob opstools-k8s-create-backup
kubectl --context staging delete cronjob opstools-k8s-prune-backup
kubectl --context staging delete cronjob opstools-terraform-drift-detection

[ ]  Update Production env.
[ ] Delete RabbitMQ Jenkins jobs.
[ ] Move s3://artsy-backup/k8s/production/ backup files to s3://artsy-backup/k8s/archive/production/. This is because of change in file naming - timezone info will be added to filenames.

Prod QA
Mostly running the jobs and check output. Jobs are safe to run.
kubectl --context production create job opstools-cleanup-completed-pods-test --from=cronjob/opstools-cleanup-completed-pods
kubectl --context production get pod | grep opstools-cleanup-completed-pods-test
kubectl --context production logs -f <pod name>

kubectl --context production create job opstools-cleanup-hokusai-run-pods-test --from=cronjob/opstools-cleanup-hokusai-run-pods
kubectl --context production get pod | grep opstools-cleanup-hokusai-run-pods-test
kubectl --context production logs -f <pod name>

kubectl --context production create job opstools-cleanup-jobs-test --from=cronjob/opstools-cleanup-jobs
kubectl --context production get pod | grep opstools-cleanup-jobs-test
kubectl --context production logs -f <pod name>

kubectl --context production create job opstools-ecr-check-repos-for-terraform-test --from=cronjob/opstools-ecr-check-repos-for-terraform
kubectl --context production get pod | opstools-ecr-check-repos-for-terraform-test
kubectl --context production logs -f <pod name>

kubectl --context production create job opstools-k8s-export-test --from=cronjob/opstools-k8s-export
kubectl --context production get pod | grep opstools-k8s-export-test
kubectl --context production logs -f <pod name>
...look for an S3 location in logs output, and confirm the location has a .tar.gz file
...confirm the filename has a 'Z' which denotes UTC timezone

kubectl --context production create job opstools-rabbitmq-export-test --from=cronjob/opstools-rabbitmq-export
kubectl --context production get pod | grep opstools-rabbitmq-export-test
kubectl --context production logs -f <pod name>
...look for the S3 location in logs and confirm it has a .json file

kubectl --context production create job opstools-s3-prune-backups-k8s-test --from=cronjob/opstools-s3-prune-backups-k8s
kubectl --context production get pod | grep opstools-s3-prune-backups-k8s-test
kubectl --context production logs -f <pod name>

kubectl --context production create job opstools-s3-prune-backups-rabbitmq-test --from=cronjob/opstools-s3-prune-backups-rabbitmq
kubectl --context production get pod | grep opstools-s3-prune-backups-rabbitmq-test
kubectl --context production logs -f <pod name>

kubectl --context production create job opstools-terraform-drift-detection-test --from=cronjob/opstools-terraform-drift-detection
kubectl --context production get pod | grep opstools-terraform-drift-detection-test
kubectl --context production logs -f <pod name>

Whew 😅 , what an epic PR! All the changes seem reasonable to me but it may make sense to get another review given the size of this PR and my inexpertise with Python.
My main comment would just be that given the size and particular sensitivity of the operations involved, it would be helpful to understand the testing plan a bit more (though test coverage looks robust). It seems like all jobs/operations are fully running in staging, so we should be able to test there for a period. Is this the plan, or did you have something else in mind?

My main comment would just be that given the size and particular sensitivity of the operations involved, it would be helpful to understand the testing plan a bit more (though test coverage looks robust).

Agreed. I'll hash out the test steps and update PR.

Added Staging/Prod QA steps.

migration applied. minor problem encountered and fixed in https://github.com/artsy/opstools/pull/37


Add ability to put anime to more tab

Describe your suggested feature
I don't use the anime tab. And there is no option to remove / move it more. It unnecessarily taking space.
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] If this is a request regarding an extension, I should be opening an issue in the extension's repository.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I will fill out all of the requested information in this form.

If you're not using the anime tab, then why not use Mihon instead?


Model Identifier Mismatch Error

Description
ValueError: Model provided has model identifier '
→
', should be 'TFL3'
I'm using google coral dev board mini and I use the inference code (semantic_segmentation.py) from the official github repo and change the arguments to my quantised model and input. Then, I got this error and I don't know how to fix it.
Click to expand!
Issue Type
Support
Operating System
Mendel Linux
Coral Device
Dev Board Mini
Other Devices
No response
Programming Language
No response
Relevant Log Output
ValueError: Model provided has model identifier '
→
', should be 'TFL3'

I just found out there are some mistakes in my python command. After I fix it, i got "Segmentation fault". How can I fix this?
Here are my python command
python3 semantic_segmentation.py
--model model_quant.tflite
--input test.png
--keep_aspect_ratio
--output ${HOME}/segmentation_result.jpg

I just found out there are some mistakes in my python command. After i fix it, I got "Segmentation fault", how can I fix this?
here are my python command
python3 semantic_segmentation.py
--model model_quant.tflite
--input test.png
--keep_aspect_ratio
--output ${HOME}/segmentation_result.jpg

Hi, There could be some issue with the model. Can you please share the model here.. Thanks!!

https://github.com/shungyan/Medical_Semantic_Segmentation/blob/master/model_quant.tflite
Hi, this is the link for my quantised model, and here are the snippets I used to quantised my model
Load the HDF5 model
model = tf.keras.models.load_model("lung_segmentation_80epochs_avg_pooling_700kparam_aug.hdf5",compile=False)
converter = tf.lite.TFLiteConverter.from_keras_model(model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_data_gen
Ensure that if any ops can't be quantized, the converter throws an error
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
Set the input and output tensors to uint8 (APIs added in r2.3)
converter.inference_input_type = tf.uint8
converter.inference_output_type = tf.uint8
tflite_model_quant = converter.convert()
Save the quantized model to disk
with open("model_quant.tflite", "wb") as f:
f.write(tflite_model_quant)

There is some issue in tflite conversion. Please try to convert using saved model: https://www.tensorflow.org/lite/models/convert/convert_models

Hi, I converted my model using saved model but it still appear the same error. Is there other way to fix this?

#0  0x0000007ff7d01710 in strlen () from /lib/aarch64-linux-gnu/libc.so.6
#1  0x0000007ff5ac1264 in tflite::InterpreterBuilder::ParseSignatureDefs(flatbuffers::Vector<flatbuffers::Offsettflite::SignatureDef > const*, tflite::Interpreter*) ()
from /usr/lib/python3/dist-packages/tflite_runtime/_pywrap_tensorflow_interpreter_wrapper.cpython-37m-aarch64-linux-gnu.so
#2  0x0000007ff5ac19d4 in tflite::InterpreterBuilder::operator()(std::unique_ptr<tflite::Interpreter, std::default_deletetflite::Interpreter >, int) ()
from /usr/lib/python3/dist-packages/tflite_runtime/_pywrap_tensorflow_interpreter_wrapper.cpython-37m-aarch64-linux-gnu.so
#3  0x0000007ff58f3440 in tflite::interpreter_wrapper::InterpreterWrapper::CreateInterpreterWrapper(std::unique_ptr<tflite::FlatBufferModel, std::default_deletetflite::FlatBufferModel >, std::unique_ptr<tflite::interpreter_wrapper::PythonErrorReporter, std::default_deletetflite::interpreter_wrapper::PythonErrorReporter >, std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > const&, std::vector<std::function<void (unsigned long)>, std::allocator<std::function<void (unsigned long)> > > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator >) ()
from /usr/lib/python3/dist-packages/tflite_runtime/_pywrap_tensorflow_interpreter_wrapper.cpython-37m-aarch64-linux-gnu.so
#4  0x0000007ff58f39c0 in tflite::interpreter_wrapper::InterpreterWrapper::CreateWrapperCPPFromFile(char const*, std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > const&, std::vector<std::function<void (unsigned long)>, std::allocator<std::function<void (unsigned long)> > > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator >) ()
from /usr/lib/python3/dist-packages/tflite_runtime/pywrap_tensorflow_interpreter_wrapper.cpython-37m-aarch64-linux-gnu.so
#5  0x0000007ff58f08d0 in pybind11::cpp_function::initialize<pybind11_init__pywrap_tensorflow_interpreter_wrapper(pybind11::module&)::{lambda(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > const&, std::vector<std::function<void (unsigned long--Type  for more, q to quit, c to continue without paging--
)>, std::allocator<std::function<void (unsigned long)> > > const&)#2}, tflite::interpreter_wrapper::InterpreterWrapper, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::_cxx11::basic_string<char, std::char_traits, std::allocator > > > const&, std::vector<std::function<void (unsigned long)>, std::allocator<std::function<void (unsigned long)> > > const&, pybind11::name, pybind11::scope, pybind11::sibling>(pybind11_init__pywrap_tensorflow_interpreter_wrapper(pybind11::module&)::{lambda(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > const&, std::vector<std::function<void (unsigned long)>, std::allocator<std::function<void (unsigned long)> > > const&)#2}&&, tflite::interpreter_wrapper::InterpreterWrapper* ()(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > const&, std::vector<std::function<void (unsigned long)>, std::allocator<std::function<void (unsigned long)> > > const&), pybind11::name const&, pybind11::scope const&, pybind11::sibling const&)::{lambda(pybind11::detail::function_call&)#3}::_FUN(pybind11::detail::function_call) ()
from /usr/lib/python3/dist-packages/tflite_runtime/_pywrap_tensorflow_interpreter_wrapper.cpython-37m-aarch64-linux-gnu.so
#6  0x0000007ff58e78ec in pybind11::cpp_function::dispatcher(_object, _object*, _object*) ()
from /usr/lib/python3/dist-packages/tflite_runtime/_pywrap_tensorflow_interpreter_wrapper.cpython-37m-aarch64-linux-gnu.so
#7  0x000000000043cf90 in _PyMethodDef_RawFastCallKeywords ()
#8  0x000000000043d030 in _PyCFunction_FastCallKeywords ()
#9  0x000000000042b0e4 in _PyEval_EvalFrameDefault ()
#10 0x00000000004df2bc in _PyEval_EvalCodeWithName ()
#11 0x000000000043c9bc in _PyFunction_FastCallDict ()
#12 0x000000000043e104 in _PyObject_Call_Prepend ()
#13 0x000000000048e078 in ?? ()
#14 0x0000000000487858 in ?? ()
#15 0x000000000043d240 in _PyObject_FastCallKeywords ()
--Type  for more, q to quit, c to continue without paging--
#16 0x0000000000425490 in _PyEval_EvalFrameDefault ()
#17 0x00000000004df2bc in _PyEval_EvalCodeWithName ()
#18 0x000000000043cb24 in _PyFunction_FastCallKeywords ()
#19 0x0000000000429e78 in _PyEval_EvalFrameDefault ()
#20 0x0000000000422914 in ?? ()
#21 0x0000000000429bac in _PyEval_EvalFrameDefault ()
#22 0x00000000004df2bc in _PyEval_EvalCodeWithName ()
#23 0x00000000004df600 in PyEval_EvalCode ()
#24 0x0000000000512430 in PyRun_FileExFlags ()
#25 0x000000000051260c in PyRun_SimpleFileExFlags ()
#26 0x0000000000431be8 in ?? ()
#27 0x0000000000431e18 in _Py_UnixMain ()
#28 0x0000007ff7ca6d24 in __libc_start_main () from /lib/aarch64-linux-gnu/libc.so.6
#29 0x000000000042c3b0 in _start ()
Hi, I got this error message by using gdb, it seems like something wrong with the interpreter but not sure what is the exact problem

Have you tried with different TF versions? And how did you get the saved model?

I tried with the saved_model and integer quantised model, and here is how i get my saved model
Load the saved model
model = tf.keras.models.load_model('normalize_lung_segmentation_10epochs_avg_pooling_700kparam_aug.hdf5',custom_objects={'dice_coef_loss': dice_coef_loss,
'dice_coef':dice_coef})
Export the model
tf.saved_model.save(model, '/content/saved_model')
saved_model_dir='/content/saved_model/'
Convert the model
converter = tf.lite.TFLiteConverter.from_saved_model(saved_model_dir) # path to the SavedModel directory
tflite_model = converter.convert()
Save the model.
with open('saved_model.tflite', 'wb') as f:
f.write(tflite_model)

normalize_lung_segmentation_10epochs_avg_pooling_700kparam_aug.hdf5

Please check how this file getting generated. And try to export the model in saved_model format instead of .hdf5

from keras.callbacks import ModelCheckpoint, LearningRateScheduler, EarlyStopping, ReduceLROnPlateau
weight_path="{}_weights.best.hdf5".format('cxr_reg')
checkpoint = ModelCheckpoint(weight_path, monitor='val_loss', verbose=1,
save_best_only=True, mode='min', save_weights_only = True)
reduceLROnPlat = ReduceLROnPlateau(monitor='val_loss', factor=0.5,
patience=3,
verbose=1, mode='min', epsilon=0.0001, cooldown=2, min_lr=1e-6)
early = EarlyStopping(monitor="val_loss",
mode="min",
patience=15) # probably needs to be more patient, but kaggle time is limited
callbacks_list = [checkpoint, early, reduceLROnPlat]
from IPython.display import clear_output
from tensorflow.keras.optimizers import Adam
from sklearn.model_selection import train_test_split
model.compile(optimizer=tf.keras.optimizers.Adam(lr=2e-4),
loss=[dice_coef_loss],
metrics = [dice_coef, 'binary_accuracy'])
loss_history = model.fit(x = train_vol,
y = train_seg,
batch_size = 16,
epochs = 10,
validation_data =(test_vol,test_seg) ,
callbacks=callbacks_list)
from google.colab import files
model.save('lung_segmentation_10epochs_avg_pooling_700kparam_aug.hdf5')
files.download('lung_segmentation_10epochs_avg_pooling_700kparam_aug.hdf5')
Hi, this is how I save the file after I trained the model, the save_model format you mean is pb file?

weight_path="{}_weights.best.hdf5".format('cxr_reg')

can you share this file please here..

Try this script on colab with tf2.11
import tensorflow as tf
from tensorflow import keras
import numpy as np
import random

def representative_dataset():
  for _ in range(100):
    data = np.random.rand(1, 128, 128, 1)
    yield [data.astype(np.float32)]

model = tf.keras.models.load_model("lung_segmentation_80epochs_avg_pooling_700kparam_aug.hdf5",compile=False)

model.input.set_shape((1,) + model.input.shape[1:])
print(model.input.shape)

converter = tf.lite.TFLiteConverter.from_keras_model(model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_dataset
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
converter.target_spec.supported_types = [tf.int8]
converter.inference_input_type = tf.int8 # or tf.uint8
converter.inference_output_type = tf.int8 # or tf.uint8

tflite_quant_model = converter.convert()

with open('test_quant.tflite', 'wb') as f:
  f.write(tflite_quant_model)

Hi, I still got the same error not sure why

which tensorflow version are you using?

2.11

Hi, I wrote a simple python code just to check the interpreter and I got this error
My python code:
import argparse
import numpy as np
from PIL import Image
from pycoral.adapters import common
from pycoral.adapters import segment
from pycoral.utils.edgetpu import make_interpreter
def main():
# Load the TFLite model
interpreter = make_interpreter("test_quant.tflite", device=':0')
if name == 'main':
main()
Error:
File "custom_semantic_segmentation.py", line 7, in
from pycoral.utils.edgetpu import make_interpreter
File "/home/mendel/coral/pycoral/pycoral/utils/edgetpu.py", line 24, in
from pycoral.pybind._pywrap_coral import GetRuntimeVersion as get_runtime_version
ModuleNotFoundError: No module named 'pycoral.pybind'

Hi, is there other way to do inference for my model?

Have you gone through the getting started documnet and tired the pycoral demo?

Yes I have tried with the semantic segmentation example and it works and I tried to use the example inference code to run my model and I get segmentation fault. Should I rewrite the inference code myself?

Please check mendel version thath you have if its not 5.3 then update the software: https://coral.ai/docs/dev-board-mini/get-started/#6-update-the-mendel-software.
And yes, you need to write your own inference code for own model for parsing the results. However, you can try sample inference script to test the model located at: https://github.com/hjonnala/snippets/blob/main/coral_inference.py
mendel@tuned-calf:~$ cat /etc/mendel_version
5.3
mendel@tuned-calf:~$ python3 coral_inference.py --model test_quant.tflite
253.75 ms
mendel@tuned-calf:~$ python3 coral_inference.py --model test_quant_edgetpu.tflite
17.14 ms

I tried your code and wrote my own inference code and its working, thanks a lot for your help!


RPCMode refactor, more sync modes

All RPCMode enums references has been moved to MultiplayerAPI.
More RPC mode checks has been moved from Node to MultiplayerAPI.
Three new RPCModes where added.

To keep compatibility though, sync was left with the current behaviour (like remote) and should be deprecated in the future. Three new keywords where added: remotesync, mastersync, slavesync, they behave like their base counterpart (remote, master, slave) but also apply the function/property locally in the caller. @reduz

I agree that this new sync behavior is better.  I can see it being much more common than the "remoteSync" case.  Anecdotally, its true for my game.  I've been manually validating senders and its been a pain.

I agree this is an improvement as its the more common (and expected) behaviour.

I've been manually validating senders

Same. Only remaining question is whether the current behaviour warrants a new keyword (remotesync)?
Maybe something more explicit on how it doesn't verify the sender and allows everyone to call it on every peer, both remote and locally? exposed?

While I'm guessing its probably less common, there are use cases for "remotesync" (ex: games where the clients + server trust each other).  I think "sync" should be in both terms to help people reason about the behavior.  They are both "send to everyone including myself".  I think it comes down to:

sync and remotesync
slavesync and remotesync

slavesync and remotesync has my vote because the behavior is clear.  Especially when compared to their siblings slave and remote.  Also the symmetry is nice :smile:

Probably changing the behaviour of sync is not correct actually, as it might unexpectedly break things for people. So using a new keyword is likely better...

Hmm yeah a breaking change at this point is probably less than ideal.  Maybe deprecate sync, but leave it (with its current behavior) for compatibility.  Then add slavesync and remotesync?

I would try to not needlessly overcomplicate the GDScript compiler. :P

yeah i agree that simplicity is important both from an implementation standpoint and a user scenario standpoint.  conceptually i think it makes more sense to have a single label that determines network state.
This has my vote:
remotesync func name(): # runs locally and on all peers
slavesync func name(): # runs locally and on all slaves  (if the caller is master)
mastersync func name(): # runs locally and on master (if the caller is a slave)
sync func name(): # for compatibility. alias for "remotesync"
# staged for deprecation / not included in learning material. removed next time breaks possible

If we leave both sync and remotesync in, I think its important to remove sync as a supported path.  Having multiple ways to do the same thing is confusing for users.

Sounds good. @Faless Thoughts?

Updated the PR to keep the old sync behaviour for compatibility. New remotesync mastersync slavesync keywords in GDScript (tested), NativeScript and Mono (not tested)

Reverted due to Mono build issues:
https://i.imgur.com/Hb97mTD.png

That didn't warrant a revert before opening an issue/giving a chance at fixing the build issue...

sorry, won't be as trigger-happy for revert next time :)

Would also be nice to get a text log (why do people make screenshot? Did
they remove the copy button on windows?), I can't read anything due to low
res (at lest on mobile). Will try from desktop ASAP
On Tue, May 29, 2018, 12:13 Max Hilbrunner<EMAIL_ADDRESS>wrote:

sorry, won't be as trigger-happy for revert next time :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/pull/19021#issuecomment-392725637,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABnBbll3a2mgd-jOX3P5i2jWnEwmQdXHks5t3R9JgaJpZM4UFRfW
.

Would also be nice to get a text log (why do people make screenshot? Did
they remove the copy button on windows?), I can't read anything due to low
res (at lest on mobile). Will try from desktop ASAP

@Faless  I was the guy who didn't find that copy button. But what happened to zooming on mobiles? I usually try to open an image in its own tab and then zoom & pan whatever...
Anyway I shared that screenshot on the irc channel while testing the latest commits, I didn't open an issue about it because I know that these things just happen and then are fixed most of the time very fast in Godot. I also didn't expect that your original one got reverted lol
@mhilbrunner You should really consider to act less nervously and maybe just ask people before merging or reverting things. In the last days it's not the first time that you acted too fast. I don't mean to attack you in any way with this, but we could avoid these little situations easily with a little more communication.
In general I start to believe that when single devs or groups of devs that are known to lead a certain area of the game engine, that we could maybe benefit to have specific branches for bigger changes. And then only merge when things have been tested on the official platform we support here (and in this case also test with Mono support which people can love or hate but it's now official a thing for Godot and people expect it to just work at some point. Sure people already push their changes in their own branch of their fork, but I think having it on the official Godot repo could help for exposure and find testers for those areas. The master branch would of course still be seen as a non stable development branch of course, but maybe less open to weird brakes due to just a new pr that got merged. Smaller changes should of course still be submitted directly for the master branch. It would maybe also help to not lose the overview of the general development of Godot. Just a thought

But what happened to zooming on mobiles? I usually try to open an image in
its own tab and then zoom & pan whatever...

It doesn't work on imgur, and it doesn't allow you to (easily) get the
original version.

In general I start to believe that when single devs or groups of devs that
are known to lead a certain area of the game engine, that we could maybe
benefit to have specific branches for bigger changes. And then only merge
when things have been tested on the official platform we support here

People would still not test it, this PR was hanging for a while, but still
remained untested. Why would it be any different if it's on a branch?

(and in this case also test with Mono support which people can love or
hate but it's now official a thing for Godot and people expect it to just
work at some point.

It's the master branch, it may occasionally break, but I'll make sure not
to update the mono part at all, and let monoers do it themselves, so I'm
sure not to break anything.

It doesn't work on imgur, and it doesn't allow you to (easily) get the
original version.

Maybe depends on the browser, most of the reddits that I check have people uploading pictures to imgur. It's not really a problem for me to get the original sized picture. :)

People would still not test it, this PR was hanging for a while, but still
remained untested. Why would it be any different if it's on a branch?

It's a different way to get exposure and a more clear way of saying that a specific thing is meant to get into master. While PRs are in a state of undefined guarantee if something will get into master or not. Of course people following the discussions on the various channels know those things, but not the ones who come the first time and see only a big list of PRs. The labels help a little, but it's not really a clear picture. Maybe it's just me but I guess the idea to have feature branches might become more attractive with the time, when Godot becomes more complex. We are already leaving that "Godot is only 20 MB" state.

It's the master branch, it may occasionally break, but I'll make sure not
to update the mono part at all, and let monoers do it themselves, so I'm
sure not to break anything.

See that's one of those things were I think that a specific branch could help as long as the mono users don't helped out. That's not directly your problem of course, but it would not be that bad if we would merge those bigger changes only after the official platforms (and official scripting languages bindings) have been tested (or at least successfully build). Maybe introduce a policy to create Issues for those branches where general requests can be put like needs testing on language X or platform Y etc. And again for those branches I would only consider the bigger changes like multiplayer architecture, renderer (like for  the initial GLES 3 development) etc. For everything else PRs for master branch would still be the way to go. But again just a thought

Most of the official supported platform are tested by CI builds, Mono/C# is
simply not enough stable/easy to build to be included in the continuous
integration.
Before PRing I build for Windows, Linux/X11, Mac, Android, iOS, UWP, HTML5,
server platform and (for library changes) FreeBSD and OpenBSD.
Keep in mind that I do this in my spare time which is very limited because
need a job to pay my bills.
I even tried to get a Mono build, installed the MSBuild spyware, the whole
.Net/Mono bloatware (3+GiB) but couldn't get it to work.
When it becomes stable, and included in CI builds (you are welcome to
contribute in that sense) these breakage will simply go away.
On Tue, May 29, 2018, 22:56 Michele Valente<EMAIL_ADDRESS>wrote:

It doesn't work on imgur, and it doesn't allow you to (easily) get the
original version.
Maybe depends on the browser, most of the reddits that I check have people
uploading pictures to imgur. It's not really a problem for me to get the
original sized picture. :)
People would still not test it, this PR was hanging for a while, but still
remained untested. Why would it be any different if it's on a branch?
It's a different way to get exposure and a more clear way of saying that a
specific thing is meant to get into master. While PRs are in a state of
undefined guarantee if something will get into master or not. Of course
people following the discussions on the various channels know those things,
but not the ones who come the first time and see only a big list of PRs.
The labels help a little, but it's not really a clear picture. Maybe it's
just me but I guess the idea to have feature branches might become more
attractive with the time, when Godot becomes more complex. We are already
leaving that "Godot is only 20 MB" state.
It's the master branch, it may occasionally break, but I'll make sure not
to update the mono part at all, and let monoers do it themselves, so I'm
sure not to break anything.
See that's one of those things were I think that a specific branch could
help as long as the mono users don't helped out. That's not directly your
problem of course, but it would not be that bad if we would merge those
bigger changes only after the official platforms (and official scripting
languages bindings) have been tested (or at least successfully build).
Maybe introduce a policy to create Issues for those branches where general
requests can be put like needs testing on language X or platform Y etc. And
again for those branches I would only consider the bigger changes like
multiplayer architecture, renderer (like for the initial GLES 3
development) etc. For everything else PRs for master branch would still be
the way to go. But again just a thought
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/pull/19021#issuecomment-392941340,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABnBbr4KoaQZ7TnS5xTE77ExbzthNk5dks5t3bXigaJpZM4UFRfW
.

Maybe it's just me but I guess the idea to have feature branches might become more attractive with the time, when Godot becomes more complex. We are already leaving that "Godot is only 20 MB" state.

In the ideal scenario, yes: we would have feature branches and people would test them and it would be merged when ready. In the real world: nobody tests even PRs, things are only discovered to be breaking after they get merged (feature branches would be even more hidden than PRs). Single devs can only test so much. I mean, reduz actually add a lot of bugs alongside the new features, but it's easy to let the community test in the master branch than he alone spend a lot of time testing it.
At least for now it's easy to merge when the PR is complete and if it fails for someone we add follow-up fixes. Especially for regular contributors, we know they stay around to fix potential issues and regressions. Maybe @mhilbrunner was a little to quick to merge some things, but in general we are quite strict about new features anyway.

The merge was fine, and a compiler error in the master branch for a configuration not tested by the CI (we can't tested everything, there are just too many possible combinations) is fine too. It's just the revert which was unnecessary, @Faless or someone else would have provided a fix within a few hours.
But anyway, what's done is done and the new PR should be good to merge :)

Most of the official supported platform are tested by CI builds, Mono/C# is
simply not enough stable/easy to build to be included in the continuous
integration.

Before PRing I build for Windows, Linux/X11, Mac, Android, iOS, UWP, HTML5,
server platform and (for library changes) FreeBSD and OpenBSD.

Keep in mind that I do this in my spare time which is very limited because I
need a job to pay my bills.

@Faless I know that you are one of those that really test things, but not everyone does that and I also don't pretend it, so your comment about doing it only in your spare time because you need to pay your bills is not needed here really. People doing things here on their spare time should not be an excuse to not overthink changes in how we can improve the usage of GitHub.

I even tried to get a Mono build, installed the MSBuild spyware, the whole
.Net/Mono bloatware (3+GiB) but couldn't get it to work.

When it becomes stable, and included in CI builds (you are welcome to
contribute in that sense) these breakage will simply go away.

The "spyware" is the only way of building Mono, in general a good advice is to not get too personal about software on GitHub (and also about people not finding a copy button ;) ). Building Mono is problematic on multiple Linux distros that's right and known (I built it on Manjaro/Arch Linux recently though). The problem is that the CI solution has an older Ubuntu version and that Ubuntu version uses an older Mono version (if at all). I don't know what I can do about it if it's just simply not available there. And letting it download and install mono from a PPA should not be an option I guess.

In the ideal scenario, yes: we would have feature branches and people would test them and it would be merged when ready. In the real world: nobody tests even PRs, things are only discovered to be breaking after they get merged (feature branches would be even more hidden than PRs). Single devs can only test so much. I mean, reduz actually add a lot of bugs alongside the new features, but it's easy to let the community test in the master branch than he alone spend a lot of time testing it.

@vnen That's why I propose to introduce a rule about creating also an accompanying issue for those kind of PRs that can be predicted to introduce potential breaks on specific platforms (and/or official scripting languages where especially Mono will always be a case for itself when introducing new stuff). One could request testing needed for it etc. Right now the problem is exposure of it. For example so many people don't even knew about bullet physics progress for example, only a few tested when it was still in development. The problem there was that people just don't knew about it. Other projects make use of feature branches and people look more regularly into those bigger topics due to curiosity or general interest in something. Of course I don't say that whenever someone comes with a bigger change or a big new feature that this person should gain merge rights etc. But a little more communication between pr developers and maintainers here could help. It was just a thought at the end, I don't pretend anything I just make my thoughts. I also think about how the user base will grow once for instance the C# support is officially announced "stable" and with export support etc. I think we underestimate here the potential new users that could bring massive amounts of PRs. And then it could become very chaotic (it actually already happens that some PRs are lost completely out of sight at some point).

At least for now it's easy to merge when the PR is complete and if it fails for someone we add follow-up fixes. Especially for regular contributors, we know they stay around to fix potential issues and regressions. Maybe @mhilbrunner was a little to quick to merge some things, but in general we are quite strict about new features anyway.

Just in case you guys got that wrong: I'm not angry at mhilbrunner or by the build error itself (that's why I did not even think about creating an issue because I know how things work here usually don't worry). But well it would be nice if every one with merge rights behaves the same way. I mean why do we have PR Review meetings? Of course small fixes can be merged without having to ask others, but when a new feature is introduced or radically changed a more strict behavior would be appreciated.

The merge was fine, and a compiler error in the master branch for a configuration not tested by the CI (we can't tested everything, there are just too many possible combinations) is fine too. It's just the revert which was unnecessary, @Faless or someone else would have provided a fix within a few hours.

But anyway, what's done is done and the new PR should be good to merge :)

@akien-mga especially since we actually don't have support for that configuration we should let first people test if it builds or works with Mono too (at least builds, everything else can be debugged or fixed afterwards and I really only mean bigger changes not small PRs). I mean the mono configuration will become popular at some point, as you can imagine a lot of C# devs could come into Godot once we say officially that C# is now stable. I don't know if continuing to treat C# like a second (or third) citizen should continue to be ok in that sense. People could also assume that C# was only introduced to just take away users from other engines who support it. The personal stand of single ones about C# (and Microsoft) should not be an excuse for not thinking about how to improve the situation. If we put C# as an official supported language on the documentation these kind of critique will just be a logic consequence. I just wanted to get this out before people start to get really pissed off about these things.

The "spyware" is the only way of building Mono, in general a good advice is to not get too personal about software on GitHub

I know it's the only way, and sorry but I do get personal on software that spies on me, violates my rights and is forced upon me.

Building Mono is problematic on multiple Linux distros that's right and known

And that alone shows how much C#/Mono is not a good multi platform choice or at least not ready enough to be considered stable.

we should let first people test if it builds or works with Mono too

Yeah, but that would mean that there are people that are actually willing to do that. and I'm glad you are.
A good idea might be creating a (public) group of Mono-enabled users, who are willing to test, that can be tagged in PRs (at least the one that touches Mono).
Than again there might be cases where even if not touching the modules/mono part other side effects may cause the Mono build to fail.
In the end, I really think the only way of fixing this is by including it in the CI builds, and that C# cannot be considered officially stable until we have that.

I know it's the only way, and sorry but I do get personal on software that spies on me, violates my rights and is forced upon me.

Listen privately I have also my opinion on these things and I share your concern (I am always on Linux and only boot up Windows once every 2-3 month or so privately). But this doesn't matter here as long as it's the only way to use build and use Mono. You are free to completely ignore the existence of Mono but your opinion won't stop people using it.

And that alone shows how much C#/Mono is not a good multi platform choice or at least not ready enough to be considered stable.

If you mean specifically for Godot right now in this moment, you're right else everything else I don't agree. On one side there is our actual non stable Mono support, on the other side there's the reality that Mono is considered a very stable thing by a lot of companies around the world (and not only kids creating games but also developers using it in daily business software development). It's ok to not like it, but saying that it's not a good multi platform choice is a little far away from reality. But I will stop the discussion here about C# and Mono itself, I don't need to convince you to get a little more positive view on this. I don't care really...

Yeah, but that would mean that there are people that are actually willing to do that. and I'm glad you are.
A good idea might be creating a (public) group of Mono-enabled users, who are willing to test, that can be tagged in PRs (at least the one that touches Mono).
Than again there might be cases where even if not touching the modules/mono part other side effects may cause the Mono build to fail.

I honestly think we could find a few Mono users that would be willing to do that. People have often really a wrong picture about C# users just because they don't work on native level directly.

In the end, I really think the only way of fixing this is by including it in the CI builds, and that C# cannot be considered officially stable until we have that.

Maybe, but would not expect to people share that view, if single ones successfully build and use it, CI should not be taken as an status indicator for the general status of the Mono support in Godot. CI can by nature only be a temporary indication not a general one.

This is getting a little offtopic. :)
@Valentactive In general I agree, so mea culpa.
My (maybe flawed) reasoning (wall of text):
For merging:

@Faless and I are basically the networking maintainers. We're doing this in our spare time. We'd both be happy if more people stepped up to help, even if it only was for testing. This is not a breaking change, we agreed on it, CI build fine, I tested it (multiple times, on multiple platforms) and it worked.
Faless wanted me to wait a few more days to merge this to give people a chance during the weekend to test it. As far as I can tell, nobody did.
The PR was open for testing nearly 2 weeks. So I merged it after the weekend.

For reverting:

I read your report that it breaks the Mono build
I had no time to look into it, as I was right on the go to be away from computers for around 1.5-2 days due to IRL
I had in the back of my mind that both faless and neikeq (for Mono) were quite busy currently IRL, so I was not sure if I could expect a fast fix or somebody else would step up to do it
Note Visual Scripting in master is broken for days now, if not weeks. As C# only has a few contributors too, I wasn't certain this would be fixed any faster if faless didn't do it

I didn't want to be the one responsible for breaking Mono on master for possibly such a long time as VS. So I reverted the change.
I should have tested the change on a Mono build, and I should have tried to reach faless to see how fast he would be able to fix it. Learned the lesson, will do so the next time, and will be more hesitant to revert something in the future.
Also please keep in mind that yes I'm new, and yes this was the second merge with a problem from me recently, but I also merged a lot of PRs. Most were fine.
And I would absolutely prefer everything to be merged in PR meetings, but thats just not gonna happen. We're now at 150+ open PRs for weeks, if not months.
Again: mea culpa!

Yes yes, I've been hearing this since ages, C# is multiplatform and many companies use it.
So multiplatform that on Linux (by your own admission) there are many known build problems.
Even getting a simple build or installing the latest SDK is problematic.
So multiplatform that on Unix systems you can't decently handle signals, that companies like Unity decided to make IL2CPP to convert C# code to CPP, that most C# programs can only run on Windows, or only build with MS.Net or only build with Mono (but almost never both) and when you have cross platform tools (e.g. xamarin) they do not work on Linux.
Sounds like a mature multiplatform environment.

@Faless  I really don't want to waste any time on this topic anymore, it doesn't make much sense...but anyway I answered you because you criticized "C#/Mono" and not just "Mono".

Building on Linux is problematic in the same sense like other projects of that sizes. But it also is a problem with single distros and their way to do things. We can't really expect from the guys working on Mono to provide support for all Linux distros that would be insane. Especially since the Linux community has always been very negative about Mono...given that the general market share of Linux is already small on Desktop it's normal that they focus just on a few distros that are known to work.  Then since it's an open source project (and now even more permissive than before) the open source community can help with that if they really want.
You are mixing things up in a way that doesn't make much sense. First of all Mono is only one implementation of the C# language and a default set of libraries that one can use.
If there are problems with signals on Unix systems that is an implementation problem and not C# as a language. We don't use C# in Godot to write system level applications, we bind it to what it's already there in Godot. For consideration about for or against a programming language to be used as a scripting language, one should also consider the use case. For doing what most of game developer do, C# is not a bad candidate.
The fact that Unity decided to develop IL2CPP is none of our business, but I tend to say that they have all the right to do so. They develop a commercial product which makes of C# a very important part in it. It could have come differently they offered also other scripting languages and who know if the bigger part of the community would have used their own JavaScript derivate maybe they would have abandon Mono completely today. But again I don't see anything wrong with it. They try to find ways to get better performance on the platforms they aim to support and if IL2CPP sounds like a solution for them then so be it. The same could be said about the recent work on static typing for GDScript and who knows maybe this will be more attractive for a dev to come up with something similar to compile GDScript to native with the help of LLVM etc. It's ironic how such an open source project can have so many people with a closed mindset.
I just woke up of a very weird dream, It seemed like in that dream I used C# for the past 13 years to do exactly what you said was not possible. In this dream I coded so many applications and they seemed to just work when executing on a different OS. Now back to seriousness and sorry but I use C# since 2005 long before I even knew about Unity and I did that from the start on both Windows and Linux. I agree on Linux the experience has not always been the best, but Mono of today is at a very different state.
You are mixing again things up here. Xamarin was/is a company and offered dedicated stuff for mobile development with C# under the same name. Since it was started by the same guy that originally started Mono (and GNOME btw too, so one that knows a few things about Linux) of course it was totally natural that a part of that development flowed back into the open source Mono stuff. That now even increased since Microsoft bought Xamarin and really a lot of good stuff was put under very permissive open source licenses.
When you start any project in any programming language it's your job to choose wisely which libraries to use if you aim for cross-platform support on the big platforms. Their support for the old "Windows.Forms" for instance was always clearly marked as experimental or not ready or on par with the Windows counterpart. If you start a project in C++ for instance you also choose Qt, GTK+ (or well in that case probably gtkmm) and not MFC.WPF etc. I don't know how much time you used C# (if at all) but I never had big problems to code applications and run them on both Windows and Linux (can't talk about macOS as I never possessed an Apple device). And even less problems when I developed a console applications (yes C# devs do that do).  Maybe a few changes here and there to let it fit better (and make use of some of the Unix specific stuff that one can find in Mono), but honestly what are we talking about? Isn't that the job of a developer to just do some work too in that sense?
Do we need the Xamarin stuff for Godot?? As a scripting language C# has all one can ask. I don't know what people expect from it seriously. It's not like GDScript adds something that C# would not be capable of except the tight integration that GDScript has by nature with Godot.

@mhilbrunner You did not need to justify anything really. Again I did not even have a problem with the status of not building with Mono support. I just shared a random thought while I was in the IRC channel. I made the mistake of writing about what I think would improve the situation here on GitHub for Godot. It must felt like an attack on you, but that was really not my intention (people who know me from IRC should know that I'm really not that kind of guy), it was just a recurring thought that I have since a longer time and it just happened that this little story here lit it up again for me. Maybe my wording here is not the best, I repeat I don't pretend anything, I just shared a thought. Since I'm almost every day in the IRC channel (also if often very silent) I have seen what you have done. It's amazing to see so much dedication, don't worry :D
To both of you Faless and mhilbrunner congrats and thanks for your work you did here, I must have sound really negative so far. Just in case it was not clear I appreciate your work a lot and am happy that Godot has so passionate people in its community. I tend to share from time to time my concerns (and I can't stand when in my opinion something is just not the whole truth) but then I usually turn silent again. And I guess I will be even more silent in future as long as we don't have a clear code of conduct here. One very important aspect for me would also be to not allow public bashing of company x, technology y etc. That's something that belongs in a chatroom not necessary under PRs or Issues on GitHub. It's not very welcoming if popular contributors here feel free to express in certain ways about technologies (or in this case more specifically programming language and its implementation) that is used officially in Godot. And apart from that we should stay on topic (me included to be the first one having failed in it). I initially only wanted to explain why that screenshot was made and shared in the IRC channel and that I did not create an issue on purpose. And later confirm that buiding works again with Mono. My mistake was then to share my general thought about what could be improved here. Lesson learned for me I guess :)

@Valentactive No worries, didn't feel like an attack at all. :) All good.
...I won't get into the C# discussion you both have going. Not going to touch that with a 10ft pole :P