Error compiling ktor with current master

Iḿ trying to compile ktor with the latest master version of this repo and getting the following error:
Could not determine the dependencies of task ':ktor-server:ktor-server-config-yaml:compileKotlinMetadata'.
> Could not resolve all task dependencies for configuration ':ktor-server:ktor-server-config-yaml:metadataCompileClasspath'.
   > Could not resolve net.mamoe.yamlkt:yamlkt:0.13.0.
     Required by:
         project :ktor-server:ktor-server-config-yaml
      > The consumer was configured to find a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'common'. However we cannot choose between the following variants of project :yamlkt:yamlkt:
          - iosArm32ApiElements
          - iosArm64ApiElements
          - iosSimulatorArm64ApiElements
          - iosX64ApiElements
          - jsIrApiElements
          - jsLegacyApiElements
          - jvmApiElements
          - jvmRuntimeElements
          - linuxArm32HfpApiElements
          - linuxArm64ApiElements
          - linuxX64ApiElements
          - macosArm64ApiElements
          - macosX64ApiElements
          - mingwX64ApiElements
          - mingwX86ApiElements
          - tvosArm64ApiElements
          - tvosSimulatorArm64ApiElements
          - tvosX64ApiElements
          - watchosArm32ApiElements
          - watchosArm64ApiElements
          - watchosSimulatorArm64ApiElements
          - watchosX64ApiElements
          - watchosX86ApiElements
        All of them match the consumer attributes:
          - Variant 'iosArm32ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'ios_arm32' but the consumer didn't ask for it
          - Variant 'iosArm64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'ios_arm64' but the consumer didn't ask for it
          - Variant 'iosSimulatorArm64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'ios_simulator_arm64' but the consumer didn't ask for it
          - Variant 'iosX64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'ios_x64' but the consumer didn't ask for it
          - Variant 'jsIrApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'js':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.js.compiler' with value 'ir' but the consumer didn't ask for it
          - Variant 'jsLegacyApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'js':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.js.compiler' with value 'legacy' but the consumer didn't ask for it
          - Variant 'jvmApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares an API of a library, preferably optimized for standard JVMs, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm':
              - Unmatched attribute:
                  - Provides its elements packaged as a jar but the consumer didn't ask for it
          - Variant 'jvmRuntimeElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a runtime of a library, preferably optimized for standard JVMs, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm':
              - Unmatched attribute:
                  - Provides its elements packaged as a jar but the consumer didn't ask for it
          - Variant 'linuxArm32HfpApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'linux_arm32_hfp' but the consumer didn't ask for it
          - Variant 'linuxArm64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'linux_arm64' but the consumer didn't ask for it
          - Variant 'linuxX64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'linux_x64' but the consumer didn't ask for it
          - Variant 'macosArm64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'macos_arm64' but the consumer didn't ask for it
          - Variant 'macosX64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'macos_x64' but the consumer didn't ask for it
          - Variant 'mingwX64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'mingw_x64' but the consumer didn't ask for it
          - Variant 'mingwX86ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attributes:
                  - Provides attribute 'artifactType' with value 'org.jetbrains.kotlin.klib' but the consumer didn't ask for it
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'mingw_x86' but the consumer didn't ask for it
          - Variant 'tvosArm64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'tvos_arm64' but the consumer didn't ask for it
          - Variant 'tvosSimulatorArm64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'tvos_simulator_arm64' but the consumer didn't ask for it
          - Variant 'tvosX64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'tvos_x64' but the consumer didn't ask for it
          - Variant 'watchosArm32ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'watchos_arm32' but the consumer didn't ask for it
          - Variant 'watchosArm64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'watchos_arm64' but the consumer didn't ask for it
          - Variant 'watchosSimulatorArm64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'watchos_simulator_arm64' but the consumer didn't ask for it
          - Variant 'watchosX64ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'watchos_x64' but the consumer didn't ask for it
          - Variant 'watchosX86ApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Unmatched attribute:
                  - Provides attribute 'org.jetbrains.kotlin.native.target' with value 'watchos_x86' but the consumer didn't ask for it
        The following variants were also considered but didn't match the requested attributes:
          - Variant 'iosArm32CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'iosArm32MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'iosArm64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'iosArm64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'iosSimulatorArm64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'iosSimulatorArm64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'iosX64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'iosX64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'jsIrRuntimeElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'js':
              - Incompatible because this component declares a usage of 'kotlin-runtime' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'jsLegacyRuntimeElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'js':
              - Incompatible because this component declares a usage of 'kotlin-runtime' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'linuxArm32HfpCInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'linuxArm32HfpMetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'linuxArm64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'linuxArm64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'linuxX64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'linuxX64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'macosArm64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'macosArm64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'macosX64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'macosX64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'metadataApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'common':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'mingwX64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'mingwX64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'mingwX86CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'mingwX86MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'tvosArm64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'tvosArm64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'tvosSimulatorArm64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'tvosSimulatorArm64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'tvosX64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'tvosX64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'watchosArm32CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'watchosArm32MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'watchosArm64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'watchosArm64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'watchosSimulatorArm64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'watchosSimulatorArm64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'watchosX64CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'watchosX64MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'watchosX86CInteropApiElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-cinterop' of a component and the consumer needed a usage of 'kotlin-api' of a component
          - Variant 'watchosX86MetadataElements' capability net.mamoe.yamlkt:yamlkt:0.13.0 declares a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'native':
              - Incompatible because this component declares a usage of 'kotlin-metadata' of a component and the consumer needed a usage of 'kotlin-api' of a component

Addding the following to gradle.properties seems to get rid of this first error:
kotlin.mpp.enableCompatibilityMetadataVariant=true
kotlin.mpp.enableCInteropCommonization=true

I start getting another error, though, but this one is probably on ktor's side:
> Task :ktor-server:ktor-server-config-yaml:compileJvmAndNixMainKotlinMetadata FAILED
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:7:8 Unresolved reference: net
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:37:23 Unresolved reference: YamlMap
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:44:15 Unresolved reference: YamlMap
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:56:51 Cannot infer a type for this parameter. Please specify it explicitly.
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:56:80 Unresolved reference: YamlMap
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:59:16 Unresolved reference: YamlLiteral
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:59:50 Unresolved reference: content
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:61:16 Unresolved reference: YamlList
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:62:36 Unresolved reference: content
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:62:50 Cannot infer a type for this parameter. Please specify it explicitly.
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:63:76 Unresolved reference: it
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:77:39 Cannot infer a type for this parameter. Please specify it explicitly.
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:78:28 Unresolved reference: YamlMap
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:85:51 Cannot infer a type for this parameter. Please specify it explicitly.
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:86:28 Unresolved reference: YamlMap
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:88:44 Unresolved reference: YamlList
e: file:///home/brunojcm/git/ktor/ktor-server/ktor-server-config-yaml/jvmAndNix/src/io/ktor/server/config/yaml/YamlConfig.kt:89:22 Overload resolution ambiguity:

I suspect it could be the issue of the composite build. Can you try ./gradlew publishToMavenLocal and then import yamlkt from mavenLocal()?

I tried that as well and got the same error. Not sure if I'm doing something wrong, or it might be some mismatch since the version in master doesn't have the -SNAPSHOT suffix.

I think I know what might be happening... First I published from inside IDEA, so that "if (idea)" in the build was probably preventing the native targets to be built and published.
Now I'm doing the publish from a separate console, then I can see all of those:
net/mamoe/yamlkt/yamlkt
net/mamoe/yamlkt/yamlkt-js
net/mamoe/yamlkt/yamlkt-jvm
net/mamoe/yamlkt/yamlkt-linuxarm32hfp
net/mamoe/yamlkt/yamlkt-linuxarm64
net/mamoe/yamlkt/yamlkt-linuxx64
net/mamoe/yamlkt/yamlkt-mingwx64
net/mamoe/yamlkt/yamlkt-mingwx86

Just looking at those, I realized... I'm not in an Apple device, so maybe by not building darwin archs I'm breaking the commonizer.

