[UX] Sort output when doing kind: list and --stdout

I'm doing some sort of post-processing on the generated YAML to be able to omit BuildConfig (as mentioned in #446) etc. When I'm done, I save it to a versioned file to be able to keep track of production config.
When running kompose convert --provider openshift --verbose --stdout (which produces a kind: list), services' and configuration blocks' order seems to be generated arbitrarily. As this is unimportant for general usage, you might provide a nice UX boost just by sorting the output which would make having it be stable and diffs actually meaningful.
For example, you might go with:

serviceA, BuildConfig
serviceA, DeploymentConfig
serviceB, BuildConfig
serviceB, DeploymentConfig
etc.

Also, stuff like environment variables and service ports might get sorted by name.

@dkarlovi The patten in which the artifacts are generated are intentional since we need the service to be created and deployed first as per kubernetes best practices. Although I tried and deployed a sample application in which service is deployed after deploymentConfig and it works. Can you provide me your docker-compose file so that I can try that too.

@procrypt I think the whole file gets ingested first, then internally sorted and applied by Kubernetes, which makes sense.
Included are: Compose file and outputs of two consecutive runs of kompose (sorry about the long comment).
Here's the docker-compose.yml file:
networks: {}
services:
  app:
    build:
      context: /src
      dockerfile: ./.infra/docker/php/Dockerfile
    depends_on:
      - broker
      - cache
      - db
    image: dkarlovi/example:app
  broker:
    build:
      context: /src
      dockerfile: ./.infra/docker/rabbitmq/Dockerfile
    hostname: broker
    image: dkarlovi/example:broker
    volumes:
    - broker:/var/lib/rabbitmq:rw
  cache:
    build:
      context: /src
      dockerfile: ./.infra/docker/redis/Dockerfile
    image: dkarlovi/example:cache
    volumes:
    - cache:/data:rw
  db:
    build:
      context: /src
      dockerfile: ./.infra/docker/mysql/Dockerfile
    image: dkarlovi/example:db
    volumes:
    - db:/var/lib/mysql:rw
  web:
    build:
      context: /src
      dockerfile: ./.infra/docker/nginx/Dockerfile
    depends_on:
      - app
      - broker
    image: dkarlovi/example:web
    ports:
    - 80:80/tcp
    - 8000:80/tcp
  worker:
    build:
      context: /src
      dockerfile: ./.infra/docker/worker/Dockerfile
    depends_on:
      - app
      - broker
      - cache
      - db
    image: dkarlovi/example:worker
version: 2
volumes:
  broker: {}
  cache: {}
  db: {}

First output of: kompose -f docker-kompose.yml convert --provider openshift --verbose --build-branch "master" --stdout:
apiVersion: v1
items:
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: app
    name: app
  spec:
    clusterIP: None
    ports:
    - name: headless
      port: 55555
      targetPort: 0
    selector:
      io.kompose.service: app
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: broker
    name: broker
  spec:
    clusterIP: None
    ports:
    - name: headless
      port: 55555
      targetPort: 0
    selector:
      io.kompose.service: broker
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: cache
    name: cache
  spec:
    clusterIP: None
    ports:
    - name: headless
      port: 55555
      targetPort: 0
    selector:
      io.kompose.service: cache
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: db
    name: db
  spec:
    clusterIP: None
    ports:
    - name: headless
      port: 55555
      targetPort: 0
    selector:
      io.kompose.service: db
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: web
    name: web
  spec:
    ports:
    - name: "80"
      port: 80
      targetPort: 80
    - name: "8000"
      port: 8000
      targetPort: 80
    selector:
      io.kompose.service: web
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: worker
    name: worker
  spec:
    clusterIP: None
    ports:
    - name: headless
      port: 55555
      targetPort: 0
    selector:
      io.kompose.service: worker
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: app
    name: app
  spec:
    replicas: 1
    selector:
      io.kompose.service: app
    strategy:
      resources: {}
    template:
      metadata:
        creationTimestamp: null
        labels:
          io.kompose.service: app
      spec:
        containers:
        - image: ' '
          name: app
          resources: {}
        restartPolicy: Always
    test: false
    triggers:
    - type: ConfigChange
    - imageChangeParams:
        automatic: true
        containerNames:
        - app
        from:
          kind: ImageStreamTag
          name: app:app
      type: ImageChange
  status: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: app
    name: app
  spec: {}
  status:
    dockerImageRepository: ""
- apiVersion: v1
  kind: BuildConfig
  metadata:
    creationTimestamp: null
    name: app
  spec:
    nodeSelector: null
    output:
      to:
        kind: ImageStreamTag
        name: app:latest
    postCommit: {}
    resources: {}
    runPolicy: Serial
    source:
      contextDir: src
      git:
        ref: master
        uri: git@git.burza.hr:burza/podravka.io.git
      type: Git
    strategy:
      dockerStrategy:
        dockerfilePath: ./.infra/docker/php/Dockerfile
      type: Docker
    triggers:
    - type: ConfigChange
    - type: ImageChange
  status:
    lastVersion: 0
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: broker
    name: broker
  spec:
    replicas: 1
    selector:
      io.kompose.service: broker
    strategy:
      resources: {}
      type: Recreate
    template:
      metadata:
        creationTimestamp: null
        labels:
          io.kompose.service: broker
      spec:
        containers:
        - image: ' '
          name: broker
          resources: {}
          volumeMounts:
          - mountPath: /var/lib/rabbitmq
            name: src_broker
        restartPolicy: Always
        volumes:
        - name: src_broker
          persistentVolumeClaim:
            claimName: src_broker
    test: false
    triggers:
    - type: ConfigChange
    - imageChangeParams:
        automatic: true
        containerNames:
        - broker
        from:
          kind: ImageStreamTag
          name: broker:broker
      type: ImageChange
  status: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: broker
    name: broker
  spec: {}
  status:
    dockerImageRepository: ""
- apiVersion: v1
  kind: BuildConfig
  metadata:
    creationTimestamp: null
    name: broker
  spec:
    nodeSelector: null
    output:
      to:
        kind: ImageStreamTag
        name: broker:latest
    postCommit: {}
    resources: {}
    runPolicy: Serial
    source:
      contextDir: src
      git:
        ref: master
        uri: git@git.burza.hr:burza/podravka.io.git
      type: Git
    strategy:
      dockerStrategy:
        dockerfilePath: ./.infra/docker/rabbitmq/Dockerfile
      type: Docker
    triggers:
    - type: ConfigChange
    - type: ImageChange
  status:
    lastVersion: 0
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: src_broker
    name: src_broker
  spec:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 100Mi
  status: {}
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: cache
    name: cache
  spec:
    replicas: 1
    selector:
      io.kompose.service: cache
    strategy:
      resources: {}
      type: Recreate
    template:
      metadata:
        creationTimestamp: null
        labels:
          io.kompose.service: cache
      spec:
        containers:
        - image: ' '
          name: cache
          resources: {}
          volumeMounts:
          - mountPath: /data
            name: src_cache
        restartPolicy: Always
        volumes:
        - name: src_cache
          persistentVolumeClaim:
            claimName: src_cache
    test: false
    triggers:
    - type: ConfigChange
    - imageChangeParams:
        automatic: true
        containerNames:
        - cache
        from:
          kind: ImageStreamTag
          name: cache:cache
      type: ImageChange
  status: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: cache
    name: cache
  spec: {}
  status:
    dockerImageRepository: ""
- apiVersion: v1
  kind: BuildConfig
  metadata:
    creationTimestamp: null
    name: cache
  spec:
    nodeSelector: null
    output:
      to:
        kind: ImageStreamTag
        name: cache:latest
    postCommit: {}
    resources: {}
    runPolicy: Serial
    source:
      contextDir: src
      git:
        ref: master
        uri: git@git.burza.hr:burza/podravka.io.git
      type: Git
    strategy:
      dockerStrategy:
        dockerfilePath: ./.infra/docker/redis/Dockerfile
      type: Docker
    triggers:
    - type: ConfigChange
    - type: ImageChange
  status:
    lastVersion: 0
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: src_cache
    name: src_cache
  spec:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 100Mi
  status: {}
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: db
    name: db
  spec:
    replicas: 1
    selector:
      io.kompose.service: db
    strategy:
      resources: {}
      type: Recreate
    template:
      metadata:
        creationTimestamp: null
        labels:
          io.kompose.service: db
      spec:
        containers:
        - image: ' '
          name: db
          resources: {}
          volumeMounts:
          - mountPath: /var/lib/mysql
            name: src_db
        restartPolicy: Always
        volumes:
        - name: src_db
          persistentVolumeClaim:
            claimName: src_db
    test: false
    triggers:
    - type: ConfigChange
    - imageChangeParams:
        automatic: true
        containerNames:
        - db
        from:
          kind: ImageStreamTag
          name: db:db
      type: ImageChange
  status: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: db
    name: db
  spec: {}
  status:
    dockerImageRepository: ""
- apiVersion: v1
  kind: BuildConfig
  metadata:
    creationTimestamp: null
    name: db
  spec:
    nodeSelector: null
    output:
      to:
        kind: ImageStreamTag
        name: db:latest
    postCommit: {}
    resources: {}
    runPolicy: Serial
    source:
      contextDir: src
      git:
        ref: master
        uri: git@git.burza.hr:burza/podravka.io.git
      type: Git
    strategy:
      dockerStrategy:
        dockerfilePath: ./.infra/docker/mysql/Dockerfile
      type: Docker
    triggers:
    - type: ConfigChange
    - type: ImageChange
  status:
    lastVersion: 0
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: src_db
    name: src_db
  spec:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 100Mi
  status: {}
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: web
    name: web
  spec:
    replicas: 1
    selector:
      io.kompose.service: web
    strategy:
      resources: {}
    template:
      metadata:
        creationTimestamp: null
        labels:
          io.kompose.service: web
      spec:
        containers:
        - image: ' '
          name: web
          ports:
          - containerPort: 80
          - containerPort: 80
          resources: {}
        restartPolicy: Always
    test: false
    triggers:
    - type: ConfigChange
    - imageChangeParams:
        automatic: true
        containerNames:
        - web
        from:
          kind: ImageStreamTag
          name: web:web
      type: ImageChange
  status: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: web
    name: web
  spec: {}
  status:
    dockerImageRepository: ""
