Cannot import TypeAdapterFactory

I'm trying to assemble an example project, followed the imports in the readme but I'm getting a unresolved reference for TypeAdapterFactory.
Searching in the projects files found the import "import com.infinum.jsonapix.TypeAdapterFactory" to then use the  TypeAdapterFactory().getListAdapter(), but I'm not being able to import it.
I'm not getting any Sync error, I think I'm not adding the kapt compiler pluging correctly and thus the jsonapix:processor is not being imported.
The code that I'm trying to run is this, from the Readme:
import com.infinum.jsonapix.TypeAdapterFactory

fun JsonApiFunApp(
    inputJsonString: String
){
    // Gets adapter for a single instance of Person
    val adapterr: TypeAdapter<Person>
    val adapter = TypeAdapterFactory().getAdapter(Person::class)

    // Gets adapter for a list of Person instances
    val listAdapter = TypeAdapterFactory().getListAdapter(Person::class)

    //adapter.convertToString(person) // Produces JSON API String from a Person instance
    adapter.convertFromString(inputJsonString) // Produces Person instance from JSON API String

    //listAdapter.convertToString(person) // Produces JSON API String from a Person list
    listAdapter.convertFromString(inputJsonString) // Produces Person list from JSON API String
}

This is what I've mofidied from the graddle files:
build.graddle:app
this is my build.graddle:app. I added the last three Id's in plugins and the first five implementations.
plugins {
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
    id "kotlinx-serialization"
    id "kotlin-kapt"
    id "kotlin-android"
}

