should be “Loading your Safe” instead of "Loading your safe", capitalised

Go through "create safe flow" and look at the text on "Load your safe" button

Found during Bug hunting session - https://pr2898--safereact.review-safe.gnosisdev.com/app

Fixed ✅


Fix QuotaHelper for spec in darga

A recent commit was made to master that namespaced a lot of the helpers in spec/support.
https://github.com/ManageIQ/manageiq/pull/10417
The one for QuotaHelper (and others) were not backported, but PRs against master still use this new namespace.  This fixes include to use the old non-namespaced module.
Links

https://github.com/ManageIQ/manageiq/pull/10281
https://github.com/ManageIQ/manageiq/pull/10417

@chessbyte hopefully this fixes the failing tests on darga...


#1730 Upgrade Vuetify to Release Version#1730

Upgrade Vuetify to 3.1.5.
Imported VDataTableServer from "vuetify/labs/VDataTable".
Replaced Location program datatate with <v-data-table-server
Implemented <v-data-table-server default sort and pagination
Search feature is not in the <v-data-table-server
There was a bug in the existing API, for page 0, it was returning the entire values,- fixed

Nice work. I assume the upgrade did not cause any significant layout break, right? Was there any direction that indicates what is the plan to move the v-data-table-server component from labs to a final release? The real question would be, can we start to replace the other components right now or hold till the component is part of the release?

yes, @andrewsignori-aot I did a smoke test, and I didn't find any significant layout break. I think it's pretty stable. And regarding the component release, I was searching for it and I couldn't find any information regarding them. I think it is pretty stable and they are also adding features and doing bug fixes for the component, https://github.com/vuetifyjs/vuetify/releases?q=VDataTableServer&expanded=true. IMO, the component has what we needed,  except the search functionality (and I couldn't find anything saying there will introduce it in v-datatable-server, though the other  2 data table has that functionality)

Great work @ann-aot . I also had the same question that @andrewsignori-aot  had  as is it the right time to change other components to vuetify data table?

Great work @ann-aot . I also had the same question that @andrewsignori-aot had as is it the right time to change other components to vuetify data table or wait till it move from labs to vuetify/lib?

https://github.com/bcgov/SIMS/pull/1754#issuecomment-1444550164


React Solana Core Example: WalletLoginError: Failed to connect with walletFailed to login with openlogin

After adding the clientId in the source code and:
npm install and npm start I'm able to login.
After the first login/logout, I'm not able to login anymore, the console is printing the following error:
Uncaught (in promise) WalletLoginError: Failed to connect with walletFailed to login with openlogin

Talk to Solana Support on the Live support page so that your issue can be looked into.

Hey @GabrielePicco can you try it again, we have updated all the examples and are currently working as expected. Also were you running it on a server or on localhost? If you're running it on a server you need to whitelist that URL on your web3auth dashboard.

Hey @yashovardhan , thanks for the response, the updated example seems to work better, but I still expect some occasional error. Some of them:

When using incognito window:

Failed to read the 'sessionStorage' property from 'Window': Access is denied for this document.
    at y (https://solana.tor.us/js/index.024a496c.js:1:112083)
    at e (https://solana.tor.us/js/FRAME.5ad51491.js:1:79104)
    at a (https://solana.tor.us/js/chunk-vendors.00d93d06.js:10:156430)

Reloading:

Error: StreamMiddleware - Unknown response id "a07099ab202fccfd5a1162deba3a268037c855e647b439c3808f9d49c87e89fd"
    at TorusInPageProvider._handleDisconnect (inPageProvider.ts:175:1)
    at TorusInPageProvider._handleStreamDisconnect (baseProvider.ts:147:1)

and sometimes:

chunk-vendors.00d93d06.js:138 Error: PollingBlockTracker - encountered an error while attempting to update latest block:
Error: PollingBlockTracker/_fetchLatestBlock() - encountered error fetching block:
Error: failed to get recent blockhash: we: Expected the value to satisfy a union of `type | type`, but received: [object Object]

These are the steps I used to run the example locally:

Clone the repo
cd examples/web-modal-sdk/solana/react-solana-web3auth-example
npm install
npm start dev

Hey @GabrielePicco
Can you try it with the latest example?

Thanks @shahbaz17 , just tried now and seems to work much better with the latest version.
I still observe this issue when using incognito window:
Failed to read the 'sessionStorage' property from 'Window': Access is denied for this document.
    at y (https://solana.tor.us/js/index.024a496c.js:1:112083)
    at e (https://solana.tor.us/js/FRAME.5ad51491.js:1:79104)
    at a (https://solana.tor.us/js/chunk-vendors.00d93d06.js:10:156430)

All the other problems seems to be fixed.

Yes @GabrielePicco it won't work in the incognito window. We need access to session storage for web3auth standard working. You can manually use local storage instead by using the storageKey in web3auth constructor https://web3auth.io/docs/sdk/web/modal/initialize#web3authoptions
I guess this is working as expected then, I'm closing this issue. Please open up a new issue/ github discussion if you still feel there's an error.


chore: fix failed in StreamConvertersSpec

Motivation:
refs: https://github.com/apache/pekko/issues/1653
Modification:
Implemented the splitIterator in test
Result:
Tests run ok.

since this was likely caused by https://github.com/apache/pekko/pull/1249, I think this should be backfit


Parsing html files.

I am trying to extract information from an html while retaining the structure. I am not able to extract information related to links and images in the html file. Can someone guide me how to parse an html file and extract information in order?

Hi @FatemaD1577. I don't believe we support extracting images, but we do support link extraction. It is captured in the metadata of the text that contains the link. Here is an example:

Also adding a link to partitioning html in our documentation if that might be helpful: https://unstructured-io.github.io/unstructured/core/partition.html#partition-html

Hi @FatemaD1577. I don't believe we support extracting images, but we do support link extraction. It is captured in the metadata of the text that contains the link. Here is an example:
Also adding a link to partitioning html in our documentation if that might be helpful: https://unstructured-io.github.io/unstructured/core/partition.html#partition-html

Hi @Coniferish, Thank you for the prompt reply can you also help understand how to use parent_id parameter from the metadata part and how we can extract information regarding parent tag.

Hi, I am processing a html file where image plays a significant place in context wrt the text. If we have to get the images too, what can be the workaround? Shall we convert the html to pdf and then do this?

Hi, I am processing a html file where image plays a significant place in context wrt the text. If we have to get the images too, what can be the workaround? Shall we convert the html to pdf and then do this?

That is a reasonable way to go if your goal is to fully partition the page the user sees, especially if there is text  in those images that you would like to extract. Generally, this is the "headless browser" use case, for which parititon_html is not a full solution, nor intended to be.

@subhamiitk Sorry for the delay.
For the parent_id question, the parent_id contains the element.id of the element's parent. For example, if we have a Title element parent_element.id=001, a child of that element would be child_element.metadata.parent_id=001


fix fluentbit operator not support Time_Key_Nanos field bug

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Does this PR introduced a user-facing change?

Additional documentation, usage docs, etc.:

DCO failed, please commit with "-s" to add a signature.


New maintainer needed

I currently don't have the resources to maintain this project. If someone is willing to put in the time to do it, I'm willing to assign the necessary privileges to that person. If you're willing to do this, reply on this issue or send me email.

Hey Enniel, apparently you don't need a typescript version anymore, adonis v5 the way it is you can create your own middleware to check your role or permission, it ends up being less heavy for any project as it just does what is necessary and it is possible to customize and know more closely what's going on


run stretch's layout on physical coordinates to fix pixel alignment

Currently, the values passed to stretch's algorithm are in logical coordinates. Due to internal rounding in stretch's algorithm, the results don't align to the pixel grid on high DPI monitors with non-integer scaling factors. This patch converts those values to physical coordinates prior to invoking the stretch and converts the results back to logical coordinates so that stretch rounds coordinates to the nearest physical pixel.

There is one artifact you can see when running a 2x scale factor. Run the UI example and watch the two elements anchored to the top edge while resizing the window from the bottom edge. They vibrate vertically due to the fractional part of logical size spinning through different values. For 2x, it would toggle between .0 and .5 which causes the items to move up and down by one pixel.

Ooh yeah thats definitely noticeable. And this pr definitely fixes it. Nice work!


Merge back changes from masterIdea14

This change brings the outstanding changes that were checked into the masterIdea14 branch back down to the src/14 directories on the master branch.  When this is submitted, we can remove masterIdea14.
All of the changes were merged down to masterIdea14 before this branch was made.  Really, we are simply moving three files from common to src/13, then adding the v14 versions of those same files from masterIdea14 into the src/14 and src/14.1 directories.  giabao's changes are already in master so they don't appear on in the changed file list.  (I tried to find a way to keep the history -- even by moving through multiple branches, -- but git doesn't provide a way for a single file to have multiple, divergent, paths in the same tree; one file can't have two or more descendants.)

approved


Cascade deletes doesn't work on many to many relations

Bug description
I'm getting an error when I try to remove an entity from a explicit many-to-many relationship.
The change you are trying to make would violate the required relation 'ContactToServerToServer' between the ContactToServerandServer models.
How to reproduce
I am using an empty posgresql database and Typescript so:

npx prisma generate
npx prisma migrate save --name init --experimental
npx prisma migrate up --experimental
DEBUG=* npx ts-node index.ts

Expected behavior
I wanted to delete the server, ( and doing so, delete also the entry in the relation table )
The created contact should not be affected
Prisma information
My prisma schema:
`// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model Contact {
  id Int @default(autoincrement()) @id
  name String @unique
  servers ContactToServer[]

}
model ContactToServer {
  contact Contact @relation(fields: [contactId], references: [id])
  contactId Int
  server Server @relation(fields: [serverId], references: [id])
  serverId Int
  functionality String

  @@id([contactId,serverId])
}
model Server {
  id Int @default(autoincrement()) @id
  hostname String @unique
  contacts ContactToServer[]
}`

and my Prisma queries:
import { PrismaClient } from "@prisma/client"

const prisma = new PrismaClient({
    log : ["info","query","warn"]
})
async function main() {
   await test()
}
async function test(){
    const contact = await prisma.contact.create({
        data : {
            name : "Alice"
        }
    })
    const contact2 = await prisma.contact.create({
        data : {
            name : "Bob"
        }
    })
    const server = await prisma.server.create({
        data : {
            hostname : "SERVER_01",
            contacts : {
                create : [
                    {
                        functionality : "Support",
                        contact : {
                            connect : {
                                name : "Bob"
                            }
                        }
                    },
                    {
                        functionality : "Hosting",
                        contact : {
                            connect : {
                                name : "Alice"
                            }
                        }
                    }
                ]
            }
        }
    })
    const deleteServer = await prisma.server.delete({
        where : {
            id : 1
        }
    })
    return
}
main()
    .catch(e => {
        throw e
    })

Environment & setup

OS: Ubuntu 18.04.4 LTS
Database: PostgreSQL 11.7
Prisma version: prisma/1.34.10 (linux-x64)
Node.js version: v12.14.1
NPM version: 6.14.4

Stack Trace
prisma-client {
  prisma-client   engineConfig: {
  prisma-client     cwd: '/home/docker/Prisma/prisma',
  prisma-client     debug: false,
  prisma-client     datamodelPath<EMAIL_ADDRESS>  prisma-client     prismaPath: undefined,
  prisma-client     datasources: [],
  prisma-client     generator: {
  prisma-client       name: 'client',
  prisma-client       provider: 'prisma-client-js',
  prisma-client       output: '/home/docker/Prisma/node_modules/@prisma/client',
  prisma-client       binaryTargets: [],
  prisma-client       config: {}
  prisma-client     },
  prisma-client     showColors: false,
  prisma-client     logLevel: 'info',
  prisma-client     logQueries: true,
  prisma-client     env: {
  prisma-client       DATABASE_URL: 'postgresql://test:test@localhost:5432/test2?schema=public'
  prisma-client     },
  prisma-client     flags: []
  prisma-client   }
  prisma-client } +0ms
  prisma-client Prisma Client call: +67ms
  prisma-client prisma.contact.create({
  prisma-client   data: {
  prisma-client     name: 'Alice'
  prisma-client   }
  prisma-client }) +1ms
  prisma-client Generated request: +0ms
  prisma-client mutation {
  prisma-client   createOneContact(data: {
  prisma-client     name: "Alice"
  prisma-client   }) {
  prisma-client     id
  prisma-client     name
  prisma-client   }
  prisma-client }
  prisma-client  +0ms
  engine {
  engine   PRISMA_DML_PATH<EMAIL_ADDRESS>  engine   PORT: '39629',
  engine   RUST_BACKTRACE: '1',
  engine   RUST_LOG: 'info',
  engine   LOG_QUERIES: 'true',
  engine   OVERWRITE_DATASOURCES: '[]'
  engine } +0ms
  engine { cwd: '/home/docker/Prisma/prisma' } +0ms
  getos { version: 'OpenSSL 1.1.1  11 Sep 2018\n' } +0ms
  getos { ls: '' } +0ms
  getos { platform: 'linux', libssl: '1.1.x' } +2ms
  plusX Execution permissions of<EMAIL_ADDRESS>are fine +0ms
  engine { flags: [ '--enable-raw-queries' ] } +4ms
  engine stderr Printing to stderr for debugging +15ms
  engine stderr Listening on <IP_ADDRESS>:39629 +1ms
  engine stdout {
  timestamp: 'Apr 29 21:46:40.768',
  level: 'INFO',
  target: 'quaint::pooled',
  fields: { message: 'Starting a postgresql pool with 15 connections.' }
} +0ms
prisma:info  Starting a postgresql pool with 15 connections.
  engine stdout {
  timestamp: 'Apr 29 21:46:40.771',
  level: 'INFO',
  target: 'query_engine::server',
  fields: { message: 'Started http server on <IP_ADDRESS>:39629' }
} +3ms
prisma:info  Started http server on <IP_ADDRESS>:39629
  engine stdout {
  timestamp: 'Apr 29 21:46:40.789',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: { query: 'BEGIN', item_type: 'query', params: '[]', duration_ms: 0 }
} +18ms
prisma:query BEGIN
  engine stdout {
  timestamp: 'Apr 29 21:46:40.790',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'INSERT INTO "public"."Contact" ("name") VALUES ($1) RETURNING "public"."Contact"."id"',
    item_type: 'query',
    params: '["Alice"]',
    duration_ms: 0
  }
} +1ms
prisma:query INSERT INTO "public"."Contact" ("name") VALUES ($1) RETURNING "public"."Contact"."id"
  engine stdout {
  timestamp: 'Apr 29 21:46:40.791',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'SELECT "public"."Contact"."id", "public"."Contact"."name" FROM "public"."Contact" WHERE "public"."Contact"."id" = $1 LIMIT $2 OFFSET $3',
    item_type: 'query',
    params: '[1,1,0]',
    duration_ms: 0
  }
} +1ms
prisma:query SELECT "public"."Contact"."id", "public"."Contact"."name" FROM "public"."Contact" WHERE "public"."Contact"."id" = $1 LIMIT $2 OFFSET $3
  engine stdout {
  timestamp: 'Apr 29 21:46:40.802',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'COMMIT',
    item_type: 'query',
    params: '[]',
    duration_ms: 10
  }
} +11ms
prisma:query COMMIT
  prisma-client Prisma Client call: +69ms
  prisma-client prisma.contact.create({
  prisma-client   data: {
  prisma-client     name: 'Bob'
  prisma-client   }
  prisma-client }) +0ms
  prisma-client Generated request: +0ms
  prisma-client mutation {
  prisma-client   createOneContact(data: {
  prisma-client     name: "Bob"
  prisma-client   }) {
  prisma-client     id
  prisma-client     name
  prisma-client   }
  prisma-client }
  prisma-client  +0ms
  engine stdout {
  timestamp: 'Apr 29 21:46:40.817',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: { query: 'BEGIN', item_type: 'query', params: '[]', duration_ms: 0 }
} +16ms
prisma:query BEGIN
  engine stdout {
  timestamp: 'Apr 29 21:46:40.818',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'INSERT INTO "public"."Contact" ("name") VALUES ($1) RETURNING "public"."Contact"."id"',
    item_type: 'query',
    params: '["Bob"]',
    duration_ms: 0
  }
} +1ms
prisma:query INSERT INTO "public"."Contact" ("name") VALUES ($1) RETURNING "public"."Contact"."id"
  engine stdout {
  timestamp: 'Apr 29 21:46:40.819',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'SELECT "public"."Contact"."id", "public"."Contact"."name" FROM "public"."Contact" WHERE "public"."Contact"."id" = $1 LIMIT $2 OFFSET $3',
    item_type: 'query',
    params: '[2,1,0]',
    duration_ms: 0
  }
} +1ms
prisma:query SELECT "public"."Contact"."id", "public"."Contact"."name" FROM "public"."Contact" WHERE "public"."Contact"."id" = $1 LIMIT $2 OFFSET $3
  engine stdout {
  timestamp: 'Apr 29 21:46:40.821',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: { query: 'COMMIT', item_type: 'query', params: '[]', duration_ms: 1 }
} +1ms
prisma:query COMMIT
  prisma-client Prisma Client call: +10ms
  prisma-client prisma.server.create({
  prisma-client   data: {
  prisma-client     hostname: 'SERVER_01',
  prisma-client     contacts: {
  prisma-client       create: [
  prisma-client         {
  prisma-client           functionality: 'Support',
  prisma-client           contact: {
  prisma-client             connect: {
  prisma-client               name: 'Bob'
  prisma-client             }
  prisma-client           }
  prisma-client         },
  prisma-client         {
  prisma-client           functionality: 'Hosting',
  prisma-client           contact: {
  prisma-client             connect: {
  prisma-client               name: 'Alice'
  prisma-client             }
  prisma-client           }
  prisma-client         }
  prisma-client       ]
  prisma-client     }
  prisma-client   }
  prisma-client }) +0ms
  prisma-client Generated request: +0ms
  prisma-client mutation {
  prisma-client   createOneServer(data: {
  prisma-client     hostname: "SERVER_01"
  prisma-client     contacts: {
  prisma-client       create: [
  prisma-client         {
  prisma-client           functionality: "Support"
  prisma-client           contact: {
  prisma-client             connect: {
  prisma-client               name: "Bob"
  prisma-client             }
  prisma-client           }
  prisma-client         },
  prisma-client         {
  prisma-client           functionality: "Hosting"
  prisma-client           contact: {
  prisma-client             connect: {
  prisma-client               name: "Alice"
  prisma-client             }
  prisma-client           }
  prisma-client         }
  prisma-client       ]
  prisma-client     }
  prisma-client   }) {
  prisma-client     id
  prisma-client     hostname
  prisma-client   }
  prisma-client }
  prisma-client  +0ms
  engine stdout {
  timestamp: 'Apr 29 21:46:40.826',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: { query: 'BEGIN', item_type: 'query', params: '[]', duration_ms: 0 }
} +6ms
prisma:query BEGIN
  engine stdout {
  timestamp: 'Apr 29 21:46:40.827',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'INSERT INTO "public"."Server" ("hostname") VALUES ($1) RETURNING "public"."Server"."id"',
    item_type: 'query',
    params: '["SERVER_01"]',
    duration_ms: 0
  }
} +1ms
prisma:query INSERT INTO "public"."Server" ("hostname") VALUES ($1) RETURNING "public"."Server"."id"
  engine stdout {
  timestamp: 'Apr 29 21:46:40.828',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'SELECT "public"."Contact"."id" FROM "public"."Contact" WHERE "public"."Contact"."name" = $1 OFFSET $2',
    item_type: 'query',
    params: '["Bob",0]',
    duration_ms: 0
  }
} +0ms
prisma:query SELECT "public"."Contact"."id" FROM "public"."Contact" WHERE "public"."Contact"."name" = $1 OFFSET $2
  engine stdout {
  timestamp: 'Apr 29 21:46:40.829',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'INSERT INTO "public"."ContactToServer" ("contactId","serverId","functionality") VALUES ($1,$2,$3) RETURNING "public"."ContactToServer"."contactId", "public"."ContactToServer"."serverId"',
    item_type: 'query',
    params: '[2,1,"Support"]',
    duration_ms: 1
  }
} +2ms
prisma:query INSERT INTO "public"."ContactToServer" ("contactId","serverId","functionality") VALUES ($1,$2,$3) RETURNING "public"."ContactToServer"."contactId", "public"."ContactToServer"."serverId"
  engine stdout {
  timestamp: 'Apr 29 21:46:40.830',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'SELECT "public"."Contact"."id" FROM "public"."Contact" WHERE "public"."Contact"."name" = $1 OFFSET $2',
    item_type: 'query',
    params: '["Alice",0]',
    duration_ms: 0
  }
} +0ms
prisma:query SELECT "public"."Contact"."id" FROM "public"."Contact" WHERE "public"."Contact"."name" = $1 OFFSET $2
  engine stdout {
  timestamp: 'Apr 29 21:46:40.831',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'INSERT INTO "public"."ContactToServer" ("contactId","serverId","functionality") VALUES ($1,$2,$3) RETURNING "public"."ContactToServer"."contactId", "public"."ContactToServer"."serverId"',
    item_type: 'query',
    params: '[1,1,"Hosting"]',
    duration_ms: 0
  }
} +3ms
prisma:query INSERT INTO "public"."ContactToServer" ("contactId","serverId","functionality") VALUES ($1,$2,$3) RETURNING "public"."ContactToServer"."contactId", "public"."ContactToServer"."serverId"
  engine stdout {
  timestamp: 'Apr 29 21:46:40.835',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'SELECT "public"."Server"."id", "public"."Server"."hostname" FROM "public"."Server" WHERE "public"."Server"."id" = $1 LIMIT $2 OFFSET $3',
    item_type: 'query',
    params: '[1,1,0]',
    duration_ms: 3
  }
} +2ms
prisma:query SELECT "public"."Server"."id", "public"."Server"."hostname" FROM "public"."Server" WHERE "public"."Server"."id" = $1 LIMIT $2 OFFSET $3
  engine stdout {
  timestamp: 'Apr 29 21:46:40.836',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: { query: 'COMMIT', item_type: 'query', params: '[]', duration_ms: 1 }
} +2ms
prisma:query COMMIT
  prisma-client Prisma Client call: +14ms
  prisma-client prisma.server.delete({
  prisma-client   where: {
  prisma-client     id: 1
  prisma-client   }
  prisma-client }) +0ms
  prisma-client Generated request: +0ms
  prisma-client mutation {
  prisma-client   deleteOneServer(where: {
  prisma-client     id: 1
  prisma-client   }) {
  prisma-client     id
  prisma-client     hostname
  prisma-client   }
  prisma-client }
  prisma-client  +0ms
  engine stdout {
  timestamp: 'Apr 29 21:46:40.839',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: { query: 'BEGIN', item_type: 'query', params: '[]', duration_ms: 0 }
} +3ms
prisma:query BEGIN
  engine stdout {
  timestamp: 'Apr 29 21:46:40.840',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'SELECT "public"."Server"."id", "public"."Server"."hostname" FROM "public"."Server" WHERE "public"."Server"."id" = $1 LIMIT $2 OFFSET $3',
    item_type: 'query',
    params: '[1,1,0]',
    duration_ms: 0
  }
} +0ms
prisma:query SELECT "public"."Server"."id", "public"."Server"."hostname" FROM "public"."Server" WHERE "public"."Server"."id" = $1 LIMIT $2 OFFSET $3
  engine stdout {
  timestamp: 'Apr 29 21:46:40.841',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'SELECT "public"."ContactToServer"."contactId", "public"."ContactToServer"."serverId", "public"."ContactToServer"."serverId" FROM "public"."ContactToServer" WHERE (1=1 AND "public"."ContactToServer"."serverId" IN ($1)) OFFSET $2',
    item_type: 'query',
    params: '[1,0]',
    duration_ms: 0
  }
} +1ms
prisma:query SELECT "public"."ContactToServer"."contactId", "public"."ContactToServer"."serverId", "public"."ContactToServer"."serverId" FROM "public"."ContactToServer" WHERE (1=1 AND "public"."ContactToServer"."serverId" IN ($1)) OFFSET $2
  engine stdout {
  timestamp: 'Apr 29 21:46:40.841',
  level: 'INFO',
  target: 'quaint::connector::metrics',
  fields: {
    query: 'ROLLBACK',
    item_type: 'query',
    params: '[]',
    duration_ms: 0
  }
} +0ms
prisma:query ROLLBACK
  engine {
  engine   error: PrismaClientKnownRequestError: The change you are trying to make would violate the required relation 'ContactToServerToServer' between the `ContactToServer` and `Server` models.
  engine       at NodeEngine.graphQLToJSError (/home/docker/Prisma/node_modules/@prisma/engine-core/dist/NodeEngine.js:560:1)
  engine       at /home/docker/Prisma/node_modules/@prisma/engine-core/dist/NodeEngine.js:468:1
  engine       at process.result (internal/process/task_queues.js:94:5)
  engine       at PrismaClientFetcher.request (/home/docker/Prisma/node_modules/@prisma/client/src/runtime/getPrismaClient.ts:621:13) {
  engine     code: 'P2014',
  engine     meta: {
  engine       relation_name: 'ContactToServerToServer',
  engine       model_a_name: 'ContactToServer',
  engine       model_b_name: 'Server'
  engine     }
  engine   }
  engine } +1ms
  printStack callsite Error:
    at Object.model [as Server] (/home/docker/Prisma/node_modules/@prisma/client/src/runtime/getPrismaClient.ts:377:28)
    at Object.n.<computed> [as delete] (/home/docker/Prisma/node_modules/@prisma/client/src/runtime/getPrismaClient.ts:512:33)
    at /home/docker/Prisma/index.ts:49:52
    at step (/home/docker/Prisma/index.ts:33:23)
    at Object.next (/home/docker/Prisma/index.ts:14:53)
    at fulfilled (/home/docker/Prisma/index.ts:5:58)
    at processTicksAndRejections (internal/process/task_queues.js:94:5) +0ms