- apiVersion: v1
  kind: BuildConfig
  metadata:
    creationTimestamp: null
    name: web
  spec:
    nodeSelector: null
    output:
      to:
        kind: ImageStreamTag
        name: web:latest
    postCommit: {}
    resources: {}
    runPolicy: Serial
    source:
      contextDir: src
      git:
        ref: master
        uri: git@git.burza.hr:burza/podravka.io.git
      type: Git
    strategy:
      dockerStrategy:
        dockerfilePath: ./.infra/docker/nginx/Dockerfile
      type: Docker
    triggers:
    - type: ConfigChange
    - type: ImageChange
  status:
    lastVersion: 0
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: worker
    name: worker
  spec:
    replicas: 1
    selector:
      io.kompose.service: worker
    strategy:
      resources: {}
    template:
      metadata:
        creationTimestamp: null
        labels:
          io.kompose.service: worker
      spec:
        containers:
        - image: ' '
          name: worker
          resources: {}
        restartPolicy: Always
    test: false
    triggers:
    - type: ConfigChange
    - imageChangeParams:
        automatic: true
        containerNames:
        - worker
        from:
          kind: ImageStreamTag
          name: worker:worker
      type: ImageChange
  status: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: worker
    name: worker
  spec: {}
  status:
    dockerImageRepository: ""
- apiVersion: v1
  kind: BuildConfig
  metadata:
    creationTimestamp: null
    name: worker
  spec:
    nodeSelector: null
    output:
      to:
        kind: ImageStreamTag
        name: worker:latest
    postCommit: {}
    resources: {}
    runPolicy: Serial
    source:
      contextDir: src
      git:
        ref: master
        uri: git@git.burza.hr:burza/podravka.io.git
      type: Git
    strategy:
      dockerStrategy:
        dockerfilePath: ./.infra/docker/worker/Dockerfile
      type: Docker
    triggers:
    - type: ConfigChange
    - type: ImageChange
  status:
    lastVersion: 0
kind: List
metadata: {}

Second output of: kompose -f docker-kompose.yml convert --provider openshift --verbose --build-branch "master" --stdout:
apiVersion: v1
items:
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: cache
    name: cache
  spec:
    clusterIP: None
    ports:
    - name: headless
      port: 55555
      targetPort: 0
    selector:
      io.kompose.service: cache
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: db
    name: db
  spec:
    clusterIP: None
    ports:
    - name: headless
      port: 55555
      targetPort: 0
    selector:
      io.kompose.service: db
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: web
    name: web
  spec:
    ports:
    - name: "80"
      port: 80
      targetPort: 80
    - name: "8000"
      port: 8000
      targetPort: 80
    selector:
      io.kompose.service: web
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: worker
    name: worker
  spec:
    clusterIP: None
    ports:
    - name: headless
      port: 55555
      targetPort: 0
    selector:
      io.kompose.service: worker
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: app
    name: app
  spec:
    clusterIP: None
    ports:
    - name: headless
      port: 55555
      targetPort: 0
    selector:
      io.kompose.service: app
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: broker
    name: broker
  spec:
    clusterIP: None
    ports:
    - name: headless
      port: 55555
      targetPort: 0
    selector:
      io.kompose.service: broker
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: cache
    name: cache
  spec:
    replicas: 1
    selector:
      io.kompose.service: cache
    strategy:
      resources: {}
      type: Recreate
    template:
      metadata:
        creationTimestamp: null
        labels:
          io.kompose.service: cache
      spec:
        containers:
        - image: ' '
          name: cache
          resources: {}
          volumeMounts:
          - mountPath: /data
            name: src_cache
        restartPolicy: Always
        volumes:
        - name: src_cache
          persistentVolumeClaim:
            claimName: src_cache
    test: false
    triggers:
    - type: ConfigChange
    - imageChangeParams:
        automatic: true
        containerNames:
        - cache
        from:
          kind: ImageStreamTag
          name: cache:cache
      type: ImageChange
  status: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: cache
    name: cache
  spec: {}
  status:
    dockerImageRepository: ""
- apiVersion: v1
  kind: BuildConfig
  metadata:
    creationTimestamp: null
    name: cache
  spec:
    nodeSelector: null
    output:
      to:
        kind: ImageStreamTag
        name: cache:latest
    postCommit: {}
    resources: {}
    runPolicy: Serial
    source:
      contextDir: src
      git:
        ref: master
        uri: git@git.burza.hr:burza/podravka.io.git
      type: Git
    strategy:
      dockerStrategy:
        dockerfilePath: ./.infra/docker/redis/Dockerfile
      type: Docker
    triggers:
    - type: ConfigChange
    - type: ImageChange
  status:
    lastVersion: 0
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: src_cache
    name: src_cache
  spec:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 100Mi
  status: {}
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: db
    name: db
  spec:
    replicas: 1
    selector:
      io.kompose.service: db
    strategy:
      resources: {}
      type: Recreate
    template:
      metadata:
        creationTimestamp: null
        labels:
          io.kompose.service: db
      spec:
        containers:
        - image: ' '
          name: db
          resources: {}
          volumeMounts:
          - mountPath: /var/lib/mysql
            name: src_db
        restartPolicy: Always
        volumes:
        - name: src_db
          persistentVolumeClaim:
            claimName: src_db
    test: false
    triggers:
    - type: ConfigChange
    - imageChangeParams:
        automatic: true
        containerNames:
        - db
        from:
          kind: ImageStreamTag
          name: db:db
      type: ImageChange
  status: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: db
    name: db
  spec: {}
  status:
    dockerImageRepository: ""
- apiVersion: v1
  kind: BuildConfig
  metadata:
    creationTimestamp: null
    name: db
  spec:
    nodeSelector: null
    output:
      to:
        kind: ImageStreamTag
        name: db:latest
    postCommit: {}
    resources: {}
    runPolicy: Serial
    source:
      contextDir: src
      git:
        ref: master
        uri: git@git.burza.hr:burza/podravka.io.git
      type: Git
    strategy:
      dockerStrategy:
        dockerfilePath: ./.infra/docker/mysql/Dockerfile
      type: Docker
    triggers:
    - type: ConfigChange
    - type: ImageChange
  status:
    lastVersion: 0
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: src_db
    name: src_db
  spec:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 100Mi
  status: {}
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: web
    name: web
  spec:
    replicas: 1
    selector:
      io.kompose.service: web
    strategy:
      resources: {}
    template:
      metadata:
        creationTimestamp: null
        labels:
          io.kompose.service: web
      spec:
        containers:
        - image: ' '
          name: web
          ports:
          - containerPort: 80
          - containerPort: 80
          resources: {}
        restartPolicy: Always
    test: false
    triggers:
    - type: ConfigChange
    - imageChangeParams:
        automatic: true
        containerNames:
        - web
        from:
          kind: ImageStreamTag
          name: web:web
      type: ImageChange
  status: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: web
    name: web
  spec: {}
  status:
    dockerImageRepository: ""
- apiVersion: v1
  kind: BuildConfig
  metadata:
    creationTimestamp: null
    name: web
  spec:
    nodeSelector: null
    output:
      to:
        kind: ImageStreamTag
        name: web:latest
    postCommit: {}
    resources: {}
    runPolicy: Serial
    source:
      contextDir: src
      git:
        ref: master
        uri: git@git.burza.hr:burza/podravka.io.git
      type: Git
    strategy:
      dockerStrategy:
        dockerfilePath: ./.infra/docker/nginx/Dockerfile
      type: Docker
    triggers:
    - type: ConfigChange
    - type: ImageChange
  status:
    lastVersion: 0
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: worker
    name: worker
  spec:
    replicas: 1
    selector:
      io.kompose.service: worker
    strategy:
      resources: {}
    template:
      metadata:
        creationTimestamp: null
        labels:
          io.kompose.service: worker
      spec:
        containers:
        - image: ' '
          name: worker
          resources: {}
        restartPolicy: Always
    test: false
    triggers:
    - type: ConfigChange
    - imageChangeParams:
        automatic: true
        containerNames:
        - worker
        from:
          kind: ImageStreamTag
          name: worker:worker
      type: ImageChange
  status: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: worker
    name: worker
  spec: {}
  status:
    dockerImageRepository: ""
- apiVersion: v1
  kind: BuildConfig
  metadata:
    creationTimestamp: null
    name: worker
  spec:
    nodeSelector: null
    output:
      to:
        kind: ImageStreamTag
        name: worker:latest
    postCommit: {}
    resources: {}
    runPolicy: Serial
    source:
      contextDir: src
      git:
        ref: master
        uri: git@git.burza.hr:burza/podravka.io.git
      type: Git
    strategy:
      dockerStrategy:
        dockerfilePath: ./.infra/docker/worker/Dockerfile
      type: Docker
    triggers:
    - type: ConfigChange
    - type: ImageChange
  status:
    lastVersion: 0
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: app
    name: app
  spec:
    replicas: 1
    selector:
      io.kompose.service: app
    strategy:
      resources: {}
    template:
      metadata:
        creationTimestamp: null
        labels:
          io.kompose.service: app
      spec:
        containers:
        - image: ' '
          name: app
          resources: {}
        restartPolicy: Always
    test: false
    triggers:
    - type: ConfigChange
    - imageChangeParams:
        automatic: true
        containerNames:
        - app
        from:
          kind: ImageStreamTag
          name: app:app
      type: ImageChange
  status: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: app
    name: app
  spec: {}
  status:
    dockerImageRepository: ""