android {
    namespace 'com.example.jsonapixtutorial'
    compileSdk 33

    defaultConfig {
        applicationId "com.example.jsonapixtutorial"
        minSdk 24
        targetSdk 33
        versionCode 1
        versionName "1.0"

        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        vectorDrawables {
            useSupportLibrary true
        }
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
    kotlinOptions {
        jvmTarget = '1.8'
    }
    buildFeatures {
        compose true
    }
    composeOptions {
        kotlinCompilerExtensionVersion '1.2.0'
    }
    packagingOptions {
        resources {
            excludes += '/META-INF/{AL2.0,LGPL2.1}'
        }
    }
}

dependencies {
    // Serialization API. Check the docs link above for newer versions
    implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.6.0")
    // Json API X
    implementation("com.infinum.jsonapix:core:1.0.0-beta02")
    kapt ("com.infinum.jsonapix:processor:1.0.0-beta02")
    // Optional: For Retrofit support
    implementation("com.infinum.jsonapix:retrofit:1.0.0-beta02")
    // Optional: Custom lint tool checker
    implementation("com.infinum.jsonapix:lint:1.0.0-beta02")

    implementation 'androidx.core:core-ktx:1.7.0'
    implementation 'androidx.lifecycle:lifecycle-runtime-ktx:2.3.1'
    implementation 'androidx.activity:activity-compose:1.3.1'
    implementation "androidx.compose.ui:ui:$compose_ui_version"
    implementation "androidx.compose.ui:ui-tooling-preview:$compose_ui_version"
    implementation 'androidx.compose.material:material:1.2.0'
    testImplementation 'junit:junit:4.13.2'
    androidTestImplementation 'androidx.test.ext:junit:1.1.5'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.5.1'
    androidTestImplementation "androidx.compose.ui:ui-test-junit4:$compose_ui_version"
    debugImplementation "androidx.compose.ui:ui-tooling:$compose_ui_version"
    debugImplementation "androidx.compose.ui:ui-test-manifest:$compose_ui_version"
}

build.graddle:project
In the build.graddle:project I added the dependencies in the buildscript, and the last two plugin ids.
buildscript {
    ext {
        compose_ui_version = '1.2.0'
    }
    dependencies {
        classpath("org.jetbrains.kotlin:kotlin-serialization:1.6.0")
    }
}// Top-level build file where you can add configuration options common to all sub-projects/modules.
plugins {
    id 'com.android.application' version '7.4.2' apply false
    id 'com.android.library' version '7.4.2' apply false
    id 'org.jetbrains.kotlin.android' version '1.7.0' apply false
    id 'org.jetbrains.kotlin.plugin.serialization' version '1.6.0'  apply true
    id 'org.jetbrains.kotlin.kapt' version '1.9.10' apply true
}

settings.graddle project
Lastly this is my settings.graddle project, the mavenCentral module was already included.
pluginManagement {
    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}
rootProject.name = "JsonApiX Tutorial"
include ':app'

Hey @Jonathan5579 ,
Thanks for pointing this out. I'll dive into the TypeAdapterFactory import and the kapt integration issue. I'll circle back once I've had a closer look.
Cheers!

Can you try to reproduce this with the new release 1.0.0?

Hey @nelsonzacharia
Can you provide us with a sample project with your case, so we can try it?

Sure, no problem. I'm trying to connect an Android application to an
existing Laravel JSON API server that also has a web interface built with
JavaScript. I'm attempting to use the same endpoints for both interfaces.
attached are files from my android project
On Thu, Feb 29, 2024 at 7:46 PM Ahmed Ali @.***> wrote:

Hey @nelsonzacharia https://github.com/nelsonzacharia
Can you provide us with a sample project with your case, so we can try it?
—
Reply to this email directly, view it on GitHub
https://github.com/infinum/kotlin-jsonapix/issues/55#issuecomment-1971544033,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABULXNHYS4PXCQQK2MVVRDTYV5NQBAVCNFSM6AAAAAA6MIZE4CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZRGU2DIMBTGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
nelson zacharia
mscomputer and mobile
phone : +255 (0) 713 127 045
my cv : nelsonzacharia.freetzi.com
web : mscomputer.freetzi.com

any recommendation
On Thu, Feb 29, 2024 at 8:55 PM Nelson Zacharia @.***>
wrote:

Sure, no problem. I'm trying to connect an Android application to an
existing Laravel JSON API server that also has a web interface built with
JavaScript. I'm attempting to use the same endpoints for both interfaces.
attached are files from my android project
On Thu, Feb 29, 2024 at 7:46 PM Ahmed Ali @.***>
wrote:

Hey @nelsonzacharia https://github.com/nelsonzacharia
Can you provide us with a sample project with your case, so we can try it?
—
Reply to this email directly, view it on GitHub
https://github.com/infinum/kotlin-jsonapix/issues/55#issuecomment-1971544033,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABULXNHYS4PXCQQK2MVVRDTYV5NQBAVCNFSM6AAAAAA6MIZE4CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZRGU2DIMBTGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
nelson zacharia
mscomputer and mobile
phone : +255 (0) 713 127 045
my cv : nelsonzacharia.freetzi.com
web : mscomputer.freetzi.com

--
nelson zacharia
mscomputer and mobile
phone : +255 (0) 713 127 045
my cv : nelsonzacharia.freetzi.com
web : mscomputer.freetzi.com

Hi @nelsonzacharia , we changed the TypeAdapterFactory class to contain only one generic function for returning both the single instance of a class and a list instance. So the TypeAdapterFactory().getListAdapter function does not exist anymore.
You can use it like this now:
Gets adapter for a single instance of Person
val adapter = TypeAdapterFactory().getAdapter(PersonModel::class)
Gets adapter for a list of Person instances
val listAdapter = TypeAdapterFactory().getAdapter(PersonList::class)
Was that your problem? If not, please provide a sample, we cannot see any files in your previous messages.


fix: solves unable to run yarn command

Is there a Jira task for this or is it just a quick fix?

Is there a Jira task for this or is it just a quick fix?

No, it is just a quick fix. I tried to run yarn to get all the needed packaged, which errored out. Solved the issue together with Kryz, and we chose to make a quick PR with it, so others won't run into the same issue.

What happend in the yarn.lock? It flipped the places of all the version and integrity?

Not sure why it did that. Just ran yarn, after we had solved the issue. The actual file should be no different than before.


data_captureJS_to_csv

This is my example implementation(javascript) of the data capture about mouse movement to CSV file

Hi @bilal-62210, thanks for this pull request. 👍
I think this is a fine first iteration of the implementation example. Before we upload it, I would like you to write your commit message following the guidelines here:
https://chris.beams.io/posts/git-commit/
You can talk with Lucas and Xavier and have them show you how to rebase your branch to update these commit messages.

hey bilal, let me know if you feel this is ready to push, and we will merge, thanks!

@bastianilso You can merge the new commit, it's the lastest version.


Make sure verifyCapabilities build steps are tied to producing a build item

W/o this a build step might not be executed and actually lead to an application build error.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

@radtriste this is a critical one, pretty much a blocker. Could you guys have a look into this?

ok to test

(tests) - kogito-examples job #684 was: FAILURE
Possible explanation: Pipeline failure or project build failure
Please look here: https://eng-jenkins-csb-business-automation.apps.ocp-c1.prod.psi.redhat.com/job/KIE/job/kogito/job/main/job/pullrequest/job/kogito-runtimes.tests.downstream.kogito-examples/684/display/redirect
See console log:

Console Logs
Checking out Revision 34c2cbeaf58086cb3d2eed257b72b22b17ade321 (main) > git config core.sparsecheckout # timeout=10 > git checkout -f 34c2cbeaf58086cb3d2eed257b72b22b17ade321 # timeout=10Commit message: "MavenCommand: Use Maven Wrapper (#211)" > git rev-list --no-walk 34c2cbeaf58086cb3d2eed257b72b22b17ade321 # timeout=10[Pipeline] Start of Pipeline[Pipeline] nodeRunning on rhos-01-kie-psi-rhel7-xlarge-549 in /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.downstream.kogito-examples[Pipeline] {[Pipeline] stage[Pipeline] { (Declarative: Checkout SCM)[Pipeline] checkoutThe recommended git tool is: NONEusing credential kie-ciCloning the remote Git repositoryAvoid second fetchChecking out Revision 49ff30e440728e9764001756b15e778d6c4c4b17 (origin/main)Commit message: "Add release branch 1.26.x after cut-off (#581)"[Pipeline] }[Pipeline] // stage[Pipeline] withEnv[Pipeline] {[Pipeline] withEnv[Pipeline] {[Pipeline] timestamps[Pipeline] {[Pipeline] timeout[2022-08-11T09:10:25.323Z] Timeout set to expire in 3 hr 0 min[Pipeline] {[Pipeline] stage[Pipeline] { (Declarative: Tool Install)[Pipeline] tool[2022-08-11T09:10:25.435Z] Installing NodeJS from /var/lib/jenkins/caches/nodejs/LINUX/amd64/16.2.0.tar.gz to /home/jenkins/tools/jenkins.plugins.nodejs.tools.NodeJSInstallation/nodejs-16.2.0 on rhos-01-kie-psi-rhel7-xlarge-549Cloning repository https://github.com/kiegroup/kogito-pipelines.git > git init /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.downstream.kogito-examples # timeout=10Fetching upstream changes from https://github.com/kiegroup/kogito-pipelines.git > git --version # timeout=10 > git --version # 'git version 2.37.1'using GIT_ASKPASS to set credentials PSSWD: kie-ci service account with access to jboss-integration private github space > git fetch --tags --force --progress -- https://github.com/kiegroup/kogito-pipelines.git +refs/heads/*:refs/remotes/origin/* # timeout=10 > git config remote.origin.url https://github.com/kiegroup/kogito-pipelines.git # timeout=10 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 > git rev-parse origin/main^{commit} # timeout=10 > git config core.sparsecheckout # timeout=10 > git checkout -f 49ff30e440728e9764001756b15e778d6c4c4b17 # timeout=10[Pipeline] envVarsForTool[Pipeline] }[Pipeline] // stage[Pipeline] withEnv[Pipeline] {[Pipeline] stage[Pipeline] { (Initialize)[Pipeline] tool[Pipeline] envVarsForTool[Pipeline] withEnv[Pipeline] {[Pipeline] script[Pipeline] {[Pipeline] sh[2022-08-11T09:10:28.118Z] + printenv[Pipeline] archiveArtifacts[2022-08-11T09:10:28.142Z] Archiving artifacts[Pipeline] }[Pipeline] // script[Pipeline] }[Pipeline] // withEnv[Pipeline] }[Pipeline] // stage[Pipeline] stage[Pipeline] { (check space before build)[Pipeline] tool[Pipeline] envVarsForTool[Pipeline] withEnv[Pipeline] {[Pipeline] script[Pipeline] {[Pipeline] dir[2022-08-11T09:10:28.612Z] Running in /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.downstream.kogito-examples[Pipeline] {[Pipeline] echo[2022-08-11T09:10:28.642Z] [INFO] space left on the machine[Pipeline] sh[2022-08-11T09:10:28.938Z] + df -h[2022-08-11T09:10:28.938Z] Filesystem      Size  Used Avail Use% Mounted on[2022-08-11T09:10:28.938Z] devtmpfs        7.8G     0  7.8G   0% /dev[2022-08-11T09:10:28.938Z] tmpfs           7.8G     0  7.8G   0% /dev/shm[2022-08-11T09:10:28.938Z] tmpfs           7.8G   17M  7.8G   1% /run[2022-08-11T09:10:28.938Z] tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup[2022-08-11T09:10:28.938Z] /dev/vda1        80G   19G   62G  23% /[2022-08-11T09:10:28.938Z] tmpfs           1.6G     0  1.6G   0% /run/user/1000[Pipeline] echo[2022-08-11T09:10:28.957Z] [INFO] space of /home/jenkins[Pipeline] sh[2022-08-11T09:10:29.240Z] + du -h -d1 /home/jenkins[2022-08-11T09:10:29.240Z] 4.0K	/home/jenkins/.ssh[2022-08-11T09:10:29.240Z] 0	/home/jenkins/go[2022-08-11T09:10:29.240Z] 8.0K	/home/jenkins/.vnc[2022-08-11T09:10:29.240Z] 8.0K	/home/jenkins/.m2[2022-08-11T09:10:29.240Z] 2.1G	/home/jenkins/git-repos[2022-08-11T09:10:29.240Z] 8.0K	/home/jenkins/.config[2022-08-11T09:10:29.240Z] 4.0K	/home/jenkins/.cekit[2022-08-11T09:10:29.496Z] 82M	/home/jenkins/virtenvs[2022-08-11T09:10:29.496Z] 31M	/home/jenkins/remoting[2022-08-11T09:10:29.496Z] 0	/home/jenkins/.cache[2022-08-11T09:10:29.496Z] 2.7M	/home/jenkins/workspace[2022-08-11T09:10:29.496Z] 0	/home/jenkins/.pki[2022-08-11T09:10:29.496Z] 0	/home/jenkins/caches[2022-08-11T09:10:29.496Z] 8.0K	/home/jenkins/.java[2022-08-11T09:10:29.496Z] 100M	/home/jenkins/tools[2022-08-11T09:10:29.496Z] 2.3G	/home/jenkins[Pipeline] echo[2022-08-11T09:10:29.515Z] [INFO] space of workspace[Pipeline] sh[2022-08-11T09:10:29.810Z] + du -h -d3 /home/jenkins/workspace[2022-08-11T09:10:29.810Z] 0	/home/jenkins/workspace/KIE/optaplanner/main[2022-08-11T09:10:29.810Z] 0	/home/jenkins/workspace/KIE/optaplanner[2022-08-11T09:10:29.810Z] 2.7M	/home/jenkins/workspace/KIE/kogito/main[2022-08-11T09:10:29.810Z] 2.7M	/home/jenkins/workspace/KIE/kogito[2022-08-11T09:10:29.810Z] 2.7M	/home/jenkins/workspace/KIE[2022-08-11T09:10:29.810Z] 2.7M	/home/jenkins/workspace[Pipeline] }[Pipeline] // dir[Pipeline] }[Pipeline] // script[Pipeline] }[Pipeline] // withEnv[Pipeline] }[Pipeline] // stage[Pipeline] stage[Pipeline] { (Install build-chain tool)[Pipeline] tool[Pipeline] envVarsForTool[Pipeline] withEnv[Pipeline] {[Pipeline] script[Pipeline] {[Pipeline] echo[2022-08-11T09:10:30.140Z] [INFO] Getting build-chain version from composite action file[Pipeline] readFile[Pipeline] echo[2022-08-11T09:10:30.231Z] [INFO] build-chain version recovered '2.3.34'[Pipeline] sh[2022-08-11T09:10:30.515Z] + npm install -g<EMAIL_ADDRESS>-registry=https://repository.engineering.redhat.com/nexus/repository/registry.npmjs.org/[2022-08-11T09:10:31.442Z] npm WARN ERESOLVE overriding peer dependency[2022-08-11T09:10:31.442Z] npm WARN Found: @octokit/core@2.5.4[2022-08-11T09:10:31.442Z] npm WARN node_modules/@kie/build-chain-action/node_modules/@octokit/core[2022-08-11T09:10:31.442Z] npm WARN<EMAIL_ADDRESS>from @octokit/rest@17.11.2[2022-08-11T09:10:31.442Z] npm WARN   node_modules/@kie/build-chain-action/node_modules/@octokit/rest[2022-08-11T09:10:31.442Z] npm WARN<EMAIL_ADDRESS>from @kie/build-chain-action@2.3.34[2022-08-11T09:10:31.442Z] npm WARN     node_modules/@kie/build-chain-action[2022-08-11T09:10:31.442Z] npm WARN     1 more (@kie/build-chain-configuration-reader)[2022-08-11T09:10:31.442Z] npm WARN   1 more (@octokit/plugin-paginate-rest)[2022-08-11T09:10:31.442Z] npm WARN [2022-08-11T09:10:31.442Z] npm WARN Could not resolve dependency:[2022-08-11T09:10:31.442Z] npm WARN peer @octokit/core@">=3" from @octokit/plugin-request-log@1.0.4[2022-08-11T09:10:31.442Z] npm WARN node_modules/@kie/build-chain-action/node_modules/@octokit/plugin-request-log[2022-08-11T09:10:31.442Z] npm WARN<EMAIL_ADDRESS>from @octokit/rest@17.11.2[2022-08-11T09:10:31.442Z] npm WARN   node_modules/@kie/build-chain-action/node_modules/@octokit/rest[2022-08-11T09:10:34.706Z] [2022-08-11T09:10:34.706Z] added 111 packages, and audited 112 packages in 4s[2022-08-11T09:10:34.706Z] [2022-08-11T09:10:34.706Z] 5 packages are looking for funding[2022-08-11T09:10:34.706Z]   run `npm fund` for details[2022-08-11T09:10:34.706Z] [2022-08-11T09:10:34.706Z] found 0 vulnerabilities[Pipeline] }[Pipeline] // script[Pipeline] }[Pipeline] // withEnv[Pipeline] }[Pipeline] // stage[Pipeline] stage[Pipeline] { (Build projects)[Pipeline] tool[Pipeline] envVarsForTool[Pipeline] tool[Pipeline] envVarsForTool[Pipeline] tool[Pipeline] envVarsForTool[Pipeline] withEnv[Pipeline] {[Pipeline] script[Pipeline] {[Pipeline] echo[2022-08-11T09:10:35.168Z] BUILD_MVN_OPTS_CURRENT = [Pipeline] configFileProvider[2022-08-11T09:10:35.203Z] provisioning config files...[2022-08-11T09:10:35.214Z] copy managed file [kogito_pr_settings] to file:/home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.downstream.kogito-examples@tmp/config7951703569256696033tmp[Pipeline] {[Pipeline] withCredentials[2022-08-11T09:10:35.255Z] Masking supported pattern matches of $GITHUB_TOKEN[Pipeline] {[Pipeline] sh[2022-08-11T09:10:35.289Z] Warning: A secret was passed to "sh" using Groovy String interpolation, which is insecure.[2022-08-11T09:10:35.290Z] 		 Affected argument(s) used the following variable(s): [GITHUB_TOKEN][2022-08-11T09:10:35.290Z] 		 See https://jenkins.io/redirect/groovy-string-interpolation for details.[2022-08-11T09:10:35.563Z] + build-chain-action -token=**** -df=https://raw.githubusercontent.com/kiegroup/kogito-pipelines/main/.ci/pull-request-config.yaml -folder=bc build pr -url=https://github.com/kiegroup/kogito-runtimes/pull/2388 -sp=kiegroup/kogito-examples --skipParallelCheckout -cct '(^mvn .*)||$1 -s /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.downstream.kogito-examples@tmp/config7951703569256696033tmp -Dmaven.wagon.http.ssl.insecure=true -Dmaven.test.failure.ignore=true'[2022-08-11T09:10:36.123Z] [INFO]  Executing pull request flow for https://github.com/kiegroup/kogito-runtimes/pull/2388 in bc[2022-08-11T09:10:36.124Z] (node:26053) Warning: Accessing non-existent property 'ClientError' of module exports inside circular dependency[2022-08-11T09:10:36.124Z] (Use `node --trace-warnings ...` to show where the warning was created)[2022-08-11T09:10:36.124Z] [INFO]  https://raw.githubusercontent.com/kiegroup/kogito-pipelines/main/.ci/pull-request-config.yaml exists, using it[2022-08-11T09:10:36.400Z] ::group::[PRE] Executing pre section for https://raw.githubusercontent.com/kiegroup/kogito-pipelines/main/.ci/pull-request-config.yaml[2022-08-11T09:10:36.400Z] [INFO]  Execute command 'export BUILD_MVN_OPTS=" -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false dependency:tree -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3"' in dir '/home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.downstream.kogito-examples'[2022-08-11T09:10:36.400Z] [INFO]  Treating export command since it's not possible to run it from the runner itself[2022-08-11T09:10:36.400Z] [INFO]  The variable BUILD_MVN_OPTS has been stored with ' -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false dependency:tree -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3' value[2022-08-11T09:10:36.400Z] ::notice title= [PRE] [Execution OK]::export BUILD_MVN_OPTS=" -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false dependency:tree -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3"[2022-08-11T09:10:36.400Z] [INFO]  Execute command 'echo "BUILD_MVN_OPTS= -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false dependency:tree -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3"' in dir '/home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.downstream.kogito-examples'[2022-08-11T09:10:36.400Z] [command]/usr/bin/echo BUILD_MVN_OPTS= -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false dependency:tree -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3[2022-08-11T09:10:36.400Z] BUILD_MVN_OPTS= -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false dependency:tree -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3[2022-08-11T09:10:36.400Z] ::notice title= [PRE] [Execution OK]::echo "BUILD_MVN_OPTS= -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false dependency:tree -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3"[2022-08-11T09:10:36.400Z] [INFO]  Execute command 'export BUILD_MVN_OPTS_CURRENT=""' in dir '/home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.downstream.kogito-examples'[2022-08-11T09:10:36.400Z] [INFO]  Treating export command since it's not possible to run it from the runner itself[2022-08-11T09:10:36.400Z] [INFO]  The variable BUILD_MVN_OPTS_CURRENT has been stored with '' value[2022-08-11T09:10:36.400Z] ::notice title= [PRE] [Execution OK]::export BUILD_MVN_OPTS_CURRENT=""[2022-08-11T09:10:36.400Z] [INFO]  Execute command 'echo "BUILD_MVN_OPTS_CURRENT="' in dir '/home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.downstream.kogito-examples'[2022-08-11T09:10:36.400Z] [command]/usr/bin/echo BUILD_MVN_OPTS_CURRENT=[2022-08-11T09:10:36.400Z] BUILD_MVN_OPTS_CURRENT=[2022-08-11T09:10:36.400Z] ::notice title= [PRE] [Execution OK]::echo "BUILD_MVN_OPTS_CURRENT="[2022-08-11T09:10:36.400Z] ::endgroup::[2022-08-11T09:10:36.400Z] ::group::[Pull Request Flow] Execution Plan...[2022-08-11T09:10:36.400Z] [INFO]  ----------------------------------------------[2022-08-11T09:10:36.400Z] [INFO]  [4] projects will be executed[2022-08-11T09:10:36.400Z] [2022-08-11T09:10:36.400Z] [INFO]  [kiegroup/drools][2022-08-11T09:10:36.400Z] [INFO]  Level Type: [upstream].[2022-08-11T09:10:36.400Z] [INFO]  mvn clean install -Dquickly ${{ env.BUILD_MVN_OPTS }} ${{ env.BUILD_MVN_OPTS_UPSTREAM }} ${{ env.DROOLS_BUILD_MVN_OPTS_UPSTREAM }}[2022-08-11T09:10:36.400Z] [INFO]  [ 'docker system prune -f' ][2022-08-11T09:10:36.400Z] [2022-08-11T09:10:36.400Z] [INFO]  [kiegroup/kogito-runtimes][2022-08-11T09:10:36.400Z] [INFO]  Level Type: [upstream].[2022-08-11T09:10:36.400Z] [INFO]  mvn clean install -Dquickly ${{ env.BUILD_MVN_OPTS }} ${{ env.BUILD_MVN_OPTS_UPSTREAM }} ${{ env.KOGITO_RUNTIMES_BUILD_MVN_OPTS_UPSTREAM }}[2022-08-11T09:10:36.400Z] [INFO]  [ 'docker system prune -f' ][2022-08-11T09:10:36.400Z] [2022-08-11T09:10:36.400Z] [INFO]  [kiegroup/kogito-apps][2022-08-11T09:10:36.400Z] [INFO]  Level Type: [upstream].[2022-08-11T09:10:36.400Z] [INFO]  mvn clean install -Dquickly ${{ env.BUILD_MVN_OPTS }} ${{ env.BUILD_MVN_OPTS_UPSTREAM }} ${{ env.KOGITO_APPS_BUILD_MVN_OPTS_UPSTREAM }}[2022-08-11T09:10:36.400Z] [INFO]  [ 'docker system prune -f' ][2022-08-11T09:10:36.400Z] [2022-08-11T09:10:36.400Z] [INFO]  [kiegroup/kogito-examples][2022-08-11T09:10:36.401Z] [INFO]  Level Type: [current].[2022-08-11T09:10:36.401Z] [INFO]  [[2022-08-11T09:10:36.401Z]   'mvn -f kogito-examples/pom.xml clean install -Dvalidate-formatting ${{ env.BUILD_MVN_OPTS }} ${{ env.BUILD_MVN_OPTS_CURRENT }} ${{ env.KOGITO_EXAMPLES_BUILD_MVN_OPTS }}',[2022-08-11T09:10:36.401Z]   'bash -c "if [ \'${{ env.DISABLE_PERSISTENCE }}\' != \'true\' ]; then mvn -f kogito-examples-persistence/pom.xml clean install -Ppersistence ${{ env.BUILD_MVN_OPTS }} ${{ env.BUILD_MVN_OPTS_CURRENT }} ${{ env.KOGITO_EXAMPLES_BUILD_MVN_OPTS }}; fi"',[2022-08-11T09:10:36.401Z]   'bash -c "if [ \'${{ env.DISABLE_EVENTS }}\' != \'true\' ]; then mvn -f kogito-examples-events/pom.xml clean install -Pevents ${{ env.BUILD_MVN_OPTS }} ${{ env.BUILD_MVN_OPTS_CURRENT }} ${{ env.KOGITO_EXAMPLES_BUILD_MVN_OPTS }}; fi"'[2022-08-11T09:10:36.401Z] ][2022-08-11T09:10:36.401Z] [INFO]  [ 'docker system prune -f' ][2022-08-11T09:10:36.401Z] [2022-08-11T09:10:36.401Z] [INFO]  ----------------------------------------------[2022-08-11T09:10:36.401Z] ::endgroup::[2022-08-11T09:10:36.401Z] ::group::[Pull Request Flow] Checking out kiegroup/kogito-runtimes and its dependencies[2022-08-11T09:10:36.401Z] [INFO]  Tree for project kiegroup/kogito-examples. Dependencies: [2022-08-11T09:10:36.401Z] kiegroup/drools,[2022-08-11T09:10:36.401Z] kiegroup/kogito-runtimes,[2022-08-11T09:10:36.401Z] kiegroup/kogito-apps,[2022-08-11T09:10:36.401Z] kiegroup/kogito-examples[2022-08-11T09:10:36.401Z] [INFO]  [kiegroup/drools] Checking out project[2022-08-11T09:10:36.657Z] [WARN]  aloubyansky/drools not found. Trying to get it by forked project list.[2022-08-11T09:11:32.840Z] [ERROR]  You have exceeded a secondary rate limit. Please wait a few minutes before you try again.[Pipeline] }[Pipeline] // withCredentials[Pipeline] }[2022-08-11T09:11:32.907Z] Deleting 1 temporary files[Pipeline] // configFileProvider[Pipeline] }[Pipeline] // scriptPost stage[Pipeline] junit[2022-08-11T09:11:33.018Z] Recording test results[2022-08-11T09:11:33.056Z] No test report files were found. Configuration error?Error when executing always post condition:Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to rhos-01-kie-psi-rhel7-xlarge-549		at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1797)		at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356)		at hudson.remoting.Channel.call(Channel.java:1001)		at hudson.FilePath.act(FilePath.java:1166)		at hudson.FilePath.act(FilePath.java:1155)		at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:107)		at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:153)		at hudson.tasks.junit.JUnitResultArchiver.parseAndSummarize(JUnitResultArchiver.java:247)		at hudson.tasks.junit.pipeline.JUnitResultsStepExecution.run(JUnitResultsStepExecution.java:63)		at hudson.tasks.junit.pipeline.JUnitResultsStepExecution.run(JUnitResultsStepExecution.java:29)		at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)		at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)hudson.AbortException: No test report files were found. Configuration error?	at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:154)	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3338)	at hudson.remoting.UserRequest.perform(UserRequest.java:211)	at hudson.remoting.UserRequest.perform(UserRequest.java:54)	at hudson.remoting.Request$2.run(Request.java:376)	at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)	at java.util.concurrent.FutureTask.run(FutureTask.java:266)	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)	at java.lang.Thread.run(Thread.java:750)[Pipeline] script[Pipeline] {[Pipeline] sh[2022-08-11T09:11:33.380Z] + rm -rf console.log[Pipeline] sh

Jenkins kogito-examples failure is random
[2022-08-11T09:11:32.840Z] [ERROR]  You have exceeded a secondary rate limit. Please wait a few minutes before you try again.
Jenkins (re)run kogito-examples tests


Add ExtractSegmentationInterface

This PR adds the ExtractSegmentationInterface, which works on the test data.

Aha, no merge conflict since the name was nested further above instead of on the end of the lists

Looks good 👍


Search, Redux

My weekend project went well, all in all well less than 10 hours, and we have a new search!
Clucene is gone, sqlite's fts is in, and it's wicked fast as well, very extensible, and we have a snippet feature now! (highlighted preview of the matching text). 2x as much code deleted as added and much less pain for new devs setting up a local env :)
All of the collections including links are now handled uniformly, and the update process is much much much more efficient using a new json streaming option.
There's two things left to do before pulling, a small visual bug in the UI (some are dup'd) I need help with, and the migration (just need to add it).  It's ready for some testing though, npm install then hit /update and run it through it's paces!