(node:26476) UnhandledPromiseRejectionWarning: Error:
Invalid `prisma.server.delete()` invocation in
/home/docker/Prisma/index.ts:49:52

The change you are trying to make would violate the required relation 'ContactToServerToServer' between the `ContactToServer` and `Server` models.
    at PrismaClientFetcher.request (/home/docker/Prisma/node_modules/@prisma/client/src/runtime/getPrismaClient.ts:640:15)
    at processTicksAndRejections (internal/process/task_queues.js:94:5)
(node:26476) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:26476) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I can confirm this bug is present in the latest alpha 2.0.0-alpha.1182

Pretty nasty bug; also occurs in the explicit M2M example on the docs

This issue should be renamed to: Support cascade delete in Many-to-Many relationships and be tagged with topic:cascade.

Any update on this? This is a very high priority bug which can make or break almost any project.

@prisma/cli          : 2.4.1
Current platform     : darwin
Query Engine         : query-engine 195d4bdc2d16132977f4ba7a8ca312f7906cb086 (at ../../.nvm/versions/node/v14.0.0/lib/node_modules/@prisma/cli/query-engine-darwin)
Migration Engine     : migration-engine-cli 195d4bdc2d16132977f4ba7a8ca312f7906cb086 (at ../../.nvm/versions/node/v14.0.0/lib/node_modules/@prisma/cli/migration-engine-darwin)
Introspection Engine : introspection-core 195d4bdc2d16132977f4ba7a8ca312f7906cb086 (at ../../.nvm/versions/node/v14.0.0/lib/node_modules/@prisma/cli/introspection-engine-darwin)
Format Binary        : prisma-fmt 195d4bdc2d16132977f4ba7a8ca312f7906cb086 (at ../../.nvm/versions/node/v14.0.0/lib/node_modules/@prisma/cli/prisma-fmt-darwin)

Now I can only look at database relationships and delete them using $queryraw.

I am also having this issue. More than 5 months since this has been opened an there is still no fix? What's the deal?

Could this be related to #2057?

I'm still getting this error until this day using  when foreign key constraint is set with on DELETE CASCADE on a PostgreSQL table using  Version 12

If you want to delete nested records in cascade deleting the parent, before you need set constraint key as nullable in the database or in your schema. This solve the issue.

This is actually a bug as it should not be needed for cascade, see https://github.com/prisma/prisma/issues/4650

I'm also facing this issue.
When deleting directly in the db (or by using tools like pgAdmin), N:M relation is correctly deleted, the prisma client prevents performing this delete operation.

I'm also facing this issue.
When deleting directly in the db (or by using tools like pgAdmin), N:M relation is correctly deleted, the prisma client prevents performing this delete operation.

What is the status with this? What is the solution?

so what is the solution when you face this? this is not a minor bug! what can i do to go forward with my project? if i reinitalize prisma from the start, will i face this issue again?

so what is the solution when you face this? this is not a minor bug! what can i do to go forward with my project? if i reinitalize prisma from the start, will i face this issue again?

You will have this error again until it is fixed.
Streigth to the point, I have an API endpoint which will call to prisma.ENTITY.deleteMany. If I do just that, the bug we are talking about will be thrown. To "fix" this, I added a call to prisma.executeRaw and deleting the things I want deleted in the database "manually" Documentation here

@JunquerGJ Thanks, i think this is what i'm going to do for now, otherwise the project i'm working on is frozen because of this bug. I hope they prioritize this issue.

Cascade delete currently doesn't work for me for 1:n relations either.
 The change you are trying to make would violate the required relation 'AToB' between the 'A' and 'B' models.
prisma (2.19.0)

Can confirm that I'm having the same issue with a 1:n relationship (latest prisma: 2.20.1)

This issue is opened by almost one year. How is it possible that with all the huge work that the prisma team is doing to improve the library, no solution has been provided yet? This is quite a big issue, and I think that it should also be labeled as bug.

@euberdeveloper maybe, this is just a small issue seen relatively and not prioritized so highly

@philippfo9 Yes, I guess, but it does not seem a tricky fix, it is the default behaviour of SQL cascade to delete the related tuples (I guess the problem is because of prisma checks).

@philippfo9 Yes, I guess, but it does not seem a tricky fix, it is the default behaviour of SQL cascade to delete the related tuples (I guess the problem is because of prisma checks).

It's time for one of us to send a PR 😁 🤙

This is an annoying bug ! I am somehow disappointed

Is there any way we can get around here until the new fix is released?
If I execute SQL (prisma.$executeRaw) myself to remove some M2M data, do I also need to manually remove the relational tables implicitly generated by Prisma, I'm not sure if manually removing data from relational tables will affect the operation of Prisma or future queries.
If the official can give a best practice I think it will definitely help a lot. (a solution for everyone until the problem is fixed)

Our project heavily depends on cascade deletions. After weeks of work to migrate from Typeorm to Prisma, we faced with this issue. This is big, Prisma should've mention this shortcoming in limitations so we would wait until it fixed. This not some behavior you would expect from a "production-ready" software!

Fixed in https://github.com/prisma/prisma-engines/pull/1947
Proposal for you all to read in https://github.com/prisma/prisma/issues/6996

This has now been released as a preview feature flag. You can read about it in the release notes for 2.26.0: https://github.com/prisma/prisma/releases/tag/2.26.0 If you have any feedback, please use this issue: https://github.com/prisma/prisma/issues/7816

It still does not work implicit many-many relations

Then please open a new issue and provide a full reproduction. Thanks.


Update the Istio proxy repo SHA

Update the Istio proxy repo SHA

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: lei-tang
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: linsun
If they are not already assigned, you can assign the PR to them by writing /assign @linsun in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

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

/cc @rkpagadala

@lei-tang: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests-v1alpha3.sh
e557e5fa3b26bafd146c0117aabdd1fcd76afcb7
link
/test e2e-bookInfo-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Close it because the bot will do the update.


border-radius is not working.

In my style.css, I have this for a custom hardware info element:
#custom-hardware {
    border-style: solid;
    border-width: 2px;
    border-image: linear-gradient(to bottom right, rgba(51, 204, 255, 238), rgba(00, 255, 153, 238)) 1;
    border-radius: 12px;
}

Though the border-radius property has no effect.
I am on CachyOS (arch based) and using Hyprland for the Desktop Environment. If you need any additional info, let me know!

I can confirm that it does round the edges. In my main configuration I use border-radius and works fine, adding border-image with linear gradient breaks it. But, testing it on W3C Schools site it seems that CSS itself doesn't accept rounding for the border images.
https://www.w3schools.com/cssref/tryit.php?filename=trycss3_border-image
#custom-hardware {
    border: 0.5rem solid transparent;
    border-image: linear-gradient(to bottom right, rgba(51, 204, 255, 238), rgba(00, 255, 153, 238)) 10%;
    border-radius: 20px;
}

@msmafra yeah, apparently border-image overrides/ignores border-radius. So for now, I just won't use border gradients. There seem to be workarounds, but right now I'm too lazy to figure them out.

@Krepppa352 Maybe using background gradients, really not sure if it's possible, one element with the grandient and its label with a solid color, applying padding and/or margin too to simulate a border.


Blazor .NET Core 3 preview 9: The type or namespace name 'RenderTreeBuilder' does not exist in the namespace 'Microsoft.AspNetCore.Components.Rendering'

Following the guide here, I immediately get an error when trying to run the app.
dotnet --version
3.0.100-preview9-014004

dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.0.0-preview8.19405.7
dotnet new blazorwasm -o WebApplication1
dotnet run