- apiVersion: v1
  kind: BuildConfig
  metadata:
    creationTimestamp: null
    name: app
  spec:
    nodeSelector: null
    output:
      to:
        kind: ImageStreamTag
        name: app:latest
    postCommit: {}
    resources: {}
    runPolicy: Serial
    source:
      contextDir: src
      git:
        ref: master
        uri: git@git.burza.hr:burza/podravka.io.git
      type: Git
    strategy:
      dockerStrategy:
        dockerfilePath: ./.infra/docker/php/Dockerfile
      type: Docker
    triggers:
    - type: ConfigChange
    - type: ImageChange
  status:
    lastVersion: 0
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: broker
    name: broker
  spec:
    replicas: 1
    selector:
      io.kompose.service: broker
    strategy:
      resources: {}
      type: Recreate
    template:
      metadata:
        creationTimestamp: null
        labels:
          io.kompose.service: broker
      spec:
        containers:
        - image: ' '
          name: broker
          resources: {}
          volumeMounts:
          - mountPath: /var/lib/rabbitmq
            name: src_broker
        restartPolicy: Always
        volumes:
        - name: src_broker
          persistentVolumeClaim:
            claimName: src_broker
    test: false
    triggers:
    - type: ConfigChange
    - imageChangeParams:
        automatic: true
        containerNames:
        - broker
        from:
          kind: ImageStreamTag
          name: broker:broker
      type: ImageChange
  status: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: broker
    name: broker
  spec: {}
  status:
    dockerImageRepository: ""
- apiVersion: v1
  kind: BuildConfig
  metadata:
    creationTimestamp: null
    name: broker
  spec:
    nodeSelector: null
    output:
      to:
        kind: ImageStreamTag
        name: broker:latest
    postCommit: {}
    resources: {}
    runPolicy: Serial
    source:
      contextDir: src
      git:
        ref: master
        uri: git@git.burza.hr:burza/podravka.io.git
      type: Git
    strategy:
      dockerStrategy:
        dockerfilePath: ./.infra/docker/rabbitmq/Dockerfile
      type: Docker
    triggers:
    - type: ConfigChange
    - type: ImageChange
  status:
    lastVersion: 0
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    creationTimestamp: null
    labels:
      io.kompose.service: src_broker
    name: src_broker
  spec:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 100Mi
  status: {}
kind: List
metadata: {}

@dkarlovi so this was intentional as @procrypt said also you can find the corresponding doc in upstream at
https://kubernetes.io/docs/concepts/configuration/overview/
which says:

It’s typically best to create a service before corresponding replication controllers, so that the scheduler can spread the pods comprising the service.

so the decision.

@surajssd thanks for the link. I've noted:

It doesn't matter WHAT the actual sort is as long as it's repeatable and stable.

As you can see from my comment, order changes between runs for me.

@dkarlovi thanks for reporting this seems to be an openshift issue!

With Kubernetes the output is right but with openshift the output is not alphabetically ordered

@surajssd great to hear. Sorting by docker-compose works too of course, as long as the order is kept between runs.

@surajssd @dkarlovi I have updated the PR accordingly, output with is in order OpenShift now.


Releases fail with bundler version error

So I can't work this one out.
Thinking maybe it's a heroku issue.
But here's the situation:
# Procfile
release: bundle exec rake db:migrate
web: bundle exec rails server -p $PORT -e $RAILS_ENV

the buildpack is set
$ heroku buildpacks --app redacted
=== redacted Buildpack URL
https://github.com/bundler/heroku-buildpack-bundler2.git

The build works fine:
-----> Ruby app detected
-----> Compiling Ruby/Rails
-----> Using Ruby version: ruby-2.6.0
-----> Installing dependencies using bundler 2.0.1
       Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
       Fetching gem metadata from https://rubygems.org/.......
       Fetching rake 12.3.2
...

-----> Discovering process types
       Procfile declares types     -> release, web
       Default types for buildpack -> console, rake
-----> Compressing...
       Done: 50.5M
-----> Launching...
 !     Release command declared: this new release will not be available until the command succeeds.
       Released v7
       https://redacted.herokuapp.com/ deployed to Heroku