Oh, and I also have to update devdocs w/ the new features :)

Working OK for me so far, except for the known issue with the duplicates

What's the rationale for moving from common/node/lsearch.js -> Collections/Search? Search is a verb and the rest of the collections represent aggregates of nouns. It feels very strange to me to have it factored that way.

It feels strange to me that Collections/Search exists at all!

The idea that additional collections would also serve as composite resources/tools has always been a goal, this is just the first opportunity to do it :)
It's also much cleaner, logic is all in one place.

The fact that you intended it all along doesn't make it less confusing for the rest of us. :-)

I still don't understand how a "composite resource/tool" is a Collection, though. It seems like we have libraries connected to the core with behavior defined, and collections are where we deal with the first-class subjects of the locker.
I'm not sure how I feel about the idea of it being cleaner to have the logic all in one place, either. Having the specific logic for specific services (independent of the synclets) all concentrated in the bits of domain-specific code has always felt strange to me, and this just feels even weirder. I know that Java developers love abstraction above all things, but keeping the specific data-type adaptors loosely coupled against the core logic of something like search seems like a much easier thing to understand and maintain in the long run.

Is this a terminology thing? I've been thinking about everything as a "service" and services and serve each other as much as they can apps.  It's a separation of logic and stack space, both of which are very well suited for how search is being used.
I don't see there being any libraries connected to core, core is a namespace and tools closely related to the namespace tasks, data functionality exists in the services.