obj\Debug\netstandard2.0\RazorDeclaration\Shared\MainLayout.razor.g.cs(49,91): error CS0234: The type or namespace name 'RenderTreeBuilder' does not exist in the namespace 'Microsoft.AspNetCore.Components.Rendering' (are you missing an assembly reference?) [C:\Users\AlexMcLean\git\WebApplication1\WebApplication1.csproj]
obj\Debug\netstandard2.0\RazorDeclaration\App.razor.g.cs(49,91): error CS0234: The type or namespace name 'RenderTreeBuilder' does not exist in the namespace 'Microsoft.AspNetCore.Components.Rendering' (are you missing an assembly reference?) [C:\Users\AlexMcLean\git\WebApplication1\WebApplication1.csproj]
obj\Debug\netstandard2.0\RazorDeclaration\Shared\NavMenu.razor.g.cs(49,91): error CS0234: The type or namespace name 'RenderTreeBuilder' does not exist in the namespace 'Microsoft.AspNetCore.Components.Rendering' (are you missing an assembly reference?) [C:\Users\AlexMcLean\git\WebApplication1\WebApplication1.csproj]
obj\Debug\netstandard2.0\RazorDeclaration\Shared\SurveyPrompt.razor.g.cs(49,91): error CS0234: The type or namespace name 'RenderTreeBuilder' does not exist in the namespace 'Microsoft.AspNetCore.Components.Rendering' (are you missing an assembly reference?) [C:\Users\AlexMcLean\git\WebApplication1\WebApplication1.csproj]
obj\Debug\netstandard2.0\RazorDeclaration\Pages\Index.razor.g.cs(51,91): error CS0234: The type or namespace name 'RenderTreeBuilder' does not exist in the namespace 'Microsoft.AspNetCore.Components.Rendering' (are you missing an assembly reference?) [C:\Users\AlexMcLean\git\WebApplication1\WebApplication1.csproj]
obj\Debug\netstandard2.0\RazorDeclaration\Pages\FetchData.razor.g.cs(51,91): error CS0234: The type or namespace name 'RenderTreeBuilder' does not exist in the namespace 'Microsoft.AspNetCore.Components.Rendering' (are you missing an assembly reference?) [C:\Users\AlexMcLean\git\WebApplication1\WebApplication1.csproj]
obj\Debug\netstandard2.0\RazorDeclaration\Pages\Counter.razor.g.cs(51,91): error CS0234: The type or namespace name 'RenderTreeBuilder' does not exist in the namespace 'Microsoft.AspNetCore.Components.Rendering' (are you missing an assembly reference?) [C:\Users\AlexMcLean\git\WebApplication1\WebApplication1.csproj]

The build failed. Fix the build errors and run again.

Is it because  the link to the templates should be updated?

The breaking changes announced here https://devblogs.microsoft.com/aspnet/asp-net-core-and-blazor-updates-in-net-core-3-0-preview-9/ are the likely cause.
I'm working through some similar issues and updating a few existing projects.

You need to update Visual Studio to the latest preview release that came out today. I ran into this exact thing and was assisted by the friendly Blazor engineers. Once I updated, everything worked!

I guess this might have been going through the pipeline while I posted this, as I had suspected the templates needed to be updated to reflect that .NET Core 3.0 preview 9 was out now (and what I had installed).
dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.0.0-preview9.19424.4
Thus, you do not need to update to the latest Visual Studio (for anyone like me who's trying to move away from VS and towards VS Code).

Im still getting this issue when upgrading any other suggestions ?

Strange. I updated VS to 16.3 Preview 3, updated the template but still the error remains. Even a new clean Blazor app has the same issue. What am i missing?

I was in the same boat as RealTadango, but running the command that mclean25 posted to update the templates fixed it for me.

The easy way is to update the Packages via NuGet

The issue is that a Preview 8 project will not work with VS 16.3.0 Preview 3.0 no matter what you install. Sadly i cannot use Preview 9 and am now stuck.

@RealTadango why can't you use Preview 9?

@RealTadango why can't you use Preview 9?

Incompatibel library (is on Preview 8)

@RealTadango have you tried just using the dotnet cli to instantiate your project instead of VS? I did that for preview 8 (with the preview 8 templates) and it worked fine for me the other day.

No, i only used the template through VS. Should that make a difference? My existing project is the issue :)

Thanks for contacting us.
Using a version of SDk with a different version of the Blazor templates is not supported. Make sure you use the latest version of the SDK, runtime and the VS 2019 Preview.

@mkArtakMSFT But i hade installed finally:

Core SDK Preview 8
Template versie Preview 8
VS 16.3.0 Preview 3.0
Project with references to Preview 8 packages

This does not work.

Right, I think you need to stack with the older VS, or newer Blazor.

Right, I think you need to stack with the older VS, or newer Blazor.

Correct. You should use all the new stack. Using the latest VS with a version older SDK is also not supported.

I read the upgrade docs, but after many failed attempts I upgraded my Preview 8 to Preview 9 project by creating a new Blazor project, and added all my pages, css,images and other changes manually was the only way I could get it to work.

I had similar issues. I had to replace Microsoft.AspNetCore.Components.Rendering with Microsoft.AspNetCore.Components.RenderTree.RenderTreeBuilder and it worked for me

Thanks. I already rebuilt manually, but that is good to know. Hopefully once the full version comes out this won't be a problem any more.

So I am using dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.0.0-preview9.19424.4
and this sdk

with the latest version of visual studio preview that I just downloaded
still got this problem with a newly created project
Help!