But then it goes on to run the release process
bundler: failed to load command: rake (/app/vendor/bundle/ruby/2.6.0/bin/rake)
Bundler::LockfileError: You must use Bundler 2 or greater with this lockfile.
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/bundler/lockfile_parser.rb:108:in `warn_for_outdated_bundler_version'
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/bundler/lockfile_parser.rb:95:in `initialize'
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/bundler/definition.rb:83:in `new'
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/bundler/definition.rb:83:in `initialize'
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/bundler/dsl.rb:234:in `new'
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/bundler/dsl.rb:234:in `to_definition'
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/bundler/dsl.rb:13:in `evaluate'
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/bundler/definition.rb:34:in `build'
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/bundler.rb:135:in `definition'
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/bundler.rb:101:in `setup'
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/bundler/setup.rb:20:in `<top (required)>'
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
  /app/vendor/ruby-2.6.0/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'

As far as I'm aware, the release should just be running a command inside the container.
bundle exec rake db:migrate

So somehow the container's bundle exec isn't using 2.0.1.
I'll try and do some more debug,
but for now this is blocking me upgrading.

Same here. Even though it seems to be using Bundler 2.0.1 when building the app, when I run:
heroku run bundle version

$ Bundler version 1.17.2 (2018-12-19 commit 3fc4de72b)

My guess is that Bundler 2.0.1 is installed, but the environment points to the old version.

@pepibumur yeah, there's some difference in the env for heroku run vs the buildpack.
I guess it's a heroku issue, rather than a buildpack one?
But can't be sure.

Same here :(

Same error here. After trying multiple approaches, I had to downgrade bundler to 1.17.3 version, which seems to be the only way around it for now, see:
https://github.com/bundler/bundler/issues/6784#issuecomment-457297894

Thought this might fix it:
https://github.com/heroku/heroku-buildpack-ruby/pull/850
But seems not

@matthewrudy It should fix it! But I believe that even though the heroku fix has been merged into master, heroku hasn't yet released the new official version. You can force heroku to use the master branch by specifying the full git url as the buildpack, but my personal preference is to just downgrade to bundler 1 until they release the new version (it looks like Heroku releases a new buildpack version once per month, so it should be soon).

@travisp that is what I did, actually.
Added the git remote directly.
But got the same issue.

(should have included my script output to show ... But the same error as before)

So v199 of the official ruby buildpack is now out,
and it doesn't work
so I will add a bug on their github.

This is now resolved
Just have to use 2.6.1 with the default ruby buildpack.
Thanks everyone.


Gradient not working correctly.

Please verify the version of auro-carousel you have installed
No response
Please describe the bug
Go to auro docsite
go to carousel
see gradient is initially not their
After interacting you can see a gradient but it is turned 90 degrees
Reproducing the error
None
Expected behavior
Gradient should always be shown and gradient should fade into background to the right or left instead of up and down.
What browsers are you seeing the problem on?
No response
Additional context
No response
Exit criteria
No response

see figma for expected look: https://www.figma.com/design/VpUz89Ov6ImBpY5YvzYbZW/Auro-toolkit?m=auto&node-id=3693-13840&t=AOFbOhrYnvi6m0QH-1


Include default values in Sdk.props

Issue describing the changes in this PR
resolves N/A
Pull request checklist

[x] My changes do not require documentation changes

[ ] Otherwise: Documentation issue linked to PR

[ ] My changes should not be added to the release notes for the next release

[x] Otherwise: I've added my notes to release_notes.md

[x] My changes do not need to be backported to a previous version

[ ] Otherwise: Backport tracked by issue/PR #issue_or_pr

[x] I have added all required tests (Unit tests, E2E tests)

Additional information
This PR adds default values to our SDK props. This will let us update our templates to be less verbose (but customers can still use old ones)
Changes
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
-    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.20.1" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.0.13" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.0-preview1" />
  </ItemGroup>

-  <ItemGroup>
-    <None Update="host.json">
-      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
-    </None>
-    <None Update="local.settings.json">
-      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
-      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
-    </None>
-  </ItemGroup>
-
</Project>

Hi, i encountered some issues with this update. In our pipeline the local.settings.json does not exists as its not checked into the repo and therefore it can not be copied. Your update adding the default values leads to the following error:
##[error]/usr/share/dotnet/sdk/8.0.101/Microsoft.Common.CurrentVersion.targets(5198,5): Error MSB3030: Could not copy the file "/azp/agent/_work/1/s/src/Function/local.settings.json" because it was not found.
Microsoft.Azure.Functions.Worker.Sdk 1.17.0-preview1 is working fine.
Maybe you can add the condition Condition="Exists('local.settings.json')" to avoid the error.


Lightning 1.8 breaks lightning-transformers

🐛 Bug

Errors:
LightningDeprecationWarning: LightningDataModule.on_save_checkpoint was deprecated in v1.6 and will be removed in v1.8. Use state_dict instead.
LightningDeprecationWarning: LightningDataModule.on_load_checkpoint was deprecated in v1.6 and will be removed in v1.8. Use load_state_dict instead.
To Reproduce
Steps to reproduce the behavior:
Run any lightning-transformers DataModule in the trainer.

Code sample

These two methods in particular cause the errors in lightning_transformers\core\data.py.
    def on_save_checkpoint(self, checkpoint: Dict[str, Any]) -> None:
        checkpoint["tokenizer"] = self.tokenizer

    def on_load_checkpoint(self, checkpoint: Dict[str, Any]) -> None:
        self.tokenizer = checkpoint["tokenizer"]

Expected behavior

This shall be addressed by ongoing work #297


Repo does not get saved in the cache

On select a repo and reload the page, I need to select the repo again.  Also, on reopening an script, the repo doesn't have been saved in the cache.
At my company we have hundreds of repos, so the experience is annoying to look for the repo every time :/
My colleague does not have this issue. And I didn't have it 6 months ago, so I'm not sure what could be... Posting the issue to see if someone could help to find the problem.

This config is saved in the chrome's local storage, maybe some configuration of your browser prevent the extension to write storage

Thanks @leonhartX ! Now is working properly :) I added scripts.google.com to the Adblock whitelist, and uninstall and install again the extension; I guess one of those (or both) helped to fix the issue!


Is there a way to authenticate to a Cloud IAP-secured resource?

I am trying to use this library to authenticate to a Cloud Identity-Aware Proxy (Cloud IAP)-secured resource from a user account. However, I don't see any way to include an IAP token. I saw a previous post saying TSC does not support SAML SSO, but I am using OAuth + OpenID and haven't seen any posts about that.

Closing stale question - I think today this would be handled using Personal Access Tokens.


Functions code should auto-deploy

We can have code deployed when Azure Functions are deployed.

i am working on ARM template that will include the AF link to the github repo.


Show Index Status

Show the last time the index was updated, as well as when the page was loaded.
┆Issue is synchronized with this JIRA Story
┆Project Name: CGP-Dashboard
┆Issue Number: DASH-5

➤ Charles Overbeck commented:
Now the index is progressively updated, so no longer applicable.


Click at the end of the sample

First of all thanks for sharing this!
Not sure if thats not an issue on my side but AudioPlaySdWavResmp seems to emit click at the end of a sample. I'm using generic piano samples that end with silence for testing.

Hey Andrjez, :) You're welcome.
I have heard a click at the end during certain circumstances. I got around this issue by inserting 4 samples of silence at the end of the wav file.
There is an improvement to make here - basically, when using interpolation, we need to read ahead at least 2 samples. so the audio is 2 samples behind. and when the wav file reaches the end, it doesn't play the remaining samples that are in the look ahead/interpolation buffer.

Would be interested to know if this solves your issue, adding extra silence at the end.... Otherwise you could send me the wave file and I will be happy to try to reproduce :) thanks

There is a feature still be implemented which will solve the "extra silence" at end of sample, which hopefully I can sort out soon..

Not sure if thats not an issue on my side but AudioPlaySdWavResmp seems to emit click at the end of a sample. I'm using generic piano samples that end with silence for testing.

Hey Andrjez,
I think this is fixed, can you give it a try?

Not sure if thats not an issue on my side but AudioPlaySdWavResmp seems to emit click at the end of a sample. I'm using generic piano samples that end with silence for testing.

Hey Andrjez,
I think this is fixed, can you give it a try?

I will need a day or two to get around to that but I will :)

I pulled the current master version, updated the usage to the new API but I'm still getting the click.
I cannot attach the WAV file directly so I uploaded it here: https://filebin.net/ds1ul8fvaioo4zvg

Ok, cool. I suspect it’s something to do with tags. currently I export wav without any extra info. I think I know how to fix it. I’ll have a look when I get back from camping on Monday :)
Thanks for the feedback, really appreciate your testing, cheers.

That should be fixed now on this branch, feaure/wavheader_datasize - If you'd like to test it, and if it works okay, I'll merge to master branch.
I was able to reproduce the issue initially and after I use the data size from the wav header, the click at the end of the sample is gone, but I never managed to test on the teensy yet. Would be really appreciated if you could confirm, thanks. and thanks for reporting the issue.

I did a quick test on a teensy and the click seems to still be there. BUT, I did it in the context of a larger codebase. I'm using AudioPlayArrayResmp now and loading the files like this:
File file = SD.open(filename);
uint64_t size = file.size();
buf = extmem_malloc(size);
file.read(buf, size);
file.close();

playWav((unsigned int *)buf, size / 2);

Ok, I've applied that fix to the array reader now too, so that code above should hopefully not have a click at the end...

🎉🎉 🥳
No click now 👍

Thats awesome! 👍 Yay!!!

going to merge this branch to master, and delete the feature branch... :)


Add document merge to wasm bindings

Description of change
Expose the Document::merge() and DocumentDiff::merge() functions to the wasm bindings.
Breaking changes:

change the parameter of WasmDocument::merge() from &str to &WasmDocumentDiff.
rename WasmIntegrationChainHistory to IntegrationChainHistory.
rename WasmDiffChainHistory to DiffChainHistory.

Type of change

[ ] Bug fix (a non-breaking change which fixes an issue)
[ ] Enhancement (a non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Fix

How the change has been tested
Examples and tests pass locally.
Change checklist

[x] I have followed the contribution guidelines for this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

@abdulmth Here's an example of applying successive DocumentDiffs to a DID document. I didn't add it to any example since this should not be a common operation for users.
let did = "did:iota:FoGZ9U7sgSJXggEroaAKB1d2TjTjJQQFURr8dWtDzB4R";
const history = await client.resolveHistory(did);

let oldDoc = history.integrationChainData()[1];
let previousDiffHistory = await client.resolveDiffHistory(oldDoc);

// Apply successive diffs to step through the DID document history
const diffDoc = Document.fromJSON(oldDoc.toJSON()); // clone
let diffDocs = [];
previousDiffHistory.chainData().forEach(function(diff) {
  diffDoc.merge(diff);
  diffDocs.push(Document.fromJSON(diffDoc.toJSON())) // clone
});
console.log(diffDocs);


[stable/external-dns] enable freeform env via secrets, doc cleanup

There's another PR open to support an Infoblox external-dns provider. This PR adds an extraEnv map that allows arbitrary environment variables to be set in the pod spec by way of secret refs.
Also any values that were present in values.yaml and templates/*.yaml but missing from the README have been added.

/ok-to-test

/lgtm

Hello,
Little typo here: https://github.com/kubernetes/charts/blame/master/stable/external-dns/README.md#L43
| logLevel                         | Verbosity of the logs (options: panic, debug, info, warn, error, fatal)
should be
| logLevel                         | Verbosity of the logs (options: panic, debug, info, warning, error, fatal)


Fulltext Index Support

Added support for Fulltext Indexes in the Migrator. Since MySQL 5.6 InnoDB now supports them.

So it seems to  be failing on the table test_events_search, with the following:
'CREATE TABLE test_events_search (event_idINT UNSIGNED NOT NULL,idINT UNSIGNED AUTO_INCREMENT NOT NULL,bodyLONGTEXT NOT NULL, INDEXtest_events_search_event_id(event_id), FULLTEXT INDEXtest_events_search_body (body), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci **ENGINE = InnoDB'**
But in the test entity itself, it specifies:
// MyISAM table for FULLTEXT searching
protected static $tableOptions = [
    **'engine' => 'MyISAM'**
];

Which seems to be being ignored. Unless I am missing something this is the actual issue, which my edit is bringing to light. Maybe a further test needs to be made to check if the table created is MyISAM or InnoDB?

The current code assumes that "fulltext" searching is MyISAM only (which it was). Looks like it needs to be updated to support newer MySQL versions. We probably need to ensure that "fulltext" can only be set with "MyISAM" as the engine when MySQL is under a certain version, but that would require an additional check.
Either that, or we just assume the user knows what they are doing, and try to run the operations no matter the "engine" specified?


Invisible steam overlay during gameplay

Hello,
ever since the big update in Chimera 43 my gaming steam overlay is invisible. When i press PS button on my DualSense I can hear the menu sounds and can even use PS button + X to start using right menu overlay and change sound volume without being able to see anything. Update 43-1 didn't help with this issue.
For example it forces me to close games by pressing PS button and then blindly by memory go menu item down -> Home -> Game Detail -> close.
Everything worked fine in v 42.
System spec:
OS Version : 43-1
OS Build : 788f4bb
Kernel Version : 6.3.9-chimeraos-1
Mesa 23.1.3
Steamdeck channel : Stable
CPU : AMD Ryzen 7 5700X
GPU : AMD Radeon 7900 XT
RAM Size : 32GB
I will gladly provide any additional information if I get instructions on how to debug gaming mode.
Thank you for your great work
Cheers

I'm facing the same issue.
Found out it seems to have to do with HDR.
If I switch on "experimental HDR support" in settings and turn on HDR, then the overlay works perfectly fine.
Disabling HDR again makes the overlay invisible again.

I can confirm HDR is the issue. However it's not really a solution since turning it on just makes everything washed off.
Not sure if the problem is at chimera or at valve here.

I am currently running with HDR enabled because it now worls much better. I guess we can close it since 1) it's probably issue on Valve's side 2) low priority.


chore(deps): update module github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper to v1.30.2

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper
require
patch
v1.30.1 -> v1.30.2

Release Notes

terraform-ibm-modules/ibmcloud-terratest-wrapper (github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper)
v1.30.2
Compare Source
Bug Fixes

deps: update gomod (#785) (e215d84)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

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

This PR has been generated by Renovate Bot.

/run pipeline

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


Question: AutoSuggestListPadding default value?

I am using an AutoSuggestBox with a custom item background color:
<AutoSuggestBox PlaceholderText="Search" QueryIcon="Find"
                x:Name="SearchAutoSuggestBox"
                QuerySubmitted="OnQuerySubmitted"
                TextChanged="SearchAutoSuggestBox_OnTextChanged"
                ItemsSource="{x:Bind SearchResultsInternal}"
                MaxSuggestionListHeight="400" UpdateTextOnSelect="False">
    <AutoSuggestBox.ItemTemplate>
        <DataTemplate x:DataType="local:ViewModel">
            <ListViewItem HorizontalContentAlignment="Stretch" Padding="6,0,6,0">
                <ListViewItem.Resources>
                    <SolidColorBrush x:Key="ListViewItemBackground" Color="Red" />
                    <SolidColorBrush x:Key="ListViewItemBackgroundSelected" Color="Red" />
                    <SolidColorBrush x:Key="ListViewItemBackgroundPointerOver" Color="Red" />
                    <SolidColorBrush x:Key="ListViewItemBackgroundSelectedPointerOver" Color="Red" />
                </ListViewItem.Resources>

                <Grid>
                    [...]
                </Grid>
            </ListViewItem>
        </DataTemplate>
    </AutoSuggestBox.ItemTemplate>
</AutoSuggestBox>

The issue is, that after adding and removing items to the search results the background of the items overlaps the border of the autosuggestbox result panel. This can be avoided by setting AutoSuggestListPadding to zero. Now I am wondering if the default is a negative value, I could not find the source for that default setting. Maybe it is a bug?
<Thickness x:Key="AutoSuggestListPadding">0</Thickness>

The AutoSuggestListPadding default value is -1,0,-1,0.  I'm not sure why, but presumably to achieve a desired look.. If that look doesn't suite your needs the light weight style is exposed for this exact reason :)


D3DX8.h error

Guys, Map editor is asking for D3Dx8 file. How can I fix this?

With the above commit now including DX8.1 (+ MFC2013 -- the last version that still used DX8), N3ME should build now.
It is, however, barely touched -- and its N3Base folder seems to be a lesser maintained clone of the original N3Base folder used by the client, so it is certainly in an interesting place.


React Warning

Hello.
Use material-ui and I have 2 warnings:

Unknown prop errors on  tag. Remove this prop from the element. https://fb.me/react-unknown-prop

value prop on input should not be null. For example

const value = undefined;
return <input type="text" value={value}/>; // <-------- bad (uncontrolled)

const value = undefined;
return <input type="text" value={value || ''}/>; // <-------- good (controlled)

How i can fix that?

Same here on a simple EmailSignUpForm :
Warning: Unknown prop errors on  tag. Remove this prop from the element. For details, see https://fb.me/react-unknown-prop 😓

Upgrading react-bootstrap dependency version from ^0.29.5 to the most recent one (0.30.7 at the moment) should fix the issue, as this has been fixed in version 0.30.1:
https://github.com/react-bootstrap/react-bootstrap/pull/2095
I am totally new to Redux and all, but I could try and do a PR.

@lynndylanhurley @tizub Would love to see this resolved. Thank you for all your hard work guys!

Maybe, problem 1 is caused by this line.

https://github.com/lynndylanhurley/redux-auth/blob/master/src/views/default/Input.js#L51

{…this.props} extracts all of AuthInput props here, but <input /> element has no errors prop.


Add --json-logs flag

[x] Double-check the spelling and grammar of all strings, code comments, etc.
[x] Double-check that all code is deterministic that needs to be
[x] Add tests to cover any new or revised logic
[ ] Ensure that the test suite passes
[x] Update the project release notes
[x] Update the project documentation, as appropriate, with a corresponding Pull Request in the Documentation repository

merged by error here https://github.com/CounterpartyXCP/counterparty-core/pull/2073


Build warnings on subsys/net/lib/http/http_client.c

Describe the bug
Depending on compile optimizations settings, subsys/net/lib/http/http_client.c builds with warnings
Expected behavior
No build warnings
Impact
Either annoyance for users, or broken CI when this is triggered in CI (it is triggered downstream with some samples).
Logs and console output
[559/734] Building C object zephyr/subsys/net/lib/http/CMakeFiles/subsys__net__lib__http.dir/http_client.c.obj
/Zephyr/subsys/net/lib/http/http_client.c: In function 'http_send_data.constprop':
/Zephyr/subsys/net/lib/http/http_client.c:112:33: warning: 'strncpy' specified bound depends on the length of the source argument [-Wstringop-truncation]
  112 |                                 strncpy(send_buf + end_of_send,
      |                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  113 |                                         data + end_of_data,
      |                                         ~~~~~~~~~~~~~~~~~~~
  114 |                                         remaining_len);
      |                                         ~~~~~~~~~~~~~~
/Zephyr/subsys/net/lib/http/http_client.c:87:41: note: length computed here
   87 |                         remaining_len = strlen(data + end_of_data);
      |                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~

Environment (please complete the following information):

OS: Linux
Toolchain: docker.io/zephyrprojectrtos/zephyr-build:v0.26.11
Zephyr Version: v3.7.0-17-gf84f55dfb0d3

@FaBjE I just tried the http-client sample but cannot see this error. Is there a way to reproduce it, can you give more information?

Compilation with west that reproduces the issue:
west build -p -b stm32h747i_disco/stm32h747xx/m7 \
    -d ../build/http-client samples/net/sockets/http_client/ -- -DCONFIG_SPEED_OPTIMIZATIONS=y

The above is using GCC 12.2.0.
Tried with native_sim but it is silent about the warning. There the GCC is 11.4.0.
The SDK version is 0.16.8 in both cases.
Also one needs to set CONFIG_SPEED_OPTIMIZATIONS=y, if that is left out there is no warning.


Review IBC queries, create test data and improve testing

In packages/stargate/src/queries/ibc.spec.ts we test Stargate IBC queries. However, the testing is very minimal because when we wrote them, we were not able to generate proper test fixtures.
The 6 expect(response).toBeTruthy(); // TODO: implement checks should be replaced with tests that check the data.
There was work from Alex and Ethan to generate test data (https://github.com/cosmos/cosmjs/pull/405 and https://github.com/cosmos/cosmjs/pull/406). Let's try to update this work.
Once we have the IbcExtension tested, I assume we have everything we need for an IBC visualizer data source.

Let's not use those linked prs. Data format is also changing we need simapp v0.40.0-rc2
We can provide test vectors when that is ready

@willclarktech @webmaster128
Here is my brief into as to what concepts are needed for the relayer:
Client/connection - are almost always 1:1 and refer to headers of another chain (to probe that something came from there). Let's list connections and each can "show details" for full client (in theory there can be multiple connections per client but I have not heard 1 example when this would be in reality, still listing connections means we would support it)
Port - each module/contract can bind onto a port. This is similar to TCP, but the same port is used for both sending and receiving.
Channel -  this is where information is sent. It involves a handshake between (connection, port) pair (one on each chain) and the channel gets it's own ID. (these ids are unique per connection)
Packet - this is a message sent over a channel and will be processed by an app on the other side. For ICS20 this packets says "move x tokens from me to you". There is an ack, which contains a result (success) or error, so the sender know if the money should be refunded locally when it fails

I have created https://github.com/CosmWasm/dApps/issues/61 to show the general workflow (3-4 pages we need to show). Here are the key queries (from the protobuf files) that we need working:
Connections:
rpc Connections(QueryConnectionsRequest) returns (QueryConnectionsResponse) - includes connection_id, client_id, state
Clients:
rpc ClientState(QueryClientStateRequest) returns (QueryClientStateResponse) - includes google.protobuf.Any client_state, which we should be able to parse. Currently defined client types are "tendermint", "localhost" and "solo_machine" (not sure where these are defined in code)
rpc ConsensusStates(QueryConsensusStatesRequest) returns (QueryConsensusStatesResponse) - returns all "consensus states" for this client - this is like a tendermint header or a solo machine pubkey. We need to figure out the concrete versions and parse them.
Channels:
rpc ConnectionChannels(QueryConnectionChannelsRequest) returns (QueryConnectionChannelsResponse)- given a connection, returns all (channel_id, port_id) pairs (local id) along with their counterparties and state
rpc PacketCommitments(QueryPacketCommitmentsRequest) returns (QueryPacketCommitmentsResponse) - lists all packet commitments for this channel

Here is the go relayer: https://github.com/cosmos/relayer
There are some scripts to set up a multiple chains for testing: https://github.com/cosmos/relayer/blob/master/scripts/two-chainz (this uses gaia, which we can replace with simapp) and just prepares the chains, not the connections. You can try these scripts out, but I woud not use them in our CI, just use them for design reference.
This will set up a relayer for 2chainz: https://github.com/cosmos/relayer/blob/master/scripts/config-relayer
And this is the demo setup scripts they run: https://github.com/cosmos/relayer#demoing-the-relayer
Please do try to get those to work out of the box (using their scripts and binaries) and when that works, we can see what we can pull out into our CI.

Closed in #510
Relayer functionality will be covered in #499 and #500


Correct description in tag kinds page

Hi, I've just found some sub-heading in tag kinds page showing something different stuff, probably copy-n-pasted, I guess.
This is just a tiny change but I thought it's good to modify for a clarification reason.
Thanks for your review on my change.

Good catch, thank you for taking the time to fix this!


0.3.7 fails to compile on arm32, while 0.3.6 compiles just fine

Hello,
I was compiling OpenBlas-0.3.7 on a Raspberry Pi4 using recent arm32 Raspbian. I did just make -j4 and got en error:
...
gemm_thread_tt -DCHAR_NAME=\"sgemm_thread_tt_\" -DCHAR_CNAME=\"sgemm_thread_tt\" -DNO_AFFINITY -I../.. -UDOUBLE  -UCOMPLEX  -c -DTHREADED_LEVEL3 -UDOUBLE -UCOMPLEX -DTT gemm.c -o sgemm_thread_tt.o
/tmp/ccVcvHlA.s: Assembler messages:
/tmp/ccvMTz5B.s: /tmp/ccVcvHlA.s:494: Error: selected processor does not support `dmb ish' in ARM mode
Assembler messages:
/tmp/ccvMTz5B.s:498: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccvMTz5B.s:588: Error: selected processor does not support `dmb ishst' in ARM mode
/tmp/ccvMTz5B.s:650: Error: selected processor does not support `dmb ishst' in ARM mode
/tmp/ccvMTz5B.s:745: Error: selected processor does not support `dmb ishst' in ARM mode
/tmp/ccvMTz5B.s:824: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccvMTz5B.s:843: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccvMTz5B.s:885: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccVcvHlA.s:582: Error: selected processor does not support `dmb ishst' in ARM mode
/tmp/ccVcvHlA.s:644: Error: selected processor does not support `dmb ishst' in ARM mode
/tmp/ccVcvHlA.s:739: Error: selected processor does not support `dmb ishst' in ARM mode
/tmp/ccVcvHlA.s:818: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccVcvHlA.s:837: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccVcvHlA.s:879: Error: selected processor does not support `dmb ish' in ARM mode
make[1]: *** [Makefile:483: sgemm_thread_nn.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:486: sgemm_thread_nt.o] Error 1
/tmp/cc2taceD.s: Assembler messages:
/tmp/cc2taceD.s:499: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/cc2taceD.s:589: Error: selected processor does not support `dmb ishst' in ARM mode
/tmp/cc2taceD.s:651: Error: selected processor does not support `dmb ishst' in ARM mode
/tmp/cc2taceD.s:746: Error: selected processor does not support `dmb ishst' in ARM mode
/tmp/cc2taceD.s:826: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/cc2taceD.s:845: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/cc2taceD.s:887: Error: selected processor does not support `dmb ish' in ARM mode
make[1]: *** [Makefile:489: sgemm_thread_tn.o] Error 1
/tmp/ccdtGaKI.s: Assembler messages:
/tmp/ccdtGaKI.s:499: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccdtGaKI.s:587: Error: selected processor does not support `dmb ishst' in ARM mode
/tmp/ccdtGaKI.s:649: Error: selected processor does not support `dmb ishst' in ARM mode
/tmp/ccdtGaKI.s:744: Error: selected processor does not support `dmb ishst' in ARM mode
/tmp/ccdtGaKI.s:824: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccdtGaKI.s:843: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccdtGaKI.s:885: Error: selected processor does not support `dmb ish' in ARM mode
make[1]: *** [Makefile:492: sgemm_thread_tt.o] Error 1
make[1]: Leaving directory '/home/pi/OpenBLAS-0.3.7/driver/level3'
make: *** [Makefile:150: libs] Error 1

On the other hand, the version 0.3.6 compiles just fine and both versions compile fine on aarch64.

Hmm.This looks like a return of issue #1961 (i.e., not automatically switchingTARGET to ARMV7 when BINARY=32 was given), but I am not aware that any recent change accidentally reverted #1987. Did you use the same make arguments and compiler for both 0.3.6 and 0.3.7 ?

Yes, it is the same:
gcc --version
gcc (Raspbian 8.3.0-6+rpi1) 8.3.0

I'm doing just this:
cd OpenBLAS-0.3.x
make clean
make -j4

However, I can see the automatically used compiler flags are different in both cases. 0.3.6:
cc -O2 -DMAX_STACK_ALLOC=2048 -marm -Wall -DF_INTERFACE_GFORT -fPIC
-DSMP_SERVER -DNO_WARMUP -DMAX_CPU_NUMBER=4 -DMAX_PARALLEL_NUMBER=1
-DVERSION=\"0.3.6\" -mfpu=neon-fp-armv8 -march=armv8-a+crc+simd -DASMNAME=samin
-DASMFNAME=samin_ -DNAME=samin_ -DCNAME=samin -DCHAR_NAME=\"samin_\"
-DCHAR_CNAME=\"samin\" -DNO_AFFINITY -I.. -I. -UDOUBLE  -UCOMPLEX -c -DUSE_ABS
-DUSE_MIN

0.3.7:
cc -O2 -DMAX_STACK_ALLOC=2048 -Wall -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER
-DNO_WARMUP -DMAX_CPU_NUMBER=4 -DMAX_PARALLEL_NUMBER=1 -DVERSION=\"0.3.7\"
-DASMNAME=cblas_sdsdot -DASMFNAME=cblas_sdsdot_ -DNAME=cblas_sdsdot_
-DCNAME=cblas_sdsdot -DCHAR_NAME=\"cblas_sdsdot_\" -DCHAR_CNAME=\"cblas_sdsdot\"
-DNO_AFFINITY -I.. -I. -UDOUBLE  -UCOMPLEX -DCBLAS```