If you're thinking of everything as services, why are a certain number of them called Collections? "Collection" is a word with a specific meaning (for me), and it makes total sense to consider Places, Contacts, Photos and Links as collections, but search is something different -- a second-order byproduct of the data types, and a cross-cutting activity. To me that's a pretty major distinction. In that world, even though it's not a part of core (and I agree that my wording was imprecise there, sorry), it totally makes sense to have a library of search functionality in common/node/lsearch.js and a set of lightweight adapters that describe how to index and query the individual data types / external service types.

Forrest said everything I was going to say. Search makes sense to me as a "service" but not as a "collection"

There's been more than a few sporadic conversations about renaming /everything/ to "service" since the beginning almost, place service, search service, facebook service, etc, to help avoid these kinds of different interpretations.  I'm game :)
Aside from that, this search collection most definitely collects data as much as any other collection does, it just collects textual data, you could call it a text collection that has a query really, but that's even more confusing.
I like to think of collections (/services) as fully isolate-able, so having something like search be a shared library feels very troublesome, and difficult to maintain even when embedded in many places.  Having it speak the same language to other collections as a peer is easy to maintain, and even fully isolate and separate/replace if needed :)

I think that to flatten everything out to "services" is a step backwards – there's a value to distinguishing the first-class entities the system is designed to manipulate from the second-order data derived from those entities, especially when the derived data is something that cuts across the rest of the data types. Search results are different from contacts or checkins.
If anything, having a library that handles the core search and indexing logic that stands apart from the entities being indexed is more isolated than treating search as yet another service -- the adapters take in external documents and produce abstracted documents that are indexed, which acts as an abstraction barrier that hides the guts of search from the rest of the locker.

I think I see the specific thing you're saying, the transformation/mapping part that is in index.js, and I would mostly agree /except/ I prefer to generalize/librarieize only after it's painful not to. I really like to implement it where it's needed first, even when I know it will likely need to be generalized, that's pretty easy to do and you'll always know more when you encounter the 2nd and 3rd needs.

Thinking about search as a collection of data almost makes it make sense
to me.  I don't think of it as all the same type, though: that data has
structure.  Maybe we flatten it all at the moment, but logically, search is
an operation on objects, not only text, right?
On Mon, Dec 05, 2011 at 02:45:42PM -0800, Jeremie Miller wrote:

There's been more than a few sporadic conversations about renaming /everything/ to "service" since the beginning almost, place service, search service, facebook service, etc, to help avoid these kinds of different interpretations.  I'm game :)
Aside from that, this search collection most definitely collects data as much as any other collection does, it just collects textual data, you could call it a text collection that has a query really, but that's even more confusing.
I like to think of collections (/services) as fully isolate-able, so having something like search be a shared library feels very troublesome, and difficult to maintain even when embedded in many places.  Having it speak the same language to other collections as a peer is easy to maintain, and even fully isolate and separate/replace if needed :)

Reply to this email directly or view it on GitHub:
https://github.com/LockerProject/Locker/pull/486#issuecomment-3024795

--

mdz

As implemented it's definitely the flattened sort, IMO the work that temas is doing on storage could impact the object style search so this isn't going too far in that direction yet.
That said, it easily could still, and I want to explore some other ideas around "hooks" in the near future as a possible model to make this pattern friendly.
On Dec 5, 2011, at 7:22 PM, Matt<EMAIL_ADDRESS>wrote:

Thinking about search as a collection of data almost makes it make sense
to me.  I don't think of it as all the same type, though: that data has
structure.  Maybe we flatten it all at the moment, but logically, search is
an operation on objects, not only text, right?
On Mon, Dec 05, 2011 at 02:45:42PM -0800, Jeremie Miller wrote:

There's been more than a few sporadic conversations about renaming /everything/ to "service" since the beginning almost, place service, search service, facebook service, etc, to help avoid these kinds of different interpretations.  I'm game :)
Aside from that, this search collection most definitely collects data as much as any other collection does, it just collects textual data, you could call it a text collection that has a query really, but that's even more confusing.
I like to think of collections (/services) as fully isolate-able, so having something like search be a shared library feels very troublesome, and difficult to maintain even when embedded in many places.  Having it speak the same language to other collections as a peer is easy to maintain, and even fully isolate and separate/replace if needed :)

Reply to this email directly or view it on GitHub:
https://github.com/LockerProject/Locker/pull/486#issuecomment-3024795

--

mdz

Reply to this email directly or view it on GitHub:
https://github.com/LockerProject/Locker/pull/486#issuecomment-3026698

If I squint and think of it as the "searchables" collection, it works for
me.  I expect that when we have something else like it, which doesn't quite
fit with the other collections, we'll end up calling it something new.
On Mon, Dec 05, 2011 at 06:01:45PM -0800, Jeremie Miller wrote:

As implemented it's definitely the flattened sort, IMO the work that temas is doing on storage could impact the object style search so this isn't going too far in that direction yet.
That said, it easily could still, and I want to explore some other ideas around "hooks" in the near future as a possible model to make this pattern friendly.
On Dec 5, 2011, at 7:22 PM, Matt<EMAIL_ADDRESS>wrote:

Thinking about search as a collection of data almost makes it make sense
to me.  I don't think of it as all the same type, though: that data has
structure.  Maybe we flatten it all at the moment, but logically, search is
an operation on objects, not only text, right?
On Mon, Dec 05, 2011 at 02:45:42PM -0800, Jeremie Miller wrote:

There's been more than a few sporadic conversations about renaming /everything/ to "service" since the beginning almost, place service, search service, facebook service, etc, to help avoid these kinds of different interpretations.  I'm game :)
Aside from that, this search collection most definitely collects data as much as any other collection does, it just collects textual data, you could call it a text collection that has a query really, but that's even more confusing.
I like to think of collections (/services) as fully isolate-able, so having something like search be a shared library feels very troublesome, and difficult to maintain even when embedded in many places.  Having it speak the same language to other collections as a peer is easy to maintain, and even fully isolate and separate/replace if needed :)

Reply to this email directly or view it on GitHub:
https://github.com/LockerProject/Locker/pull/486#issuecomment-3024795

--

mdz

Reply to this email directly or view it on GitHub:
https://github.com/LockerProject/Locker/pull/486#issuecomment-3026698

Reply to this email directly or view it on GitHub:
https://github.com/LockerProject/Locker/pull/486#issuecomment-3027082

--

mdz

I think my point is that you have to distort the model of a "service" pretty heavily to make the data-type collections / endpoints and the search service / endpoint look like the same thing -- that's a level of abstraction that doesn't provide a whole lot of leverage for me.
I feel like we, collectively, have a pretty good feeling for how search ought to work, given that I think every single member of the team has implemented at least one search service in the past, and as such we don't need to be too too experimental about how we implement our search service. The access patterns around storage and representation and the usage patterns around search are different, both conceptually and concretely, than the other data types we work with. I can see search broadening (to deal with things like location data), and I do see commonalities (from a superficial, protocol level), but I feel pretty strongly that trying to force them to fit the same mold is to awkwardly juxtapose two concepts that don't fit together too naturally.

Seems like a good time/place to talk levels of abstraction: it's all about services.  Services have always been about a single level of abstraction that embodies isolation (process+code), a namespace (http endpoint + fs dir), access (talk to other services, send/receive events), and a bit of scheduling.  While you can group them by different themes (connectors, collections, and even apps) they are still one clear level of abstraction, they are all peers in a person's data micro-ecosystem.
There's always been a deep intent to embrace a very open sense of innovation and experimentation in services, any dev should feel encouraged to clone one and extend it for a different purpose.  In the long run there will be competition and decay, the namespaces and which other services you choose to depend on are a dynamic thing, an organic evolution not a clean directory. Each service can strive to internally be a clean and powerful set of utilities around the value it's adding in either mapping in external data/utilities or building on existing local data, but there should be a growing directory of services available, something the registry will help enable and accelerate.
On search, I /do/ think we need to be experimental, and iteratively so, this is a step forward from clucene on that path and with r-trees available and the ability to do structured joins, there's a lot of untapped potential, which could happen inside of this service or inside of places or any other service by just copying the working patterns here (it's not that much code), I'm not idealistic about where that happens as long as it just happens :)  I'd rather see the functionality being created closest to where it's needed first, before trying to fit anything into a mold, and in this case we had done exactly that with search previously (was in two places) that happened to be the same mold, a simple text-based user facing search with optional type filtering and time sort.
Every service is going to have very different conceptual and concrete patterns around usage, storage, representations of data, that's something that makes them powerful as a participant in this mini ecology.

+1 on erictj's bitcoins.
This pull is more about crossing off clucene and replacing it with something functional rather than any sort of reorganization. While the specific word "Collection" for search does feel strange, that is entirely tangential to whether this is a step forward for this component of the system.
I'm excited to see all this get in when we are able!

I agree that first and foremost we need a search API that works. If CLucene isn't getting us there, then we absolutely need a replacement. I will point out here that this morning was the first time I'd heard the discussion framed in terms of CLucene being technically unacceptable rather than it being risky to depend on an EOL / dead project. That definitely recalibrates the priority.
My point of view resembles Eric's from the beginning of his final paragraph. Having an /index and /query endpoint exposed per Collection is the concrete version of the "cross-cutting concern" I was mentioning previously.
Furthermore, the reason I've spent so much time on distinguishing between service, collection, API, and related concepts is that it has been a source of ongoing confusion for me understanding why the system is laid out the way it is, and a good chunk of that confusion was rooted in not always having a solid grasp on which pieces of the architecture the team considers central and which are considered peripheral. Nomenclature is important.
Jer, I think you and I are thinking about abstraction in different ways, maybe. I'm largely preoccupied with the structure and type of the data, and you seem more interested in the flow of the data. I say this because I don't really see the kind of abstraction you were describing as particularly germane to this distinction. For me, the sticking point is that search is an activity (or verb) and Collections represent aggregates of documents (nouns). It seems to me that to say they're the same because they're both based on documents (some to be indexed, some to be browsed) is to rely on a very technical understanding of search that doesn't map well to how the two different things are used. I know there's overlap, but I think they are different kinds of data, and trying to make them fit together doesn't make sense.