I suspect it could be the issue of the composite build. Can you try ./gradlew publishToMavenLocal and then import yamlkt from mavenLocal()?

You were right. I cleaned my local repo and changed the master version to 0.13.0-SNAPSHOT, then published again, and I could make ktor build locally.
I still needed the changes in https://github.com/Him188/yamlkt/pull/62 to allow consumers to know what are the supported platforms.
Are you planning a new release soon? Iḿ trying to expedite https://youtrack.jetbrains.com/issue/KTOR-5753 and a new yamlkt will certainly be needed as 0.12.0 does not support all the archs needed but ktor.

Yes, I've been trying to release 0.13.0 for some time, but I got OOM from GitHub Actions for Windows.
Luckily I have both Apple and Windows machines, so I can do it locally. Hopefully I can find some time and release 0.13.0 today.

Yes, I've been trying to release 0.13.0 for some time, but I got OOM from GitHub Actions for Windows.

Is this OS-level OOM or Gradle crashing? I got a few of those here as well on linux, then just retried and they were gone.
Maybe org.gradle.jvmargs=-Xmx2g can help if it's just Gradle.

Luckily I have both Apple and Windows machines, so I can do it locally. Hopefully I can find some time and release 0.13.0 today.

That would be nice!
I think we can close this issue, I can build ktor now.

It was Kotlin compiler OOM. Log from CI:

Execution failed for task ':yamlkt:compileTestKotlinMingwX64'.

https://github.com/Him188/yamlkt/actions/runs/4707552299/jobs/8521297790
I don't know if I enabled parallel task execution for yamlkt, I would disable it if so.
From KT-47522, I will try org.gradle.jvmargs=-Dkotlin.daemon.jvm.options="-Xmx2g".


source control view full commit message

When in the Source Control tab you can see a list of "outgoing" commits.
this is very useful but, it would be nice to be able to see the entire commit message.
simply by just hovering on the commit, it should show the entire commit message.

/duplicate and being addressed in PR https://github.com/microsoft/vscode/pull/202262

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


wlx-overlay-s: 0.4.2 -> 0.4.3

Description of changes
https://github.com/galister/wlx-overlay-s/tree/v0.4.3
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

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

1 package built:

wlx-overlay-s


Add Knock: permanent branch addition

This adds a branch of this project that should remain unmerged and can be used to practice adding Knock into the example app, both by Knock users and new Knock team members.
I'll close this PR and rename/maybe protect the branch once I get y'alls thoughts on how this looks.

That's a really good question and totally up for debate. I made it extremely clear, I guess because 1) it's easier to pull back from what we have here to something more vague, and 2) this is not engineering onboarding.
I think however this first round goes we'll probably want to amend it based on their feedback. Maybe it's better to strip it down more from this and if it ends up being too hard or confusing, add instructions in for the next set of hires. I was a little worried about the thing you're bringing up where this is a built out, unfamiliar app, and Knock is also unfamiliar, so hand-holding would be fine for them to get the hang of it. Maybe one thing we could do is be explicit about the "level 1" requirements but less instructive about the rest (or vice versa)?

This is a really interesting idea and I'm curious to hear feedback from new hires and customers who try this.
Some questions:

when would a customer want to practice adding Knock into our example app? would they prefer to just add it directly into their own app rather than add it 2x?
how do you envision us letting customers and new hires know this branch exists? How should they interact with this branch? E.g. should they make a branch off of this branch? should they view it in the github compare view?
how do we make sure this branch gets kept up to date as we update main? main is probably updated infrequently, but that makes it much more likely the updater forgets to update this branch as well

when would a customer want to practice adding Knock into our example app? would they prefer to just add it directly into their own app rather than add it 2x?

I imagine this happens more when a potential customer is evaluating Knock, or a potential hire is trying to understand our product.

how do you envision us letting customers and new hires know this branch exists? How should they interact with this branch? E.g. should they make a branch off of this branch? should they view it in the github compare view?

I'm imagining this being a totally local project for anyone who uses it and restrict pushing to it. So if they don't make their own branch, they would just switch to using this one locally and not make any upstream changes. In terms of how to let them know it exists, I think it's most effective for new hires so I don't feel like we need to widely publicize it, but i was going to add a message about it in the README of main.

how do we make sure this branch gets kept up to date as we update main? main is probably updated infrequently, but that makes it much more likely the updater forgets to update this branch as well

Good question. I think the best answer I have is making a note in the pr template of this project to port any changes to main to this branch as well, but open to ideas!

Yeah, those are good points. One option is to progressively give more detail if the person onboarding wants it, so the first readme just has the high level goals and then we have a additional linked pages with more detailed instructions ("If you're stuck, here are some hints…").
@connorlindsey, do you think I should take out the pointers throughout the files too? or make them less explicit? I shaved down the instructions entirely and I'll put them elsewhere and link to it here when it's ready.

@meryldakin I think we should leave them. Without them, I think it'll be a pain trying to find the right places to add the Knock calls.
Also, what do you think about linking the docs from the readme and pushing users there? I think an important part of the onboarding exercise is testing our docs/in-app onboarding.

@connorlindsey @cjbell made a couple of changes here after chatting with chris about it:

Removed the toggle_muted action to remove complexity in setting preferences
Removed the slack integration
Remove mentions of segment
Added instructions to inline-identify when triggering workflows

This should make the project more streamlined, lmk what you think!

Closing because we don't intend to merge this branch.


is all function in VssDataBase threadsafe?

some query is not protected by mutex:
https://github.com/eclipse/kuksa.val/blob/761420934fd7cf3497032565a21c937f35c7c0d3/src/VssDatabase.cpp#L111

Probably not :) Should consider this a bug, secure every access to the jsoncons main tree.
I would assume multiple reads are not a problem, so for performance in the longterm probably write should lock the whole tree for everyone, and read should only lock it for write

val-server seems stable and is in maintenace mode anyway. Closing


[Fix bug] add file extension when loading commonvoice audio file

In response to this issue #1125

Thanks for the quick reply.
Unfortunately, it does not work on Ubuntu because os.path.join adds the directory separator '/'  and therefore builds path like :
/opt/Datasets/CommonVoice/fr_79h_2019-02-25/fr/clips/2760b7263452ca460dd0ad387bbc091a7ef0eb5e5b28d19742047ed438857c123f47834a24b3087f2e9eb25ec3f9b506ff61ad60fb22b00e4aa3125e5920374c/.mp3
see the last '/.mp3'
Instead of
filename = os.path.join(path, folder_audio, fileid, ext_audio)

what about
filename = os.path.join(path, folder_audio, fileid + ext_audio)

Hi @jeremyfix , for the moment I can't reproduce it locally
I have this issue 'torchaudio C++ extension is not available.'
But I will make a change and see if it makes the cicd pipeline green again.
thanks.

@AzizCode92 I tried to check why some unittest failed and I'm wondering if the content of the tsv file did not change
Indeed, if I look at the first lines of fr_79h_2019-02-25/fr/train.tsv
client_id       path    sentence        up_votes        down_votes      age     gender  accent
a2e8e1e1cc74d08c92a53d7b9ff84e077eb90410edd85b8882f16fd037cecfcb6a19413c6c63ce6458cfea9579878fa91cef18343441c601cae0597a4b0d3144        89e67e7682b36786a0b4b4022c4d42090c86edd96c78c12d30088e62522b8fe466ea4912e6a1055dfb91b296a0743e0a2bbe16cebac98ee5349e3e8262cb9329        Or sur ce point nous n’avons aucune réponse de votre part.      2       0       twenties        male    france
a2e8e1e1cc74d08c92a53d7b9ff84e077eb90410edd85b8882f16fd037cecfcb6a19413c6c63ce6458cfea9579878fa91cef18343441c601cae0597a4b0d3144        87d71819a26179e93acfee149d0b21b7bf5e926e367d80b2b3792d45f46e04853a514945783ff764c1fc237b4eb0ee2b0a7a7cbd395acbdfcfa9d76a6e199bbd        Monsieur de La Verpillière, laissez parler le ministre  2       0       twenties        male    france