Are these from the 32bit builds? The 0.3.7 one seems to miss a -march hint for the compiler, so it could be that my #1987 was incomplete

Yes, these are both arm32 builds. The 0.3.7 is also missing -marm. Should it be auto-detected?

It should be, but it looks as if the auto-detection still sees it as an aarch64 system when it is running a 32bit os. (Not sure why this is, as that informations is derived from either uname or gcc -E output.)
Right now I am no longer sure if the added code from #1987 gets executed at all in your case, but if it does it should be equivalent to compiling as make TARGET=ARMV7.

Now I see what is happening. I'm using aarch64 kernel and both arm32 and aarch64 userland. Then even in arm32 userland the uame -a still returns aarch64, which probably confuses the auto-detection:
Linux raspberrypi4 4.19.66-v8-fc5826fb999e-p4-bis+ #2 SMP PREEMPT Fri Aug 16 13:58:31 GMT 2019 aarch64 GNU/Linux
Strange that 0.3.6 gets it right.

So I got myself a Pi4B to debug this - cpuinfo in raspbian appears to be a complete mess (https://github.com/raspberrypi/linux/issues/3022), and the default raspbian install appears to be a purely 32bit armeabihf environment despite the ARMV8 cpu. How does one get an aarch64 kernel on this thing, and optionally the aarch64 userland to match ? (Though for now I am primarily interested in reproducing your mixed arm32/arm64 setup)

Great :) First you need Sakaki's pre-compiled aarch64 kernel. Better wait a bit, she promised to fix problem with WiFi later today. Untar it to -C / and I think the only change needed in /boot/config.txt is kernel=kernel8-p4.img and you boot aarch64 kernel into Raspbian arm32 userland.
But before you also need to run sudo rpi-update. It will update the arm32 kernel (which you don't need), but also firmware files, which are compatible with the new kernel.
Then for aarch64 userland the easiest is schroot with vanilla Debian Buster aarch64.
sudo apt-get install -y debootstrap schroot
sudo debootstrap --arch=arm64 buster /srv/chroot/pi64

Then you fill this into the file /etc/schroot/chroot.d/pi64:
[pi64]
description=VC4 arm64 testing
type=directory
directory=/srv/chroot/pi64
users=pi
root-groups=root
profile=desktop
personality=linux
preserve-environment=true

you may need to install e.g. sudo as well, otherwise you'd not be able to install anything once inside of the chroot:
sudo schroot -c pi64 -- apt-get install -y sudo
and you can chroot yourself into aarch64 userland:
schroot -c pi64

The new Sakaki's kernel <IP_ADDRESS>90827 is out.

Bisected to #2110 (and we even had misgivings about using uname -m to define ARCH early in the build :frowning_face: ) I'll do the PR later

Oh, that was fast :) Could you, please, look into https://github.com/xianyi/OpenBLAS/issues/2230, once you already have RPi4?  Or alternatively you can test small problem sizes.