I'm def thinking more of the flow, and I get the verb/noun thing, but don't want to constrain services in that way either.  This is mostly the search collection because that's what it was already, I just replaced the back-end, in a more true sense as I said earlier it's the "text collection" that has a query api :)
IMO also def see this evolving however it should best for the other collections, probably with them doing their own search, this collection is an excellent pattern to copy off of for that and for others like it.


Issue template for bug report.

As discussed in today's community meeting, added issue template for bug report.

Please rebase your PR so that all commits follow the conventional commit message format: https://www.conventionalcommits.org/en/v1.0.0/

@metacosm I updated all the messages with style tag as we are adding template/styling for our issue/bug creation process. I squashed all the commits as well.

Thank you!


Progamatically show/hide operator, rule and group button

Hello ,
I am looking for a way to only add groups(hide the add rule button) on base level with only OR operator selected(AND would be disabled here). Whenever the said group is added the operator allowed will only be OR (hiding AND operator). Now, nested groups are allowed but only to one level i.e. hide the Add Groups button whenever a group is added on base level.
I am using React 16.8.0 with  react-querybuilder: "^3.1.2"
For ex. as shown below i want to hide the marked buttons. Would it be possible?

Thanks for the support

I was able to hide the rule and group buttons using css:

.queryBuilder>.ruleGroup.ruleGroup>.ruleGroup-header>.ruleGroup-addRule{
display: none;
}
.queryBuilder>.ruleGroup.ruleGroup>.ruleGroup.ruleGroup .ruleGroup-addGroup{
display: none;
}

But, still need some help on, how do I ensure that base group's operator is always OR combinator and all the subsequent sub-groups will be AND operator.

Solved it! can check at https://stackblitz.com/edit/react-6g5ygt


Implement Package URL into all standard reports

Abstract
There are inconsistencies in how identifiers are represented in the XML reports, both with regard to schema and the format of data.
Observations
It appears that the identifier on relatedDependencies is only used for Maven projects which greatly reduces the usefulness of the element. It also appears the dependency-check schema is inconsistent between dependency and relatedDependency. One has a list of identifiers, the other only has a single identifier without any evidence. If a parser is using Jackson, or similar XML to object deserialization technique, both representations would need to be implemented on a single Dependency object resulting in fragile, less than ideal code.
In addition, the identifier on the dependency node has a slightly different format than the single identifier on the relatedDependency node.
Recognition
Ideally, the solution would be to standardize both the schema and the format of data in the report. However, this may introduce breaking changes throughout the ecosystem.
Proposed Solution
Leverage the Package URL specification to provide a structured, predictable, and supportable format to identify a components ecosystem and its relevant metadata for every dependency and relatedDependency.
The Package URL specification has already been implemented in Dependency-Track. Refer to https://docs.dependencytrack.org/datasources/routing/
The official Package URL Java implementation is located here: https://github.com/package-url/packageurl-java . This library will automatically create canonicalized Package URLs that adheres to the current specification.
The proposed solution should NOT modify the existing XML schema.
Examples
<identifiers>
    <identifier type="maven" confidence="HIGH">
        <name>(org.apache.commons:io:1.3.4)</name>
    </identifier>
    <identifier type="package-url" confidence="HIGH">
        <name>Generated Package URL</name>
<EMAIL_ADDRESS>    </identifier>
</identifiers>

<identifiers>
    <identifier type="package-url" confidence="HIGH">
        <name>Generated Package URL</name>
<EMAIL_ADDRESS>    </identifier>
</identifiers>

<identifiers>
    <identifier type="package-url" confidence="HIGH">
        <name>Generated Package URL</name>
        <url>pkg:gem/jruby-launcher@1.1.2?platform=java</url>
    </identifier>
</identifiers>

<identifiers>
    <identifier type="package-url" confidence="HIGH">
        <name>Generated Package URL</name>
<EMAIL_ADDRESS>    </identifier>
</identifiers>

I would completely agree. I've also been reconsidering the entire "related dependencies" concept.
BTW - In your first example:
    <identifier type="maven" confidence="HIGH">
        <name>(org.apache.commons:io:1.3.4)</name>
    </identifier>

There are erroneous placed parentheses around the identifier. This was a mistake and they will be removed in the next version.

Package URLs are now being used in the 5.x branch. In some cases we are unable to identify a dependency (most common in Cli, Ant, and Jenkins scanning) and thus no package URL will be in the report.
Lastly, we are considering removing the DependencyBundlingAnalyzer which creates the "related dependencies" section of the report.


OpenAIWhisperParser raises error if audio has duration too close to the chunk limit

System Info
LangChain: 0.0.250
Python: 3.11.4
OS: Pop 22.04
Who can help?
@agola11
@eyurtsev
Information

[ ] The official example notebooks/scripts
[X] My own modified scripts

Related Components

[ ] LLMs/Chat Models
[ ] Embedding Models
[ ] Prompts / Prompt Templates / Prompt Selectors
[ ] Output Parsers
[X] Document Loaders
[ ] Vector Stores / Retrievers
[ ] Memory
[ ] Agents / Agent Executors
[ ] Tools / Toolkits
[ ] Chains
[ ] Callbacks/Tracing
[ ] Async

Reproduction
Input
from pathlib import Path

from langchain.document_loaders.blob_loaders.schema import Blob
from langchain.document_loaders.parsers.audio import OpenAIWhisperParser

OPENAI_API_KEY = "<MY-KEY>"

audio_file = Path("~/Downloads/audio.mp3").expanduser()
audio_total_seconds = AudioSegment.from_file(audio_file).duration_seconds

print("Audio length (seconds):", audio_total_seconds)

blob = Blob.from_path(audio_file, mime_type="audio/mp3")
parser = OpenAIWhisperParser(api_key=OPENAI_API_KEY)
parser.parse(blob)

Output
Audio length (seconds): 1200.064
Transcribing part 1!
Transcribing part 2!
Attempt 1 failed. Exception: Audio file is too short. Minimum audio length is 0.1 seconds.
Attempt 2 failed. Exception: Invalid file format. Supported formats: ['flac', 'm4a', 'mp3', 'mp4', 'mpeg', 'mpga', 'oga', 'ogg', 'wav', 'webm']
Attempt 3 failed. Exception: Invalid file format. Supported formats: ['flac', 'm4a', 'mp3', 'mp4', 'mpeg', 'mpga', 'oga', 'ogg', 'wav', 'webm']
Failed to transcribe after 3 attempts.

Expected behavior
Due to its internal rule of processing audio in 20-minute chunks, OpenAIWhisperParser is prone to crashing when transcribing audio with durations that are dangerously close to this limit. Given that OpenAI already has a very low audio length threshold of 0.1 seconds, a simple bypass could effectively resolve this issue.
# https://github.com/langchain-ai/langchain/blob/master/libs/langchain/langchain/document_loaders/parsers/audio.py#L47

chunk_duration = 20
chunk_duration_ms = chunk_duration * 60 * 1000
chunk_length_threshold = 0.1

# Split the audio into chunk_duration_ms chunks
for split_number, i in enumerate(range(0, len(audio), chunk_duration_ms)):
    # Audio chunk
    chunk = audio[i : i + chunk_duration_ms]
    if chunk.duration_seconds < chunk_length_threshold:
        continue

I think it's relevant, although not a priority.


Check for CommonJS before AMD

Scenario

I'm building an embeddable widget using Browserify.
Some client sites already have RequireJS loaded on the page, so define() is defined
Some of my CommonJS dependencies use UMD
So... these UMD dependencies suddenly can't be resolved since the UMD wrapper decides that this is an AMD context.

Solution
I think the solution is pretty simple - simply check for module.exports before checking for define. Browserify - unlike RequireJS - doesn't need to pollute the global namespace so the likelihood of module and exports being globally defined is low.
Thoughts?

This normally is not a problem -- I thought the browserified bundles were generated wrapped in a closure with var define set to undefined if I recall correctly, so that anything in the browserified bundle should be self-contained. Maybe that is the "standalone" option in the browserify options?
Maybe diving more into how the bundle is generated might give more insight to the issue.

Hey @jrburke -
That's right - Browserify builds are self-contained. AMD loaders, by contrast, tend to define window.define and window.require in order to support async loading.
In my scenario (please re-read the "scenario" portion) - I'm using Browserify to bundle all dependencies into a single self-contained script. Some of my dependencies are use the UMD format.
The UMD code currently checks for AMD before CommonJS:
if (typeof define === 'function' && define.amd) {
    define(['b'], factory);
} else if (typeof exports === 'object') {
    module.exports = factory(require('b'));
}

Because define and define.amd are defined on the window object on client sites, the AMD test is positive event though this code is part of a Browserify bundle. Oops!
The fix is to simply switch the order of the tests:
if (typeof exports === 'object') {
    module.exports = factory(require('b'));
} else if (typeof define === 'function' && define.amd) {
    define(['b'], factory);
}

Problem solved! Since Browserify builds are self-contained, module and module.exports shouldn't be globally defined so the reverse problem (loading CommonJS when you want AMD) is unlikely to occur.
Make sense?

Sorry, I was a bit rushed in posting before: I was trying to indicate that any build tool that collects a bunch of modules that can have UMD forms need to adequately seal the environment, since they cannot guarantee the order in which a module may test for module environments.
If a user using AMD builds with r.js optimizer and almond for a set of self-contained modules, almond defines a local define for that set, it is not using the global one.
While it is true that usually AMD module systems do have a global define/require set up, it is not a guarantee that they are, just more likely.
Similar to the bundled AMD build case which encapsulates the AMD/CJS module APIs in a closure, I am pretty sure browserify also has an option for that, so I was trying figure out how we can solve the problem you had, since changing the suggestions here will not lead to fixing the problem you observed. The suggestions in this repo are just suggestions.
So if this issue is about figuring out the best way to use browserify to make sure this problem does not occur, we can do that. If you just feel like the AMD definitions should come second in this repo of suggestions, I'll let other contributors to this repo decide on that. I do not believe it will solve the issue though as module bundlers need to be aware of both formats since modules are authored by a wide range of people, and so a range of UMD-type module detection blocks.

@jrburke - Thanks for your detailed reply! Sorry for delaying in getting back.
Your suggestion that Browserify redefine define within its bundled closurescope makes excellent sense. The Browserify documentation is unfortunately lacking on this point, but it looks like Browserify's --standalone option enables this "sealing" by adding the following inside a wrapping closure:
var define, module, exports;

That will solve my problem. I've added a comment https://github.com/substack/node-browserify/issues/1073 proposing that this behavior be enabled by default.
While I still think that checking for CommonJS before AMD is a safter default, I agree that sealing the module bundle is needed regardless.

+1 This is how mozilla/localForage does it as well.

@jrburke - There is another reason to do so because webpack hacks AMD codes into CommonJS. Despite the performance costs of transformation, present order makes it difficult to detect weather the environment is using AMD or CommonJS for further function.

