Spec: Finalize the new API

Discussion already started in Tableland public APIs across platforms are inconsistent. We have to finish a final spec.

@carsonfarmer, on question. Is this a duplicate of https://github.com/tablelandnetwork/docs/issues/20? Or this one is for internal discussion first, and the linked one is to open up our "draft" conclusion to the community and try to get some feedback?

Probably one could be consumed into the other. They do seem redundant.

@carsonfarmer , bumping to 5.1.0.

Continuing the discussion started in that linked Notion document here. Firstly, the outcome "so far" from that discussion includes the following two decisions:

We should drop support for JSON RPC and focus only on REST APIs
We should adopt versioning prefixing for our REST APIs

Additionally, it was suggested in a recent Discord discussion, that the final outcome of this particular ticket should probably be an OpenAPI specification.
From @jsign:

Getting a bit ahead about some work that will start in some weeks reg the new REST APIs.
What do you think if the outcome of the TPD for the REST API is an OpenAPI 3.0 file spec.
So, apart from the SQL Spec we can have the OpenAPI 3.0 file spec, and that being our source of truth.
This is useful because we could use Swagger to automatically generate:

Automatically generate Servers for Go (and other languages)
Automatically generate CLIs (e.g: in Go)
Automatically generate clients of the REST API (Go, JS, Rust, C#, Python, etc)
Automatically generate a deployable classic Swag documentation that can actually target the real validator via UI: example = https://petstore.swagger.io/?_ga=2.237182793.837962381.1667929888-1702797342.1667929888#/store/placeOrder

What I like about the “spec first” approach, is that if we upgrade our spec to include some new method or similar, we can have defined processes in our repos (SDKs, Validator, CLIs, etc) to update to the new spec. So.. we can spend less time on boilerplate.
TBH, I haven’t used Swagger for years, so I’m not 100% sure it won’t have any downside. Probably we can discover this when we jump into the implementation. In any case, the OpenAPI 3.0 spec that can generate that last-bullet-UI, I think is already a big win. If can also generate nice server, client and CLI code, that’d be great but we’ll can see how that plays out.

I think this is a great idea. So I'm going to kick off the discussion here with a draft OpenAPI 3.0 Spec (attached in the following comment). You can view this spec and its output here:

tableland.txt

openapi: 3.0.3
info:
  title: Tableland Validator - OpenAPI 3.0
  description: |-
    In Tableland, Validators are the execution unit/actors of the protocol.
    They have the following responsibilities:
    - Listen to on-chain events to materialize Tableland-compliant SQL queries in a database engine (currently, SQLite by default).
    - Serve read-queries (e.g: SELECT * FROM foo_69_1) to the external world.
    - Serve state queries (e.g. list tables, get receipts, etc) to the external world.

    In the 1.0.0 release of the Tableland Validator API, we've switched to a design first approach!
    You can now help us improve the API whether it's by making changes to the definition itself or to the code.
    That way, with time, we can improve the API in general, and expose some of the new features in OAS3.

  termsOfService: http://docs.tableland.xyz
  contact:
    name: core devs
    email<EMAIL_ADDRESS>  license:
    name: Apache 2.0
    url: http://www.apache.org/licenses/LICENSE-2.0.html
  version: 1.0.0
externalDocs:
  description: Tableland docs
  url: http://docs.tableland.xyz
servers:
  - url: https://testnet.tableland.xyz/api/v1
tags:
  - name: query
    description: Query the Tableland network
    externalDocs:
      description: Find out more about queries
      url: http://docs.tableland.xyz
  - name: receipt
    description: Get information about transaction progress
    externalDocs:
      description: Find out more about receipts
      url: http://docs.tableland.xyz
  - name: tables
    description: Access to table information
    externalDocs:
      description: Find out more about tables
      url: http://docs.tableland.xyz
paths:
  /query:
    get:
      tags:
        - query
      summary: Query the Tableland network
      description: Returns the results of a SQL query against the Tabeland network
      operationId: queryFromQuery
      parameters:
        - name: statement
          in: query
          description: The SQL query statement
          required: true
          schema:
            type: string
        - name: format
          in: query
          description: >
            The requested response format:
             * `objects` - Returns the query results as a JSON array of JSON objects.
             * `table` - Return the query results as a JSON object with columns and rows properties.
          required: false
          schema:
            type: string
            enum:
              - objects
              - table
            default: "objects"
        - name: extract
          in: query
          description: Whether or not to extract the JSON object from the single property of the surrounding JSON object.
          required: false
          schema:
            type: boolean
            default: false
        - name: unwrap
          in: query
          description: Whether or not to unwrap the returned JSON objects from their surrounding array.
          required: false
          schema:
            type: boolean
            default: false
      responses:
        "200":
          description: successful operation
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/QueryResponse"
        "400":
          description: Invalid query/statement value
  /exec:
    get:
      tags:
        - query
      summary: Query the Tableland network
      description: Returns the results of a SQL query against the Tabeland network
      operationId: queryFromBody
      requestBody:
        description: A paired statement and params to use to query the Tableland network.
        required: true
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/ExecRequest"
      responses:
        "200":
          description: successful operation
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/ExecResponse"
        "400":
          description: Invalid query/statement value
  /receipt/{txnHash}:
    get:
      tags:
        - receipt
      summary: Query the Tableland network for transaction status
      description: Returns the status of a given transaction receipt by hash
      operationId: receiptByTxnHash
      parameters:
        - name: txnHash
          in: path
          description: The parent chain transaction hash
          required: true
          schema:
            type: string
      responses:
        "200":
          description: successful operation
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/TxnReceipt"
        "400":
          description: Invalid query/statement value
  /tables/byStructure:
    get:
      tags:
        - tables
      summary: Finds tables by structure
      description: Returns all tables that match a given structure
      operationId: findTablesByStructure
      parameters:
        - name: strcture
          in: query
          description: Structure to filter on
          required: true
          schema:
            type: string
      responses:
        "200":
          description: successful operation
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/Info"
        "400":
          description: Invalid structure value
  /tables/byOwner:
    get:
      tags:
        - tables
      summary: Finds tables by owner
      description: Returns all tables owned by a given address
      operationId: findTablesByOwner
      parameters:
        - name: owner
          in: query
          description: Owner to filter on
          required: true
          schema:
            type: string
      responses:
        "200":
          description: successful operation
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/Info"
        "400":
          description: Invalid owner value
  /tables/{tableId}:
    get:
      tags:
        - tables
      summary: Get information about a table
      description: Returns information about a single table
      operationId: getTableById
      parameters:
        - name: tableId
          in: path
          description: ID of table to return
          required: true
          schema:
            type: string
      responses:
        "200":
          description: successful operation
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Table"
        "400":
          description: Invalid ID supplied
        "404":
          description: Table not found
  /tables/{tableId}/schema:
    get:
      tags:
        - tables
      summary: Get a table's schema information
      description: Returns information about a single table's schema
      operationId: getTableSchema
      parameters:
        - name: tableId
          in: path
          description: ID of table to query
          required: true
          schema:
            type: string
      responses:
        "200":
          description: successful operation
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Schema"
components:
  schemas:
    ExecRequest:
      type: object
      properties:
        statement:
          description: The SQL query statement(s) to execute.
          nullable: false
          oneOf:
            - type: array
              items:
                type: string
            - type: string
          example: "SELECT name, age FROM users WHERE age < ?1"
        params:
          description: The set of params to bind to the provided statement(s).
          nullable: true
          type: array
          items:
            oneOf:
              - type: string
              - type: number
              - type: integer
              - type: boolean
              - type: array
                items:
                  oneOf:
                    - type: string
                    - type: number
                    - type: integer
                    - type: boolean
          example: [20]
    ExecResponse:
      type: object
      properties:
        lastRowId:
          type: number
          example: 1
          nullable: true
        changes:
          type: number
          example: 0
          nullable: false
        duration:
          type: number
          example: 0
          nullable: false
        error:
          type: string
          example: "Something went wrong"
          nullable: true
        results:
          type: array
          nullable: true
          items:
            type: object
    AnyObject:
      type: object
    TableObject:
      type: object
      properties:
        columns:
          type: array
          items:
            type: string
        rows:
          type: array
          items:
            type: object
    QueryResponse:
      oneOf:
        - $ref: "#/components/schemas/AnyObject"
        - $ref: "#/components/schemas/TableObject"
      # Figure out how to use a discriminator properly here
      discriminator:
        propertyName: columns
    Table:
      type: object
      properties:
        name:
          type: string
          example: healthbot_5_1
        external_url:
          type: string
          example: https://testnet.tableland.network/tables/healthbot_5_1
        image:
          type: string
          example: https://render.tableland.xyz/healthbot_5_1
        attributes:
          type: array
          items:
            type: "object"
            properties:
              display_type:
                type: "string"
                description: "The display type for marketplaces"
              trait_type:
                type: "string"
                description: "The trait type for marketplaces"
              value:
                description: "The value of the property"
                oneOf:
                  - type: string
                  - type: number
                  - type: integer
                  - type: boolean
                  - type: object
          example:
            {
              "display_type": "date",
              "trait_type": "created",
              "value":<PHONE_NUMBER>,
            }
    TxnReceipt:
      type: object
      properties:
        tableId:
          type: string
          example: healthbot_5_1
        txnHash:
          type: string
          example: "0x400508d7cc035b14cc53f64393a8dafcc55f66ad8f9b44d626744157337e2098"
        blockNumber:
          type: number
          example: 1
        chainId:
          type: number
          example: 80001
    Info:
      type: object
      properties:
        owner:
          type: string
          example: "0xbAb12215Ed94713A290e0c618fa8177fAb5eFd2D"
        name:
          type: string
          example: "healthbot_5_1"
        structure:
          type: string
          example: "799dcf5ed5cfeb9e221500db95531ab9197224f8fc9cb9452ce30e4b5cea80d1"
    Schema:
      type: object
      properties:
        columns:
          type: array
          items:
            $ref: "#/components/schemas/Column"
        tableConstraints:
          type: array
          items:
            type: string
          example: ["PRIMARY KEY (id)"]
    Column:
      type: object
      properties:
        name:
          type: string
          example: "id"
        type:
          type: string
          example: "integer"
        constraints:
          type: array
          items:
            type: string
          example: ["NOT NULL", "PRIMARY KEY", "UNIQUE"]

tableland_open_api.txt

I am also happy for us to put this somewhere more collaborative and work on it from there, or not use it directly and just use the visual editor to help drive the discussion.

Some additional things to consider:

I didn't include paging in any of the above APIs, but we probably should
I am hoping/assuming we can avoid requiring chainId information in the above APIs in favor of using tableId or tableName to include at least {chainId}_{tableId}. So essentially all APIs should prefer tableName over tableId.
In all cases, prefix on the tableName should be optional.
We should avoid any of the validate APIs in favor of doing that client side.
I have included both a /query endpoint and an /exec endpoint. This isn't ideal, it would be better to have one. I think one is totally doable, but I've included both variants to help our discussion.

The body based version is more constrained, which is a good thing IMO
The body based version doesn't overload query params, which can cause issues with long queries
The body based version supports "prepared statement" style calls (separating the statement from the params)
The query based version supports more formatting options (based on our current REST API)
The query based version doesn't include the query metadata (just the raw results)
The query based version plays nicely with marketplaces and things that require a raw URI

Yes v prefix for sure, I think that's in the spec at the top. Not sure yet how to specify multiple versions in a single spec doc yet though? And yes also to security section. I wasn't sure about that stuff so left it out, thanks for flagging!

+1 for "v" prefix

Yes v prefix for sure, I think that's in the spec at the top. Not sure yet how to specify multiple versions in a single spec doc yet though?

I think we wouldn't have to put the v1 in the top (base API) and just put it as part of the route definitions if we want to keep all that in the same yaml spec.
I think we should also decide if the versioning is per method (route) or general, like:

Does it make sense to say we release a new version of the spec?
Can we generate a new version of a single method?
When we add a new method, it starts with v1?
How do we signal experimental APIs as suggested by @sanderpick?

Ah yes interesting. There must be some "best practices" documentation out there on this exact thing right? Also, for the experimental stuff, perhaps a prefix like vDev or even vX or something? From a client's perspective, it is nice to have a single "version" of the API to deal with, rather than having to create specific methods for specific versions of each endpoint... but since we'll be able to generate the clients, maybe this isn't such as big deal after all?

https://www.bennorthrop.com/Essays/2019/api-versioning-with-openapi-and-api-first.php

Hey folks, thanks to a quick meeting with @jsign and @brunocalza I think we have a first draft proposal to share with the rest of the team. I've updated the above comment with the latest spec document. Note that most docs links etc are currently placeholders.
Details:

We will use a global API version, which will strictly follow semver best practices.
API paths will all be prefixed with /api/v{majorVersion}, ignoring the minor and patch version values.
There will no longer be any auth tokens required on any endpoints.
By convention, all required params are included in an API path, and all optional params are included as query params. The only exception is the statement param in the /query endpoint, which while required, is allowed to be a query param.
We have switched to using the concept of a table owner rather than a table controller (which is a separate thing).
Minor and patch updates to the spec will be done "in-place", and major updates will require a new spec doc with the major version bumped. This is an uncommon thing. It is still open as to how many, and for how long, we support previous major versions of the spec.
Anything that can be done client side, should be done client side. This means we've dropped all the validate* endpoints, and calculating structure hashes should be done using the WASM parser lib.
Validator APIs will not relay anything for the clients. This means all mutating functionality must do through the smart contract (which is out of scope for this discussion, but API changes there should also be considered soon). Notice that there are only GET based APIs specified.

Open Questions:

What should we call in development versions of the spec? Do we want to support this?
Do the above set of endpoints cover your current use cases (@carsonfarmer has attempted to ensure that this is indeed the case)?
Do the above set of endpoints cover your short-term anticipated use cases? If you have major API change requests (like new features, we'll do this as part of separate work).
Do the above set of endpoints cover known use cases from the community? Again, @carsonfarmer thinks they do.
Are there any concerns about the length of query parameters (for the SQL statement in particular).
Would a POST style API that let's users send fetch requests with SQL statements in the body of the request solve any additional use cases for you or known users?

Anything else I've missed @jsign or @brunocalza ?

In a conversation with @awmuncy just now, I realized, we perhaps don't need some of the above APIs, as they can be done already via directly calling read methods on the contract. For instance, the "owner" method is a basic ERC721 contract call to return the address of the owner of a given NFT (in this case, the Tableland Tables NFT). Similarly, "listing" my tables can be done (on a per chain basis) via listing my tokens. This leaves out the prefix of a table IIRC, but perhaps we can modify the registry to include this information. At the end of the day, we can reduce the validator API to almost only query and some of the structure and schema APIs.

Would the idea be to include them in the SDK / CLI, instead? They'd be useful functions to call there but makes sense re: validator load.

Yes exactly. We'll still need to make it easy to get that information, but it would be good to depend on the validators for as little as possible. Given we don't have the incentives totally sorted yet.

+1, after we remove validator GRANT / REVOKE, it shouldn't need to know anything about table owners

oop, on call with Carson... we realized we should consider the "listen to a table" push API

oop, on call with Carson... we realized we should consider the "listen to a table" push API

I'd advise being cautious about this APIs. Not because they are hard to create (we've done this in Hub and Powergate), but I see some open questions that might be better to be sure we can know how to answer because, in the future, it could backfire.
In general, subscription-like APIs are a burden for validators because:

They have open connections, and the number of file descriptors in a machine is capped and consumes resources (even if nothing is happening)
It can be hairy, depending on each validator infrastructure, to configure things correctly if reverse proxies are dropping idle connections. We have experienced this before ourselves in Hub. This will depend on each validator understanding their infra.

But the biggest question for me is how to make this sustainable for validators or how a payment model would work.
In read-queries, it's easy to reason about a potential per-request payment model.
This API has two vectors of costs:

An open connection consumes resources, even if no data is being exchanged. This should be potentially accounted for in the payments. It's a constant rate of cost.
Some extra cost per event or similar.

Also, feels like we should allow some way for the user to pay for the API service while is happening, or before and have some budget.
My point here is that we can do this API today, and forget about these things. But if in the future the above questions don't have a good answer, there might be validators simply disabling this API because it doesn't make sense to them. If users build their apps entirely relying on an API, then deprecating it becomes a problem.
I wasn't in that convo, so maybe there's already a plan. Just dumping here my first thoughts.

Yeh, it seems like we can probably create the experience of a listen API on the client by leveraging the existing subscription APIs available via an ETH node (such as alchemy) and our receipt poll-based API.

Upon further reflection, it is clear that we can remove the /tables/owner/{address} API proposed in the spec above, as this information is available via the smart contract. Additionally, if we want further rich information, we can query the smart contract, and then request table info via the /tables/tableName API. The only stipulation (which I think we will need anyway) is that prefix is lost in that case. But I think we might want to consider storing table prefixes on the registry anyway so the the pure smart contract experience is closer to the sdk based experience for a developer.

I'm also still wondering if the reverse lookup by structureHash is actually a useful API? Do we know of anyone using it?

Lastly, from conversations around the TablelandTables NFT () and the content that is being rendered there, it might be quite useful to simply return the schema information and the table info via a single API. The same API that marketplaces use. Currently, the renderer for a table on a marketplace is always making at least 2 API calls to get the metadata required to display the table state... why not make that a single API call?
That might mean that /tables/{tableName} would return the existing Table type response, and that response would include a schema key that includes the Schema type.

With all of the above in mind, my updated proposed API spec is included here:
openapi: 3.0.3
info:
  title: Tableland Validator - OpenAPI 3.0
  description: |-
    In Tableland, Validators are the execution unit/actors of the protocol.
    They have the following responsibilities:
    - Listen to on-chain events to materialize Tableland-compliant SQL queries in a database engine (currently, SQLite by default).
    - Serve read-queries (e.g: SELECT * FROM foo_69_1) to the external world.
    - Serve state queries (e.g. list tables, get receipts, etc) to the external world.

    In the 1.0.0 release of the Tableland Validator API, we've switched to a design first approach!
    You can now help us improve the API whether it's by making changes to the definition itself or to the code.
    That way, with time, we can improve the API in general, and expose some of the new features in OAS3.

  termsOfService: http://docs.tableland.xyz
  contact:
    name: core devs
    email<EMAIL_ADDRESS>  license:
    name: Apache 2.0
    url: http://www.apache.org/licenses/LICENSE-2.0.html
  version: 1.0.0
externalDocs:
  description: Tableland docs
  url: http://docs.tableland.xyz
servers:
  - url: https://testnet.tableland.xyz/api/v1
tags:
  - name: query
    description: Query the Tableland network
    externalDocs:
      description: Find out more about queries
      url: http://docs.tableland.xyz
  - name: receipt
    description: Get information about transaction progress
    externalDocs:
      description: Find out more about receipts
      url: http://docs.tableland.xyz
  - name: tables
    description: Access to table information
    externalDocs:
      description: Find out more about tables
      url: http://docs.tableland.xyz
paths:
  /query:
    get:
      tags:
        - query
      summary: Query the Tableland network
      description: Returns the results of a SQL query against the Tabeland network
      operationId: queryFromQuery
      parameters:
        - name: statement
          in: query
          description: The SQL query statement
          required: true
          schema:
            type: string
        - name: format
          in: query
          description: >
            The requested response format:
             * `objects` - Returns the query results as a JSON array of JSON objects.
             * `table` - Return the query results as a JSON object with columns and rows properties.
          required: false
          schema:
            type: string
            enum:
              - objects
              - table
            default: "objects"
        - name: extract
          in: query
          description: Whether or not to extract the JSON object from the single property of the surrounding JSON object.
          required: false
          schema:
            type: boolean
            default: false
        - name: unwrap
          in: query
          description: Whether or not to unwrap the returned JSON objects from their surrounding array.
          required: false
          schema:
            type: boolean
            default: false
      responses:
        "200":
          description: successful operation
          content:
            application/json:
              schema:
                type: object
        "400":
          description: Invalid query/statement value
  /receipt/{chainId}/{txnHash}:
    get:
      tags:
        - receipt
      summary: Query the Tableland network for transaction status
      description: Returns the status of a given transaction receipt by hash
      operationId: receiptByTxnHash
      parameters:
        - name: chainId
          in: path
          description: The parent chain to target
          required: true
          schema:
            type: number
        - name: txnHash
          in: path
          description: The transaction hash to request
          required: true
          schema:
            type: string
      responses:
        "200":
          description: successful operation
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/TxnReceipt"
        "400":
          description: Invalid query/statement value
  /tables/structure/{hash}:
    get:
      tags:
        - tables
      summary: Finds tables by structure
      description: Returns all tables that match a given structure
      operationId: findTablesByStructure
      parameters:
        - name: hash
          in: path
          description: Structure hash to filter on
          required: true
          schema:
            type: string
        - name: chainId
          in: query
          description: The parent chain to filter on
          required: false
          schema:
            type: number
      responses:
        "200":
          description: successful operation
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/Info"
        "400":
          description: Invalid structure value
  /tables/{tableName}:
    get:
      tags:
        - tables
      summary: Get information about a table
      description: Returns information about a single table, including schema information
      operationId: getTableByName
      parameters:
        - name: tableName
          in: path
          description: Full name of table to return
          required: true
          schema:
            type: string
      responses:
        "200":
          description: successful operation
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Table"
        "400":
          description: Invalid name supplied
        "404":
          description: Table not found
components:
  schemas:
    Table:
      type: object
      properties:
        name:
          type: string
          example: healthbot_5_1
        external_url:
          type: string
          example: https://testnet.tableland.network/tables/healthbot_5_1
        image:
          type: string
          example: https://render.tableland.xyz/healthbot_5_1
        attributes:
          type: array
          items:
            type: "object"
            properties:
              display_type:
                type: "string"
                description: "The display type for marketplaces"
              trait_type:
                type: "string"
                description: "The trait type for marketplaces"
              value:
                description: "The value of the property"
                oneOf:
                  - type: string
                  - type: number
                  - type: integer
                  - type: boolean
                  - type: object
          example:
            {
              "display_type": "date",
              "trait_type": "created",
              "value":<PHONE_NUMBER>,
            }
        schema:
          $ref: "#/components/schemas/Schema"
    TxnReceipt:
      type: object
      properties:
        tableId:
          type: string
          example: healthbot_5_1
        txnHash:
          type: string
          example: "0x400508d7cc035b14cc53f64393a8dafcc55f66ad8f9b44d626744157337e2098"
        blockNumber:
          type: number
          example: 1
        chainId:
          type: number
          example: 80001
    Info:
      type: object
      properties:
        owner:
          type: string
          example: "0xbAb12215Ed94713A290e0c618fa8177fAb5eFd2D"
        name:
          type: string
          example: "healthbot_5_1"
        structure:
          type: string
          example: "799dcf5ed5cfeb9e221500db95531ab9197224f8fc9cb9452ce30e4b5cea80d1"
    Schema:
      type: object
      properties:
        columns:
          type: array
          items:
            $ref: "#/components/schemas/Column"
        tableConstraints:
          type: array
          items:
            type: string
          example: ["PRIMARY KEY (id)"]
    Column:
      type: object
      properties:
        name:
          type: string
          example: "id"
        type:
          type: string
          example: "integer"
        constraints:
          type: array
          items:
            type: string
          example: ["NOT NULL", "PRIMARY KEY", "UNIQUE"]

structureHash

The PR that added this feature is https://github.com/tablelandnetwork/go-tableland/pull/208, maybe @brunocalza  will remember if someone was wanting this.

I think the table meta data endpoint should only require the chain ID and the table ID, not the table's name. This is how the current validator works, and I think it makes sense. The prefix isn't easy to get from the smart contract.
So
/tables/chain/{chain}/table/{tableId}

Or something like that.
@andrewxhill has thoughts on how we should manage the prefix in the future. For now, it seems to me expecting the prefix in the API call to find out information about the table isn't necessary or ideal.

Ok, so then I'm in favor of removing it and, potentially in the future, optimizing our API to support discovery in a more targeted way. For instance, I imagine we'll see things like table staking, and things like that that might drive discovery. Additionally, sharing schemas and things as packages seems more useful than searching via hashes. I don't want to make a final call here, but I think we should strongly consider dropping that API as well.
cc @joewagner because I think he has actually done some things with that API?

Ok, aside from that last comment about potentially dropping the hashStructure API and perhaps not requiring the full table name in APIs in favor of just the chainId and tableId, I am going to consider this issue "closed" for further discussion. The proposal is going to move forward as described in the above drafts. It is now available in this draft PR: https://github.com/tablelandnetwork/docs/pull/39. Further changes and discussions should probably happen there. Once that PR is merged, this issue will be fully resolved.

I'm ok dropping the /chain/${chainId}/tables/structure/${hash} endpoint.  cc: @awmuncy is this something you are using in the dashboard?

Nope, I am not using the structured hash for anything.

To try closing the remaining topic of discussion:

I think the table meta data endpoint should only require the chain ID and the table ID, not the table's name. This is how the current validator works, and I think it makes sense. The prefix isn't easy to get from the smart contract.

Does anyone have a strong argument against @awmuncy  proposal change?

Plus one to the endpoint taking chain ID and table ID, and NOT the full table name.

Seems fine to me to drop the prefix. In that case, we should avoid using it in any of the APIs.

Taking a close look at all this finally...
Seems that TxnReceipt should have an optional error field in case the txn errored.
For tables/structure/{hash}, I assume that if you don't provide a chainId, then all chains are searched and all results returned? If so, I think it would make more sense to have the chain id filter support a list of chain ids and be called chainIds.
Otherwise, looking really good! I love the simplicity.

I think we are going to drop tables/structure/{hash} anyway, so that part is probably not needed, though a similar argument would apply to listing tables. But you are right about TxnReceipt.

Yeah, TxnReceipt is incomplete; it should be the same as today:
// TxnReceipt is a Tableland event processing receipt.
type TxnReceipt struct {
	ChainID     int64  `json:"chain_id"`
	TxnHash     string `json:"txn_hash"`
	BlockNumber int64  `json:"block_number"`

	TableID       *string `json:"table_id,omitempty"`
	Error         string  `json:"error"`
	ErrorEventIdx int     `json:"error_event_idx"`
}

// GetReceiptResponse is a GetTxnReceipt response.
type GetReceiptResponse struct {
	Ok      bool        `json:"ok"`
	Receipt *TxnReceipt `json:"receipt,omitempty"`
}

To keep the ball moving...I see it's missing:

Error
ErrorEventIdx
And we should decide what to do with the Ok case. Ok is false today if the receipt doesn't exist. We can return a particular status code instead of using an Ok field. Maybe 404.

Open to comments.

Yeh let's leverage status codes for this case of the receipt not being found. That makes sense semantically.


advanced scheduling proposal

What this PR does / why we need it:
This PR adds a proposal for an advanced scheduling concept for Landscaper Deployments to target clusters.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

NONE

I like the first approach. Even if this is a little bit more complex, it is much more flexible.


Make NAT proxy mode work with wildcards listen addresses

On a server/host with a static IP, I would use a mapping like follows for a proxy:
  eth0:
    ipv4.address: <IP_ADDRESS>
    ipv6.address: fd42:775d:eec4:b58a:216:3eff:fe80:46d7
    nictype: bridged
    parent: lxdbr0
    type: nic
  proxy-http-ipv4:
    connect: tcp:<IP_ADDRESS>:80
    listen: tcp:<IP_ADDRESS>:80
    nat: "true"
    type: proxy
  proxy-http-ipv6:
    connect: tcp:[fd42:775d:eec4:b58a:216:3eff:fe80:46d7]:80
    listen: tcp:[2405:6580:3240:0:e054:650f:561a:8]:80
    nat: "true"
    type: proxy

With it, I can do these from external, and they will be passed to a container:
curl -v <IP_ADDRESS>
curl -v [2405:6580:3240:0:e054:650f:561a:8]

However, what if host's external IP may change from time to time? How to specify a "catchall IP" (or, any IP on a given interface)?
I've tried using:
    listen: tcp:<IP_ADDRESS>:80

    listen: tcp:[::]:80

but then, these don't pass the traffic to the container. Using lxd 4.0.

Seems that "<IP_ADDRESS>" or "::" only work if we don't set "nat: true".

@tomponline feels like we should be able to support that and probably validate things better.

If connect= is IPv4, then bind= needs to be IPv4, same for IPv6
If wildcard, then apply a NAT rule without a destination filter

What do you think?

@stgraber so right now we add DNAT rules like so:
Chain PREROUTING (policy ACCEPT 18 packets, 3139 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>              tcp dpt:81 /* generated for LXD container test_c1 (http-proxy) */ to:<IP_ADDRESS>:80

Chain OUTPUT (policy ACCEPT 208 packets, 15260 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>              tcp dpt:81 /* generated for LXD container test_c1 (http-proxy) */ to:<IP_ADDRESS>:80

If we removed the destination filter and changed it to "any", then my concern is that we would end up DNATing all output traffic to the proxy's listen port (in this case 81) from the LXD host, and similarly all traffic being routed through the LXD host to port 81 would also get DNATed to the instance.
This is because the packets are not arriving at the INPUT chain like the non-NAT proxy mode, which allows it to just bind to <IP_ADDRESS>. Which means we cant differentiate between packets destined for addresses on the LXD host vs traffic being forwarded through.
We could periodically poll the LXD host's addresses and modify the firewall rules perhaps?
If not perhaps we should just validate this and prevent it from being setup instead?

It seems this was closed as 'wonfix'? Is there a best practice for cases where there may be multiple IPs, floating IPs or dynamic IPs? Since lxd recognizes all host networks, would it be feasible to implement this using PREROUTING -i  instead? Or, simply trust admins and allow them to make configuration mistakes such as catching <IP_ADDRESS>/0 on a router?

The problem isn't with getting traffic from IPs you didn't think about, we're fine with giving users the ability to shoot themselves in the foot. Instead the issue is that LXD also generates hairpin rules so containers can hit their own or other proxy devices and to do so properly we need to know the address and can't use wildcard.

-i ! interface might work there, since we know the hairpin interface?

or, turning it around, giving the hairpin rule the interface flag

Nope, we tried :)
Other than matching on very specific interfaces, the alternative is to go down the packet marking route, which is problematic as we don't know what marks may be in use on the system.


Allcoredocs

Looking at Query/* docs is lower priority as @anpete wrote them and I reviewed them.
I think the ones that need review the most are

DbContextOptionsBuilder
WarningBehavior
WarningsConfigurationBuilder

:shipit:


Java errors in 6.10.4

since I Migrate to 6.10.4 i get these errors. I deleted deployment folder but that doesn't help.
compile:
[javac] Compiling 141 source files to C:\Users\Jan\Documents\Mendix\HTRT-main_3\deployment\run\bin
[javac] C:\Users\Jan\Documents\Mendix\HTRT-main_3\javasource\projects\proxies\DropElement.java:157: error: cannot find symbol
[javac] 	public final machines.proxies.Element getDropElement_Elements() throws com.mendix.core.CoreException
[javac] 	                             ^
[javac]   symbol:   class Element
[javac]   location: package machines.proxies
[javac] C:\Users\Jan\Documents\Mendix\HTRT-main_3\javasource\projects\proxies\DropElement.java:166: error: cannot find symbol
[javac] 	public final machines.proxies.Element getDropElement_Elements(com.mendix.systemwideinterfaces.core.IContext context) throws com.mendix.core.CoreException
[javac] 	                             ^
[javac]   symbol:   class Element
[javac]   location: package machines.proxies
[javac] C:\Users\Jan\Documents\Mendix\HTRT-main_3\javasource\projects\proxies\DropElement.java:179: error: cannot find symbol
[javac] 	public final void setDropElement_Elements(machines.proxies.Element dropelement_elements)
[javac] 	                                                          ^
[javac]   symbol:   class Element
[javac]   location: package machines.proxies
[javac] C:\Users\Jan\Documents\Mendix\HTRT-main_3\javasource\projects\proxies\DropElement.java:189: error: cannot find symbol
[javac] 	public final void setDropElement_Elements(com.mendix.systemwideinterfaces.core.IContext context, machines.proxies.Element dropelement_elements)
[javac]

sorry close was not close page

Hi, I originally created this widget when working for Synobsys. I recently started migrating the widgets to 6.10.2 with a test in Mendix 7. Could you try the version distributed by ITvisors?

https://appstore.home.mendix.com/link/app/36773/Itvisors/Drag-and-drop-support-widget

Thx. I will try.

Same errors. I deleted the widget from my project and deleted the javasource but still problems.
I think getDropElement made me think it is something with the widget.
machines.proxies.Element getDropElement_Elements() throws com.mendix.core.CoreException
[javac] 	                             ^
[javac]   symbol:   class Element
[javac]   location: package machines.proxies

It complains about a class Element which appears to exist in module Machines. Did you create or import a module Machines? If the module got deleted or renamed, the javasource was probably left behind.


Is this redshift compatible?

To be honest, I don't know. I've never seen a RedShift generated query plan.

Hey @AlexTatiyants awesome work.
This is an example Redshift query plan. Any tips on how I can make this work with Pev? Would really appreciate any help.
XN HashAggregate  (cost=306291059252.90..306291059253.09 rows=77 width=1246)
  ->  XN Hash Join DS_BCAST_INNER  (cost=215253136895.51..306291059250.40 rows=77 width=1246)
        Hash Cond: (("outer".site_uv_id)::text = ("inner".site_uv_id)::text)
        Join Filter: (("outer".dw_start_ts <= date_add('s'::text, 30::bigint, "inner".conv_dt)) AND ("outer".dw_start_ts >= date_add('s'::text, -30::bigint, "inner".conv_dt)) AND ("outer".dw_eff_dt <= (date("inner".winner_event_dt) + 6)) AND ("outer".dw_eff_dt >= date("inner".winner_event_dt)))
        ->  XN Hash Left Join DS_BCAST_INNER  (cost=180145614607.30..191269408227.25 rows=26611299 width=59)
              Hash Cond: ("outer".dw_ref_sk = ("inner".dw_ref_sk)::bigint)
              ->  XN Hash Left Join DS_DIST_ALL_NONE  (cost=180145613455.87..180215136926.55 rows=26611299 width=67)
                    Hash Cond: ((lower(btrim(("outer".utm_medium_cd)::text)) = ("inner".channel_short_cd)::text) AND (("outer".vendor_nm)::text = ("inner".vendor_nm)::text))
                    ->  XN Hash Left Join DS_DIST_ALL_NONE  (cost=180145613454.36..180203290428.91 rows=26611299 width=82)
                          Hash Cond: (lower(btrim(("outer".utm_source_tx)::text)) = ("inner".vendor_short_cd)::text)
                          ->  XN Hash Left Join DS_DIST_ALL_NONE  (cost=180145613453.80..180202365685.70 rows=26611299 width=75)
                                Hash Cond: (("outer".dw_ad_id)::text = ("inner".dw_ad_id)::text)
                                ->  XN Hash Left Join DS_DIST_ALL_NONE  (cost=180145609418.03..180202013537.89 rows=26611299 width=119)
                                      Hash Cond: (("outer".dw_campaign_id)::character(40) = "inner".dw_campaign_id)
                                      ->  XN Hash Right Join DS_DIST_NONE  (cost=180145609366.56..180201148619.20 rows=26611299 width=163)
                                            Hash Cond: (("outer".dw_session_id)::text = ("inner".dw_session_id)::text)
                                            ->  XN Seq Scan on mktg_mta_f ss  (cost=0.00..2426349.00 rows=194107920 width=114)
                                                  Filter: (dw_attr_model_id = 101)
                                            ->  XN Hash  (cost=180145542838.31..180145542838.31 rows=26611299 width=75)
                                                  ->  XN Hash Join DS_BCAST_INNER  (cost=58136.13..180145542838.31 rows=26611299 width=75)
                                                        Hash Cond: ("outer".dw_user_agent_id = ("inner".dw_user_agent_id)::bigint)
                                                        ->  XN Hash Join DS_DIST_ALL_NONE  (cost=35621.22..25375456.18 rows=26611299 width=83)
                                                              Hash Cond: ("outer".first_dw_page_sk = "inner".dw_page_sk)
                                                              Join Filter: (("inner".dw_eff_dt <= "outer".dw_eff_dt) AND ("inner".dw_expr_dt >= "outer".dw_eff_dt))
                                                              ->  XN Hash Join DS_DIST_ALL_NONE  (cost=17810.61..18924228.04 rows=66844524 width=91)
                                                                    Hash Cond: ("outer".last_dw_page_sk = "inner".dw_page_sk)
                                                                    Join Filter: (("inner".dw_eff_dt <= "outer".dw_eff_dt) AND ("inner".dw_expr_dt >= "outer".dw_eff_dt))
                                                                    ->  XN Seq Scan on dw_session_event_f a  (cost=0.00..2746411.78 rows=167905764 width=99)
                                                                          Filter: ((dw_eff_dt >= '2015-01-01'::date) AND (dw_suspected_bot_in = false))
                                                                    ->  XN Hash  (cost=14248.49..14248.49 rows=1424849 width=16)
                                                                          ->  XN Seq Scan on dw_page_detail_d b2  (cost=0.00..14248.49 rows=1424849 width=16)
                                                              ->  XN Hash  (cost=14248.49..14248.49 rows=1424849 width=16)
                                                                    ->  XN Seq Scan on dw_page_detail_d b  (cost=0.00..14248.49 rows=1424849 width=16)
                                                        ->  XN Hash  (cost=18762.42..18762.42 rows=1500994 width=4)
                                                              ->  XN Seq Scan on user_agent_d c  (cost=0.00..18762.42 rows=1500994 width=4)
                                                                    Filter: (curr_in = 1)
                                      ->  XN Hash  (cost=41.18..41.18 rows=4118 width=44)
                                            ->  XN Seq Scan on mktg_campaign_lnk_d cmpgn  (cost=0.00..41.18 rows=4118 width=44)
                                ->  XN Hash  (cost=3228.61..3228.61 rows=322861 width=44)
                                      ->  XN Seq Scan on mktg_ad_lnk_d ad  (cost=0.00..3228.61 rows=322861 width=44)
                          ->  XN Hash  (cost=0.45..0.45 rows=45 width=18)
                                ->  XN Seq Scan on ba_mktg_vdnr_xref src  (cost=0.00..0.45 rows=45 width=18)
                    ->  XN Hash  (cost=1.01..1.01 rows=101 width=16)
                          ->  XN Seq Scan on ba_mktg_ch_xref md  (cost=0.00..1.01 rows=101 width=16)
              ->  XN Hash  (cost=921.14..921.14 rows=92114 width=4)
                    ->  XN Seq Scan on dw_referral_d r  (cost=0.00..921.14 rows=92114 width=4)
        ->  XN Hash  (cost=35107522272.23..35107522272.23 rows=6390 width=1215)
              ->  XN Hash Left Join DS_DIST_OUTER  (cost=1884.00..35107522272.23 rows=6390 width=1215)
                    Outer Dist Key: "outer".winner_entity_id
                    Hash Cond: ("outer".winner_entity_id = "inner".ad_id)
                    ->  XN Hash Left Join DS_BCAST_INNER  (cost=1315.50..26644321561.71 rows=6390 width=1184)
                          Hash Cond: (("outer".event_type_id)::integer = "inner".event_type_id)
                          ->  XN Hash Right Join DS_DIST_BOTH  (cost=1315.41..26642081419.59 rows=6390 width=1169)
                                Outer Dist Key: p.plcmt_id
                                Inner Dist Key: c.plcmt_id
                                Hash Cond: ("outer".plcmt_id = "inner".plcmt_id)
                                ->  XN Subquery Scan p  (cost=942.92..1172.51 rows=22959 width=1036)
                                      ->  XN HashAggregate  (cost=942.92..942.92 rows=22959 width=111)
                                            ->  XN Seq Scan on mktg_sizmek_plcmt_d  (cost=0.00..659.91 rows=37734 width=111)
                                                  Filter: (curr_in = 1)
                                ->  XN Hash  (cost=372.35..372.35 rows=57 width=141)
                                      ->  XN Seq Scan on mktg_sizmek_conv_f c  (cost=0.00..372.35 rows=57 width=141)
                                            Filter: ((dw_eff_dt >= '2017-03-21'::date) AND (dw_eff_dt <= '2017-03-27'::date) AND (date(winner_event_dt) >= '2016-12-20'::date) AND ('2017-03-27'::date >= date(winner_event_dt)) AND (conv_tag_id = 918404) AND ((site_uv_id)::text <> ''::text))
                          ->  XN Hash  (cost=0.07..0.07 rows=7 width=21)
                                ->  XN Seq Scan on mktg_sizmek_event_type_d e  (cost=0.00..0.07 rows=7 width=21)
                    ->  XN Hash  (cost=454.80..454.80 rows=45480 width=35)
                          ->  XN Seq Scan on mktg_sizmek_ad_d ad  (cost=0.00..454.80 rows=45480 width=35)

hi @snagireddy91, handling this would probably require modifications to the Plan service, though I am curious what happens if you give a JSON version of this to pev as is.

@AlexTatiyants can you recommend any tools for converting query plans to JSON (redshift or otherwise)?
Redshift doesn't support exporting plans as JSON and I don't know enough to translate a plan like @snagireddy91's above into JSON by hand.

Unfortunately, I’m not aware of any tools that do this.
On July 23, 2017 at 9:34:56 PM, Shahid Chohan<EMAIL_ADDRESS>wrote:
@AlexTatiyants https://github.com/alextatiyants can you recommend any
tools for converting query plans to JSON (redshift or otherwise)?
Redshift doesn't support exporting plans as JSON and I don't know enough to
translate a plan like @snagireddy91 https://github.com/snagireddy91's
above into JSON by hand.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AlexTatiyants/pev/issues/21#issuecomment-317317181,
or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAvQnkCJ-dAlkF-r9ZQAQCaixhuBeQbKks5sRB7ugaJpZM4KLYOA
.


Art

Nothing new, just making the existing code better.

/cc @AsaAyers @k2b6s9j

Looks perfectly fine for me, I will make same changes for linter-eslint (use of fat arrow instead of .bind)

Looking good.

Great.


Problem parse.py

Hey. I'm trying to make out akaso v50 elite. There is a problem with disassembling folders A and B. Your parse.py does not work correctly.

Hey there!
I have never touched an Akaso v50 Elite but I am sure most of info here is still relevant for it. Right now the parse.py script only decompresses and parses the SST or SFN files extracted from the A and B fat images. If you actually want to extract the A and B partitions you need to use the carve.py script, then mount the fat files and copy the contents.
I have added a quick guide on how you could modify the files on the A and B partitions:
https://github.com/Linouth/iCatch-V50-Playground/tree/master/reversing#modifying-the-partitions
If there is anything you get stuck on or that is not clear, just let me know.

hello.
I'm just getting involved in this issue to ask for information about the project.
I'll start by saying that I'm interested in analyzing the firmware of a minicam (MateCamX9) that uses a SPCA6500 chip. I wanted to investigate with IDA Pro or Ghidra starting from the MateCam-X9.BRN firmware update file.
I quickly read this repository and I've already found some interesting info!
But I wanted to ask to start with, in IDA or Ghidra what type of processor was selected to start the firmware analysis.
That's all.
Thank you very much and have a nice day.


updated incentive

Correction in incentive

changes made:
1.(contract/ModelRepository.sol) incentive calculation is not accurate because it is calculating the incentive without considering 'Model.targetError'. Its assumes the targetError =0.  Added incentiveCalculations() which considers the 'targetValue'  to derive  correct incentive.
2.(test/modelrepository.js) edited: targetValue, where targetValue < initialValue
3. (test/TestModelRepository) added: unit test for incentive calculations

Changes made on files mentioned above. Please check it. Thank you.


⚠ Bofrost.de has degraded performance

In 3438d67, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1832 ms

Resolved: Bofrost.de performance has improved in a642f15 after 8 minutes.


GF Sad Animation

Describe your problem here.
I want when the player misses a note, the gf will do the animation crying. If someone could help me I would really appreciate it
Are you modding a build from source or with Lua?
Source
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
No response

I've literally never done lua before, but by looking through the wiki I think something like this might work
function noteMiss()
    characterPlayAnim("gf", "sad", true);
end

I've literally never done lua before, but by looking through the wiki I think something like this might work
function noteMiss()
    characterPlayAnim("gf", "sad", true);
end

or if using source code, just add:
if (gf != null) gf.playAnim("sad", true);

to the noteMiss function

In the source code, in which file do I need to put that???

I've literally never done lua before, but by looking through the wiki I think something like this might work
function noteMiss()
    characterPlayAnim("gf", "sad", true);
end

or if using source code, just add:
if (gf != null) gf.playAnim("sad", true);

to the noteMiss function

In the source code, in which file do I need to put that???

I'd assume in Playstate.hx

I've literally never done lua before, but by looking through the wiki I think something like this might work
function noteMiss()
    characterPlayAnim("gf", "sad", true);
end

or if using source code, just add:
if (gf != null) gf.playAnim("sad", true);

to the noteMiss function

In the source code, in which file do I need to put that???

PlayState.hx

Oki let me check

I've literally never done lua before, but by looking through the wiki I think something like this might work
function noteMiss()
    characterPlayAnim("gf", "sad", true);
end

I've literally never done lua before, but by looking through the wiki I think something like this might work
function noteMiss()
    characterPlayAnim("gf", "sad", true);
end

or if using source code, just add:
if (gf != null) gf.playAnim("sad", true);

to the noteMiss function

In the source code, in which file do I need to put that???

PlayState.hx

Thank you so much. Now I can continue with my mod. TYSM ❤❤

ur welcome


Versioned docker images

Could you maybe tag a versioned docker image?
This image is really great and works well but I don't really like relying on "latest" tags in production :)

Yes, good idea, I will think about it some bit later.

@kvaps Any progress with this issue ? I can help with this. Versioning really helps when using this in production. I like this image a lot, but not able to use in production, because of the versions not available.

@Dineshs91 This is the case in the new version of this project: https://github.com/vdhpieter/docker-letsencrypt-webroot currently at v1.0.0 😄Let me know if I can help with anything else!


Combined registration prevents office phone extensions

Added to note indicating that office phone will not allow extensions if the user is a part of combined registration.

@dakoer : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


Fix generated IL for the DynamicInvoke thunk

Since the HelperParamRef/In intrinsics are currently faked as being
member methods of the delegate itself (they have ByRef return values and
can't be expressed as a C# method we could put [Intrinsic] on), they
need to be instantiated as open before being called from the referenced
code. RyuJIT apparently doesn't care, but CppCodeGen is more sensitive.
(Boy I'm glad I spent time improving the IL disassembly -
troubleshooting this was a breeze.)

This is blocking the NMirror -> Master FI.


[FLINK-13213][table-api] Keep MinIdleStateRetentionTime/MaxIdleStateRetentionTime in TableConfig after call toAppendStream/toRetractStream without QueryConfig parameters

What is the purpose of the change
Fix a minor problem which is referred in https://issues.apache.org/jira/browse/FLINK-13213
Brief change log

Update toAppendStream and toRetractStream in StreamTableEnvironmentImpl

Verifying this change
Update on an existed testcases.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

LGTM. cc @dawidwys, please help to take a look if you have time.


[Feature Request] Skins without humanoid type rig

Add the ability to replace the player’s model with any model, no matter whether it has a rig or not. It’s better to just replace the model with a prefab so there will be more opportunities for customization.

That was how we originally did it, but so many people had trouble with mapping their generic rig that it was explicitly suggested that we map bones using the humanoid avatar instead.
This method has been so much more successful in every way than the generic method that there is absolutely no reason to go back.
People have managed to import generic rigs to begin with in the past simply by having a humanoid skeleton, and then using that skeleton to drive their model's rig, put in some work and you should be able to achieve what ever it is you're interested in.


xcode15 with react-native 0.70.6

Description
When executing the "yarn install" command in React Native version 0.70.6 with Xcode 15, issues may arise due to variables in the node_modules directory having IPHONEOS_DEPLOYMENT_TARGET set to 11.0. This becomes problematic as Xcode 15 requires a minimum version of 12.0 or higher.
Despite setting the target to 12.4 in the Xcode project, this change may not be reflected in the dependencies within the "ios" directory of the Pods.
React Native Version
0.70.6
Output of npx react-native info
Node: 16.18.0 - /var/folders/0j/cs58wbzn787d4y_ny2g5fp7h0000gn/T/yarn--1696337667133-0.11308239162388678/node
Yarn: 1.22.18 - /var/folders/0j/cs58wbzn787d4y_ny2g5fp7h0000gn/T/yarn--1696337667133-0.11308239162388678/yarn
npm: 8.19.2 - /usr/local/bin/npm
Watchman: 2<IP_ADDRESS> - /usr/local/bin/watchman
Managers:
CocoaPods: 1.12.1 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 23.0, iOS 17.0, macOS 14.0, tvOS 17.0, watchOS 10.0
Android SDK: Not Found
IDEs:
Android Studio: 2022.2 AI-222.4459.24.2221.9971841
Xcode: 15.0/15A240d - /usr/bin/xcodebuild
Languages:
Java: 11.0.19 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 18.1.0 => 18.1.0
react-native: 0.70.6 => 0.70.6
react-native-macos: Not Found
Steps to reproduce
Looks like you're trying to set up and run a React Native project. Let's break down the steps in English:

Navigate to the root directory of your React Native project:
cd root/

Install project dependencies using Yarn:
yarn install

Change to the "ios" directory and install CocoaPods dependencies:
cd ios && pod install && cd ..

Make sure you have CocoaPods installed (gem install cocoapods) if you haven't already.

Once the dependencies are installed, go back to the project root:
cd ..

Run the project on an iOS simulator or device:
yarn ios

If you encounter any specific errors during these steps, please provide more details about the error messages or issues you're facing. I'm here to help troubleshoot!
Snack, screenshot, or link to a repository
I created a patch for temporary
yarn react-native react-native0.70.6
diff --git a/node_modules/react-native/scripts/cocoapods/codegen_utils.rb b/node_modules/react-native/scripts/cocoapods/codegen_utils.rb
index 406e993..9efc9c8 100644
--- a/node_modules/react-native/scripts/cocoapods/codegen_utils.rb
+++ b/node_modules/react-native/scripts/cocoapods/codegen_utils.rb
@@ -84,7 +84,7 @@ class CodegenUtils
'source' => { :git => '' },
'header_mappings_dir' => './',
'platforms' => {

       'ios' => '11.0',

       'ios' => '12.4',
     },
     'source_files' => "**/*.{h,mm,cpp}",
     'pod_target_xcconfig' => { "HEADER_SEARCH_PATHS" =>

diff --git a/node_modules/react-native/sdks/hermes/hermes-engine.podspec b/node_modules/react-native/sdks/hermes/hermes-engine.podspec
new file mode 100644
index 0000000..8d331e0
--- /dev/null
+++ b/node_modules/react-native/sdks/hermes/hermes-engine.podspec
@@ -0,0 +1,84 @@
+# Copyright (c) Meta Platforms, Inc. and affiliates.
+#
+# This source code is licensed under the MIT license found in the
+# LICENSE file in the root directory of this source tree.
+
+require "json"
+require "open3"
+
+# sdks/hermesc/osx-bin/ImportHermesc.cmake
+import_hermesc_file=File.join(dir, "..", "hermesc", "osx-bin", "ImportHermesc.cmake")
+
+# package.json
+package_file = File.join(dir, "..", "..", "package.json")
+package = JSON.parse(File.read(package_file))
+version = package['version']
+
+# We need to check the current git branch/remote to verify if
+# we're on a React Native release branch to actually build Hermes.
+currentbranch, err = Open3.capture3("git rev-parse --abbrev-ref HEAD")
+currentremote, err = Open3.capture3("git config --get remote.origin.url")
+
+source = {}
+git = "https://github.com/facebook/hermes.git"
+
+if ENV.has_key?('HERMES_ENGINE_TARBALL_PATH')

Pod::UI.puts '[Hermes] Using pre-built Hermes binaries from local path.' if Object.const_defined?("Pod::UI")
source[:http] = "file://#{ENV['HERMES_ENGINE_TARBALL_PATH']}"
+elsif version == '1000.0.0'
Pod::UI.puts '[Hermes] Hermes needs to be compiled, installing hermes-engine may take a while...'.yellow if Object.const_defined?("Pod::UI")
source[:git] = git
source[:commit] = git ls-remote https://github.com/facebook/hermes main | cut -f 1.strip
+elsif currentremote.strip.end_with?("facebook/react-native.git") and currentbranch.strip.end_with?("-stable")
Pod::UI.puts '[Hermes] Detected that you are on a React Native release branch, building Hermes from source...'.yellow if Object.const_defined?("Pod::UI")
hermestag_file = File.join(dir, "..", ".hermesversion")
hermestag = File.read(hermestag_file).strip
source[:git] = git
source[:tag] = hermestag
+else
source[:http] = "https://github.com/facebook/react-native/releases/download/v#{version}/hermes-runtime-darwin-v#{version}.tar.gz"
+end

+module HermesHelper

BUILD_TYPE = :debug

BUILD_TYPE = :release
+end

+Pod::Spec.new do |spec|

spec.name        = "hermes-engine"
spec.version     = version
spec.summary     = "Hermes is a small and lightweight JavaScript engine optimized for running React Native."
spec.description = "Hermes is a JavaScript engine optimized for fast start-up of React Native apps. It features ahead-of-time static optimization and compact bytecode."
spec.homepage    = "https://hermesengine.dev"
spec.license     = package["license"]
spec.author      = "Facebook"
spec.source      = source
spec.platforms   = { :osx => "10.13", :ios => "12.4" }

spec.preserve_paths      = ["destroot/bin/"].concat(HermesHelper::BUILD_TYPE == :debug ? ["**/.{h,c,cpp}"] : [])
spec.source_files        = "destroot/include/**/*.h"
spec.header_mappings_dir = "destroot/include"

spec.ios.vendored_frameworks = "destroot/Library/Frameworks/universal/hermes.xcframework"
spec.osx.vendored_frameworks = "destroot/Library/Frameworks/macosx/hermes.framework"

spec.xcconfig            = { "CLANG_CXX_LANGUAGE_STANDARD" => "c++17", "CLANG_CXX_LIBRARY" => "compiler-default", "GCC_PREPROCESSOR_DEFINITIONS" => "HERMES_ENABLE_DEBUGGER=1" }

if source[:git] then
spec.prepare_command = <<-EOS

 # When true, debug build will be used.

 # See `build-apple-framework.sh` for details

 DEBUG=#{HermesHelper::BUILD_TYPE == :debug}

 # Set HERMES_OVERRIDE_HERMESC_PATH if pre-built HermesC is available

 #{File.exist?(import_hermesc_file) ? "export HERMES_OVERRIDE_HERMESC_PATH=#{import_hermesc_file}" : ""}

 #{File.exist?(import_hermesc_file) ? "echo \"Overriding HermesC path...\"" : ""}

 # Build iOS framework

 ./utils/build-ios-framework.sh

 # Build Mac framework

 ./utils/build-mac-framework.sh

EOS
end
+end

Hello there! We already have the fixes landed in the 0.70 branch. The release crew is currently busy handling the RC.0 for 0.73. As soon as that's done, they will take care of releasing the older versions (0.72, 0.71, and 0.70)

We're running into the same issue with React native 0.71.6 and XCode 15. The OP description and details are on point. Looking forward to the fix in upcoming versions.

Hopefully, the fix for 0.70 will arrive early next week

@cortinico Hey, is there any news about the 0.70 fix?

@cipolleschi Hey, is there any news about the 0.70 fix?

@cipolleschi Hey, is there any news about the 0.70 fix?

@cipolleschi Hey, is there any news about the 0.70 fix?

@huntie @lunaleaps are working on the 0.70.x point release which will be out as soon as it's ready and stable

0.70.14 has been released yesterday! 🎉

@cipolleschi still facing the same issue with 0.71.14 version, any solutions?

Hi @akmal-k, sorry for the late reply, but I was off these days.
can you run, from <you_project>/ios folder:
bundle exec pod deintegrate
bundle exec pod install

and try again?

** BUILD FAILED **
The following build commands failed:
CompileC /Users/tanvi/Library/Developer/Xcode/DerivedData/AwesomeProject2-cmbpvdswagsgpdfyrbkfftlxllsa/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/RCT-Folly.build/Objects-normal/x86_64/json.o /Users/tanvi/Documents/ReactNative/AwesomeProject2/ios/Pods/RCT-Folly/folly/json.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'RCT-Folly' from project 'Pods')
(1 failure)
@cipolleschi This error shows up when react native version 0.71.4 is run on Xcode 15

@Yeasirarafat53 that message does not report any error.
The command you are reporting only tells me that file you are trying to build, but there isn't any cause of the failure. Please, follow the steps described here to highlight the actual error and report that.


ALM Toolkit not showing results of comparison

ALM Toolkit version 5.0.44 is not able to show the results of comparison between Power BI Desktop and Dataset in the service. It gives the message "ALM Toolkit - finished comparing datasets" but displays no visual way of confirming this. Can this be looked into please?

Hi, thanks for raising! I would need to create repro to debug it. Can you check the Options settings? It's possible that based on the settings, it's not picking up any diffs so it's showing a blank differences grid by design.

Hi Christian, thanks for getting back to me. I've just tried this again and just like magic, the visual comparisons are back up and running. Not sure how or why!

No worries. Glad you're unblocked!

No worries. Glad you're unblocked!


Copying doesn't copy to clipboard

When you right click > copy, you can paste it where you like. Simple. But if you want to copy a file and then paste it in e.g. Discord or any program, it won't paste because it didn't copy to Windows Clipboard (? i guess that's how it works).
This is related to the drag and drop being a bit wonky: You need to first properly click the file you want to drag and drop before you can actually drag and drop it. My suggestion, if you drag any file, selected or not, that file will be dragged. It's annoying to always having to select the file, because that is currently the only way to get a file "out of Files" into another program since copy won't do it

Could you provide some more info?

What version of the app are you using?
Does copying a file from Files app and paste it inside Files work?
Does copying a file from Files app and paste it to windows explorer work?

Could you provide some more info?

What version of the app are you using?
Does copying a file from Files app and paste it inside Files work?
Does copying a file from Files app and paste it to windows explorer work?

v<IP_ADDRESS>
Yes, copying and pasting within files works as expected.
Copying files from files > explorer works fine as well
However, when I copy a file and try to CTRL+V it into any other program, it won't work, it also doesn't show up in Win+V in case its an image

v<IP_ADDRESS>
Yes, copying and pasting within files works as expected.
Copying files from files > explorer works fine as well
However, when I copy a file and try to CTRL+V it into any other program, it won't work, it also doesn't show up in Win+V in case its an image

@ToothyDev Is this still an issue in v1.5?


WebUI release process

Description
Setup CI workflows for releasing the WebUI. This issue spans across this repo, rucio/containers
Motivation
No response
Change
No response
Additional Information

[ ] The Rucio API needs to be changed.

See https://github.com/rucio/containers/pull/230


where i can read the full of all method documentation for this library?

Thanks for stopping by to let us know something could be better!
PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Hi @BachtiarAH
We do not currently provide reference documentation for this library. The best way to see the method documentation is to browse the code. Note this line in the README:

it will be very difficult to use this library without first understanding the JSON syntax for the API, so it is recommended to look at the APIs Explorer before using any of the services here.

Thank you for your suggestion, we'll look into adding reference documentation as well


chore(main): release 0.6.0

:robot: I have created a release beep boop
0.6.0 (2023-04-04)
Features

cli: build a nice cli interface for composerize-ts (907e681)

Bug Fixes

options: correct long-opt value detach/d (0c8140f)
parser: don't use errors but more messages to make parsing of partly incorrect cmds possible (c126ec5)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/cgoIT/composerize-ts/releases/tag/v0.6.0 :sunflower:


Updated readme github buttons

Added a 'open in cloudshell' feature into the Readme

please test this

please test this


du - time 0.1 is outdated

as per https://deps.rs/repo/github/uutils/coreutils

I'll take this issue.
time 0.2 is a complete rewrite with an almost entirely different api, so I'm looking at just switching to the latest version of chrono.

Yeah, we are using time 0.1 in other places too (like ls, stat or install)
Would you be interested in doing the same?
thanks


Server panics when operating in multi-instance mode

Bug report
When running the server under multi-tenancy using gotrue multi all requests to the server fail with a nil reference panic. This is most likely occurring here:
https://github.com/supabase/gotrue/blob/8689fd206f2c5d678880c2254ddf85b53fa22485/api/middleware.go#L97-L101
The panic is triggered because in this case, config is always null because the withInstanceConfig method (which updates the config) isn't called until the end of the function here:
https://github.com/supabase/gotrue/blob/8689fd206f2c5d678880c2254ddf85b53fa22485/api/middleware.go#L137
This is kind of a chicken or egg problem in acquiring the instance specific JWT Token. In the Netlify version of the service, the operator token is used to verify the JWS, which is non-ideal since the my understanding is that he client is supposed to posses this token.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:

Run the server in multi-tenancy mode using: gotrue multi
Create an instance by sending a POST request to the /settings endpoint.
Send a request to the API using a signature in the x-nf-sign header with the following claims: { "site_url": "https://example.netlify.com", "netlify_id": "2c2db737-649f-4572-9740-e8691d57806a", "id": "db6a5e12-c314-4b6b-8f35-d87709cdf32c" }
The server will now panic when the config variable (which is always nil) is accessed.

Expected behavior
The API should respond without a panic when the request is called.
System information

OS: Ubuntu
Server: supabase/gotrue v2.6.30

Additional context
It seems the issue was introduced in https://github.com/supabase/gotrue/pull/124 (commit: https://github.com/supabase/gotrue/commit/0574ddcb7651232ed68cb1144c3b788636e4cd0e)
Potential Solutions
One approach could be to use the unverified signature to lookup the instance configuration (and the instance specific JWT Secret) and using that to verify the signature. Another option could be to require that users provide the instance id in the header.
I think at the minimum, this error should be handled correctly and the behavior documented.
I tried both these solutions locally and am happy to send a PR to address this if you could provide some guidance on what the expected behavior here would be.

Hey @pratheekrebala,
We have unfortunately decided to deprecate the multi command together with references to instanceID for now.  We will review this decision again when we expand as a team.
Feel free to let us know if you have any further questions!


Lost account and Lost my ADA

I create new account and send some ADA to account address.
then cardano-sl is killed by system oom.   restart it, but I can't see my account.
I think  cardano-sl is auto restore wallet and default account or not save my new account.
I still have wallet key, how can I find my account and  ADA in this account?

@bigzhu Please use it for support: https://daedaluswallet.io/faq/#support


chore: refer to resource labels as attributes

Which problem is this PR solving?

Fixes #1416 (use OTEL_RESOURCE_ATTRIBUTES instead of OTEL_RESOURCE_LABELS)

Short description of the changes

Key value pairs describing a resource were originally called labels. The terminology in OTel has been updated to use attributes instead. In addition to updating the EnvDetector to use OTEL_RESOURCE_ATTRIBUTES instead of OTEL_RESOURCE_LABELS, this PR updates the rest of the codebase to consistently use attributes instead of labels for Resources.

/cc @markwolff since your new packages will need to incorporate these changes

confirm. I'll resolve the conflicts

Conventional Commits requires that a ! be appended to the commit type or a footer BREAKING CHANGE be added to breaking change commit messages. I have renamed the PR to include the !


cmake: Set memusage property for lld

lld gained support for the --print-memory-usage flag somewhat recently (May 2023). Associate this flag with the memusage property when building with lld, similar to what is done for GNU ld.

What version is that in? Distros have llvm version 16 so if this is not present in that version that it's too new to assume will be present

this why check_set_linker_property() is used, to ensure this property is only set if linker supports it:

In case it is still helpful, lld's support for --print-memory-usage was added here: https://github.com/llvm/llvm-project/commit/811cbfc26233587f01f1b7b8cdeb8200747c366a. So, I think 17.0 is the first release that supports it.
I was also a bit unsure about this initially, so I did test with an LLVM 16 build as well as a tip LLVM build and everything seemed to work as expected (not set for LLVM 16, set for tip LLVM which supports the flag)!
Thanks everyone for looking over this!


Express: Cleaning up and packaging.

I'm working on a round of cleaning up and package management stuff for the express server now that I think it's to sort of an alpha usability level.  I'm making it available for global install, and i'm thinking about the best way to publish it to the npm repository, which means I new two new single word names.  I'd like to propose sfw-noded for the command that goes in path, and sfwiki for the npm/node require name.  This would mean that the entire process of getting a server up and running on a computer with node installed would be two commands:
npm install -g sfwiki
sfw-noded
Is this something we want to do?  If so I've got to solve the problem that npm expects the package.json to be at the top level of the thing to be installed, which doesn't lend itself well to how we are organized.  One possible way to solve that is by using symbolic links out from the servers to all of the shared files they include.  I believe git supports this, but it may be a problem for developers on old (widows xp?) platforms.  The git repo would stay organized in the same way, but the servers would access the files as if they were inside their own server/servername folder, so any server could be packaged up as it's own thing with the client for deployment.

I'm feeling like Smallest Federated Wiki and SWF are working names. I'd like to reserve Federated Wiki, fed.wiki.org, and fedwiki as important names for the ongoing project.
How about we think through what we'd want the experience to be for a fresh install of fedwiki and not make that be a package until we can deliver on that experience. I'd like to make that be our first numbered version, maybe 0.1.0. Of course we'd want to be aligned with "semantic version numbers" but I'd have to refresh my memory on how they work.
Here are some things that have been in the back of my mind:

Usability traps that lose content have been fixed. (I'm working on this today.)
Sequence numbers in the journal actions. (Max Ogden says I need them based on his CouchDB experience.)
Default front page that makes sense to new user. (A fork of fed.wiki.org with links to help)
All tests green

Sounds like a good plan.


Rename pagination actions to match other table-related actions

Rename pagination actions to FetchXXXRequestAction, to match corresponding sort and request actions.

superseded by dx


Save setup configuration

A checkbox should show up in the setup dialog, and when selected, further opening the setup dialog will keep the same values, makes life a lot easier

This relies on #70


Subtree push with 1.77.0 nightly 2023-12-28

I figured I'd get another subtree push done in an effort to do them on a more regular basis.
r? @calebcartwright

@compiler-errors Thanks! I'm still not sure when we'll do the full subtree-sync with r-l/rust, but in an effort to make that process a little easier we're trying to do more regular subtree pushes.


Can I get help with the package documentation ?

Hello,
As I do some breaking changes to the package based on the changes and deprecation from the API, can I get some help reflecting those changes in the documentation in README.md and Dart code docs?
if you can't make the changes, please point it to me in a GitHub issue, it is appreciated.
Thank you!

Never mind, I will do it myself.


Add health-check to v10

v2018 has the functionality and it should be included in v10 as well.
https://github.com/ibm-apiconnect/v2018-postmortem/blob/master/generate_postmortem.sh#L292

The tool no longer relies on apiup tool.  Due to this change, unable to include health-check date.


Track open_shard timeouts with a counter

The open_shard RPC endpoint is used to grab security docs. There are
fairly aggressive timeouts on these requests so that when a node is too
busy it'll try the next shard. Rather than log everytime these fail
(which can be substantial under load) lets just use a counter that can
be graphed and alerted on.
COUCHDB-3234

+1


Unable to see post choices

I downloaded the final version of the package from Git, with Celery (also tried the version without Celery). I next ran "python manage.py db upgrade". I then tried to register a new user, and get a screen that just says:
Hello, neela!
All
Followers

«
»

I don't see any choices to post a blog.
My roles table in the database is empty.
I haven't changed any of the code from Git.
Would appreciate any thoughts on what I could do to get the code working.
Thank you.

This is explained in the book. There is a deploy step that creates user roles, which is what is missing. Try running python manage.py deploy and then create your user, so that it gets assigned the proper role. There's also the configuration, which you should review and edit as appropriate.

Thank you. This worked. I somehow overlooked it.


notification + social sharing footer styling

updated notification styling
footer social sharing links added

:100: :cake:


[Feature] [flink] Upgrade flink to 1.13.5

Purpose of this pull request

Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in you PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs

hi, it is best to attach your corresponding proposal

hi, it is best to attach your corresponding proposal
https://github.com/apache/incubator-seatunnel/discussions/1129

@chaozwn @CalvinKirs , why not directly update the Flink version to 1.14?

@chaozwn @CalvinKirs , why not directly upgrade the Flink version to 1.14?

https://lists.apache.org/thread/ml880ltvp1lbgtgcm9n5ynyw5kr6406y
There is the relevant context here, do you have any good suggestions?

hi @chaozwn, please rebase the dev branch.

long time no response, if you have an update please leave a comment and I'll reopen it.


这是什么意思

(cosyvoice) root@amax:/data/xyw23131036/cosyvoice/CosyVoice# PYTHONPATH=third_party/Matcha-TTS python api.py
2024-08-11 14:11:31,215 - modelscope - INFO - PyTorch version 2.0.1+cu118 Found.
2024-08-11 14:11:31,216 - modelscope - INFO - Loading ast index from /root/.cache/modelscope/ast_indexer
2024-08-11 14:11:31,245 - modelscope - INFO - Loading done! Current index file version is 1.15.0, with md5 4b288142160eff9dde432695529dc918 and a total number of 980 components indexed
failed to import ttsfrd, use WeTextProcessing instead
/opt/anaconda3/envs/cosyvoice/lib/python3.8/site-packages/torch/_jit_internal.py:726: FutureWarning: ignore(True) has been deprecated. TorchScript will now drop the function call on compilation. Use torch.jit.unused now. {}
warnings.warn(
/opt/anaconda3/envs/cosyvoice/lib/python3.8/site-packages/diffusers/models/lora.py:393: FutureWarning: LoRACompatibleLinear is deprecated and will be removed in version 1.0.0. Use of LoRACompatibleLinear is deprecated. Please switch to PEFT backend by installing PEFT: pip install peft.
deprecate("LoRACompatibleLinear", "1.0.0", deprecation_message)
2024-08-11 14:11:39.692424345 [W:onnxruntime:, session_state.cc:1162 VerifyEachNodeIsAssignedToAnEp] Some nodes were not assigned to the preferred execution providers which may or may not have an negative impact on performance. e.g. ORT explicitly assigns shape related ops to CPU to improve perf.
2024-08-11 14:11:39.692451160 [W:onnxruntime:, session_state.cc:1164 VerifyEachNodeIsAssignedToAnEp] Rerunning with verbose output on a non-minimal build will show node assignments.
2024-08-11 14:11:39,872 WETEXT INFO found existing fst: /opt/anaconda3/envs/cosyvoice/lib/python3.8/site-packages/tn/zh_tn_tagger.fst
INFO:wetext-zh_normalizer:found existing fst: /opt/anaconda3/envs/cosyvoice/lib/python3.8/site-packages/tn/zh_tn_tagger.fst
2024-08-11 14:11:39,872 WETEXT INFO                     /opt/anaconda3/envs/cosyvoice/lib/python3.8/site-packages/tn/zh_tn_verbalizer.fst
INFO:wetext-zh_normalizer:                    /opt/anaconda3/envs/cosyvoice/lib/python3.8/site-packages/tn/zh_tn_verbalizer.fst
2024-08-11 14:11:39,872 WETEXT INFO skip building fst for zh_normalizer ...
INFO:wetext-zh_normalizer:skip building fst for zh_normalizer ...
2024-08-11 14:11:40,199 WETEXT INFO found existing fst: /opt/anaconda3/envs/cosyvoice/lib/python3.8/site-packages/tn/en_tn_tagger.fst
INFO:wetext-en_normalizer:found existing fst: /opt/anaconda3/envs/cosyvoice/lib/python3.8/site-packages/tn/en_tn_tagger.fst
2024-08-11 14:11:40,199 WETEXT INFO                     /opt/anaconda3/envs/cosyvoice/lib/python3.8/site-packages/tn/en_tn_verbalizer.fst
INFO:wetext-en_normalizer:                    /opt/anaconda3/envs/cosyvoice/lib/python3.8/site-packages/tn/en_tn_verbalizer.fst
2024-08-11 14:11:40,199 WETEXT INFO skip building fst for en_normalizer ...
INFO:wetext-en_normalizer:skip building fst for en_normalizer ...
['中文女', '中文男', '日语男', '粤语女', '英文女', '英文男', '韩语女']
Traceback (most recent call last):
File "api.py", line 25, in
uvicorn.run(app,
NameError: name 'uvicorn' is not defined

fastapi.py is supported by community developers, you can ask such question in our dingding group


Release SSHNP new version with rv points

Is your feature request related to a problem? Please describe.

create sshrv rendezvous point

Removing the need for the use of ngrok

Add basic security to rv (ngrok has none)

Describe the solution you'd like
Bring new sshrv code into repo
Add basic secirity to sshrv
Extensive testing
Sign and publish 3.2.1
Describe alternatives you've considered
No response
Additional context
No response

Sshnp code in PR we just need the at_activate 2.0 to be working too!
And the managed by Atsign sshrvd poi ts up one per region..
Sshrv.AM
Sshrv.EU
Sshrv.AP
Working on both of these early this week.

Complete