No promises as I still have to try and schroot myself in the foot... also my Pi4 came with a whole collection of tiny heatsinks but no fan.


Update fastlane side of ActionCollector to support version and crash

Bump minimum required version of fastlane_core for ToolCollector changes
Remove String monkey-patching from fastlane that has been moved into fastlane_core
Update cli_tools_distributor to use the new fastlane_module String method in fastlane_core
Fix cli_tools_distributor_spec to be runnable on its own
Fix puts action to not error if passed a nil value
Update fastlane_runner to distinguish between a user error and a crash

Looks great, really good changes!


Warnings in Visual Studio (2017)

Hey
First of all, I want to tell you, that this plugin is really cool stuff! - THX
I have a Resx file, where one Value has an empty string as wanted text. In all translations
Now, I get a warning (this is okay), but I get as many warnings, as properties are in the resx file.
In my case, I have 23 properties within the RESX file. So, I get 23 warnings, for a missing translation, but it is only the one, which is wanted.
THX

@Intelli-Soft what are "properties within the RESX file"?

The resorce keys – sorry
Thx
Gesendet von meinem Windows 10 Phone

Von: tom-englert<EMAIL_ADDRESS>Gesendet: Thursday, July 5, 2018 11:21:58 AM
An: tom-englert/ResXResourceManager
Cc: Harald Bacik; Mention
Betreff: Re: [tom-englert/ResXResourceManager] Warnings in Visual Studio (2017) (#150)
@Intelli-Softhttps://github.com/Intelli-Soft what are "properties within the RESX file"?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/tom-englert/ResXResourceManager/issues/150#issuecomment-402660974, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANcSm5Hv9FiVBJ20rBA9ZVdGOVguftVJks5uDdq2gaJpZM4VDg3g.

I get exactly one warning per empty cell. Can you post a screen shot?

Hey
Sure – I hope this works, when I embed the picture here:
<EMAIL_ADDRESS>Von: tom-englert<EMAIL_ADDRESS>Gesendet: Donnerstag, 5. Juli 2018 12:10
An: tom-englert/ResXResourceManager<EMAIL_ADDRESS>Cc: Harald Bacik<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Betreff: Re: [tom-englert/ResXResourceManager] Warnings in Visual Studio (2017) (#150)
I get exactly one warning per empty cell. Can you post a screen shot?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/tom-englert/ResXResourceManager/issues/150#issuecomment-402674125, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANcSm-7bzIoa2XvHGhcCKo7bljH0Vy74ks5uDeXdgaJpZM4VDg3g.

@Intelli-Soft: no, there is no image embeddd

Looks like your neutral column is not visible, but empty for all entries.

Okay. – So, it means I must set a neutral language. – Can I set the “de-at” as neutral anyhow, or do I have to copy all values from de-at to neutral?
THX
Von: tom-englert<EMAIL_ADDRESS>Gesendet: Freitag, 6. Juli 2018 14:40
An: tom-englert/ResXResourceManager<EMAIL_ADDRESS>Cc: Harald Bacik<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Betreff: Re: [tom-englert/ResXResourceManager] Warnings in Visual Studio (2017) (#150)
Looks like your neutral column is not visible, but empty for all entries.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/tom-englert/ResXResourceManager/issues/150#issuecomment-403022091, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANcSmwh5XhsQIudFRv2krVrJAc-7Uvrfks5uD1qPgaJpZM4VDg3g.

you can just rename or copy the ???.de-at.resx file to ???.resx

Perfect! – THX a lot – You can close this “issue” – What wasn’t any
Von: tom-englert<EMAIL_ADDRESS>Gesendet: Freitag, 6. Juli 2018 16:07
An: tom-englert/ResXResourceManager<EMAIL_ADDRESS>Cc: Harald Bacik<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Betreff: Re: [tom-englert/ResXResourceManager] Warnings in Visual Studio (2017) (#150)
you can just rename or copy the ???.de-at.resx file to ???.resx
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/tom-englert/ResXResourceManager/issues/150#issuecomment-403044793, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANcSm74juWQH763EsX66QdEgr_AuvQhCks5uD28JgaJpZM4VDg3g.


Future combinators

I am new to async PHP, so I might be missing smth. Why amphp v3 does not have any Future combinators?
Here's how I return single Future for two operations now (btw, is it correct?):
async(static fn (): array => await([
    async(static function (): void { delay(2); }), // some IO
    async(static function (): void { delay(3); }), // another IO
]));

Wouldn't it be nicer to do smth like?
all([
    async(static function (): void { delay(2); }), // some IO
    async(static function (): void { delay(3); }), // another IO
]);

Thanks for the project. I am having a lot of fun with it!

See https://github.com/amphp/amp/blob/3.x/src/Future/functions.php. You probably want awaitAll().

@Bilge , no, I want a function that immediately returns a single Future, not awaited result.

I have no idea what you're talking about.

Well, I am talking about a function like React\Promise\all. It returns Promise, not awaited result array like await in amphp.

Returns a promise that will resolve only once all the items in $promisesOrValues have resolved. The resolution value of the returned promise will be an array containing the resolution values of each of the items in $promisesOrValues.

Let me put it this way:
Amp\Future\await() is callable(iterable<TKey, Future<TValue>>): array<TKey, TValue>
But I want callable(iterable<TKey, Future<TValue>>): Future<array<TKey, TValue>>

@Bilge , does it make sense now? I can give an example of problem I am solving.
Here are similar methods/functions in other langiuages: JS, C#. Note that return type is different from Amp\Future\await or Amp\Future\awaitAll.

You can wrap it in async() if you really need that, but we use futures rarely with fibers, only when necessary.

Thank you, @kelunik, that makes sense! After three days of experimenting with amphp 3 I now understand, why await combinators are much more useful.


Do not leak UInt32 types to Elixir

I was able to remove most of them, except for expr_count which still returns u32. Trying to cast the value there changes the result of the expression and two tests fail. It seems to be a polars bug that would need to be isolated.


Cancel button behavior

PR for #14
This PR should be reviewed (and merged) after #16 and #17, as it also includes the changes.

I like the configurability of this PR.
Only thing: #14 was actually a bug introduced by pull request #8, so the default behavior should be clearOnCancel = false. I changed this (and your demo, to make it interesting).


[WIP] Directly run storeserver main class replace jar for coverage

Is this ready for review?

This is a failed attempt.


Disable default unique slug generation so slug validation rule 'uniqu…

…e' is applicable
Currently, duplicate attribute names are allowed.  Looking at the rules in Attribute.php model, it appears this is not desirable because of the 'unique' rule on 'slug'.
Attribute.php:
    public function __construct(array $attributes = [])
    {
        parent::__construct($attributes);

        $this->setTable(config('rinvex.attributes.tables.attributes'));
        $this->setRules([
            'name' => 'required|string|max:150',
            'description' => 'nullable|string|max:10000',
            'slug' => 'required|alpha_dash|max:150|unique:'.config('rinvex.attributes.tables.attributes').',slug',
            'sort_order' => 'nullable|integer|max:10000000',
            'group' => 'nullable|string|max:150',
            'type' => 'required|string|max:150',
            'is_required' => 'sometimes|boolean',
            'is_collection' => 'sometimes|boolean',
            'default' => 'nullable|string|max:10000',
        ]);
    }

Since spatie/laravel-sluggable makes all slugs unique by default by appending a dash and a number to the end, this rule will never be enforced (see sluggable docs).  In order to prevent this default behavior, allowDuplicateSlugs() should be called.  Then, any attempt to save an attribute with an existing name will result in an error.

Would not be risky to have two attributes with the same slug? Considering that you can reuse the same attribute for various entities, I do not really see this needed.
Could you provide an scenario?

cc @dhildreth

The scenario that brought this to my attention was through an administration page for modifying and creating new attributes.  The user would goto add a new attribute, but mistakingly recreates an existing attribute.  For example, the "cpu_speed" attribute (slug = "cpu-speed") already exists but the user attempts to create it again.  This should not be allowed and should alert the user via validation rules in Attribute.php.  Instead, it is allowed because the slug is created as "cpu-speed-1".  The validation rule
'slug' => 'required|alpha_dash|max:150|unique:'.config('rinvex.attributes.tables.attributes').',slug'
will always pass successfully as long as allowDuplicateSlugs() isn't being called.

But don't we agree that having 2 attributes with the same name is useless taking into consideration what I mentioned below? That they can be attached to multiple entities and reuse them.
Maybe just need to add a warning to the UI rather than blocking the creation.
What do you think @Omranic?

I was able to get around this issue in with my project by creating my own App\Attribute.php model that extends the original Rinvex\Attributes\Models\Attribute.php model.  I still feel that this pull request is a worthwhile change for others.  If not, you may as well remove the validation rule because it's not going to accomplish anything.  I know it sounds trivial, but I did spend quite a bit of time debugging this one for my use case.

I do not really understand your issue at all, you can use the same attribute for multiple entities, isn't that what you want?

Info not provided


Added Chrome Dino Game using Python

A simple Chrome Dino Game Replica built using Python.

closes #254

closes #233


Is it possible to using colon and comma in template?

In liquid, normally using colon and comma to determine filter arguments.
For example: {{ "This is an example" | replace: "an", "a" }}
However in scriban: {{ "This is an example." | string.replace "an" "a" }}
Using like that not understandable, you need to look closer for space. If I have any chance to change the space with comma and also add a colon. I prefer this usage.
Why I need to ask this, because I cannot use LiquidParse below code.
var template = Template.Parse("{{ 'Hello World' | string.replace 'World' name }}");
var result = template.Evaluate(new { Name = "Mars" });

This is by design and can't be changed in Scriban. Also Liquid had never specified the way arguments would be parsed, so that's why it was not implemented in Scriban (Liquid support is not a full Liquid support, more a support to help transitioning)

Thanks for quick reply. So why I cannot use Evaluate with LiquidParse? It is thrown exception. However, render is working expected.
Exception:Scriban.Syntax.ScriptRuntimeException: '<input>(1,20) : error : The functionreplace was not found'

Oh, right, for the second issue, Evaluate is currently assuming Scriban language. It's a bug (Internally it has to use "LiquidTemplateContextnotTemplateContext`)

This should be fixed (the usage of Liquid functions in Template.Evaluate) in the next release 3.0.4


dynamic machinekey parameter

I think the dynamic machinekey parameter to decrypt the token is better, my ValidationAlgorithm: HMACSHA256, I can't use your middleware...

Can you elaborate more, please? The machine key can be passed in to each call to decrypt the token.


App icon visibility

Summary:
The app icons is not properly visible if the background colour is same as the app colour.
We can envelope the icon within a white circle or square to make it visible in all backgrounds.
Screen-shots:

Discussions on app icon #868

Solved:)


AttributeError: module 'pywhiten.cfg' has no attribute 'pkg_path'

I'm trying to follow the tutorial, and my example.py looks like
import numpy as np
t,m = np.loadtxt("TIC120257786_lk.csv").T

import pywhiten
print(pywhiten.cfg.pkg_path)

pywhitener = pywhiten.PyWhitener(time=t, data=m)

pywhitener.auto()

When I run python example.py, I get this error:

Traceback (most recent call last):
File "/Users/sjm/Desktop/TESS_sandbox/pywhiten_tutorial/example.py", line 5, in
print(pywhiten.cfg.pkg_path)

      ^^^^^^^^^^^^^^^^^^^^^

AttributeError: module 'pywhiten.cfg' has no attribute 'pkg_path'

I'm running Python 3.11.5 on Mac OS 11.7.6

Sincere apologies for the slow response, unfortunately I was not automatically notified of the posting of this issue. This should be fixed by the updated version 1.2 released in November. Cheers.


Relevancy changes in rc0 - are they expected?

Some SDK tests of Java SDK are failing on main: https://github.com/meilisearch/meilisearch/actions/runs/9301805080/job/25601375025
Can you confirm they are expected? I don't see any link with https://github.com/meilisearch/meilisearch/issues/4639
Here are the tests, I managed to reproduce them with Postman, so without Java SDK
👉 Dataset: movies.json
1 - Test testRawSearchSort
cf: https://github.com/meilisearch/meilisearch-java/blob/47d8adfd18212c5b45d9f9443b8aade7c31ccb4c/src/test/java/com/meilisearch/integration/SearchTest.java#L508
Steps:

Import dataset
sortableAttributes: ["title"]
search:

{
    "q": "and",
    "sort": ["title:asc"]
}

v1.8.1:  document 495764 is first
v1.9.0 (so main): document 38700 is first, and 495764 is third
2 - Test testRawSearchSortWithIntParameter
cf: https://github.com/meilisearch/meilisearch-java/blob/47d8adfd18212c5b45d9f9443b8aade7c31ccb4c/src/test/java/com/meilisearch/integration/SearchTest.java#L543
Steps:

Import dataset
sortableAttributes: ["id"]
search:

{
    "q": "and",
    "sort": ["id:asc"]
}

v1.8.1: document 671 is first (and 38700 is third and not second, which is weird btw)
v1.9.0: document 671 is second and document 38700 is first again
3 - Test testSearchWithCustomizedHighlight
cf: https://github.com/meilisearch/meilisearch-java/blob/47d8adfd18212c5b45d9f9443b8aade7c31ccb4c/src/test/java/com/meilisearch/integration/SearchTest.java#L277
Steps:

Import dataset
search:

{
    "q": "and",
    "attributesToHighlight": ["title"],
    "highlightPreTag": "(⊃｡•́‿•̀｡)⊃ ",
    "highlightPostTag": " ⊂(´• ω •`⊂)"
}

v1.8.1: 495764 is first
v1.9.0: 38700 is first again. 495764 is forth.
4 - Test testSearchHighlight
cf: https://github.com/meilisearch/meilisearch-java/blob/47d8adfd18212c5b45d9f9443b8aade7c31ccb4c/src/test/java/com/meilisearch/integration/SearchTest.java#L249
Steps:
Steps:

Import dataset
search:

{
    "q": "and",
    "attributesToHighlight": ["title"]
}

v1.8.1: 495764 is first
v1.9.0: 38700 is first, 495764 is 4th

Hello :wave:,
the discrepancies are indeed caused by https://github.com/meilisearch/meilisearch/issues/4639

As these tests don't specify the searchableAttributes, before (v1.8.1), the fields would be ordered in decreasing order of relevancy: id (attributeRankingOrderScore=1.0), title (attributeRankingOrderScore=0.857), poster (attributeRankingOrderScore=0.714), overview (attributeRankingOrderScore=0.571), release_date (attributeRankingOrderScore=0.429), languages (attributeRankingOrderScore=0.286), genres (attributeRankingOrderScore=0.143). Now, the fields are no longer ordered (all attributeRankingOrderScore=1.0 regardless of the field).
As these tests use the default ranking rule order, attributes is ranked above sort
in v1.8.1, attributeRankingOrderScore was what would break the tie between documents, hence the previous order (it would favor documents where and would appear in title rather than overview)
in v1.9.0 it is now queryWordDistanceScore that breaks the tie, hence the new order (it favors documents where and appears near the beginning of either title or overview, without a preference for one or the other).

Possible fixes:

Update the tests to match the new results,
Explicitly set searchableAttributes to ["title", "overview"], which should revert the previous behavior and results
If the idea of tests (1) and (2) is to test sort, consider changing the default ranking rule to have sort at first (I'm not sure, depends on what the tests want to check)

No worries about the tests, I will update them accordingly.

As these tests don't specify the searchableAttributes, before (v1.8.1), the fields would be ordered in decreasing order of relevancy: id (attributeRankingOrderScore=1.0), title (attributeRankingOrderScore=0.857), poster (attributeRankingOrderScore=0.714), overview (attributeRankingOrderScore=0.571), release_date (attributeRankingOrderScore=0.429), languages (attributeRankingOrderScore=0.286), genres (attributeRankingOrderScore=0.143). Now, the fields are no longer ordered (all attributeRankingOrderScore=1.0 regardless of the field).

This is a huge impact, I did not realize it with the https://github.com/meilisearch/meilisearch/issues/4639, my bad. Is it something we really want? I mean, it's less convenient for users regarding product perspective, so what do we gain technically?
Did you discuss with @meilisearch/product-team before doing it? (real question, I don't know)

I mean, it's less convenient for users regarding product perspective (before you entered most of the dataset, with title at top, and it worked), so what do we gain technically?

Huuum, why is it less convenient? It still works, right? It’s just not ordered in the same way, and we didn’t rely on the fact that maybe the ordering of the first time we’ve discovered every field was important, but that was the point.

Did you discuss with @meilisearch/product-team before doing it? (real question, I don't know)

No, I think we were in a call with all the engineers, saying that it’s what we originally wanted to do but couldn’t. Since it was non-breaking and only a relevancy change, we didn’t communicate much about it except for the issue.

Is it something we really want?

No strong opinion on my side; I don't think it’s hard to revert to the previous behavior.
But we should really get @ManyTheFish and @Kerollmops in the discussion because they’re the real relevancy expert here 👀

Thanks @irevoire for summarizing the situation here

Is it something we really want?

No strong opinion either way, there's a definite benefit to avoiding "automagic" behavior, but I agree that this particular one was useful, and that the change is probably disruptive.
The important parts for me are:

gives us the ability to finally untie the importance (or weight) of each field with their order.

and the fix on the priority of nested fields.

The fix for nested is nice, but the global change looks less convenient to me. So, personally, no strong opinion.

we can have one without the other so it shouldn't be a factor in the decision about the default weights

it's always good to check with @meilisearch/product-team 😊

agreed

Closing this issue, decision has been made: the behavior is expected, and we keep it as it is! 🎉


DependencyCheck files outside of the folder specified

Hello,
I have a problem where I used version 5.0.0-M2. The problem is I have removed the problematic dll from the folder that I wish to scan but the dependencycheck still scanned the dll but it is in another folder C:\Users\User\AppData\Local\Temp\dctempb8e8dc2b-974f-4fb5-b674-95014d9397e5\check21571493770273509tmp\4\lib\net45\BotDetect.Web.UI.Mvc.dll
Strangely, I noticed it is able to get the removed above DLL back into the AppData Local.
Can you please advise what should I do to get the dependencycheck to scan the folder that I specified?

Hello! Any status on this one?

First, please consider upgrading dependency-check; you are using a milestone release (5.2.1 is the latest).
Second, when DLL files are found in zip, jar, war, bz2, etc. archive files - they are extracted to a temporary location, analyzed, and then deleted.  We should update the error message to use a different path (the one that points to the file in the directory scanned).


[feat] Allow docking of browser dev tools when launching tauri in dev mode.

Describe the problem
Trying to debug the frontend using browser dev tools and the window is not docked
Describe the solution you'd like
Be apple to specify that the debug tools are docked when running the app in dev mode.  Also be able to specify the position as in left bottom and so on.
Example:   window.open_devtools('right');  This would open the dev tools on launch and dock to the right side of the window.
Alternatives considered
No response
Additional context
No response

Thanks for the requst. Unfortunetly, none of the webviews have apis for this as far as i can see. They only have some for generic open/close :(


[Performance] Few request failures due to "Remote client closed the connection before completing outbound response"

Description:
Observed few requests getting failed due to "Remote client closed the connection before completing outbound response" when the throughput is around 1000, 2000 range
Steps to reproduce:
Passthrough HTTP service, with netty backend
Affected Versions:
ballerina-platform-0.970.1
Observations
[2018-05-17 01:34:13,149] WARN  {org.wso2.transport.http.netty.sender.TargetHandler} - Idle timeout triggered while reading inbound response
[2018-05-17 01:34:13,150] WARN  {org.wso2.transport.http.netty.sender.TargetHandler} - Idle timeout has reached hence closing the connection 39a5e871
[2018-05-17 01:34:13,151] ERROR {org.wso2.transport.http.netty.common.Util} - Remote client closed the connection before completing outbound response
java.io.IOException: Remote client closed the connection before completing outbound response
        at org.wso2.transport.http.netty.common.Util.lambda$checkForResponseWriteStatus$9(Util.java:599)
        at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:507)
        at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:481)
        at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:420)
        at io.netty.util.concurrent.DefaultPromise.addListener(DefaultPromise.java:163)
        at io.netty.channel.DefaultChannelPromise.addListener(DefaultChannelPromise.java:93)
        at io.netty.channel.DefaultChannelPromise.addListener(DefaultChannelPromise.java:28)
        at org.wso2.transport.http.netty.common.Util.checkForResponseWriteStatus(Util.java:595)
        at org.wso2.transport.http.netty.contractimpl.HttpOutboundRespListener.writeOutboundResponseBody(HttpOutboundRespListener.java:198)
        at org.wso2.transport.http.netty.contractimpl.HttpOutboundRespListener.writeOutboundResponse(HttpOutboundRespListener.java:149)
        at org.wso2.transport.http.netty.contractimpl.HttpOutboundRespListener.lambda$null$35(HttpOutboundRespListener.java:102)
        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:463)
        at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.lang.Thread.run(Thread.java:748)

ballerina-passthroug-round1.log.zip

The default idle timeout is 60s and when the idle timeout is reached while reading or before reading the response it will close the connection. After the connection is closed if we try to send a message then this exception is thrown. This is to be expected. This might be because the backend is slow. Try increasingtimeoutMillis in the client config to fix this.


Ability to earn badges

Users should earn badges based on milestones achieved
eg.

Most code committed
Most Test cases committed
Most Code Reviews
etc

What gives points [1]
Collaborating effectively.
Following best practices.
Reviewing code, sending pull requests, increasing the test coverage... Be careful, don't break the build :)
[1] http://www.gitpoints.com


Please bump dependency on packaging to 23 or newer

The azure-cli-core package has version 22 as the maximum version of packaging in its dependencies:
'packaging>=20.9,<22.0'

Since the current version of packaging is now 23 [1], this limitation should be bumped so Linux distributions packaging the Azure CLI don't run into dependency issues.

[1] https://pypi.org/project/packaging/

+1 on this. I'm using tox, which has a dependency of packaging>=23. azure-cli-core is not compatible.

@jiasli. We only use from packaging.version import parse, can we upgrade it like #20661?


Feature Request: Real-time subscription 'before'

I would like to propose the inclusion of "before": {<data>} in the real-time subscription to "action": "update".
This idea draws inspiration from discord's API, specifically the discord.on_user_update(before, after) event. Although it may not be widely utilized, it has the potential to be valuable in certain scenarios. To maintain backward compatibility, retain the existing "record": {<data>} structure and adding "before": {<data>} to the event data.
If implementing this change proves to be excessive, please do not feel pressured.

It can be implemented without too much changes but I'm not sure how useful that would be because usually when you track updates client-side you already have the old/before record state somewhere (eg. fetched from a getList/getOne call) and we may end up sending too much unnecessary information which could further increase the messages latency.
Do you have a real use case for it? How do you plan to use it?

Message latency is a concern, which could be solved by:
pb.collection('---').subscribe('*', function (e) {
    console.log(e.record);
}, true);

true representing include_before_data. While this would add another check to the pb backend, it would reduce payload when sending an event if the extra information is not wanted. include_before_data defaulting to false, obviously.
My case for it is outside client side usage, being used in the backend. For instance, when the email successfully changes, you could check if e.before.email !=== e.record.email and log the change, or send an email to the e.before.email saying their email successfully changed. Sure, this can be done client side too, but it is an example of possible usage.
Another usage would be hiding sensitive data, such as SMTP login or admin login, in the event the client app was cracked. By having the ability to know previous data, I can track changes in the database as well as I could client-side, while protecting the information that matters the most.

I don't think the suggested flag proposal is good idea because it will work only with the update action and it doesn't make much sense to have it for every other subscribe action and topic.
I could understand the first example when you have another middleware service involved, but I don't understand the other one with _"hiding sensitive data, such as SMTP login or admin login".
In general, if you need more control over the realtime events you can attach to the Go app hooks (soon there will be an option to attach to the app hooks with JS too). The realtime APIs relies on the OnModel* hooks.
I'll close the issue for now as I think the cons outweigh the pros, but depending on the users demand and the eventual blocker use cases that could arise, I may reconsider it in the future.

Okay! Thank you for your consideration, it's much appreciated.


x/build: add LUCI openbsd-arm64 builder

Please add a LUCI builder for openbsd/arm64 with hostname openbsd-arm64-jsing - note that this will be running on the same hardware as the current host-openbsd-arm64-joelsing builder. This machine is not capable of running both forms and will need to be hard migrated at some point in time. CSR for this builder is attached.
openbsd-arm64-jsing.csr.txt

Here's the certificate: openbsd-arm64-jsing-1715630445.cert.txt.
Please feel free to stop the old coordinator builder on your end whenever it's getting in the way of bringing up the new LUCI builder.