@HQidea my previous comment applies for webpack too. There are other owners for this repo that can manage an ordering pull request, but it is not something I want to spend time on.

Ok.. so background.. This is how it used to be, in fact here is the patch that changed the order.
And, this blog ran into the problem that caused this..
Update: @BlaineBublitz pointed out the above UMD wrapper is incorrect as the AMD build tools will expose exports as an object. Thus we should check for AMD first for the above to actually work.

The funny thing is, I copied the above UMD example directly from https://github.com/umdjs/umd. I don't want this post to rag on UMD because UMD has very good intentions. But it kind of drives the point home that even UMD's own examples are incorrect.

Update 2: Kudos to @BlaineBublitz for sending a pull request and fixing this issue: https://github.com/umdjs/umd/commit/992cc0d071b7ebcd7feaad2a5349bdbeab09a0fe

So just focusing on this

Update: @BlaineBublitz pointed out the above UMD wrapper is incorrect as the AMD build tools will expose exports as an object. Thus we should check for AMD first for the above to actually work.

It's at odds with your statement

I think the solution is pretty simple - simply check for module.exports before checking for define. Browserify - unlike RequireJS - doesn't need to pollute the global namespace so the likelihood of module and exports being globally defined is low.

Turns out that AMD build tolls expose exports as an object which would throw this into CommonJS mode. What say you?

Ok, researching this further, it looks like one template has a fix nodeAdapter.js
typeof module === 'object' && module.exports && typeof define !== 'function' ?

@aldendaniels said,

That's right - Browserify builds are self-contained. AMD loaders, by contrast, tend to define window.define and window.require in order to support async loading.

So it makes me wonder if whatever problem you're experiencing could be alleviated with making CommonJS's test first, and adding that condition that typeof define !== 'function'. Is there any case where we want CommonJS behavior and typeof define == 'function'?
I'm just brute forcing this and auditing. Please give some input guys.

I'm going to close this. Feel free to reopen it with response.

Hello, we are running into this problem as well. With the rise of webpack, which understands all module types under the sun, we are running into the problem where the ordering of the define and module.exports matters.
We have tested it with webpack, and switching the order to check for CJS first includes our module as we'd expect. If this order is not changed we then have to alias all the paths in our libraries because webpack doesn't use the same path system as requirejs.
I feel this is a reason to change the UMD templates


Make react the default view in preparation for test tomorrow

Oh are we testing tomorrow? Is a subteam using SB for the UMD hunt?
On Fri, Jan 1, 2021, 4:41 PM Ryan Liu<EMAIL_ADDRESS>wrote:

@asdfryan https://github.com/asdfryan requested your review on: #281
https://github.com/cardinalitypuzzles/smallboard/pull/281 Make react
the default view in preparation for test tomorrow.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/cardinalitypuzzles/smallboard/pull/281#event-4161359108,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTQKHOUOKWUGG3IGPC7H4DSXZTUDANCNFSM4VQU22MA
.

Oh are we testing tomorrow? Is a subteam using SB for the UMD hunt?
On Fri, Jan 1, 2021, 4:41 PM Ryan Liu<EMAIL_ADDRESS>wrote:

@asdfryan https://github.com/asdfryan requested your review on: #281
https://github.com/cardinalitypuzzles/smallboard/pull/281 Make react
the default view in preparation for test tomorrow.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/cardinalitypuzzles/smallboard/pull/281#event-4161359108,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTQKHOUOKWUGG3IGPC7H4DSXZTUDANCNFSM4VQU22MA
.


Validator

Pull Request Description
What issue does this change request address?
Closes #23
What are the significant changes in functionality due to this change request?
Introduces the Validator class.
The Validator is called on-demand by the Dispatcher classes whenever they have a need to; if no Validator is used, then no errors are raised.
If a Validator finds problems, then it reports these problems back to the Dispatcher, who can do whatever it wants with the information.
For an example of usage, see the ExampleValidator, who takes the silly approach of demanding the delta between any two production/consumption activities to be no greater than 0.2, a very arbitrary value for demonstration purposes.
By comparing the production_flex and validator tests, you can see the validator forces a phased approach to changing production levels, rather than a sudden change. This includes changes to the pyomo_dispatch to accomodate taking new limit constrictions from the Validator's concerns.

For Change Control Board: Change Request Review
The following review must be completed by an authorized member of the Change Control Board.

[x] 1. Review all computer code.
[x] 2. If any changes occur to the input syntax, there must be an accompanying change to the user manual and xsd schema. If the input syntax change deprecates existing input files, a conversion script needs to be added (see Conversion Scripts).
[x] 3. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the wiki for details.
[ ] 4. Automated Tests should pass.
[x] 5. If significant functionality is added, there must be tests added to check this. Tests should cover all possible options.  Multiple short tests are preferred over one large tes.
[x] 6. If the change modifies or adds a requirement or a requirement based test case, the Change Control Board's Chair or designee also needs to approve the change.  The requirements and the requirements test shall be in sync.
[x] 7. The merge request must reference an issue.  If the issue is closed, the issue close checklist shall be done.
[x] 8. If an analytic test is changed/added, the the analytic documentation must be updated/added.
[x] 9. If any test used as a basis for documentation examples have been changed, the associated documentation must be reviewed and assured the text matches the example.

Modifications are good to go. No comments on coding style or functionality.
Since CIVET is not running yet, did you test this manually and so, can you report the result of the regression testing?

Results of regression test:
out.log

Checklist passed.
PR can be approved.
Merging...


Add .gm fly

Changes Proposed:

Issues Addressed:

Closes

SOURCE:

Tests Performed:

How to Test the Changes:

Merge conflict here for some reason

Merge conflict here for some reason

⛔ - Resolving conflicts
✅ - Make a new branch


Unable to load custom HBase configuration files

https://issues.apache.org/jira/browse/CAMEL-11692

I screwed up the fix for this. Hence waiting for a release containing:
https://issues.apache.org/jira/browse/CAMEL-11944


ENH: Display a dialog to save trans and fids before quitting the coreg app

This PR basically rewrites the closeEvent() function to allow displaying a dialog in the coreg app in case the user did not save trans.
It is still work in progress. In its current state, it works but the code to achieve it needs refactoring. Plus it does not save the fids yet.
Closes #10236

https://user-images.githubusercontent.com/18143289/152819894-dea04c8d-7b7e-46a2-93a7-998078e67ef7.mp4

I will extract the changes made to the GUI API in another PR. I also have to work on a notebook alternative and testing.

If you haven't started, I think it's okay to do the notebook separately. The Qt interface is much more commonly used here

Okay then, let's go with Qt first.

@GuillaumeFavelier since we're not releasing until next week sometime, I optimistically marked this for 1.0. Let me know when it's ready to test! From a quick look at the code, it looks reasonable so far

This is the wrong prompt, it should prompt about the fiducials:
$ mne coreg -s sample -d subjects --fif MEG/sample/sample_audvis_raw.fif --trans MEG/sample/sample_audvis_raw-trans.fif

https://user-images.githubusercontent.com/2365790/154496353-4ebe5f01-bb1f-4642-8366-e2e7c295cf52.mp4
Also from a UI perspective I expected save/discard/cancel, where save does save-then-exit, discard does exit (without save), and cancel aborts the exit operation (without save) so that the user can do other things.

Thanks for the feedback, I will rework all of that :+1:

During one interaction I got a segfault caused by:
  File "/Users/larsoner/python/mne-python/mne/viz/backends/_qt.py", line 64, in func
    callback(button_name)
  File "/Users/larsoner/python/mne-python/mne/gui/_coreg.py", line 1740, in _close_dialog_callback
    assert button_name == "Discard"
AssertionError

It was for MRI fiducials, and the button was labeled "Don't save". I think "Discard" is more common in UI designs.
Also, any Qt event handler should be wrapped with @safe_event so that, even if there are bugs like this, the UI does not segfault.

When I load, lock fids, set to uniform scale mode, then set scaling to 99 instead of 100, I get a box saying that the head<->MRI transform is not saved. This is actually not correct -- it is the head<->MRI trans I loaded, what I didn't save was the "scaled subject MRI". So I think you need to track three states:

MRI fids modified
trans modified
MRI scale modified

Another point -- when the dialog comes up, if I click "Save", it correctly pulls up a save dialog. But if I then hit "cancel" on the system dialog -- and thus don't save anything -- the UI still exists. I think it should only exit if the user actually saved a file. In this sense, the cancel of the system dialog works like the cancel of the previous dialog, and the only way a user can "lose their work" is if they actually click the "Discard" button.

the button was labeled "Don't save".

Oh no, on my system the name is Discard so this button.text() is not standard or the button itself is not.

So I think you need to track three states

I see

the only way a user can "lose their work" is if they actually click the "Discard" button.

Makes sense

Oh no, on my system the name is Discard so this button.text() is not standard or the button itself is not.

Okay so it's a standard (my version of) macOS thing, that's fine -- just update the assert or remove it

Hopefully it's good enough now :pray:

I still got:
(base) bunker:MNE-sample-data larsoner$ mne coreg -s sample -d subjects --fif MEG/sample/sample_audvis_raw.fif --trans MEG/sample/sample_audvis_raw-trans.fif
Traceback (most recent call last):
  File "/Users/larsoner/python/mne-python/mne/viz/backends/_qt.py", line 67, in func
    callback(button_name)
  File "/Users/larsoner/python/mne-python/mne/gui/_coreg.py", line 1765, in _close_dialog_callback
    assert button_name == "Discard"
AssertionError
Fatal Python error: Aborted

when I tweaked a fiducial, hit the X to close, then hit "Don't save". I pushed a commit to get rid of the assertion

What is the exact value of button_name that is compared to 'Discard' on your system?

I put it in the code commented out

... more specifically:
        #     assert button_name in ("Discard", "Don't Save"), button_name

You checked windows to make sure this is correct there?

While testing https://github.com/hoechenberger/mne-installers on Windows, I ran mne coreg -s sample -d subjects:

So it uses "Discard" too!
I also ran into other bugs specific to Windows but now I can debug properly and fix them in another PR.

crash during _configure_status_bar
hangs while using _CheckInside

I also ran into other bugs specific to Windows but now I can debug properly and fix them in another PR.