Visual Studio is not in Preview at the moment, so if you just got it you installed the right place.
Here is the Visual Studio I installed yesterday in Help > About:
16.3.4
Is this the same version you are using? If not click the menu item Help > Check For Updates.
When I create a new Blazor project, I just use Visual Studio and select new project > Blazor App.
Not sure if that helps any, here is a video I made creating a Blazor project if you want to watch:
(I think the Blazor create project part is in the second half, but I don't have time to watch right now.)
https://www.youtube.com/watch?v=sowTLLeAfm8

Maybe I can help with that issue (or I have a similiar one).
I am trying to build my app within a docker container. I developed it with my Win 10 x64 PC on the command line.
No issues so far.
But with this simple dockerfile i get the same Errors as in the first post.
FROM mcr.microsoft.com/dotnet/core/sdk:3.0-alpine AS dotnet

WORKDIR /app
COPY /src /app
RUN dotnet publish -c Release

Failing part of the log output:
```shell
Microsoft (R) Build Engine version 16.3.0-preview-19329-01+d31fdbf01 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 6.02 sec for /app/Dark.csproj.
  You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview
/build/obj/Release/netstandard2.0/RazorDeclaration/App.razor.g.cs(61,92): error CS0234: The type or namespace name 'RenderTreeBuilder' does not exist in the namespace 'Microsoft.AspNetCore.Components.RenderTree' (are you missing an assembly reference?) [/app/Dark.csproj]
/build/obj/Release/netstandard2.0/RazorDeclaration/Component/Index/Index.razor.g.cs(62,92): error CS0234: The type or namespace name 'RenderTreeBuilder' does not exist in the namespace 'Microsoft.AspNetCore.Components.RenderTree' (are you missing an assembly reference?) [/app/Dark.csproj]

This is Happening with the alpine version of the sdk. If I use the "normal" one everything works as expected:
FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS dotnet

Hi, it looks like you are posting on a closed issue/PR/commit!
We're very likely to lose track of your bug/feedback/question unless you:

Open a new issue
Explain very clearly what you need help with
If you think you have found a bug, include detailed repro steps so that we can investigate the problem

Thanks!


Server should respond with 200 and [success: false] when request fails

http://phonetworks.com:1338/setProfile?about=SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2%20SUPERDUPER2&public_id=16D58CF2-FD88-4A49-972B-6F60054BF023


API change in SDL3.0's SDL_audio.h breaks compilation

In a recent change to SDL3/SDL_audio.h, extern DECLSPEC void SDLCALL SDL_PauseAudioDevice(SDL_AudioDeviceID dev, int pause_on); has been changed to extern DECLSPEC void SDLCALL SDL_PauseAudioDevice(SDL_AudioDeviceID dev);
Commit is https://github.com/libsdl-org/SDL/commit/93e2903ac550b9f0ac034af4174658c1f5ffbc04
This breaks compilation of SDL_mixer on src/mixer.c, which is still using int pause_on in the older SDL_audio.h and results in the following errors:
/home/etna/Tmpbuild/SDL_mixer/src/mixer.c:535:40: error: too many arguments to function call, expected single argument 'dev', have 2 arguments
    SDL_PauseAudioDevice(audio_device, 0);
    ~~~~~~~~~~~~~~~~~~~~               ^
/home/etna/Runtime/Deps/SDL2-Build07Jan2022/include/SDL3/SDL_audio.h:640:30: note: 'SDL_PauseAudioDevice' declared here
extern DECLSPEC void SDLCALL SDL_PauseAudioDevice(SDL_AudioDeviceID dev);
                             ^
/home/etna/Tmpbuild/SDL_mixer/src/mixer.c:550:40: error: too many arguments to function call, expected single argument 'dev', have 2 arguments
    SDL_PauseAudioDevice(audio_device, pause_on);
    ~~~~~~~~~~~~~~~~~~~~               ^~~~~~~~
/home/etna/Runtime/Deps/SDL2-Build07Jan2022/include/SDL3/SDL_audio.h:640:30: note: 'SDL_PauseAudioDevice' declared here
extern DECLSPEC void SDLCALL SDL_PauseAudioDevice(SDL_AudioDeviceID dev);

Please help to update SDL_mixer to use the updated API.
Thank you.

fix done !
https://github.com/libsdl-org/SDL_mixer/commit/313242a47a9baed4b47c8c5add6eae3ef0f852dc


Repeated shrinking of already shortened URL

Expected Behavior
If a kzilla.xyz/* url is entered it should not be shrink further.
Current Behavior
If a kzilla.xyz/* url we are able to shrink it again.
Steps to Reproduce

Go to kzilla.xyz
In the URL field enter kzilla.xyz, copy the newly generated kzilla.xyz/* link
Paste the link again in kzilla.xyz.
This will generate a new link and it can be continued indefinetly

Sure @pratham-bhatnagar go ahead.

fixed with #187 in v2


bundle up multiple monitors (for split:window and split:grabroguewindows)

This patch suggests that, for example, if num_workspaces is 5 and we have 2 monitors, and assuming we have a window on workspace 7 (the second workspace on the second monitor), then when the second monitor is removed, the window will be grabbed to workspace 2 (and not the currently active monitor).
This makes the grab notion behave more like Microsoft Windows ( :-( ) but is more friendly to users.
Note that this is rebased on 0.44.1 (until the build with 0.45.0 is resolved).

It isn't really clear to me what this is supposed to being doing?
focusMultipleWorkspaces seems to break changing workspaces in many situations. Is the goal to treat switching workspaces as a single workspace across all monitors? ie switching to workspace 3 should focus the third workspace on all monitors? If that is the goal you might want to look at using hyprland-virtual-desktops instead of hyprsplit.
split:grabroguewindows's behavior is also broken, trying unplugging monitor id 0. windows that were in workspaces on monitor 0 are not grabbed.

You are right - hyprland-virtual-desktops does exactly what I want it to. Thanks for the informative reply!

You're right - hyprland-virtual-desktops does everything I need. Thanks for the informative reply!


Add YIP-draft-title_yVault_new_Asset.md

Proposal to add LINK as an asset for collateral in delegated yVaults.

Rejected in favor of https://github.com/iearn-finance/YIPS/pull/15


Assignment bug in DetConBLoss and CE

Thanks for your awesome job.
But, in DetConBLoss line(133-134) This parameters passed to CE by (logits, labels, weight). But CE definition is(labels, logits, weight).

Thanks for catching this. I'll submit a PR shortly.

Fixed in #2


Get rid of id properties

Why don't you use self.$imageElement but search for the element?
You should avoid using the id property of HTML elements in general. It's fine if you only think of your own content type as a standalone version, but it will break if you put more than one of them into compound content types such as H5P Column.
https://github.com/msdlt/h5p.LinkedImageSwap/blob/48d5259272acc6d2289d23b217bd55d6342511de/linked-image-swap.js#L191-L192

@theotherdy Hope I am not bugging you :-) I simply had a glance at your code yesterday and stumbled across those. I could have a more thorough look this weekend if you don't mind.

No, not at all - it's very useful indeed. - thank you! Any feedback very welcome - particularly if you had any ideas for the !important I have found myself having to use in the css to get rid of margins, or any tips for how to get FontAwesome to work instead of the css solution that doesn't seem to antialias well :)


Add bindings for more NEON instructions

The SIMD implementation of Adler32 in github.com/guzba/crunchy currently does not compile on ARM due to missing bindings for the following instructions:

vld1q_lane_u32
vpadalq_u16
vaddw_u8
vpadalq_u8
vshlq_n_u32
vmlal_u16
vpadd_u32

I added the listed bindings and also took the opportunity to add bindings for all operand sizes within the respective family of instructions.

Fixing missing bindings is great. I'll get this merged and tagged quick.

Thanks for the PR here, this is appreciated. I've included it in release tagged 1.2.4


go/types, cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode [1.22 backport]

@taking requested issue https://github.com/golang/go/issues/68658 to be considered for backport to the next 1.22 minor release.

@gopherbot please backport this to 1.22. It's necessary to have consistent file versions with build tags with later versions.

CC @griesemer .
https://go.dev/cl/615685 has some helpful context on why FileVersions from go/types needs to be updated.

Related Issues and Documentation

cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode [1.23 backport] #69094 (closed)
cmd/compile: Go 1.22 changes support for modules that declare `go 1.0` [1.22 backport] #65619 (closed)
cmd/go: module loader looks for the wrong tags if the "go-import" prefix includes the major-version suffix [1.12 backport] #30665 (closed)
cmd/go: error if GOCACHE is set but is not an absolute path [1.12 backport] #30493 (closed)
cmd/go: breakage with go version command and GOFLAGS environment variable [1.15 backport] #41464 (closed)
os/exec: calling Cmd.Start after setting Cmd.Path manually to absolute path without ".exe" no longer implicitly adds ".exe" in Go 1.22 [1.22 backport] #66598 (closed)
cmd/fix: invalid -go=go1.21.0 [1.23 backport] [1.22 backport] #68827 (closed)
cmd/fix: invalid -go=go1.21.0 [1.23 backport] #68826 (closed)
cmd/go: TestScript/gotoolchain_issue66175 fails on tip locally [1.22 backport] #67311 (closed)
cmd/go: 'go get<EMAIL_ADDRESS>fails when the go.mod file for […]/v2 is at the repo root [1.13 backport] #34497 (closed)

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Example that shows the discontinuity between 1.22 and 1.23:
package main

import (
	"fmt"
	"go/ast"
	"go/importer"
	"go/parser"
	"go/token"
	"go/types"
)

func main() {
	contents := `

//go:build go1.18

// FileVersion == "go1.18"  according to go 1.22, 1.21.
// FileVersion == "go1.21"  according to go 1.23, tip.

package p

func p[T any, S []T](x T) {}

func f() {
	var f func(int) = p // Use a 1.21 feature.
	print(f)
}
	`

	fset := token.NewFileSet()
	file, err := parser.ParseFile(fset, "p.go", contents, 0)
	if err != nil {
		panic(err)
	}

	conf := types.Config{
		Importer:  importer.Default(),
		GoVersion: "go1.21",
	}
	info := types.Info{}
	_, err = conf.Check("", fset, []*ast.File{file}, &info)

	fmt.Println(err)
}

1.23 says this type checks. 1.22 says this does not type check with the following error:
p.go:9:20: implicitly instantiated function in assignment requires go1.21 or later

https://go.dev/cl/617635 has more examples where go/types.Info.FileVersions has a different meaning in 1.22.
Back porting would mean FileVersions would have a single consistent semantics going forward. This is also not a trivial backport or an issue that impacts many users directly. It may not be worth the risk.
But THB if someone came up and asked me how to use go/types.Info.FileVersions correctly, I would at this point tell them to skip to 1.23 or to only use it for the specific check 'is this file >= 1.22 or unknown (until you stop supporting 1.22)'. This way they could skip needing to specialize for both cases.
So we need to decide if we are going to accept go/types producing different FileVersion values as Unfortunate or to back port.

Moving from cmd/go review. This is a go/types decision.

Discussed in the release meeting, we thought that that this is a subtle edge case that doesn’t seem to be causing problems for most users (if one wants 1.21 feature, they probably shouldn't use 1.18 build tag). So this is mostly potentially for tool authors? But we haven’t heard external reports so far. So might not be worth the risk of backporting fairly late in the 1.22 cycle.
@timothy-king what do you think? Thanks.

So with some additional prodding and admittedly very strange choices, one can lift this to a compiler problem:
-- go.mod --
module example.com/m

go 1.21
-- main.go --
//go:build go1.16

package main

func P[T any]() {} // uses a go 1.18 feature

func main() {
        println("ran")
}

This builds with go1.20.14 and go1.23.1 while it fails to build with go1.21.13 and go1.22.7:
% go1.20.14 build; ./m
ran
% go1.21.13 build
# example.com/m
./m.go:5:8: type parameter requires go1.18 or later (-lang was set to go1.21; check go.mod)
./m.go:5:10: predeclared any requires go1.18 or later (-lang was set to go1.21; check go.mod)
% go1.22.7 build
# example.com/m
./m.go:5:8: type parameter requires go1.18 or later (file declares //go:build go1.16)
./m.go:5:10: predeclared any requires go1.18 or later (file declares //go:build go1.16)
% go1.23.1 build; ./m
ran

There are multiple odd choices in this example: a 1.16 build tag, using a 1.18 feature, and using go1.20.14 with a go1.21 module. But still not backwards compatible in the strictest sense. A working example stopped compiling even if it is an edge case.
TBH the bit I really want to fix is that I want a simpler world where FileVersions has one meaning and the current 1.22 meaning is a bug. This is an obnoxious bit of tech debt I would like to get rid of.
It may not be worth the risk though as you said. I'll let other decide.

Yes, this can leads to a compilation failure. But using 1.18 feature with a 1.16 build tag seems a bad choice, and is probably really are. It doesn't seem too bad that this doesn't compile with Go 1.22, given that this would also not compile with Go 1.21.

Given the lack of user-reported issues, we've decided not to backport.


Change migration 168 to no-op

A new migration should be provided for the intended fix.

best sol to not break more ...

best sol to not break more ...

Shouldn't this have been backported to 1.13? The broken v168 migration is included in 1.13.2.

@jpraet It's not. Migrations dont get backported at all.
Just the fix for the migration & a workaround where backported witch work fine


/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found while using cloudnativepg on top of fdw

Here is the error
ERROR:  could not load library "/usr/lib/postgresql/15/lib/steampipe_postgres_aws.so": /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /usr/lib/postgresql/15/lib/steampipe_postgres_aws.so)

I have the following Dockerfile for running postgres fdw
# Stage 1: Building the Go executable
FROM golang:1.22.2-bookworm AS build

WORKDIR /build

COPY ./ .

RUN go build -o main main.go

# Final image
FROM postgres:15

ENV TERM=xterm

RUN apt-get update && apt-get upgrade -y && \
    apt-get install -y curl && \
    rm -rf /var/lib/apt/lists/*

COPY install_fdw.sh /tmp/
RUN /tmp/install_fdw.sh && \
    rm /tmp/install_fdw.sh

COPY --from=build /build/main /
COPY --from=build /build/init.sh /docker-entrypoint-initdb.d

I decided to shift to cloudnativepg
and tried using postgres image with ghcr.io/cloudnative-pg/postgresql:15
Its very hard and error prone to upgrade GLIBC and I still did not succeed . Is there any other smart solution in place here?

Here is my attempt to upgrade it
FROM golang:1.22.2-bookworm AS build

WORKDIR /build

COPY ./ .

RUN go build -o main main.go

# Stage 2: Install GLIBC 2.32 on CloudNativePG
FROM ghcr.io/cloudnative-pg/postgresql:15.4-3 AS final

ENV TERM=xterm
ENV GLIBC_VERSION=2.32

USER root

# Install dependencies for building GLIBC, including gawk and bison
RUN apt-get update && apt-get install -y \
    build-essential \
    wget \
    gcc \
    libc6-dev \
    libtool \
    make \
    gawk \
    bison \
    --no-install-recommends && \
    rm -rf /var/lib/apt/lists/*

# Download, compile, and install GLIBC 2.32
WORKDIR /tmp

RUN wget http://ftp.gnu.org/gnu/libc/glibc-${GLIBC_VERSION}.tar.gz && \
    tar -xzf glibc-${GLIBC_VERSION}.tar.gz && \
    cd glibc-${GLIBC_VERSION} && \
    mkdir build && cd build && \
    ../configure --prefix=/opt/glibc-${GLIBC_VERSION} && \
    make -j$(nproc) && \
    make install && \
    rm -rf /tmp/glibc-${GLIBC_VERSION}*

# Update the library path
ENV LD_LIBRARY_PATH=/opt/glibc-${GLIBC_VERSION}/lib:$LD_LIBRARY_PATH

# Copy the FDW installation script and run it
COPY install_fdw.sh /tmp/
RUN chmod +x /tmp/install_fdw.sh && \
    /bin/sh -c 'LD_LIBRARY_PATH=/opt/glibc-2.32/lib:$LD_LIBRARY_PATH /tmp/install_fdw.sh' && \
    rm /tmp/install_fdw.sh

# Copy the built Go binary and init script
COPY --from=build /build/main /
COPY --from=build /build/init.sh /docker-entrypoint-initdb.d

But does not work yet

@sadathknorket Thanks for putting in the effort to write up this detailed issue.
From the details, it seems like you're trying to install steampipe_postgres_aws_15 extension. What is the glibc version used in your image?
I will try and replicate this.


password using FSKView 1.1.7

I am having a problem dealing with the password in FSKView.  I see the one in the settings.xml but it does not work, what am I doing wrong. It seems the only one you can use is what is in the settings.xml, correct ?  Yet when I do use that PW,  all it says is  INCORRECT USERNAME/PASSWORD.
I had other issues, but got them figured out, but that this one.

Looks like I got the answer in groups.io , qrssknights.

Looks like I got the answer in https://groups.io/g/qrssknights

Welcome to Knights Al.
You don't need to use those settings unless you decide to upload your grabs to a website.

If at some time you think that you'd like to become an online grabber, then you can upload
each grab automatically, to your own website.

Many of us just open an qsl.net account and upload the files to it.

If a grabber seems to be doing good public service then one of us will add it to the
AJ4VD compendium.

73/4 de Andy


Updates to allow tests to pass

I've made various changes that fix inconsistencies with the original ECMWF code. The tests now all pass.
I'm not completely satisfied with the changes at present and want to try to smooth out some of the rough edges, but wanted to open this to raise awareness that I've got the tests to pass.
There is a confusing bit of code that affects using the ghost flags from the ORCA halo which I still don't understand.
The new code is slower than the old code. I've removed all the file output I could find but there is still something slowing it down. These are the test output times from the old code:

Start 1: atlas_test_orca_plugin
1/7 Test 1: atlas_test_orca_plugin ............   Passed    0.33 sec
Start 2: atlas_test_orca_grid_specs
2/7 Test 2: atlas_test_orca_grid_specs ........   Passed    0.08 sec
Start 3: atlas_test_orca_grid
3/7 Test 3: atlas_test_orca_grid ..............   Passed    0.16 sec
Start 4: atlas_test_orca_mesh
4/7 Test 4: atlas_test_orca_mesh ..............   Passed    1.24 sec
Start 5: atlas_test_orca_valid_elements
5/7 Test 5: atlas_test_orca_valid_elements ....   Passed    4.09 sec
Start 6: atlas_test_orca_polygon_locator
6/7 Test 6: atlas_test_orca_polygon_locator ...   Passed   11.69 sec
Start 7: atlas_test_orca_mesh_boundaries
7/7 Test 7: atlas_test_orca_mesh_boundaries ...   Passed   48.54 sec

And here is the new code times:

Start  1: atlas_test_orca_plugin
1/13 Test  1: atlas_test_orca_plugin ........................   Passed    0.38 sec
Start  2: atlas_test_orca_grid_specs
2/13 Test  2: atlas_test_orca_grid_specs ....................   Passed    0.10 sec
Start  3: atlas_test_orca_grid
3/13 Test  3: atlas_test_orca_grid ..........................   Passed    2.46 sec
Start  4: atlas_test_orca_mesh
4/13 Test  4: atlas_test_orca_mesh ..........................   Passed    2.35 sec
Start  5: atlas_test_orca_valid_elements
5/13 Test  5: atlas_test_orca_valid_elements ................   Passed    9.05 sec
Start  6: atlas_test_orca_polygon_locator
6/13 Test  6: atlas_test_orca_polygon_locator ...............   Passed   18.33 sec
Start  7: atlas_test_orca_mesh_boundaries_NOMPI
7/13 Test  7: atlas_test_orca_mesh_boundaries_NOMPI .........   Passed   74.10 sec
Start  8: atlas_test_orca_mesh_boundaries_MPI2
8/13 Test  8: atlas_test_orca_mesh_boundaries_MPI2 ..........   Passed   67.94 sec
Start  9: atlas_test_orca_surrounding_rectangle_NOMPI
9/13 Test  9: atlas_test_orca_surrounding_rectangle_NOMPI ...   Passed    0.38 sec
Start 10: atlas_test_orca_surrounding_rectangle_MPI2
10/13 Test 10: atlas_test_orca_surrounding_rectangle_MPI2 ....   Passed    1.97 sec
Start 11: atlas_test_orca_surrounding_rectangle_MPI4
11/13 Test 11: atlas_test_orca_surrounding_rectangle_MPI4 ....   Passed    0.92 sec
Start 12: atlas_test_orca_local_grid_NOMPI
12/13 Test 12: atlas_test_orca_local_grid_NOMPI ..............   Passed    0.10 sec
Start 13: atlas_test_orca_local_grid_MPI2
13/13 Test 13: atlas_test_orca_local_grid_MPI2 ...............   Passed    0.57 sec

when you say this is slower, are you testing vs the head of develop? The base atlas_test_orca_mesh_boundaries uses 2 processors, so should match in timings with our MPI2 version. Having said that I would not at all be surprised if this is slower as I intentionally chose to ignore performance in the interests of improving my understanding. If we can get halos working and prove that we have resolved the issues with correctness in sith, we can revisit performance again and make improvements. Certainly for our use case the meshgeneration step hasn't been a huge performance issue, and seems to scale with MPI fairly well. Whereas I/O and interpolation are where we lose a lot of our time.

when you say this is slower, are you testing vs the head of develop? The base atlas_test_orca_mesh_boundaries uses 2 processors, so should match in timings with our MPI2 version. Having said that I would not at all be surprised if this is slower as I intentionally chose to ignore performance in the interests of improving my understanding. If we can get halos working and prove that we have resolved the issues with correctness in sith, we can revisit performance again and make improvements. Certainly for our use case the meshgeneration step hasn't been a huge performance issue, and seems to scale with MPI fairly well. Whereas I/O and interpolation are where we lose a lot of our time.

Yes, my timing were versus develop. I agree that the difference isn't enough to be a problem. I was more worried that something was going wrong, but it sounds like it is not completely unexpected.


Fixed mapping to non-collection object when using KZProperty with NS_BLOCK_ASSERTIONS defined

Description
When mapping a collection into a non-collection type using KZProperty with NS_BLOCK_ASSERTIONS defined, BOOL result of the operation was returning YES when it should be returning NO.

thanks for contributing


[solax_x1:188]: The device is or was offline. Broadcasting discovery for address configuration...

Hey guys,
thank for this modules. In my case I try to use it with a Solax X1 mini 1.5 V2.
And I only receive the text which is mentioned in the title.
May anyone has the same issue and can help me to fix it.
regards
frank

Could you provide some details about your setup? A photo of your wiring (incl. the RS485 module) and the important parts (uart secontion) of your configuration yaml?
Another intepretation of the log message is: "The device doesn't respond". Therefore we must sure your device is connected properly. If this is the case it's possible your device version uses another protocol. Let's start with the wiring!

I won´t be at home till friday - so I decided to do a small scheme of the cabling.
solax_issue.pdf
And the code too:
`
substitutions:
name: solar-powermeter
esphome:
name: ${name}
platform: esp8266
board: d1_mini
external_components:
#- source: github://syssi/esphome-modbus-solax-x1@add-solax-x1-mini-g2-compatibility

source: github://syssi/esphome-modbus-solax-x1@main
refresh: 0s

uart:
baud_rate: 9600
tx_pin: GPIO2
rx_pin: GPIO1
solax_x1:
serial_number: "3132333435363737363534333231"
address: 0x0A
update_interval: 2s
text_sensor:

platform: solax_x1
mode_name:
name: "${name} mode name"
errors:
name: "${name} errors"
`

thanks!

I assume your RS485 module isn't handled properly:
https://electronics.stackexchange.com/questions/153500/correctly-using-re-and-de-with-rs485
I will add a flow control pin to the component to support your rs485 module. At the moment DE/RE isn't used correctly.

I've introduce a flow control pin here:
https://github.com/syssi/esphome-modbus-solax-x1/pull/19
Please use this new feature branch for your tests:
external_components:
  - source: github://syssi/esphome-modbus-solax-x1@add-flow-control
    refresh: 0s

The next step is to update your configuration to use flow control pin:
https://github.com/syssi/esphome-modbus-solax-x1/pull/19/files#diff-dbc81de7d9fb76af6e67b9c8b02f69c8ea7f35b243a2898f26520c759e0d7b6d
This should fit for you
uart:
  id: uart0
  baud_rate: 9600
  tx_pin: GPIO2
  rx_pin: GPIO1

modbus_solax:
  id: modbus0
  uart_id: uart0
  flow_control_pin: GPIO2

solax_x1:
  modbus_solax_id: modbus0
  serial_number: "3132333435363737363534333231"
  address: 0x0A
  update_interval: 2s

Do i have to change my wiring physically? Or may I can use the:
D1=GPIO4 as tx to the RS485-pin RO,
D2=GPIO5 as rx to the RS485-pin DI and
GPIO0 as flowcontrole pin, connected to the bridged RS485-pins RE/DE ?
Or shell I change GPIO5 to the original tx-pin and the GPIO to the rx-pin on the microcrontroller?
Because I changed the my code to your provided one and nothing different happened than the issue above.

The tx_pin must connected to DI not RI. If you use GPIO4 and GPIO5 a software serial implementation is used by ESPHome. I would use the hardware UART pins of the ESP8266. The best wiring would look like this:
https://github.com/KlausLi/Esp-Soyosource-Controller/blob/main/BastelPlan3000_Soyosource_Controller_by_BavarianSuperGuy.png
api:
ota:
logger:
  level: INFO
  baud_rate: 0  # <--- super important!

uart:
  id: uart0
  baud_rate: 9600
  tx_pin: GPIO1
  rx_pin: GPIO3

modbus_solax:
  id: modbus0
  uart_id: uart0
  flow_control_pin: GPIO0

solax_x1:
  modbus_solax_id: modbus0
  serial_number: "3132333435363737363534333231"
  address: 0x0A
  update_interval: 2s

Ah ok got you.
So my config:
uart:
id: uart0
baud_rate: 9600
tx_pin: GPIO4
rx_pin: GPIO5
modbus_solax:

id: modbus0
uart_id: uart0
flow_control_pin: GPIO2

solax_x1:
modbus_solax_id: modbus0
serial_number: "3132333435363737363534333231"
address: 0x0A
update_interval: 2s
Won´t work properly.
Then I really have to wait till weekend, when I´m able to solder the pins to tx and rx instead using GPIO4 and GPIO5. GPIO2 also seems to be wrong and has to be GPIO0.

1.:  Yes I´m from Germany.
3.: You're right.
4.: See 1. ......
So I have to give it another try tomorrow!

I´m just trying to receive the data stream. But like yesterday in the evening, no changes .....

Please check your wiring this weekend. It's super important RE/DE is connected properly.
Inverter settings: I don't have any menu items to enable/disable modbus. There is also no menu item to change the modbus address / device id for example. At my firmware version modbus is always enabled. Are you able to control something in this regard?

Yes - I will check, if RE/DE is connected properly
I have the enabling option and also a menu to change the address of modbus.
But like you said, I´m only able to check that on friday.

The different menu sounds like real modbus rtu (polling selected registers). There are multiple things we should try as soon you have access to your device. ;-)

Could you provide your exact model name of the type label (something like X1-2.0-S-D(L)), the software versions (master/manager) of your device and may be some photos of the menu structure? It should help to compare your device with well known devices/protocols.

Good morning. Well- the sun is shining so I was able to take a look at my settings.

Could you look for some firmware versions at the menu?

Do you need these?

Perfect! Next wish: Could you provide a photo of the type label (on the right side of the device)?

Please provide some photos of your new wiring as next step. Enable the debug output of the UART component:
https://github.com/syssi/esphome-modbus-solax-x1#debugging
Provide some logs. It would like to know there is some serial traffic (outgoing & incoming) or not.

Sorry for the bad quality:
TX= DI = blue cable
RX = RO = green cable
D4 = DE/RE = brown cable

Alright! Next step is to collect some serial traffic. Could you provide some logs (debug output of the uart component enabled)?

Could you provide your configuration yaml? I would like to check you are using (D4 = GPIO2 vs. D3 = GPIO0).

I think there ist some communication......

Looks good! :-) Issue solved.

Thank you very much for supporting me!

Please make sure to set the logger to 0 baud if you use GPIO1 and 3. Otherwise log messages are transmitted to the inverter too. ;-)

I will merge the flow control support into main now. Please update the feature branch at the external components section to @main again later the day.

Of course. It should be fine like this!

Perfect! Last question about your device: You've enabled the ModbusRTU setting and the device address is set to 1. Right? I would like to improve the docs.

No is disabled the RTU option.


Fix all windows cycles

Finally got a windows box test environment set up. This should fix all remaining cycles in Phobos.
Note that I had to move some documented examples. I tried to keep the spirit of the documentation, and still have the examples moved to different files where they won't cause cycles.

LGTM

Auto-merge toggled on


Bump Kubernetes in 6.3 and master to 1.17.2

Just to keep up with k8s releases https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.17.md#v1172 - a few relevant fixes in there on kubeletes and other similar

fixed in https://github.com/gravitational/gravity/pull/1080

Used this issue for 6.3.x branch... I'll create a separate one for master/7.x


Setting timeMode as 'week'

I can't get the 'week' view.
I changing the timeMode value from 'day' to 'week', but nothing happens.
It's possible?

Currently, only a single day is supported. I haven't gotten around to it unfortunately


Remove FCVAR_SERVER_CAN_EXECUTE from disconnect

Servers should use the NSDisconnectPlayer script function instead. (clients can just ignore the disconnect command, it's more a suggestion)
Closes #553

To be clear, do clients already ignore disconnect?
Normal clients do not ignore disconnect, but a malicious one very much could. Therefore using disconnect to disconnect a client is a bad idea and we shouldn't allow for it. The purpose of disconnect is for a client to disconnect themselves from a server.

How is it handled in regards to vanilla? Like what happens if you run this PR in vanilla?
Nothing, this is reverting disconnect back to vanilla behaviour. Vanilla doesn't expect disconnect to be called by servers because they could just choose to ignore it, vanilla uses other native functions to properly disconnect a client.

To be clear, do clients already ignore disconnect?

Normal clients do not ignore disconnect, but a malicious one very much could. Therefore using disconnect to disconnect a client is a bad idea and we shouldn't allow for it. The purpose of disconnect is for a client to disconnect themselves from a server.

Aight, thanks for the clarification <3
The only thing I need to keep in mind then in that regard is to give modders a heads-up in case they somehow made a server-mod that sends disconnect to client.
Man I wish I already had a system in place to crawl Thunderstore mods for this sorta stuff ^^"

The only thing I need to keep in mind then in that regard is to give modders a heads-up in case they somehow made a server-mod that sends disconnect to client.

I think when we added NSDisconnectPlayer we did a similar notification already tbh

So I got around writing a quick Thunderstore scraper and based on my local dataset, the following mods at their latest version will be affected

Zanieon-Matchmaking_Mixtape_Menu-1.2.0
SoftSleeper-Attrition_Extended_Overhaul-1.2.11
VoyageDB_Modding_Home-Attrition_Extended-1.9.3
NanohmProtogen-VanillaPlus-2.4.1
VoyageDB_Modding_Home-Grunt_Mode-3.3.2
VoyageDB_Modding_Home-Nessie_Temp_Fix-1.3.16
The_Peepeepoopoo_man-Titanframework-2.4.2
Okudai-loeb-1.0.1
Capt_Diqhedd-GoMortyYourself-1.0.1
VoyageDB_Modding_Home-Modded_Bleedout_Game-1.0.3
VoyageDB_Modding_Home-The_Spawner_English-1.2.0
VoyageDB_Modding_Home-The_Spawner_English-1.2.0
taskinoz-EnhancedMenuMod-1.14.0
zxcPandora-DeveloperMode-1.0.1
EladNLG-RoguelikeBETA-0.3.102
EladNLG-Roguelike-0.3.102

checked by running:
$ find thunderstore -type f -exec grep -l '"disconnect[ "]' {} +
thunderstore/Zanieon-Matchmaking_Mixtape_Menu-1.2.0/mods/MixtapeMenu/mod/scripts/vscripts/ui/menu_lobby.nut
thunderstore/SoftSleeper-Attrition_Extended_Overhaul-1.2.11/mods/ATTExtendOverhaul/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut
thunderstore/VoyageDB_Modding_Home-Attrition_Extended-1.9.3/mods/AITdmExtended/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut
thunderstore/NanohmProtogen-VanillaPlus-2.4.1/mods/NP.VanillaPlus/mod/scripts/vscripts/ui/menu_lobby.nut
thunderstore/VoyageDB_Modding_Home-Grunt_Mode-3.3.2/mods/GruntModeNS/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut
thunderstore/VoyageDB_Modding_Home-Nessie_Temp_Fix-1.3.16/mods/NessieTempFix/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut
thunderstore/The_Peepeepoopoo_man-Titanframework-2.4.2/mods/peepee.Titanframework/mod/scripts/vscripts/sh_loadouts.nut
thunderstore/Okudai-loeb-1.0.1/mods/okudai.loeb/mod/scripts/vscripts/ui/menu_lobby.nut
thunderstore/Capt_Diqhedd-GoMortyYourself-1.0.1/mods/Diq.GoMortyYourself/mod/scripts/vscripts/cl_mortyyourself.gnut
thunderstore/VoyageDB_Modding_Home-Modded_Bleedout_Game-1.0.3/mods/Modded.Bleedout/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut
thunderstore/VoyageDB_Modding_Home-The_Spawner_English-1.2.0/mods/Super.Mixed.Game.English/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut
thunderstore/VoyageDB_Modding_Home-The_Spawner_English-1.2.0/mods/Super.Mixed.Game.English/mod/scripts/vscripts/sh_loadouts.nut
thunderstore/taskinoz-EnhancedMenuMod-1.14.0/mods/Enhanced.Menu.Mod.Northstar/mod/scripts/vscripts/sp/sp_training.nut
thunderstore/zxcPandora-DeveloperMode-1.0.1/mods/DeveloperMode/mod/scripts/vscripts/sh_loadouts.nut
thunderstore/EladNLG-RoguelikeBETA-0.3.102/mods/EladNLG.Roguelike/mod/scripts/vscripts/sp/_savegame.gnut
thunderstore/EladNLG-Roguelike-0.3.102/mods/EladNLG.Roguelike/mod/scripts/vscripts/sp/_savegame.gnut

What would you say is the best way to proceed? Ping mod authors and release PR as part of minor release?

So I got around writing a quick Thunderstore scraper and based on my local dataset, the following mods at their latest version will be affected

Zanieon-Matchmaking_Mixtape_Menu-1.2.0
SoftSleeper-Attrition_Extended_Overhaul-1.2.11
VoyageDB_Modding_Home-Attrition_Extended-1.9.3
NanohmProtogen-VanillaPlus-2.4.1
VoyageDB_Modding_Home-Grunt_Mode-3.3.2
VoyageDB_Modding_Home-Nessie_Temp_Fix-1.3.16
The_Peepeepoopoo_man-Titanframework-2.4.2
Okudai-loeb-1.0.1
Capt_Diqhedd-GoMortyYourself-1.0.1
VoyageDB_Modding_Home-Modded_Bleedout_Game-1.0.3
VoyageDB_Modding_Home-The_Spawner_English-1.2.0
VoyageDB_Modding_Home-The_Spawner_English-1.2.0
taskinoz-EnhancedMenuMod-1.14.0
zxcPandora-DeveloperMode-1.0.1
EladNLG-RoguelikeBETA-0.3.102
EladNLG-Roguelike-0.3.102

Note that only mods that do this on server are affected by this, which reduces this count quite a lot.

Note that only mods that do this on server are affected by this, which reduces this count quite a lot.

Good point. I manually looked through the mods a bit and this is what I ended up with:
Client
thunderstore/Zanieon-Matchmaking_Mixtape_Menu-1.2.0/mods/MixtapeMenu/mod/scripts/vscripts/ui/menu_lobby.nut
thunderstore/NanohmProtogen-VanillaPlus-2.4.1/mods/NP.VanillaPlus/mod/scripts/vscripts/ui/menu_lobby.nut
thunderstore/Okudai-loeb-1.0.1/mods/okudai.loeb/mod/scripts/vscripts/ui/menu_lobby.nut
thunderstore/Capt_Diqhedd-GoMortyYourself-1.0.1/mods/Diq.GoMortyYourself/mod/scripts/vscripts/cl_mortyyourself.gnut

Server
thunderstore/SoftSleeper-Attrition_Extended_Overhaul-1.2.11/mods/ATTExtendOverhaul/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut
thunderstore/VoyageDB_Modding_Home-Attrition_Extended-1.9.3/mods/AITdmExtended/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut
thunderstore/VoyageDB_Modding_Home-Grunt_Mode-3.3.2/mods/GruntModeNS/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut
thunderstore/VoyageDB_Modding_Home-Nessie_Temp_Fix-1.3.16/mods/NessieTempFix/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut
thunderstore/The_Peepeepoopoo_man-Titanframework-2.4.2/mods/peepee.Titanframework/mod/scripts/vscripts/sh_loadouts.nut
thunderstore/VoyageDB_Modding_Home-Modded_Bleedout_Game-1.0.3/mods/Modded.Bleedout/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut
thunderstore/VoyageDB_Modding_Home-The_Spawner_English-1.2.0/mods/Super.Mixed.Game.English/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut
thunderstore/VoyageDB_Modding_Home-The_Spawner_English-1.2.0/mods/Super.Mixed.Game.English/mod/scripts/vscripts/sh_loadouts.nut
thunderstore/zxcPandora-DeveloperMode-1.0.1/mods/DeveloperMode/mod/scripts/vscripts/sh_loadouts.nut

No clue
thunderstore/taskinoz-EnhancedMenuMod-1.14.0/mods/Enhanced.Menu.Mod.Northstar/mod/scripts/vscripts/sp/sp_training.nut
thunderstore/EladNLG-RoguelikeBETA-0.3.102/mods/EladNLG.Roguelike/mod/scripts/vscripts/sp/_savegame.gnut
thunderstore/EladNLG-Roguelike-0.3.102/mods/EladNLG.Roguelike/mod/scripts/vscripts/sp/_savegame.gnut

Looking at it further the majority of the server sided mods that call disconnect do so cause they modify existing Northstar scripts

https://github.com/R2Northstar/NorthstarMods/blob/343051c9014207f8785d2194a52ec2f082657ca2/Northstar.Custom/mod/scripts/vscripts/burnmeter/sh_burnmeter.gnut#L210
https://github.com/R2Northstar/NorthstarMods/blob/343051c9014207f8785d2194a52ec2f082657ca2/Northstar.CustomServers/mod/scripts/vscripts/sh_loadouts.nut#L1512
https://github.com/R2Northstar/NorthstarMods/blob/343051c9014207f8785d2194a52ec2f082657ca2/Northstar.CustomServers/mod/scripts/vscripts/sh_loadouts.nut#L1522

From the look of it, they are called on server but I might be mistaken.
If they are, I guess we'd have to update the corresponding mod code as well ^^"

Not a lot that we can do about the mods that override these files. Lets be honest, they aren't going to get updated. But yeah https://github.com/R2Northstar/NorthstarMods/pull/841 fixes the cases in Northstar.


404 during installation

The following instructions do not work since https://github.com/bitnami/kube-prod-runtime/releases/download/v0.3.1/bkpr-v0.3.1-linux-amd64.tar.gz returns 404. This seems to be due to the fact that BKPR_VERSION is set to the stable release not to the pre-release and the stable release is actually called kubeprod (kubeprod-v0.3.1-linux-amd64.tar.gz)
BKPR_VERSION=$(curl --silent "https://api.github.com/repos/bitnami/kube-prod-runtime/releases/latest" | jq -r '.tag_name')
curl -LO https://github.com/bitnami/kube-prod-runtime/releases/download/${BKPR_VERSION}/bkpr-${BKPR_VERSION}-linux-amd64.tar.gz
tar xf bkpr-${BKPR_VERSION}-linux-amd64.tar.gz

@migmartri I spotted the same error, the correct link should be:
https://github.com/bitnami/kube-prod-runtime/releases/download/v0.3.1/kubeprod-v0.3.1-linux-amd64.tar.gz (btw, you can see all available releases here: https://github.com/bitnami/kube-prod-runtime/releases/)
interestingly, the 1.0 version does follows this convention. E.g:
https://github.com/bitnami/kube-prod-runtime/releases/download/v1.0.0-rc5/bkpr-v1.0.0-rc5-linux-amd64.tar.gz
I guess this is likely a typo in the 0.3.1 release name.

Urgh.  Yes, your assessment above is correct - we changed the artifact name between 0.3.1 and 1.0.0(-rc).
Given that the "real" 1.0 release is imminent, and it is hard/impossible to rename the existing 0.3.1 github artifacts, I'm going to close this as wontfix.  It's a real bug, however, so thank you both for the report and investigation!
Aside: For your testing, I strongly recommend you both use the 1.0.0-rc candidates.


Targets are first class objects

I couldn't take it anymore, having the @targets and @target in a Deploy object.

Now each Target is a top level object with only the details about... the target.
A Deploy is composed of a Target plus the options that come from the command line - the "deploy" options if you will.
There is no more base configuration - the main Configuration object holds all the base config.
There is no more deploy configuration - that is all handled by the main Configuration and by config.targets=

All specs are passing.  Feel free to comment, disapprove, or offer other ideas on how to make this code a little easier to work with.  @camertron @rfroetscher @matl33t

OK i updated this so that now it is basically 100% backwards compatible except for the default rake db:migrate thing, which i think needs to come out at some point. it's also been tested.

@matl33t  are you concerned at all about the fact that rake db:migrate is no longer the default / do you see any problems with that?
i'm going to take this puppy through another round of testing all the commands then i will merge and someone should release (i'm not sure i can release yet?)
also i think after this change the code is getting to a point where maybe we should do a blog post or something; it's much more readable and work withable as code on top of the functionality which has always been pretty awesome.

no issues with removing db:migrate - since this will come with a major version bump we can roll this out without breaking applications


Manual operation DOM and Update properties Will cause inexplicable bugs

Description
I created an demo
I had an list [0, 1, 2], rendered like

0

1

2

Clickd the change Dom button will change the dom structure:

1

0

2

I didn't update list, now click the 'done' button,update list [0, 1, 2] to [1, 0, 2], but it's render:

0

1

2

I console list print [1, 0, 2], why list list is [1, 0, 2] but dom structure is [0, 1, 2]

You can't manually change the DOM under control of lit-html, you have to change the data then re-render. If you change the DOM you may disturb the marker nodes that lit-html uses to perform updates. In this case when you re-order the divs you also reorder the markers for the list items. The result is expected if you know how lit-html works, but clearly unexpected for most. So the best advice is don't do that. You can give manually managed DOM to lit-html to render to a spot. We talk about this restriction a bit here: https://lit-element.polymer-project.org/guide/templates#design-a-performant-template

Closing as working as intended


Vouch not running via Helm

When running Vouch-Proxy (version 0.19.2 and 0.23.1 tested) using Helm Charts, I'm getting the following exception:
{"level":"fatal","ts":1618323472.0185509,"msg":"envconfig.Process: assigning VOUCH_PORT to Port: converting 'tcp://10.xx.xx.xx:9090' to type int. details: strconv.ParseInt: parsing \"tcp://10.xx.xx.xx:9090\": invalid syntax"}

Here's my values.yaml:
replicaCount: 1

image:
  repository: "voucher/vouch-proxy"
  pullPolicy: IfNotPresent
  tag: "0.19.2"

serviceAccount:
  create: true
  annotations: {}
  name: ""

podAnnotations: {}

podSecurityContext: {}

securityContext: {}

service:
  type: ClusterIP
  port: 9090
  internalPort: 9090

probes:
  liveness:
    enabled: true
    initialDelaySeconds: 0
    timeoutSeconds: 1
    successThreshold: 1
    failureThreshold: 5
    periodSeconds: 10
  readiness:
    enabled: true
    initialDelaySeconds: 0
    timeoutSeconds: 1
    successThreshold: 1
    failureThreshold: 5
    periodSeconds: 10
  startup:
    enabled: true
    timeoutSeconds: 1
    successThreshold: 1
    initialDelaySeconds: 5
    failureThreshold: 30
    periodSeconds: 10

ingress:
  enabled: false
  annotations: {}
  hosts:
    - host: dev-system.company.net
      path: "/vouch(/|$)(.*)"
  tls: []

resources: {}

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 4
  targetCPUUtilizationPercentage: 80

nodeSelector: {}

tolerations: []

affinity: {}

project: myproject

namespace: myproject

# vouch config
config:
  vouch:
    logLevel: debug
#    testing: false
#    listen: <IP_ADDRESS>
#    port: 9090
    allowAllUsers: true
    headers:
      claims:
        - groups
    cookie:
      secure: false
      domain: company.net
  oauth:
    provider: adfs
    client_id: xxx
    client_secret: xxx
    auth_url: https://idp-test.company.net/nidp/oauth/nam/authz
    token_url: https://idp-test.company.net/nidp/oauth/nam/token
    user_info_url: https://idp-test.company.net/nidp/oauth/nam/userinfo
    scopes:
      – openid
      - microprofile-jwt
    callback_url: https://services-local.company.net/sso/auth

probes:
  liveness:
    enabled: true
    initialDelaySeconds: 0
    periodSeconds: 1
    timeoutSeconds: 1
    successThreshold: 1
    failureThreshold: 3
  readiness:
    enabled: true
    initialDelaySeconds: 0
    periodSeconds: 1
    timeoutSeconds: 1
    successThreshold: 1
    failureThreshold: 3
  startup:
    enabled: true
    initialDelaySeconds: 0
    periodSeconds: 1
    timeoutSeconds: 1
    successThreshold: 1
    failureThreshold: 3

I'm not sure what to tell you. I'm running 0.23.1 via my helm chart and it works just fine.
https://github.com/vouch/vouch-proxy/compare/v0.19.2..master doesn't seem to mention anything about port
i explicitly set vouch_port to a value in my helm chart to get around the kubernetes setting it to an address. So maybe your not using my chart?

Yes, you were right, I only took the values.yaml and missed the cahnges in the other files, especially the deployment.yaml. I took your complete helm project as template and added/changed our company-specific configs and now it works. Thank you for the help.

So to be clear, you took my stuff, heavily modified it, then filed a report with no indication that you made any changes at all, and  asked me to debug it?


“hwameistor-scheduler” Not scheduled to the specified node

1.Node anti affinity yaml：

2Scheduled to “controller-node”, expected not to be scheduled to “controller-node”

3.hwameistor-scheduler logs

4.hwameistor version
ghcr.m.daocloud.io/hwameistor/scheduler:v0.14.5

Due to the inability to reproduce the issue, it is inconvenient to investigate

please upgrade hwameistor version to v0.14.6 and re-test


Adding better description

Closes https://github.com/MicrosoftDocs/office-docs-powershell/issues/6742

Docs Build status updates of commit 6078a40:
:clock10: Pending: waiting for processors (38 builds ahead of you)
:warning: Docs Build is busy, currently there are 38 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 55bc130:
:clock10: Pending: waiting for processors (38 builds ahead of you)
:warning: Docs Build is busy, currently there are 38 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 6078a40:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/New-CsTeamsMessagingPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 55bc130:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/New-CsTeamsMessagingPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Set-CsTeamsMessagingPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

https://github.com/MicrosoftDocs/office-docs-powershell/issues/6743

@Kateyanne Please merge this PR. Thanks

Docs Build status updates of commit 7981d8b:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/New-CsTeamsMessagingPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Set-CsTeamsMessagingPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Add function-level tracing to TDAG

Previous discussion about the challenges with reconstructing the call stack in post-processing: https://github.com/trailofbits/polytracker/issues/6367


Test Issue created at Mon, 12 Apr 2021 10:07:30 GMT

Test issue body  Mon, 12 Apr 2021 10:07:30 GMT

Comment on issue at Mon, 12 Apr 2021 10:07:33 GMT


Wiring: v0.4 Power Entry and Switch harness

This branch begins the process updating the wiring harness design files and documentation for v0.4, starting with the power entry and switch harness.
We are trying out wireviz for creating the drawings.  The YAML source file is committed to the repo, while the output files will be stored in the google drive, with the exception of images used for the github documentation.
The README.md has also been updated to reflect the v0.4 harness.
I think we should make each harness update its own branch and PR for the sake of PR granularity (not try to make this PR cover all the harnesses).
Note that the process photos are TBD until we do the first harness build.  I suggest we merge this PR first and then we can open another PR in the future to add those images.
Self-review checklist:

[x] Self-review: looked through the Files changed tab, browsed repository in branch
[x] Documentation updated - reflects changes in code, electrical or mechanical design
[x] Documentation and graphics follow the documentation style guide
[x] New content is linked, easily discoverable, does not require too many clicks
[x] Follows other relevant parts of contributor wiki
[x] PR has a descriptive name
[x] Tagged relevant reviewers

Looking good!  Thoughts so far:

Pinout of the power connector is inconsistent between the power supply (https://www.meanwell.com/webapp/product/search.aspx?prod=GSM160A) and the female connector (http://www.kycon.com/Pub_Eng_Draw/KPJX-PM-4S.pdf): the positive pins are 1 and 4 by the power supply's numbering, but this makes them pins 2 and 4 by the female connector's numbering.  So the wiring diagram is correct by the power supply's numbering, but should probably use the female connector's numbering - also maybe worth a note in the docs just to make this explicit?
Is there a specific reason for the 4.7 mm quick-connect size?  Looks like out of promising candidate power switches, the JWMW series all use 2.8 mm (0.11") quick-connects, and the WR and R7 series both use 6.3 mm (0.25") quick-connects.

@dcstraney thanks,
(1) that's maddening.  Probably best clarify this with an image.  There is a way to do this in wireviz.
(2), I just did a search using the basic parameters you picked in the ticket and chose the terminal size that was most common among them, to cover the most options.  In any case, we expect the cables to still change a bit as we progress with integration; the purpose of this PR is more to establish a new way of defining cables for v0.4 (going away from Altium and to something open-source).  We can change this when a switch is selected.

for reference here is the meanwell power supply pinout:

and that of the kycon receptacle:

Here is what the updated wiring diagram looks like

:

It's doing that visual overlapping thing we don't like.


Add a filter to convert some 'basic' 4XX responses into 'problem' responses

RFC 7807
Use ProblemDescription as the preferred format for "error" responses from API endpoints.
Introduce a new attribute that assumes that your API confers to some expectations. Expectations:
(a) Any API which participates in model binding will have model state errors
(b) API accepting id parameters will 404.
(c) More ...?
On the API description end, this means we will add a provider to enhance the description based on these expectations. See https://github.com/aspnet/Mvc/issues/6785
On the output end, we'll add a filter \ change the execution to return a ProblemDescription if the action result matches one of our expectations.
Introduce new types that allow modifying what the shape of the error description is. We'll produce a ProblemDescription and allow users to modify it's shape.

We're not doing a filter. The plan is to use action result execution extensibility to do this.

I have the capability to return new format results in exception handler?

Default flow for exception in controller will also use the new format?

No, it's primarily meant to convert ActionResult with error status codes to errors.

I have the capability to return new format results in exception handler?
Yup. The plan would be to have some way to customize what the format looks like. Right now, you could do this for ApiControllers using ApiBehaviorOptions.InvalidModelStateResponseFactory. e.g. https://github.com/aspnet/Mvc/blob/dev/test/WebSites/BasicWebSite/Startup.cs#L37-L47

Moving this out to preview2. We need to design this which we did not get around to as part of this release.


add padding to align columns nicely

fixes https://github.com/alcortesm/AllBase/issues/7

[Current coverage][cc-pull] is 100%

Merging [#8][cc-pull] into [master][cc-base-branch] will not change coverage

@@           master    #8   diff @@
===================================
  Files           6     6
  Lines         111   120     +9
  Methods         0     0
  Messages        0     0
  Branches       20    22     +2
===================================
+ Hits          111   120     +9
  Misses          0     0
  Partials        0     0

Powered by Codecov. Last updated by [5a6b091...2b6b5f4][cc-compare]
[cc-base-branch]: https://codecov.io/gh/alcortesm/AllBase/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/alcortesm/AllBase/compare/5a6b0913b035e5c6212d0f0d8daa79ab077fe0d2...2b6b5f49ed6284d83cc5633c9c130bf13d192b1e
[cc-pull]: https://codecov.io/gh/alcortesm/AllBase/pull/8?src=pr


Change Code Page to 1252

how to change code page to 1252 in Dockerfile for example? I don't want to use UTF8. I'm using ltsc2019

Can you clarify what you are trying to do?

Are you trying to save your Dockerfile in windows-1252 character encoded format?
Are you trying to run a command in your dockerfile which converts an existing document from UTF8 to windows-1252?
Something else?

Thank's
Em ter., 6 de dez. de 2022 às 14:11, Noah Whitehead <
@.***> escreveu:

@ronaldobim https://github.com/ronaldobim We are currently looking into
this issue, and I will get back to you with more information.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/Windows-Containers/issues/272#issuecomment-1339699197,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALVZERSTNVYNGP4GUHHHS4DWL5XVBANCNFSM6AAAAAAQKVSITA
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Ronaldo Cesar Bim
Skype - ronaldobim
e-mail - @.***

Thanks, de manifest file solved.