Notice the second column, which holds the path if I'm not wrong, does not contain any extension.
If I now look at your unitest, you provide a wav extension in the second column containing the path to the clip.
Therefore, a possible fix could be to remove the "wav" extension in the  _train_csv_contents list.
I then also think there is a need to adapt the audio_path to add the COMMONVOICE._ext_audio extension

@AzizCode92 If we face the same os.path.join issue as before, I believe the line
audio_path = os.path.join(audio_base_path, content[1], COMMONVOICE._ext_audio)

should be changed to
audio_path = os.path.join(audio_base_path, content[1] + COMMONVOICE._ext_audio)

@jeremyfix yes, you're right. Good catch.
thanks

@AzizCode92
This time, the TestCommonVoice passed but the cicd fails because of
torchaudio_unittest/datasets/utils_test.py::TestIterator::test_bg_iterator

Too long with no output (exceeded 10m0s): context deadline exceeded

yes, the previous tests related to commonvoice were passed.
I will try to restart the pipeline again.

@jeremyfix
Couldn't restart it manually, so i did a new commit to launch it again, let's wait and see.

@AzizCode92  apparently, still the same pipeline issue.

@AzizCode92 , @jeremyfix
Thanks for working on this. However, the current approach does not seem to be the right approach.
The fundamental issue is that different language has different format for the path value.
For English ver 5.1, the extension is included, and this is how we tested the implementation.
$ head -3 CommonVoice/cv-corpus-5.1-2020-06-22/en/train.tsv
client_id	path	sentence	up_votes	down_votes	age	gender	accent	locale	segment
f1f6414c04e74453065e1b7fc1639c6f728dc03ed9589034b8531d8c7d8b994f223f2b79d5fcc42a2b7b19f8cbca5af08f31d47a554ddd682df04ba62caaaa56	common_voice_en_20009651.mp3	"It just didn't seem fair."	2	1				en
f1f6414c04e74453065e1b7fc1639c6f728dc03ed9589034b8531d8c7d8b994f223f2b79d5fcc42a2b7b19f8cbca5af08f31d47a554ddd682df04ba62caaaa56	common_voice_en_20009653.mp3	The anticipated synergies of the two modes of transportation were entirely absent.	2	0				en

But looks like French version does not have the extension, as part of the path.
So we need to do some sort of file existence check, with or without additional extension.
So instead of modifying the exiting test, we need to add a new test samples, then make the implementation handle both cases.
I would extract the construction of mock test dataset (what is done in setUpClass, right now) into a helper function, then add a new helper function of mock test dataset for French case, then reuse the test cases.
Also this make me wonder, is there another format than mp3?

And you would like to run test locally, then you can build it with
python setup.py develop

Update:
Commonvoice dataset tests are green but it seems that test_bg_iterator  is having a timeout error.
torchaudio_unittest/datasets/utils_test.py::TestIterator::test_bg_iterator

Too long with no output (exceeded 10m0s): context deadline exceeded

Update:
Commonvoice dataset tests are green but it seems that test_bg_iterator is having a timeout error.
torchaudio_unittest/datasets/utils_test.py::TestIterator::test_bg_iterator

Too long with no output (exceeded 10m0s): context deadline exceeded

So this is a bug in bg_iterator. Seems like it does not propagate error from the background job.

@mthrok, thanks for your feedback.
I committed some modification to the code to improve it further. It seems that there are some problem when collecting dependencies of macos_conda_py3.7. That's why the build is failing now.

@mthrok, thank you for your feedback.
I committed some modification to the code to improve it further. It seems that there are some problem when collecting dependencies of macos_conda_py3.7. That's why the build is failing now.

Yeah, build workflow often fails when upstream PyTorch nightly package has an issue.

@AzizCode92  Thank you for having fixed this !


Cannot add children