Great -- I would say these are high priority since they will probably make the coreg gui unusable on Windows :(
It now works for me on macOS, thanks @GuillaumeFavelier !

I'll work on windows for a while to fix those 👍


Evaluate low-pass filter again

I found out that the existing low pass filter by "synthrs" library doesn't do what I expected it to do. It outputs more values than I put into it.
Try to implement a very simple low-pass filter by myself and evaluate again. Good enough for "simple" songs?
We could provide multiple beat-detection algorithms anyway.

[ ] check accuracy with most simple low pass filter
[ ] check accuracy with most simple low pass filter and overlapping samples

see crate "lowpass-filter"


Add EitherValuable

In Scala 2.13.x, the RightProjection is deprecated (this time for good: https://github.com/scalatest/scalatest/pull/975).
So you can no longer write (without a deprecation warning about right):
val either: Either[String, Int] = Right(5)

either.value.right should ===(5)

So I added EitherValuable which has rightValue and leftValue.

Oh, I opened #1775 without seeing this PR first, I think either approach is good.

I lost interest in this


Stuck in "Setting up default database tables in directory"

Hi, I can't create serverpod project, it seems to generate the flutter directory fine, but it get stucked at this point:
Setting up default database tables in /directory...
And I don't see any error message either.

Hi! Any chance you can do a flutter doctor and paste the output here?

flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 2.10.2, on macOS 12.1 21C52 darwin-arm, locale
en-GB)
[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 13.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2020.3)
[✓] VS Code (version 1.64.2)
[✓] Connected device (2 available)
[✓] HTTP Host Availability
• No issues found!
serverpod create squadhead
Creating project squadhead...

Running dart pub get in /Users/kousikambani/Development/tools/squadhead/squadhead_client
Resolving dependencies...

async 2.8.2
charcode 1.3.1
collection 1.15.0
crypto 3.0.1
http 0.13.4
http_parser 4.0.0
meta 1.7.0
path 1.8.1
serverpod_client 0.9.4
serverpod_serialization 0.9.4
source_span 1.8.2
stream_channel 2.1.0
string_scanner 1.1.0
term_glyph 1.2.0
typed_data 1.3.0
web_socket_channel 2.1.0
yaml 3.1.0
Changed 17 dependencies!

All done!
In order to run your application, type:
$ cd .
$ flutter run
Your application code is in ./lib/main.dart.
Setting up default database tables in /Users/kousikambani/Development/tools/squadhead/squadhead_server

Hi I was managed to solve the issue,
I had to keep docker open , So I guess it should be written in the doc.

Great! I will add that to the dock, thanks for letting me know!


Hourly weather with OpenWeather doesn’t show precipation data (always 0%).

I'm seeing this too.

Fixed on my fork and made a pull request too


How do I build from source?

Hi, I cloned this repo and ran go build and got this error:
no Go files in C:\Users\milo5\Desktop\GitHub\triangula

Any ideas on how I can build from source?
My antivirus doesn't let me download the gui so I'm trying to self build it. Thanks!

I don't believe this repo has a main function, so if you want the gui, you'll need to run go build on https://github.com/RH12503/Triangula-GUI or for the cli, you need to run go build triangula/main.go on https://github.com/RH12503/Triangula-CLI.
I'm not sure what's up with the Virus Scanner though. I ran the latest 2 versions (Windows, Linux, and Max) against Virus Total and it didn't have a problem. If you could list your virus scanner, that'd be helper for the author to be able to investigate.

Oh, thank you.

Thanks @alexis-evelyn! Is your issue resolved now @Milo123459?

I don't believe this repo has a main function, so if you want the gui, you'll need to run go build on https://github.com/RH12503/Triangula-GUI or for the cli, you need to run go build triangula/main.go on https://github.com/RH12503/Triangula-CLI.
I'm not sure what's up with the Virus Scanner though. I ran the latest 2 versions (Windows, Linux, and Mac) against Virus Total and it didn't have a problem. If you could list your virus scanner, that'd be helpful for the author to be able to investigate.

What does this repo contain exactly then?


fix: Added support for generating docs for referenced types

Closes https://github.com/ipfs/aegir/issues/1130

This PR originally had excludeExternals set to true - I couldn't see what it did here so I removed that line.  If it's solving a problem could you open a new PR that re-enables it and expand the docs tests to show what it's used for and to prevent regressions?

This PR originally had excludeExternals set to true - I couldn't see what it did here so I removed that line.

This was to prevent projects which may reference classes which are built into the language (e.g. HTMLElement), from generating documentation for those references.  If that's not a commonality for aegir managed projects then it wouldn't make a difference.


fix: Remove data resource for sns topic to avoid race condition

Description
Remove the SNS Topic Data Resource and instead craft the SNS Topic ARN as a string.
Motivation and Context
Data Resources are evaluated before any code is executed, so if a single terraform apply intends to create an SNS topic and create this module, the apply will fail because the data resource cannot resolve.  Avoiding the use of data resources by deriving the SNS manually corrects the issue in this case.
#46
Breaking Changes
This should not affect any existing deployment aside from seeing a change from removing a data resource.
How Has This Been Tested?
Using the examples

This PR works for me.

@antonbabenko Why has this PR not been reviewed? create_sns_topic = false with sns_topic_name       = blah is broken if blah does not already exist.


Integrate with django-stubs

@timabbott
I'm working on a Django plugin for mypy here
https://github.com/mkurnikov/django-stubs
I want to integrate it into Zulip next, it's the biggest Django project I could find on GitHub and it already heavily invested in mypy.
Some questions:

For now, I completely ignore strict-optional = True , would it be a blocker for Zulip?
I test with Django 2.1.x, Zulip is still on 1.11.x. I see there is a PR to change that
https://github.com/zulip/zulip/pull/11307. Although, most of the stubs should be compatible.
PR is going to be HUGE, how would you prefer it to be submitted? Split in small files, or as one big chunk?

Edit from tabbott: See also the earlier duplicate https://github.com/zulip/zulip/issues/991.

@mkurnikov awesome!  As you say, we're highly invested in mypy and integrating with some sort of Django stubs is the big open TODO item for making our mypy setup even better (as with Django, we have a ton of implicit Anys from Django stuff).

For now, I completely ignore strict-optional = True , would it be a blocker for Zulip?

We use strict-optional by default but have it turned off for many files; probably it can be turned off for the Django stubs as well?  See our mypy.ini in this project for the current setup.
https://zulip.readthedocs.io/en/latest/testing/mypy.html is probably also useful reading.  If you want to dip your toes in for getting a feel for how we do our work, you could do the upgrade to yesterday's mypy release; those generally are pretty quick.

I test with Django 2.1.x, Zulip is still on 1.11.x. I see there is a PR to change that #11307. Although, most of the stubs should be compatible.

As you can see, #11307 is a pretty small PR; probably you can test against master and it'll be fine.  If that turns out to not be true due to actual Django version differences, we can think about either including #11307 in your branches or something else. It'll probably merge in a few weeks in any case.

PR is going to be HUGE, how would you prefer it to be submitted? Split in small files, or as one big chunk?

See https://zulip.readthedocs.io/en/latest/contributing/version-control.html for a sense of how we typically do commits in the project.  It's definitely worth breaking things up into individual commits that are O(100) LOC or less and pass Zulip CI and submitting those as you're confident in their changes.  That way, I can review, give feedback on the approach, and merge those commits as we go along.
I'd start with a commit that adds django-stubs as a dependency (with a pinned version; see https://zulip.readthedocs.io/en/latest/subsystems/dependencies.html for how we manage Python deps), and add an option to tools/run-mypy to use the stubs, so everyone can use the same tooling for type-checking with this tooling as we work on integrating things.  That option might require a temporarily forked mypy.ini kept under stubs/ or something (and then the option to run-mypy would just use the different mypy.ini).
I think there's a few good ways to split up the actual annotation changes -- by particular Django feature or by file.
You can also start a thread on #backend > django stubs or something on chat.zulip.org for more tactical discussion about the project as you go along.

@mkurnikov just wanted to check in on where you are on this and whether there's anything we can do to help!  And to again invite you to start a thread on #backend on chat.zulip.org to talk through things as you get started.

I tried to start, found the task too complex, and decided to postpone till better times:)
Just

I'd start with a commit that adds django-stubs as a dependency

gives me ~3000 lines of errors because of all those # type:  comments like
content = models.TextField()  # type: str

Makes sense.  Those lines of course are exactly what we want for having mypy consider the message.content field to be a string in code that interacts with that field as you would want, but obviously require some fancy logic on the Django side to handle.

Just an update: Zulip is now on Django 2.x.

Also worth mentioning that https://pypi.org/project/django-stubs/ is probably the right project to use these days.

I'm now picking this up. My first attempt was to simply add django-stubs to the requirements. But apparently, there are way too many mypy errors for us to fix manually. So perhaps we need to first figure out a way to solve some of the easy ones through scripting. @zulipbot claim

I posted a comment on the PR with some notes on strategy for this; I actually am very encouraged by the results of this initial attempt.


Brief Host Changes

Commit messages explain most of what happened. Some basic cleanup before beginning to do some more serious host work.

I'm not sure what I changed that's causing the integration test to fail, but the renter is no longer able to upload files.
@lukechampine ideas?

I've confirmed that it's my corrections to the way the host is calculating the height, but I'm not sure why that's significant.

The build failed a few times due to timestamping problems with consensus. I wasn't able to get to the root of the problem because by the time I had added debugging statements, the problems had stopped. Possibly a buggy clock on the Travis side, it wasn't code should be failing nondeterministically.
I've added some extra debugging info

updated


My bug report: output color of Receive-job loses

Steps to reproduce

Build a dotnet project with template blazorserver or anything that has colored output.

Run the following:

start-job {dotnet run}
receive-job -wait 1

Expected behavior
The output should be colorful.
Actual behavior
The output is all of the white chars.
Environment data

Name                           Value
----                           -----
PSVersion                      7.1.0
PSEdition                      Core
GitCommitId                    7.1.0
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Note that many utilities, notably those with a Unix heritage, conditionally apply coloring (via VT / ANSI escape sequences) to their output, namely based on whether their stdout stream is connected to a terminal (DO color) or not (do NOT color).
Background jobs aren't directly connected to a terminal, which probably explains why you're not seeing colored output.
At least some GNU utilities (preinstalled on Linux platforms) allow you to unconditionally request colored output,
using --color=always, such as  ls and grep.


Verify that start_indices have the same type in DynamicSliceOp

inferDynamicUpdateSliceOp also has the same verification logic, so I've moved the duplicate logic to variadicTensorsHaveSameElType function.
closes #557

The function tensorsHaveSameElType right above variadicTensorsHaveSameElType is very similar in terms of functionality. We can consider to merge these functions together which requires some thinking of how to handle variadic tensors vs fixed-length inputs to the unified function.


Tech Leaders Pride

A bot a command that would return a random Tech leader in the LGBTQ community, with a picture of them, a small write up of who they are, what they do, and how they represent the community. possible bot command could be !techlgbtq

Adding a command to showcase notable LGBTQ+ community leaders active in the tech industry sounds good.
I would recommend though simplifying the command name. Most of the pride commands should be trying to have a similar command name structure to keep things easy to remember, so using the currently approved .prideavatar command as a basis, .prideleaders or similar would be better.

.pridehero or .prideleader seems good. plural strikes me as odd.

@MadisonMcdonald said she's going to work on this one.

@MadisonMcdonald Hey Madi, how are you doing on this issue?

I wnt to work on this :)

I've assigned you @Anubhav1603.
Feel free to ask any clarification questions if needed, and since it'll likely involve a decent amount of prose-like information, be sure to have at least another set of eyes go over the text for spell-checks/grammar to avoid needing to do so during code review.

I will take over PR #485. Thanks


Create zh-tw.toml

language support for Traditional Chinese (zh-tw)

If you like, you can create this PR in the fork.
Hint: The fork contains some additional text!


$award command functions

So I recently got Nadekobot on my Discord.
And I've been trying to use the $award command in order to plant them in our channels for fun.
So far I've tried several different methods of using the command, the bot recognizes the command, but it doesn't do anything.
$award @name 5
$award 5 @name
$award "5" @name
$award @name "5"
Is there anything I'm missing with the method of writing the $award command? Or do you have any ideas on the issue?

a. It's bot owner only, ie. your id must be in the credentials.json/ownerIds array.
b. Syntax should be $award 5 @person


Cannot see any project!

Please give a detailed description of the issue you’re experiencing or the feedback you’d like to provide.
Feel free to attach any relevant screenshots or logs, and please keep the app version and device info in the issue!

App Version: 3.1		Device: iPhone 12
OS: iOS 17.2

Version 3.2.1 of Zeitgeist, now available in the App Store, fixes the bug that prevented projects from being loaded correctly. Thanks for your patience!


Version Compatibility

I'm making this issue for discussion, as the suggestion by @visuallization in #71 is worth noting, the python module works either on Godot 3.5 or 4.0, and the addon code is now a submodule, so we could go back to having a single branch here and let users select for which version download examples and the addon.
This also applies to the C# ONNX loader, most of it could be written as version independent

This sounds good, it's easier to maintain as well.

Closing


Added support for AMD require to angular-ui-router.d.ts

Added support for AMD require to angular-ui-router.d.ts

@wiredprogrammer thanks mate!

note
https://github.com/angular-ui/ui-router/blob/master/release/angular-ui-router.js#L9-L11


Add support for logrotate scripts

also added trusty to platforms

@bigjust Thanks for adding the tests too!


Hi Team, while creating a new job to sync content between two AEM 6.3 instances curl command is failing

Thanks for taking the time to fill out an issue! To help the community solve your issue, please provide answers to the following questions, along with supporting log and configuration files.
What version of AEM are you running?
How do you produce the issue?
Does the issue occur consistently?
Any additional details?

Closing as duplicate of #200.


Sample Data change UX for horizontal scrolling (and vertical)

Is your feature request related to a problem? Please describe.
I have a table with 142 columns. However there are no vertical or horizontal scrolls bars. For vertical scrolling I can use the mouse, but for the horizontal scrolling - I have to use the mouse pad and two touch points or arrows on my keyboard.
I have tested it withy couple users and none of them realized that they should do a horizontal scrolling. The arrows right ONLY appears after using left arrow or mouse pad.

Describe the solution you'd like
A horizontal scroll pad on screen (rather than having to use the mouse pad or arrows).
like

Describe alternatives you've considered
teaching users that there is possibility to scroll, but I can't teach every user,..
Additional context
1.0. UI, Sample Data

#harsha will be picking this one once finished with the separate column issue!

@Ashish8689  hello, was this addressed in 1.0.2 still same inconvenience with Horizontal Scrolling:
https://sandbox.open-metadata.org/table/sample_data.ecommerce_db.shopify.dim_customer/sample_data.
try scrolling horizontally, so seeing all 29 columns just using a standard mouse.

@DovileKr You can use the shift key with Mouse to perform a horizontal scroll, Don't need a mouse pad or arrow keys, Give it a try and let me know if that's works


Add IPFSBay

Unstoppable marketplace in the IPFS network.
What kind of PR is this?
Select only one to speed up review/approval; i.e., don't lump an addition and a removal into a single PR.

[x] Adding something new to awesome-ipfs
[ ] Editing something already listed on awesome-ipfs
[ ] Removing something from awesome-ipfs
[ ] Something else (if so, please explain in the "Additional details" section below)

Pre-submit checklist
Please confirm ALL of the following before submitting your PR.

[x] This PR includes only one addition, removal, or edit.
[x] I edited the /data directory instead of the README.md.
[x] I reviewed the content policy and the and the IPFS Community Code of Conduct to ensure my submission meets the requirements.
[x] I have followed the CONTRIBUTING.md guidelines.

Additional details
Is there anything else we should know about this PR?

For new additions: What is your project's current size/reach?

For new additions: What is your project's potential size/reach?

For new additions: How critical is IPFS to your project?

[ ] Essential
[ ] Somewhat critical
[ ] Useful, but not critical

For new additions: What core goal(s) does your project address?

[ ] Big-data solutions
[x] Freedom from corporate/government interference
[ ] Data integrity
[ ] Dev tools or other ways to enable developers
[ ] Disaster resilience/recovery
[x] File storage/retrieval
[ ] File streaming
[ ] Permanent archiving
[ ] Self-sovereign identity
[ ] Platforms that utilize consensus, reputation, or incentivization
[ ] Other (please list)

Is anything about IPFS blocking your project?

You haven't added the picture file     picture: /images/ipfsbay.png

Hello.
Image just added.
Thank you.
Sent with Proton Mail secure email.
------- Original Message -------
On Saturday, July 2nd, 2022 at 2:13 PM, ipfsbay @.***> wrote:

Hello.
Thank you for a reply.
Yes, I know that logo is not included, because the repository tell me:
Uploads are disabled. File uploads require push access to this repository.
This error is maybe on my side, I am not sure.
Please, be so kind and use this logo: https://ipfsbay.com/images/logo.png
Thank you very much.
Team IPFSBay
Sent with Proton Mail secure email.
------- Original Message -------
On Saturday, July 2nd, 2022 at 18:38, Hector Sanjuan @.***> wrote:

You haven't added the picture file  picture: /images/ipfsbay.png
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Hello.
Thank you for a reply.
Yes, I know that logo is not included, because the repository tell me:
Uploads are disabled. File uploads require push access to this repository.
This error is maybe on my side, I am not sure.
Please, be so kind and use this logo: https://ipfsbay.com/images/logo.png
Thank you very much.
Team IPFSBay
Sent with Proton Mail secure email.
------- Original Message -------
On Saturday, July 2nd, 2022 at 18:38, Hector Sanjuan @.***> wrote:

You haven't added the picture file  picture: /images/ipfsbay.png
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


[1.10-rc1] docker pull nonexistent-or-private-image should say "not found"

With 1.9:
$ docker-1.9 pull foobar
Using default tag: latest
Pulling repository docker.io/library/foobar
Error: image library/foobar:latest not found

With 1.10.0-rc1:
$ docker-1.10.0-rc1 pull foobar
Using default tag: latest
Pulling repository docker.io/library/foobar
unauthorized: access to the requested resource is not authorized
Error: image library/foobar not found

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
For more information about reporting issues, see CONTRIBUTING.md.
You don't have to include this information if this is a feature request
(This is an automated, informational response)

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

The daemon's behavior here isn't really any different than 1.9, it's just that 1.9 was hiding the first error. https://github.com/docker/docker/pull/17617 caused both errors to be visible. We can consider reverting #17617 if this is a problem.

But keep in mind that any cosmetic fix will have to be revisited for 1.11, which won't have v1 fallbacks masking the 401. It probably makes sense to pursue a registry-side fix in parallel.

@aaronlehmann thanks for the root cause. I'd suggest we revert the PR, and fix this registry-side before 1.11. Once that's done we can revert the revert?

@tiborvass after a quick chat with @aaronlehmann : reverting #17617 as a way to fix cosmetics for 1.10 sounds ok.
Fixing the underlying issue should really be done for 1.11 though (cc @docker/distribution-maintainers ) - and this is probably tricky to get right.

@dmp42 ok thanks for confirming!


Hide Local unit contact details on the list view for logged in users

There are data privacy concerns therefore I ask to hide Focal person name, phone number and email from the Local unit List View.
https://go.ifrc.org/countries/116/ns-overview/context-and-structure
Could be visible though for those, who have access to the Local Unit Form.

@tovari Should this be hidden for all logged-in users, or should it remain visible to specific users based on their permissions?

@samshara, who has editing access currently? I couldn't find out based on the permissions.
Best would be to show this for users with editing permission.

@tovari Currently, edit access is restricted in the production environment.
In the staging environment, edit access is available for CountryAdmin and SuperUser roles.
Per issue #1415, the workflow will soon include RegionAdmin as well.
We will be hiding the details for other users.


Directly support heap package for JavaScript

User request: submission.

I don't think there will be much demand for this; the normal JS judge also doesn't support this at the moment, so I would not add it at this time.


Update Nix infra, update index-state

Description

Update haskell.nix

Switch to nixpkgs-unstable pin used by haskell.nix
Several Windows-specific workarounds are now unnecessary

Update HLS to latest, i.e. <IP_ADDRESS> (HLS needs haskell.nix-specific patches, which are easier to pull in this way). Supersedes #3730.
Update index-state to 2022-07-01. Supersedes #3897.

Checklist

Branch

[x] Commit sequence broadly makes sense
[x] Commits have useful messages
[x] New tests are added if needed and existing tests are updated
[x] If this branch changes Consensus and has any consequences for downstream repositories or end users, said changes must be documented in interface-CHANGELOG.md
[x] If this branch changes Network and has any consequences for downstream repositories or end users, said changes must be documented in interface-CHANGELOG.md
[x] If serialization changes, user-facing consequences (e.g. replay from genesis) are confirmed to be intentional.

Pull Request

[x] Self-reviewed the diff
[x] Useful pull request description at least containing the following information:

What does this PR change?
Why these changes were needed?
How does this affect downstream repositories and/or end-users?
Which ticket does this PR close (if any)? If it does, is it linked?

[x] Reviewer requested

You also bumped your source-repository-package deps, is that deliberate?

Yes, those are due to the index-state update.

bors merge

Oh sorry, apparently I'm not a good enough reviewer for this repo :)

bors cancel

bors merge


[WIP] Adds the chart and dialog for analog voting

Currently everything is still in progress.

Implements some "nice-to-have"-features.
Implements a library for charts for evaluating it.

The breadcromb navigation looks promising; but there is no indicator which state is active. Please also auto-open the dialog instead of sending a stop to the server, when the user tries to stop the poll (analog polls are auto-stopped when entering votes and with #5133 the /stop/-request is forbidden for analog polls)
Also a partial update is missing, if the poll is on a state different than created.

@GabrielInTheWorld Please fix the client tests.