I'm trying to add my 2 kids (< 13 yo), but when I click the "save" button nothing happens.
(btw I'm a mentor from CoderDojo Milano - Italy)

@DanielBrierton This should be fixed, am i right ?

I believe so @Wardormeur.
@lordkada Sorry, this managed to fly under our radar. Did you manage to get your kids added to your account since? Really sorry for the delay in getting back to you.

yes, it worked. Thanks!


fix: remove generation of expose:_splunkd_data stanza in web.conf

This commit removes generation of
[expose:_splunkd_data]
pattern = data/*
methods = GET

for web.conf.
Closes #303.

Codecov Report

Merging #395 (a187e7a) into main (067c3b8) will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #395      +/-   ##
==========================================
- Coverage   78.98%   78.95%   -0.03%
==========================================
  Files          27       27
  Lines        1732     1730       -2
==========================================
- Hits         1368     1366       -2
  Misses        364      364

Impacted Files
Coverage Δ

...k_add_on_ucc_framework/uccrestbuilder/rest_conf.py
90.90% <ø> (-0.76%)
:arrow_down:

Continue to review full report at Codecov.

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

@arys-splunk Please confirm if this does not cause an issue with fetching indexes in index dropdown in UI since that depends on the data endpoint.

@arys-splunk Please confirm if this does not cause an issue with fetching indexes in index dropdown in UI since that depends on the data endpoint.

I tested it with the add-on that has index fetching component in UI and it works without that stanza in web.conf.

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

v5.10.1
GitHub release

Your semantic-release bot :package::rocket:


Add MPW CI as a badge

https://github.com/The-OpenROAD-Project/OpenLane/blob/master/README.md should have a badge pointing to the MPW CI's created by Vijayan.
Prompt
A clear and concise description of what shortcoming you feel OpenLane has.
Proposal
A clear and concise description of what you want to happen.

Why.

@donn Tim had asked me to create improved CI to help avoid OpenLane needing to use a release branch but instead work from the head. This can be one step in that direction. We could start with just one set of the MPW designs and set them to be required to pass when a PR is made.

I'm not against the idea, but we need to discuss it first.


Feature Request: SASS for Meteor.js

Could you please provide an official SASS package on https://atmospherejs.com/materialize ?
Users could then override variables by creating (for example) a file named client/materialize-override.scss and still get updates...
You could make use of: https://atmospherejs.com/fourseven/scss
Also check: https://atmospherejs.com/grigio/materialize-sass

:+1
I use fourseven's scss (libsass) package with materialise.
Its less then ideal atm because the atmosphere materialize release does not include the scss files. It would be great to have scss files in the package.
I agree a seperate atmosphere package would be a more elegant design.

Yes, as it's not possible to change the primary and secondary color variables in the redish/greenish current package its only use is for testing, so that's not very useful. A package with the latests scss files and a way to override _varriables.scss would be SO cool...

:+1:

Same Here, it would be great !
Can help contribute if someone gives me a clue of where to start / look at. (Where is the repository or the folder for materialize:materialize meteor package ?)
It also breaks all the materialize sass mixins and functions.

:+1::

:+1:

:+1:

:thumbsup:

+1

+1

+1

@Chun-Yang Thanks. I can't use your package though. Reasons are:
Using https://atmospherejs.com/materialize makes sense as it will always have the latest materialize release. Your package will soon be out of date unless you continually maintain it. You should use a submodule to upstream instead. Or; you could simply change your package so that it contains only the upstream sass files. That means your package would be used in conjunction with the https://atmospherejs.com/materialize package.

@dcworldwide Thank you for your feedback, I will update my package and use submodule. I do not think using materialize smart package is a good choice since it will import compiled css and js. Again, thank you.

OK i agree with you. In that case your package will work great

Thanks @Chun-Yang I'll have a look at your package!

:+1:

@Chun-Yang nice package, working great for me! :+1:

:+1:

:+1: This is a must

+1

Are we any closer to getting SASS support on this official Materialize library for Meteor.js?

+1

+1

Someone has already made a package for this.
https://atmospherejs.com/poetic/materialize-scss

+1

In Meteor 1.2 you could make use of @import "{}/file.scss" to allow users to override variables...
Check: https://quip.com/RXFlAk9Rc2xI
The less and stylus packages now support cross-package imports! If you specify a file like
@import "{package}/file.less" (with the curly braces), it will load the file from that package. Use @import "{}/file.less" to load a file from your app.

That's a great addition to Meteor — but I don't think it solves anything in this case as the package doesn't actually contain the SASS files, just a single CSS output. Or am I missing something?

@artshostak yes this is the case now, but they could make one with sass and use the new feature to allow us to customize things :)

There is a sass materialize package for meteor already. I recommend using
it. Search atmosphere for it
On 31 Aug 2015 21:52, "boustanihani"<EMAIL_ADDRESS>wrote:

@artshostak https://github.com/artshostak yes this is the case now, but
they could make one with sass and use the new feature to allow us to
customize things :)
—
Reply to this email directly or view it on GitHub
https://github.com/Dogfalo/materialize/issues/1018#issuecomment-136464222
.

I know, we would like to have an official one :bowtie:

It would be really great to have a Meteor package where you could specify variables like colors and so on.

There is one. You're using the wrong package
On 20 Oct 2015 11:42 a.m., "Mitar"<EMAIL_ADDRESS>wrote:

It would be really great to have a Meteor package where you could specify
variables like colors and so on.
—
Reply to this email directly or view it on GitHub
https://github.com/Dogfalo/materialize/issues/1018#issuecomment-149478949
.

You mean poetic/materialize-scss? The issue is that it is not recent. See this ticket: https://github.com/poetic/meteor-materialize-sass/issues/10
This is exactly the situation why there is this ticket and why 3rd party package is not enough. Because 3rd party package has to fix some issues to work with Meteor which are not merged upstream it is complicated to maintain it.

Ah. Ok. I haven't upgraded the project I was using it on to 1.2 yet
On 20 Oct 2015 11:57 a.m., "Mitar"<EMAIL_ADDRESS>wrote:

You mean poetic/materialize-scss
https://github.com/poetic/meteor-materialize-sass/? The issue is that
it is not recent. See this ticket: poetic/meteor-materialize-sass#10
https://github.com/poetic/meteor-materialize-sass/issues/10
This is exactly the situation why there is this ticket and why 3rd party
package is not enough. Because 3rd party package has to fix some issues to
work with Meteor which are not merged upstream it is complicated to
maintain it.
—
Reply to this email directly or view it on GitHub
https://github.com/Dogfalo/materialize/issues/1018#issuecomment-149482955
.

:+1:

:+1:

Yes please, we should be able to have sass files to customize variables, and we could also remove unused imports in sass. Please implement that :D Don't hesitate on taking the code of unofficials plugins...

There's another package that offers sass for materialise as mentioned above
I believe
On 7 Jun 2016 00:23, "NitroBAY"<EMAIL_ADDRESS>wrote:

Yes please, we should be able to have sass files to customize variables,
and we could also remove unused imports in sass. Please implement that :D
Don't hesitate on taking the code of unofficials plugins...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Dogfalo/materialize/issues/1018#issuecomment-224092614,
or mute the thread
https://github.com/notifications/unsubscribe/AC8oXwIKihX6So5KWjsgsJXkK4fNkaOkks5qJI--gaJpZM4D1_bm
.

That I use, but the official one have to include sass support

👍

5afb6000a seems to fix the problem :D

So I tried to use it as poetic materialize but it wasn't  working because package.js forgot to import a file so I fix package.js in #3280. Once the fork merged, all should working like with poetic, I test it.

Still need to add a few lines to the readme on how to use it in a meteor app, but other than that, the package should be working with Sass for the next release!

Yeah, as #3280 is forked now you just need to fix #3281 and it should be great. Thanks @Dogfalo

@Dogfalo so what's going on with #3281 bug ?

Could anyone explain how to configure custom colors with Meteor? So how to set SCSS variables using Meteor?

I figured it out. I changed in package.js of this package the addFiles line to:
api.addFiles(scssFiles, 'client', {isImport: true});

And then I just create a SCSS file in my app and do:
@import "{materialize:materialize}/sass/components/color";
$primary-color: color("blue", "lighten-2");

@import "{materialize:materialize}/sass/materialize";

Already been added!

@Dogfalo please it seems that the atmosphere package is somewhat broken as sass import only works if one install materialize from a local version fetched from the repo.

This was fixed in the newest version

Having trouble overriding scss vars using materialize:materialize 0.98.2
I added this to my main.scss:
@import "{materialize:materialize}/sass/components/_color.scss";
$primary-color: color("blue", "lighten-2");
// import main scss file
@import "{materialize:materialize}/sass/materialize.scss";
But is doesn't seem to do anything, not even any errors.


Use consistent iconography

Kind of issue

[ ] Feature
[ ] Bug
[x] Design
[ ] Other, namely:

Description
Currently, the iconography is a bit inconsistent, the icons for ordering were custom made for the old website; the dark/light/system mode icons are taken from Feather Icons (the system one is custom-made based on Feather Icons icons); and for #47 we need a "legal" icon which Feather Icon's does not seem to have.
In the table below I aim to create an overview of some icon packs that I'm familiar with and whether or not they have each icon. The most obvious finding, it doesn't look like any icon pack provides "sort by color" or "sort by relevance" :sweat:

Icons
Font Awesome
Feather Icons
iconsvg
Heroicons
Phosphor Icons
System UIcons

Light mode
Yes
Yes
Yes
Yes
Yes
No

Dark mode
Yes
Yes
Yes
Yes
Yes
No

Light/Dark mode
No?
No?
No?
No?
No?
No

External link
Yes
Yes
Yes
Yes
Yes?
Yes?

Legal
Yes
No
No
Yes
No
No

Sort alphabetically
Yes
No
No
No?
No?
No?

Sort by color
No?
No
No
No
No
No

Sort by relevance
No?
No
No
No
No
No

How about just sticking with custom made icons?
Assuming that we're all skilled enough to create SVG icons ourselves, we could as well create a custom legal/sort by color/etc. icon.

That works as well :+1:

Can I throw Material Design Icons into the mix here as well?
Themes

Legal

Sorting

Other

There is also the new Google Fonts icons, which seems to be different to the Material icons... 🤔

Is this really that important? The icons looks fine, and is not as if we are sourcing them from their origins, we have the local svg code for each one.
Maybe since I don't have design experience I don't see something in the icons that looks bad to a more trained eye or something, but the site looks fine to me.
Changing the icons is more work, so, does it really matter?

Due to be closed in 1 week's time unless @simple-icons/maintainers express interest in this moving forward.


How do you add delays in the response

For example , the code below I would like to use a delay property to simulate a slow response
fetchMocker.mockIf(/http:\/\/[^/]+:?\d*\/api\/slow/, async (req) =>   {       if (req.method === 'DELETE') {         return {           body: '{"data":{"id":"a12345"}}',           headers: {             'X-Some-Response-Header': 'Some header value',           },           **delay: 2000,**         }       }   } )
I am unable to find anything in the docs related to this.

I think you should be able to use a sleep before returning, right?  This is the function I use to be able to await sleep(500) for example:
export function sleep(ms: number): Promise<void> {
  return new Promise((resolve) => setTimeout(resolve, ms));
}


[AVM Question/Feedback]: dns_servers should be applied in the same order they were passed to the module

Check for previous/existing GitHub issues

[x] I have checked for previous/existing GitHub issues

Description
Hi,
The ordering of dns servers configured on a vnet does matter (see https://learn.microsoft.com/en-us/azure/virtual-network/manage-virtual-network#change-dns-servers ), so it would be better if the module could keep the order in which the dns server list is passed to the module.
I guess that would require changing the dns_servers variable type from a set to a list, maybe with distinct() to prevent duplicates.
Thanks :)

@Cyr-Az I think distinct would break the ordering, but we could add validation to the input variable. We are happy to accept a PR if you need this soon.


Webcord crashed, now crashes on startup.

Acknowledgements

[X] I have checked that there is no other issue describing the same or
similar problem that I currently have, regardless if it has been
closed or open.

[X] This bug affects Discord website.

[ ] This issue is confirmed to be reproducible when WebCord is packaged
on at least all three latest supported Electron major releases.

[ ] This issue is reproducible in Chrome, Chromium or any
Chromium-based browser, e.g Brave or Edge (please write in
Additional Context which browser you have used if it is neither
Chrome nor unmodified Chromium).

[ ] There are no fixes done to master which resolves this issue.

[ ] My issue describes one of the unstable and/or not fully implemented
features.

[ ] I have found a workaround to mitigate or temporarily fix this issue
in affected releases (please write it in Additional context section
below).

Operating System / Platform
🐧 Linux
Operating system architecture
x64 (64-bit Intel/AMD)
Electron version
v29.1.1-1
Application version
v4.8.0-2
Bug description
Recently webcord crashed mid use (while I was in a call, looking at someone stream) and ever since it hasn't worked.  It crashes on startup with the following dump:

/usr/lib/electron29/electron[5630]: ../../third_party/electron_node/src/node_builtins.cc:328:MaybeLocal node::builtins::BuiltinLoader::LookupAndCompileInternal(Local, const char *, std::vector<Local> *, Realm *): Assertion `(this) == (optional_realm->env()->builtin_loader())' failed.
1: 0x56497ab19d46  [/usr/lib/electron29/electron /usr/lib/webcord]
2: 0x56497ab199cd  [/usr/lib/electron29/electron /usr/lib/webcord]
3: 0x56497aaf6e98  [/usr/lib/electron29/electron /usr/lib/webcord]
4: 0x5649697b9471  [/usr/lib/electron29/electron /usr/lib/webcord]
5: 0x5649697b5f75  [/usr/lib/electron29/electron /usr/lib/webcord]
6: 0x56497abf11a2  [/usr/lib/electron29/electron /usr/lib/webcord]
7: 0x56496ea70fc7  [/usr/lib/electron29/electron /usr/lib/webcord]
Received signal 6
#0 0x56497313ea13 (/usr/lib/electron29/electron+0xe66da12)
#1 0x56497311a354 (/usr/lib/electron29/electron+0xe649353)
#2 0x56497313e32b (/usr/lib/electron29/electron+0xe66d32a)
#3 0x7f4760070770 (/usr/lib/libc.so.6+0x4076f)
#4 0x7f47600c132c (/usr/lib/libc.so.6+0x9132b)
#5 0x7f47600706c8 gsignal
#6 0x7f47600584b8 abort
#7 0x56497ab19d55 (/usr/lib/electron29/electron+0x16048d54)
#8 0x56497ab199cd (/usr/lib/electron29/electron+0x160489cc)
#9 0x56497aaf6e98 (/usr/lib/electron29/electron+0x16025e97)
#10 0x5649697b9471 (/usr/lib/electron29/electron+0x4ce8470)
#11 0x5649697b5f75 (/usr/lib/electron29/electron+0x4ce4f74)
#12 0x56497abf11a2 (/usr/lib/electron29/electron+0x161201a1)
#13 0x56496ea70fc7 (/usr/lib/electron29/electron+0x9f9ffc6)
r8:<PHONE_NUMBER>000000  r9:<PHONE_NUMBER>000001 r10:<PHONE_NUMBER>000008 r11:<PHONE_NUMBER>000246
r12: 0000380c00098000 r13:<PHONE_NUMBER>000006 r14: 00007f476020d6a0 r15: 0000380c003a0518
di:<PHONE_NUMBER>0015fe  si:<PHONE_NUMBER>0015fe  bp: 00007f475c93c940  bx:<PHONE_NUMBER>0015fe
dx:<PHONE_NUMBER>000006  ax:<PHONE_NUMBER>000000  cx: 00007f47600c132c  sp: 00007ffff0774190
ip: 00007f47600c132c efl:<PHONE_NUMBER>000246 cgf: 002b000000000033 erf:<PHONE_NUMBER>000000
trp:<PHONE_NUMBER>000000 msk:<PHONE_NUMBER>000000 cr2:<PHONE_NUMBER>000000
[end of stack trace]
zsh: IOT instruction (core dumped)  webcord

Reinstalling doesn't resolve the issue; neither does reinstalling electron29. Trying to run electron29 itself causes the same issue, though presumably webcord is at fault since it crashing caused this. Neither of the two has had an update between it functioning and it not.
Additional context
My system uses:

Manjaro linux KDE 6.6.19-1
Window system X11
KDE Plasma 5.27.10

Webcord was, I believe, running on a Nvidia RTX 4060 laptop. I also have a 7840HS iGPU.

also have this problem :| 7940hs

since

I've

Reinstalling doesn't resolve the issue; neither does reinstalling electron29. Trying to run electron29 itself causes the same issue, though presumably webcord is at fault since it crashing caused this. Neither of the two has had an update between it functioning and it not.

I've found the only thing that fixes it is clearing out the cache for the app in your user directory. Buuuuuut that's only temporary, because after you open it back up, sign back in, then close it again, you come across the same issue.


Enable sysvsem extension

Trying out frankenphp and get this error:
Semaphore extension (sysvsem) is required.

Caused by the default Lock factory in Symfony 6.3.

See https://github.com/dunglas/frankenphp/pull/203


Suggest ALL-UPPER-CASE candidates for ALL-UPPER-CASE target word

Tweak for https://github.com/kamykn/spelunker.vim/issues/67.

Also fixed all word replace (ZL, ZC) failed after UPPERCASELetters.
Example
Replace Spll -> Spell:

Original (Wrong) Word
All-Replace w/ Bug
All-Replace w/ Bug Fix
Remarks

SPLSpll
(no change)
SPLSpell
It had expected no CAPITAL letters come before the word.

SplSpll
SplSpell
SplSpell

splSpll
splSpell
splSpell

splspll
(no change)
(no change)
Not word beginning.

Replace spll -> spell

Original (Wrong) Word
All-Replace w/ Bug
All-Replace w/ Bug Fix
Remarks

spll
spell
spell

spllSPL
spellSPL
sepllSPL

Spellspll
Spellspell
(no change)
Not word beginning. Original ver. had replaced wrongly.

splspll
splspell
(no change)
Not word beginning. Original ver. had replaced wrongly.

SPLspll
(no change)
(no change)
Not word beginning.


FriendFeed shut down

FriendFeed shut down on April 2015, makes no sense to keep it in the sharing bar.

Thanks for the heads up, indeed it shall be removed


(afputils) Any chance of adding MGA support?

Been trying to look around to see if any there are any resources/tools/information in regards to extract the various graphics types used in Metal Gear Arcade until the AFP file format but have yielded 0 results thus far. The game doesn't have any IFS files included with it and instead includes solely an 'AFP' folder which contains both various .afp and .xml files. I will upload the folder here for anyone interested in looking into it.
Example of the errors seen when trying to 'print' these AFP files. raise Exception("Invalid bits set in feature mask!") Exception: Invalid bits set in feature mask!  also when trying to use the list option it leads to no output.
https://drive.google.com/file/d/1U8jymes0f0hdHElsfdX3ICvZSTWafXuB/view

I had a look and it appears the game doesn't even care about the flag bit that is set on all the files. Possibly it is a version incompatibility flag. I pushed an update to ignore it and I can dump out the bytecode and textures of all the MGA files now. However, it looks like the game was coded similarly to BishiBashi, where the AFPs are not just movies but actual interactive flash files. My bytecode engine does not have support for the majority of what it needs to render nor does it have a place to run interactivity so there's likely not much you can render out of the animations. However, textures and such are available and should even be re-packable.

Note that the XML files are simply binxml properties, presumably used by various AFP files. You can decode them using binutils but they don't yield much interesting info aside from configuration data.

Closing this as I don't think there's going to be much more development on MGA. If you find a bug in texture decoding/encoding feel free to open a new bug.


feat(markdown-to-ast): update to remark-parse@9

fix #717
TODO

[ ] Review snapshot diffs

Expected failed test results: https://github.com/textlint/textlint/runs/2561863141?check_suite_focus=true

Updating snapshots https://github.com/textlint/textlint/pull/767/commits/fe7c07580046a13cddcfcc675c5faf2c7adc05d1
We need to review it.


Unable to find archetypes

Hi!
 When I create new content, I encounter the warning:
ERROR (date and time) Unable to find archetypes directory for theme "cocoa-eh"
I understand that archetypes are somewhat like templates for metadata, but I don't think I have any need to use them. Is there any way I can suppress this error? Sorry about this not necessarily being theme-specific. :wolf:

Hi ! Thanks you for your issue !
I thought that archetypes were optionnals, but in fact, no. I will create a
post template too to have a useful archetypes.
Le 29 Mar. 2017 04:47, "Michael Noronha"<EMAIL_ADDRESS>a
écrit :

Hi!
 When I
create new content, I encounter the warning:
ERROR (date and time) Unable to find archetypes directory for theme
"cocoa-eh"
I understand that archetypes are somewhat like templates for metadata, but
I don't think I have any need to use them. Is there any way I can suppress
this error? Sorry about this not necessarily being theme-specific. 🐺
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fuegowolf/cocoa-eh-hugo-theme/issues/21, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AATo8pEH0DRC9U3xDZZh-GaXqaQ9UoySks5rqcYvgaJpZM4Msby6
.

Ah, I didn't notice "useful archetypes" so the pull request I made just adds a minimal empty one purely to suppress the error. With a blank default archetype, new content metadata includes a date and title. Is there anything you had in mind (for default or posts/blog content specifically)?

Great pull request ! Sorry to not have the time to do it right now, but a typical archetype is something like this :
+++
date = "2016-12-18"
tags = ["blahblah"]
title = "Title"
description = "Desc"
meta_img = "/images/image.jpg"
+++

If you can't set it in your pull request I will merge it and see it later ! Thx :)

Addressed in #22 :hammer:

Fix with PR #22 ! Thanks you again !


How to load a custom structure model？

hello， when I run the following code, I am prompted that only support  AutoModelForCausalLMWithValueHead and AutoModelForSeq2SeqLMWithValueHead. But these two structures seem to only be able to load the specified pre-trained model.
ppo_trainer = PPOTrainer(config, gen_model, gen_ref_model, tokenizer)
My model is trained by the T5, and the structure has changed. I would like to know how to load my model? Is it supported?

Hi @estuday
Thanks for the issue, how your new architecture is defined? Perhaps you can make it inherit from an AutoModelForSeq2SeqLMWithValueHead and overwrite the necessary methods.

Hi @estuday Thanks for the issue, how your new architecture is defined? Perhaps you can make it inherit from an AutoModelForSeq2SeqLMWithValueHead and overwrite the necessary methods.

hi @younesbelkada , thanks for your reply. If the model is loaded with the following code, how to apply it to the trl frame?
from transformers import T5ForConditionalGeneration
model=T5ForConditionalGeneration.from_pretrained('t5-small')

Hi @estuday
If you want to fine-tune a T5 model using PPO you should run:
from trl import AutoModelForSeq2SeqLMWithValueHead

model = AutoModelForSeq2SeqLMWithValueHead.from_pretrained("t5-small")

...
ppo_trainer = PPOTrainer(config, model, ref_model=None, ...)

You can reproduce the sentiment tuning experiment with t5 model: https://github.com/lvwerra/trl/blob/main/examples/scripts/sentiment_tuning.py by passing --use_seq2seq argument.

Hi @estuday If you want to fine-tune a T5 model using PPO you should run:
from trl import AutoModelForSeq2SeqLMWithValueHead

model = AutoModelForSeq2SeqLMWithValueHead.from_pretrained("t5-small")

...
ppo_trainer = PPOTrainer(config, model, ref_model=None, ...)

You can reproduce the sentiment tuning experiment with t5 model: https://github.com/lvwerra/trl/blob/main/examples/scripts/sentiment_tuning.py by passing --use_seq2seq argument.

hi @younesbelkada.
Actually, I don't want to use the T5 model directly for the trl framework. I've fine-tuned the T5 before this, so its structure has changed.
I have tried the following code, but failed:
trl_model=AutoModelForSeq2SeqLMWithValueHead.from_pretrained('t5-base')
finetuned_model=Mymodel.load_from_checkpoint('path/to/mymodel.ckpt')
trl_model=trl_model.load_state_dict(finetuned_model.state_dict())

Mymodel can be regarded as a model read by T5ForConditionalGeneration.from_pretrained('t5-base'), which is different from the structure read by AutoModelForSeq2SeqLMWithValueHead.from_pretrained('t5-base')

What do you mean by "different from the structure"? Is it a different architecture? Otherwise you could simply do:
trl_model = AutoModelForSeq2SeqLMWithValueHead.from_pretrained('path/to/mymodel.ckpt')


Added iPad support

Set example to Formsheet presentation on iPad
Switched example to Univeral App

Master has been heavily updated to handle CocoaPods. The commit is no longer valid.


large rework of structure, remove dead pages, clean up

Adds CLI toolchain parts
Adds new setup without container
Adds theory section (WIP)

test borks on code blocks - don't think this matters thou


what to file the highlighted commands after the script runs at once

Hi @Rajulolabhattu
I don't see what this has to do with the Ansible Role. So I'll close this issue.
Kind regards,
Werner


core.py and services.py have too many lines

core.py and services.py have too many lines and should probably be refactored.

In the core.py, the methods for getting favorites and managing playlists aren't really functionalities of the player, but rather of the whole sonos system.
I would suggest refactoring them to their own module.


Create a Logo for project

Describe the feature
Create a logo for name ExamTime.
Add ScreenShots
none
Record

[X] I agree to follow this project's Code of Conduct
[ ] I'm a GSSoC'24 contributor
[ ] I want to work on this issue

Hey! @Yashshukla11 Can you assign me this issue under GSSoC. I have good experience in designing and also in UI/UX.
Little about me : I am experienced contributor as I have completed Hacktoberfest-2020 and Hactoberfest-2023 successfully.

Hey! @Yashshukla11
I have made couple of amazing logos should I post it Here or any other way I can send it to you?

DM me on discord

I have sent the mail, Hope you like it.

I would like to work on this issue. Please assign me this task for GSSoC'24.

please assign this issue to me


Nothing happens after question 10

Maybe a readme with a "work in progress" notice would help? And by the way, how can people help finish this project? Seems quite interesting and useful :)

I added WIP to the description. It's been a while since I've worked on this, but I think my approach wasn't very effective. It'll probably need a branching question system.


fix(docs): broken link in top-level README

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area ci

/area event

/area event_derive

/area plugin

/area plugin_api

/area plugin_derive

/area plugin_tests

What this PR does / why we need it:
Fix the doc link on the front page. Again :)
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: gnosek
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [gnosek]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 110368da7f0d3bfa1c240a9418462977c7988f7f

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: gnosek, mrgian
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [gnosek,mrgian]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


fix: make multi-processing in baseline models more consistent

Closes #907
Set Context of ProcesspoolExecutors to spawn

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

v0.27.0
GitHub release

Your semantic-release bot :package::rocket:


Apply tax to fees to match DoorDash total

DoorDash applies tax to charges like service fees, but not tips. We currently don't apply tax to any fees.

Not necessary after #4. The total order tax amount is now added explicitly and then split proportionally, which removes the need to calculate tax amounts for every line item or fee (or even know what the tax rate is).


feat: add more mention of needing to install Sharp manually

What kind of changes does this PR include?

New or updated content

Description
Adds some more mention that you might need to install sharp manually into your project if you're using a strict package manager

Oops, just realized I added a bunch of formatting changes by accident (very used to format on save here), let me know if that's an issue


Added more Documentation.

Moved Screen Fade properties and methods from game to Screen class

Tested all new vehicles on 1.0.757.2 and the spawned ok :)

@kagikn there we go, no issues with it now :)


Fixed #25853 -- Added support for GeoHash function on SpatiaLite.

https://code.djangoproject.com/ticket/25853

Looks like the failing test is because self.lwgeom_version() returns None even though SpatiaLite is 4.1.1. Do we need to install an additional package or something?

@timgraham
The test failed because I made a faulty check of lwgeom_version(), it's fixed now. It looks like installing liblwgeom is not sufficient and SpatiaLite should be compiled with LWGEOM to support GeoHash function as it done in the latest Ubuntu releases. I don't know if we should merge this until we have SpatiaLite compiled with LWGEOM on Jenkins.

I think it's fine if the test pass with or without LWGEOM compiled in.

@claudep
I tested it locally both with and without LWGEOM support and test passed.

merged in 25f5b5c19dc23c6c09877c9c652a934e9669573d, thanks!


Core actions

Codecov Report

Merging #5 (19ab208) into master (6b686b2) will increase coverage by 11.53%.
The diff coverage is 98.38%.

@@             Coverage Diff             @@
##           master       #5       +/-   ##
===========================================
+ Coverage   80.76%   92.30%   +11.53%
===========================================
  Files           2        3        +1
  Lines          52       91       +39
===========================================
+ Hits           42       84       +42
+ Misses         10        7        -3

Impacted Files
Coverage Δ

src/construction.jl
96.77% <96.77%> (ø)

src/basetypes.jl
100.00% <100.00%> (+33.33%)
:arrow_up:

src/graphfunctions.jl
86.36% <100.00%> (+1.36%)
:arrow_up:

Continue to review full report at Codecov.

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


Vue2 + Webpack 2 + Cssnext Nesting not working (node.parent.after is not a function)

Has this been solved?


Show contacts list

Can I use some method to show to user his contacts list where he can share contact with bot?

No, but any of your users can simply go to the contact they would like to share with the bot and choose "Share Contact" and then send it to the bot.

Thank you!


fix buffer pool for uncompressed buffers

This quick commit speeds up zq searches by 25% by sending the
decompressed buffers to a pool along with the compressed buffers.
It's a bit hacky and this could all use some more work but
I think it's okay to check in for now.

A simpler way to address this is to do what we used to do and have zngio.Writer.Write call Writer.flush before (rather than after) len(Writer.values) exceeds Writer.thresh.

flush() means multiple things that you don't know ahead of time and even if you just focused on the compressed buffers there are uncompressed buffers that need to be managed also.  To me, having the buffer pool adapt to the size of the buffers in use rather than making sure the encode path always stays below the max buffer size is "simpler" but perhaps this is chocolate vs vanilla.  And anyway, you can't have an invariant that all buffers will always be smaller than the max because you can have an arbitrarily large value so you have to deal with the exception anyway.


Fix retrieving images from Google Container Registry

Google Container Registry doesn't implement the Docker registry API
correctly: when trying to access
"REGISTRY/repositories/IMAGE/NAME/tags/TAG" it fails with a 405.
Instead of getting the tag from that URL, get the JSON with all the tags
and look for the one we want. This is what Docker does.
Fixes #39

@iaguis I'm confused how this isn't a bug in GCR tbh; are they just relying on the Docker client to fall back to retrieving all tags? :-/

lgtm

@iaguis I'm confused how this isn't a bug in GCR tbh; are they just relying on the Docker client to fall back to retrieving all tags? :-/

I think so. It's clearly in the API :/

Thanks!


Increase lucio self healing from 10 to 12 heals per second

Created by: MaxwellJung
Ally healing remains unchanged at 16 heals per second

moved from ow1_emulator_backup#583

mentioned in merge request ow1_emulator_backup!295


Cell community detection

Cell community detection to be integrated into stereopy.

Forgive my bothering, a demo run script and samples will be needed. Thx~


Decouple data from install directories

This addresses #16
We set a new environment variable called $G4BASE
which tracks $SOFT_DIR. Data is installed to $G4BASE/data
where it can be cached and used by all versions of Geant4 instead
of unnecessarily downloading repeatedly the same file.
Other fixes :

This commit also adds $GEANT4_DIR/bin to the PATH so that we can
find geant4-config
The install path is corrected for CLHEP and GCC versions

please test

the builds failed  because there was a problem locating the tarball.


Merging 0.1 dev branch to main

Time to update the main branch with latest fixes again.

@mhesselbarth merging the current dev branch into main. If you do further commits, create a new version please on dev (0.1.1)


Night CI 2023-07-06: Failed

action url: https://github.com/spidernet-io/spiderpool/actions/runs/5479775404

the bug same as #2007


Add option for IPSec also/instead

It would be nice if piVPN also had an option for IPSec based server.  Example -
https://github.com/hwdsl2/setup-ipsec-vpn

PiVPN is no longer maintained, see the README

PiVPN Issue Template

Issue
Have you searched for similar issues and solutions?
(yes/no / which issues?)

Console output of curl -L install.pivpn.io | bash
  Output Here

Console output of pivpn add or pivpn add nopass
  Output Here

Console output of pivpn debug
  Output Here

Console Output of sudo iptables -t nat -S
  Output Here

Console Output of sudo iptables -S
  Output Here

output of sudo netstat -uanp | grep openvpn
  Output Here

Have you taken any steps towards solving your issue?
 which?

i'm strongly against that because that's a complete different vpn/security technology and there is enough work to be done in pivpn itself

@drduker I agree with @devZer0, and if you need an IPSec VPN instead, why not use the project you've linked?

PiVPN’s name denotes no specific vpn technology but just vpn.  All I am saying is it would be nice to have the other option.  If pivpn doesn’t have enough support as it is then ignore this suggestion.  I think the adoption of pivpn would be much larger if they used a solution that would work with their phones natively without downloading an OpenVPN client also.  And I wasn’t necessarily suggesting that I would use IPSec instead, it would be nice to have it in addition to and running alongside of as the raspberry pi could handle that.

I can agree with both @devZer0 and @drduker ... having this said .. i won't close this .. leave it tagged as enhancement and not priority.
I can see benefit on adding support for both IPSec and Wireguard .. however PiVPN doesn't have enough maintainers and supporters to add such features.
Maybe if there are already some projects for such type of servers we can help getting them some visibility by adding links for them in our README?
Dunno .. it is indeed to much for us at the moment but doesn't seems completely nonsense!

going to ditch this option as we are considering adding support go wireguard instead.
Wireguard endorses most of the concerns listed here.


[WIP]Write Activity

Features Till now :

[x] Rich text editor with Quilljs having Bold , italic , underline , strikethrough , Lists , paragraph align, Foreground and background colour , undo , redo .
[x] Images : resize and text wrapping
[x] Journal connectivity
[x] Multi user collaboration
[x] Export to doc , txt , PDF
[x] Responsive : Works across different screen size
[ ] copy-paste feature
[ ] Tables Integration
[ ] Speak integration

I've tested DOCX export.
The format is not supported by LibreOffice thought it works into Word.
May be it could interesting to convert to DOC instead?
Plus it look like there is some issue in encoding character with accent (like é,à,è, ...).

Very good job on ODT generation :+1:
Three remarks:

Font changing in ODT seems not work, is it a limitation?
Do you update the DOC generation to avoid using base64 encoding for images?
Could you change the two icons for ODT/DOC generation: use the same image than TXT/PDF generation with ODT and DOC instead of TXT/PDF.

Regarding the font family change in ODT , I will fix it .
Regarding the doc , It is not the encoding we are doing at the end causing issue , It is because when we add images through journal chooser , we get them in a base64 format which are not supported . Is there a way to avoid that ?
Regarding icons , do you want to replace the odt and doc icon with icons similar to txt and PDF ? ( I was not able to find similar one's for ODT and DOC ) .

Regarding encoding, the problem is that only recent versions of Word support base64 encoding so it will be better to use binary encoding instead. It's not possible in Journal Chooser to encode in something else than base64 because it's returned as a string. BTW you could try to re-encode it as a Blob object then create an URL that you could affect to the src property for the image. You could find an example here.
Regarding icons, the icon don't exist. You could obtain it by editing the SVG file in InkScape to update the text.

Just tested. The level of ODT support is now very good :+1:

Copy and Paste Issue has been Fixed

Few remarks:

Why you remove quill.min.js instead of quill.js? I guess the first is minimized so it should be better to use this one
Will be better to put all libraries in the lib directory and put code for the activity in the js directory
The standard indentation rules for Sugarizer is to use TAB, currently you seem to use a mix of TAB and SPACE. Could you fix it?
Could you change the welcome text to the one in the screen capture below? The image could be found here. Note that the text should be localized.

Done Changes

@ashish0910  It doesn't solve the issue of welcome text construction.
As I said previously, the user name should be pass as parameter in first sentence.
For other sentence, I don't see other way of doing the job to use tag into each sentence to isolate part of sentence to format.

I have added some fixes for Localisation

A very smart way to solve the issue :+1:
I love the method name dangerouslyPasteHTML :smile:
Hope it's not too dangerous!


Allow passing a context to deserialize/serialize so that custom aliases can access the context

When trying to write a custom type mapping, it would be helpful to pass a context along with the value to be deserialized/serialized.
Presently I'm trying to use Bond to create an RPC for an object oriented language. When serializing objects, I can create a per client LUT to store the live objects. However, when deserializing, I can't directly access that object on a per-client basis due to the deserialize "get_aliased_value" doesn't allow a context parameter. I'm sure such a context would be helpful for other situations as well.
Suggestion (C++):
bond::aliased_type::type get_aliased_value(T const& value, void* pContext);
void set_aliased_value(T& var, bond::aliased_type::type val, void* pContext);
Similar updates for the other types of alias overrides would be needed as well plus equivalents for other languages.

It seems like you want to be able to pool objects, intern them in some per-client scope when transforming them into your custom C++ types. And, it's the per-client scoping (compared to global scoping) that needs to context. I could also see something that uses per-client state to handle the conversion. For example, looking up the client's culture to know how to parse a numerical value in a string into a C++ type. Am I following?
I'm not opposed to adding a void* context parameter to the alias functions and preferentially invoking get_aliased_value(T const& value, void* userContext); &c. if they exist.
Instead of adding a bunch of Serialize and Deserialize overloads with a context parameter, if something like there were implemented, I think it should be limited to just the "low level" Apply function.
Maybe the transforms can have an optional ctor added that takes a context parameter and none of the driving APIs need to be touched... This is not something that most people will use. (And, if it become super popular, adding such overloads is easy to do.)
template <typename Protocols = BuiltInProtocols, typename T, typename Writer>
void SerializeWithContext(const T& t, Writer& output)
{
    void* context = GetCurrentContextViaMagic();
    Apply<Protocols>(
        Serializer<Writer, Protocols>(output, context),
        obj);
}

One potential way I can think to implement this today is to use thread-local storage to store the context pointer. Thread-local storage has drawbacks, for sure, but maybe it will work for you.
I don't think an allocator will work to smuggle such context around: it isn't passed to the aliasing functions. (Maybe it should be...)
I would implement this in each language individually. This isn't a feature that needs to exist in all languages for them to interoperate with each other.

It seems like you want to be able to pool objects, intern them in some per-client scope when transforming them into your custom C++ types. And, it's the per-client scoping (compared to global scoping) that needs to context. I could also see something that uses per-client state to handle the conversion. For example, looking up the client's culture to know how to parse a numerical value in a string into a C++ type. Am I following?

Yes, that describes it pretty well. I'm already pulling context information from the RPC call itself pretty much as you describe.
While I could do it in two steps, it would be great to deserialize it directly into the object I want, especially in cases where the objects may be deeply embedded in a structure. I could also probably accomplish it with a specialized Transform that hooks into the built-in serializers, but that is a lot of work compared to having a context.

One potential way I can think to implement this today is to use thread-local storage to store the context pointer. Thread-local storage has drawbacks, for sure, but maybe it will work for you.

I'll experiment with thread local storage. Luckily C++ natively supports the concept now so it won't be as ugly. Of course every thread wouldn't necessary need the context or multiple threads may share the same context, so there is some waste. However, it isn't a bad interim solution.

I don't think an allocator will work to smuggle such context around: it isn't passed to the aliasing functions. (Maybe it should be...)

An allocator seems kind of like a hack. Maybe if it was an allocator local to the serialization it is fine, but if it had to be embedded in the schema/generated structures, I would be opposed to that. Of course if it is local to the serialization, then it is essentially a non-generic context.

I would implement this in each language individually. This isn't a feature that needs to exist in all languages for them to interoperate with each other.

Yes, I think you are correct there. Since the context is going to be specific to an application, it's availability in each language only matters for applications that want the feature in a particular language. For my use case, it only needs to be in C++.

A context parameter isn't something that we currently need at Microsoft, so we have no plans to implement this. You are welcome to contribute, if thread-local storage doesn't meet your needs.

I'll definitely look into this. If I find a non-intrusive way to add the feature, I'll definitely create the pull request.


Closes #75 - Add identifier definitions to Sharding Page in docs

Summary

Resolve #75 . This PR adds documentation for the EntryID, UUID, LogID and Log Index.
Release Note

Documentation

This is a Doc PR.

@lkatalin @ltagliaferri Please, I would love a review.

+1 for the updates to the text. Long term, I think documentation like this needs to be either under Rekor or in a dedicated place for developers, as this is dev-specific documentation

+1 for the updates to the text. Long term, I think documentation like this needs to be either under Rekor or in a dedicated place for developers, as this is dev-specific documentation

Yeah, having a dev-specific section would make sense. Should we start a Rekor -> development page on https://docs.sigstore.dev/? Or do you think it would fit better in the Rekor repo's README.md?

+1 for the updates to the text. Long term, I think documentation like this needs to be either under Rekor or in a dedicated place for developers, as this is dev-specific documentation

Yeah, having a dev-specific section would make sense. Should we start a Rekor -> development page on https://docs.sigstore.dev/? Or do you think it would fit better in the Rekor repo's README.md?

Can you file an illus to discuss this @lkatalin

Can you file an issue to discuss this @lkatalin ? Thank you

Done: https://github.com/sigstore/docs/issues/117


Asdivine Hearts [PCSE00968]

App summary

App name: Asdivine Hearts
App serial: PCSE00968
App version: 1.00

Vita3K summary

Version: v0.1.5
Build number: 2692
Commit hash: https://github.com/vita3k/vita3k/commit/067135d2
CPU backend: Dynarmic

Test environment summary

Tested by: gymzatan
OS: Windows 11
CPU: AMD Ryzen 7 5800H
GPU: AMD Radeon(TM) Graphics
RAM: 16 GB

Issues
Game stays at the loading screen.
Screenshots

Log
vita3k.log
Recommended labels

Intro
unity

as of https://github.com/Vita3K/Vita3K/commit/4280bea5906fdabf90cbb8493a31cf33c96b0b9b, the game now goes ingame, with slowdowns (4-13fps).
Screenshots

Logs
vita3k.log
Recommended Labels

Ingame +
slow


Analyze rets response at login

Description
Checking the RETS response codes at login. Should make for better error handling
GitHub Issues

Coverage decreased (-0.3%) to 91.958% when pulling 5ed8e0c1b191030c372806a91f5dddee02c56374 on mcrowson:analyze_rets_response_at_login into 3b1b30fb5999d76299fb73da8eb0fbb98767ec45 on refindlyllc:development.

Coverage decreased (-0.3%) to 91.958% when pulling 5ed8e0c1b191030c372806a91f5dddee02c56374 on mcrowson:analyze_rets_response_at_login into 3b1b30fb5999d76299fb73da8eb0fbb98767ec45 on refindlyllc:development.


Added Josh to developers

Test steps:
Open index.html
Verify Josh is on there
Link goes to BetweenTwoRocks.com

Really? Between Two Rocks?

Be sure to sign up at https://hacktoberfest.digitalocean.com and do your four pull requests before the end of October to get your free t-shirt!