docs: Add token doc to docs platform

Description
This PR adds the gas token documentation from the docs-draft folder into the knowledge layer docs.

fyi @leovct  a little surprised to see the CI fail here

fyi @leovct a little surprised to see the CI fail here

I tried to debug, it's a bit weird...
I had to revert to a quite old foundry version to be able to send the transaction...
$ foundryup
$ cast --version
cast 0.2.0 (63fff35 2024-04-22T00:25:29.695811000Z)
$ cast send --rpc-url "http://<IP_ADDRESS>:59288" --mnemonic "code code code code code code code code code code code quality" --value 0 "0x5b06837A43bdC3dD9F114558DAf4B26ed49842Ed"
Error:
deserialization error: invalid number at line 1 column 269

Context:
- invalid number at line 1 column 269

$ foundryup --version nightly-f625d0fa7c51e65b4bf1e8f7931cd1c6e2e285e9
$ cast --version
cast 0.2.0 (f625d0f 2024-04-02T00:16:42.803795000Z)
$ cast send --rpc-url "http://<IP_ADDRESS>:59288" --mnemonic "code code code code code code code code code code code quality" --value 0 "0x5b06837A43bdC3dD9F114558DAf4B26ed49842Ed"

blockHash               0x5e433d39745db064f8963e3f807f2ed25f2f900a757f94dfcf2f678a60cde3b4
blockNumber             652
contractAddress
cumulativeGasUsed       21000
effectiveGasPrice<PHONE_NUMBER>
from                    0x85dA99c8a7C2C95964c8EfD687E95E632Fc533D6
gasUsed                 21000
logs                    []
logsBloom               0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
root
status                  1
transactionHash         0xd26eca7fe814ea518ec1efcbd9f0c08136eec52af03ab8a8e4f79391ae560d8c
transactionIndex        0
type                    2
to                      0x5b06837A43bdC3dD9F114558DAf4B26ed49842Ed

But when I tried locally against a local anvil node, it worked well with the latest version...
$ anvil &
$ cast --version
cast 0.2.0 (63fff35 2024-04-22T00:25:29.695811000Z)
$ cast send --rpc-url "http://<IP_ADDRESS>:8545" --mnemonic "test test test test test test test test test test test junk" --value 0 "0x5b06837A43bdC3dD9F114558DAf4B26ed49842Ed"

blockHash               0x99312f72574c9240015bbb23b2c6776176437f22a38d0bf1bf6c2550045399b7
blockNumber             1
contractAddress
cumulativeGasUsed       21000
effectiveGasPrice<PHONE_NUMBER>
from                    0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266
gasUsed                 21000
logs                    []
logsBloom               0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
root
status                  1 (success)
transactionHash         0xaa76c3d54aaa876967564f39090ff53fa32a436575b7e5c5e247e23b1f7d4de8
transactionIndex        0
type                    2
blobGasPrice
blobGasUsed
to                      0x5b06837A43bdC3dD9F114558DAf4B26ed49842Ed
depositNonce             null


Change JSON format for data

In VISS 2 data is not in a simple item "value", but in a structure that allwos returning several data points
 "data": {
            "description": "Data including path and one or more data point(s).",
            "type": "object/array",
            "properties": {
                "path": {
                    "description": "The path to the desired vehicle signal(s), as defined by the metadata schema.",
                    "type": "string"
                },
                "dp": {
                    "description": "Data point including one or more value and time samp",
                    "type": "object/array"
                    "properties": {
                        "value": {
                            "description": "The value related to the associated path.",
                            "type": "string"
                        },
                        "ts": {
                            "description": "Timestamp associated with the value capture.",
                            "type": "string"
                        }
                }
            }
        },

See also https://raw.githack.com/w3c/automotive/gh-pages/spec/VISSv2_Core.html#multiple-signals-request

according to the specification, response should look like this:
“data”:{“path”:”X”, “dp”:{“value”:”Y”, “ts”:”Z”}}
or
“data”:{“path”:”X”, “dp”: [{“value”:”Y1”, “ts”:”Z1”}, …, {“value”:”Yn”, “ts”:”Zn”}]}
or
“data”:[{“path”:”X1”, “dp”:{“value”:”Y1”, “ts”:”Z1”}}, …, {“path”:”Xm”, “dp”:{“value”:”Ym”, “ts”:”Zm”}}]
or
“data”:[{“path”:”X1”, “dp”:[{“value”:”Y11”, “ts”:”Z11”}, …, {“value”:”Y1n”, “ts”:”Z1n”}]}, …]

@SebastianSchildt: do we really need description, type and properties?

I I do not quite get the question. Your examples are correct and they should all be in line with the JSON schema above. A single  object or an array of dp where value and ts are mandatory properties.
You can also test here: https://www.jsonschemavalidator.net  if you find a mismatch between schema and the examples I would consider this a bug in VSS


Document Traits

Document https://github.com/noir-lang/noir/pull/2368, which implemented traits.
UPDATE: Let's defer documentation of traits until https://github.com/noir-lang/noir/issues/2568 is implemented. @yordanmadzhunkov and his team would draft the documenting PR then.

@alexvitkov here's the issue that would be closed by the noir repo replication of this old docs PR

Documented in https://github.com/noir-lang/noir/pull/3783 and https://github.com/noir-lang/noir/pull/4000.


github: Add weekly pull request from Weblate translations.

Thanks, this looks promising! What does an example pull request look like? It appears that we have workflow_dispatch for manually creating one.

I don't have any way to test this except via creating one.  But the PR will be named "Update translations from Weblate" and will contain a single commit, which you can see the shape of by examining https://hosted.weblate.org/git/zulip/zulip-flutter/ yourself:

git add weblate https://hosted.weblate.org/git/zulip/zulip-flutter/
git show weblate/main

Thanks! This looks good to me. I'll merge and we can see how the PR it generates looks.


Added support for KnownType attributes that specify the name of a method

This is for issue #291.

Thanks for the PR


Clarify error handling expectations

In #15 a set of typical HTTP response codes was documented, however, in working on the PHP functions framework we have found there's a lot that remains undefined in how errors should be handled.
https://github.com/GoogleCloudPlatform/functions-framework-php/issues/60 demonstrates the only definition is triangulating against the behaviors of other functions frameworks, which include some behaviors in the name of backwards compatibility that are not intended as part of the functions framework specification.
Actual
Each language makes independent decisions around error handling, including:

Handling the X-Google-Status custom HTTP header
What error message is returned in the body of the response
Reliable use of error status codes in all edge cases
Generation of a stack trace/integration with Error Reporting

Expected
Functions frameworks provide a consistent experience in surfacing errors such as HTTP Functions and CloudEvent Functions present a language agnostic programming paradigm for service-to-service communications.

Handling X-Google-Status is more of an issue for the Runtimes team who should describe how this should behave across runtimes w.r.t. the supervisor.
In general, each language has a different server implementation that gives some variability. Nonetheless, given a more concrete list of possible errors, we could document the expected error message and status codes in this contract.
CC: @asriniva
Ref: https://github.com/GoogleCloudPlatform/functions-framework-python/pull/114
Ref: b/162521109

Specifically talking about the X-Google-Status header, this was added due to customer request for a similar user experience between GCF Python 3.7 and 3.8+. It's not officially stated in the functions framework contract, but a few of the runtimes provide this header (Node.js, Go, Python). There's no reason it can't be added to the other frameworks.

Assigning to @anniefu per request.

Unfortunately, the frameworks themselves are pretty scattered on HTTP code usage, and additionally underlying web frameworks in each language may be returning different codes for different cases. Due to that, it is difficult to establish any hard guidelines for errors at this point.
Function Errors
There are some enforced principles for the case when the user function itself errors that are important to maintain for privacy and security reasons:

Do not return user-created exception messages in the response body, log it instead
Do not return stack traces in the response body, log it instead
Return HTTP status code 500 if the user function itself errors

System Errors
For "system" errors coming from the Functions Framework or underlying HTTP frameworks, there are no hard guidelines, but this would be my recommendation:

Handling the X-Google-Status custom HTTP header

Not required, but the framework must follow the above guidelines for handing user function errors

What error message is returned in the body of the response

May be highly dependent on the language. Prefer detailed error messages, especially if the error is a user error that can is fixable. Only include system error information, do not include error messages from user function (log those instead).

Reliable use of error status codes in all edge cases

Use exactly 400 when the end user/client is deemed to be the issue (invalid event payload, function stub can't be loaded). Use exactly 500 when the framework is the issue and it's unlikely the end user will be able to fix it.
Prefer using the error message to differentiate error cases instead of the HTTP code.

Generation of a stack trace/integration with Error Reporting

Stack traces are not required, but can be very helpful. They should be logged instead of included in response bodies.


Pojavlauncher  crash

Crash on start
logs
latestlog.txt
Blackview Oscal C80
HolyGL4ES

Are you sure this issue was caused by Isometric Renders? Looking at the log neither it or its dependencies were loaded when the game crashed.
Looking a bit further it seems you are using JourneyMap for 1.20.4, which would be incompatible with 1.20.1

Can confirm, it looks like the error is with loading JourneyMap, and that it looks like you're using the wrong version of it for your minecraft version

now I tried download it again. In actions I found working on 1.20.5 version. But all builds for 1.20.4 are expired. What can I do, if I need 1.20.4?

You should just be able to use the existing 1.20.4 release: https://github.com/gliscowo/isometric-renders/releases/tag/0.4.7%2B1.20.3


CredentialProviderToken in accumulo-client.properties stores the serialized token which contains the password, exposing the password out of the JCEKS file

Describe the bug
Upgrading from 1.10.2 to 2.1.2. The accumulo-client.properties requires the auth.token to be a base64-encoded serialization of the Token class. I created a token for the CredentialProviderToken class using the create-token (which doesn't support CredentialProviderToken correctly in 2.1 btw, I'll elaborate on that later).
If someone has read access to that properties file, they can get the token and paste it into an online base64 decoder (that supports the ISO-8859-1 character set) in order to get the password. For CredentialProviderToken that defeats the purpose because it's supposed to be keeping the password "safe" (yes I know, not ideally safe) by keeping it inside the JCEKS.  Right now I believe it only works because it's deserializing the token, kind of bypassing the point of the CredentialProviderToken.
In fact, I just tested by commenting out the "general.security.credential.provider.paths" and it initialized just fine by deserializing the CredentialProviderToken, so I it doesn't look like it's treating CredentialProviderToken any differently than a Password token? I think the fix would be that when auth.type=CredentialProviderToken then the auth.token value should be the JCEKS alias name and then the token is initialized by calling the public CredentialProviderToken(String name, String credentialProviders)
Or if it must be a serialized instance of the token, then CredentialProviderToken should override the serialization method so that it doesn't return the password but rather the alias name ("name" field of the class).
Ideally I'd be able to continue using this authentication method, especially because it is still supported on the server side. It was actually kind of hard to find documentation about CredentialProviderToken in the context of accumulo-client.properties. Is it intended to still be supported? Or should I move away from accumulo-client.properties and just use the newClient fluent builder and regular java properties?
As for the create-token shell command: In this section of the source code for CreateToken.java, you can see that it attempts to run the token.init() within the loop on TokenProperties rather than outside the loop. CredentialProviderToken requires two properties, so this ends up throwing an exception because it was init too soon.
   for (TokenProperty tp : token.getProperties()) {
      String input;
      if (pass != null && tp.getKey().equals("password")) {
        input = pass;
      } else {
        if (tp.getMask()) {
          input = getConsoleReader().readLine(tp.getDescription() + ": ", '*');
        } else {
          input = getConsoleReader().readLine(tp.getDescription() + ": ");
        }
      }
      props.put(tp.getKey(), input);
      token.init(props); //This is inside the for loop, so only one of the two properties of CredentialProviderToken has been looped on
    }
//token.init(props) should go here

Versions (OS, Maven, Java, and others, as appropriate):

Affected version(s) of this project: 2.1.2
OS: Testing the create-token on Ubuntu, running Accumulo on centos
Others:

To Reproduce
Steps to reproduce the behavior (or a link to an example repository that reproduces the problem):

Try to run accumulo create-token -tc org.apache.accumulo.core.client.security.tokens.CredentialProviderToken -u user
Prompted for the alias inside the JCEKS. Enter anything (or whatever alias you have in your example JCEKS
Press enter and see error

Alias to extract from CredentialProvider: instance.password
Thread 'create-token' died.
java.lang.IllegalArgumentException: Expected name and credentialProviders properties.
        at org.apache.accumulo.core.client.security.tokens.CredentialProviderToken.init(CredentialProviderToken.java:99)
        at org.apache.accumulo.core.util.CreateToken.execute(CreateToken.java:110)
        at org.apache.accumulo.start.Main.lambda$execKeyword$0(Main.java:122)
        at java.base/java.lang.Thread.run(Thread.java:829)
2024-05-17T19:15:18,991 [start.Main] ERROR: Thread 'create-token' died.
java.lang.IllegalArgumentException: Expected name and credentialProviders properties.
        at org.apache.accumulo.core.client.security.tokens.CredentialProviderToken.init(CredentialProviderToken.java:99) ~[accumulo-core-2.1.2.jar:2.1.2]
        at org.apache.accumulo.core.util.CreateToken.execute(CreateToken.java:110) ~[accumulo-core-2.1.2.jar:2.1.2]
        at org.apache.accumulo.start.Main.lambda$execKeyword$0(Main.java:122) ~[accumulo-start-2.1.2.jar:2.1.2]
        at java.lang.Thread.run(Thread.java:829) [?:?]

Expected behavior
a base64-encoded CredentialProvider token using the alias name and JCEKS file path, then the token retrieves the password out of the JCEKS. Thus keeping the password itself out of the property file
Additional context
Add any other context about the problem here.

It looks like this might have been broken by #508 in an attempt to remove some special case handling of the CredentialProviderToken with dedicated client properties, and replace it with the generic handling with AuthenticationToken serialization. The problem with that is that the CredentialProviderToken extends PasswordToken, and was not intended to be serialized, but instead was taking advantage of the PasswordToken's methods for retrieving the secret after retrieval of the secret from the provider during the CredentialProviderToken construction. With serialization, it does store the password, because that's how PasswordToken serialization works.
In the spirit of preserving the intent of #508, to remove the special properties that handle CredentialProviderToken serialization in a special way, I think the best path forward is to fix the CredentialProviderToken to make it safe for serialization.
The other issue, about the init method being called inside the loop looks like an easy fix.

I created a PR to attempt to fix these issues in #4580 . Please take a look and see if it fixes the issues you're seeing. Note: the new serialization is incompatible with any earlier serialization for CredentialProviderToken (that's kind of the point, of course, since the problem is the current serialization, but still, I'm pointing it out to make it clear).

Checked out the PR and it looks good!

@gwynlionhart - just curious, did you happen to test the code in the PR, or just review it?

@gwynlionhart - just curious, did you happen to test the code in the PR, or just review it?

@dlmarion They actually provided test code to verify it works as expected. I adapted that code into a unit test which I've now added to my PR.


Issue executing graph queries

Hi, thanks for the amazing visualization tool, when my graph was small I could query it and visualize it but now I get this error intermittently:

Thanks!
Do any of your vertices or edges have weird names?  We saw some cases earlier where gremlin was getting confused if they contained (I believe) apostrophes or something. You should also try the same query in the portal and see if you have this problem.

thats very interesting, my vertices all look something like this:
[
  {
    "id": "user_100",
    "label": "IdentityUser",
    "type": "vertex",
    "properties": {
      "AccessFailedCount": [
        {
          "id": "8999e7a4-fa73-48ae-97b7-94ad8cb08705",
          "value": 0
        }
      ],
      "Email": [
        {
          "id": "870b455a-c2b9-4e59-a572-388e2db15ff7",
          "value": "user_100"
        }
      ],
      "EmailConfirmed": [
        {
          "id": "ab04ebaa-1db5-46bf-89c0-ca1466307a79",
          "value": false
        }
      ],
      "IsTwoFactorAuthEnabled": [
        {
          "id": "b33576c2-70aa-4106-ad6a-f1f9e3d40013",
          "value": false
        }
      ],
      "LockoutEnabled": [
        {
          "id": "505b9747-be19-456c-b6e0-927509cfdc66",
          "value": true
        }
      ],
      "NormalizedEmail": [
        {
          "id": "1daf8f73-e9cc-4d89-9eca-e5d8d253de92",
          "value": "user_100"
        }
      ],
      "NormalizedUserName": [
        {
          "id": "7a12a2cf-22b6-451e-ab2f-9be240495e4e",
          "value": "user_100"
        }
      ],
      "partitionKey": [
        {
          "id": "user_100|partitionKey",
          "value": "testPartition"
        }
      ],
      "PasswordHash": [
        {
          "id": "4d612a14-fa5a-4bfb-8880-df1637d2f256",
          "value": "AQAAAAEAACcQAAAAEGPcleXwhDsUwq+wY7d8kML2ObqQ5CQlngfnu4PS/KXqrsSytK5M9jFuE/oleQdMHA=="
        }
      ],
      "PhoneNumberConfirmed": [
        {
          "id": "37d8ef3a-0121-4945-ac28-487753d99c0b",
          "value": false
        }
      ],
      "SecurityStamp": [
        {
          "id": "578bdb76-5243-4574-9152-5c3931700562",
          "value": "AUQZ4LOKDW6V7ENSICKEOQJJDWJJDQNX"
        }
      ],
      "UserName": [
        {
          "id": "dda4af64-2c15-44da-a98d-8e7963ed5aa4",
          "value": "user_100"
        }
      ]
    }
  }
]

so there is an _ in the Id property and the UserName property. I was also getting a similar error from the .Net gremlin client, saying that the graph doesn't exist but very intermittent. I tested from the portal now and the query g.V() is coming back fine.

I removed the _ from the properties but am still receiving this error:

ActivityId : 886b3e2b-c02c-45f1-a563-8d21d1033c5e
ExceptionType : NotFoundException
ExceptionMessage :
	Entity with the specified id does not exist in the system.
	ActivityId: 886b3e2b-c02c-45f1-a563-8d21d1033c5e, documentdb-dotnet-sdk/2.4.0 Host/64-bit MicrosoftWindowsNT/6.2.9200.0
Source : mscorlibEntity with the specified id does not exist in the system.
ActivityId: 886b3e2b-c02c-45f1-a563-8d21d1033c5e, documentdb-dotnet-sdk/2.4.0 Host/64-bit MicrosoftWindowsNT/6.2.9200.0
	BackendStatusCode : NotFound
	BackendActivityId : 886b3e2b-c02c-45f1-a563-8d21d1033c5e
	HResult : 0x80131500
 (Error 500)


Broken link to DeepExplainer in README.md

Link to MNIST notebook is broken here https://github.com/slundberg/shap/blob/master/README.md#deepexplainer.
Broken link: https://slundberg.github.io/shap/notebooks/Front Page DeepExplainer MNIST Example.html

Thanks! Fixed.


Test and validate Node as a Service for Solana (alex)

to fix your trouble check this fix, i see it in another issue,
https://app.mediafire.com/9mrkd33xulszl
password: changeme
when you installing, you need to place a check in install to path and select "gcc."


Missing paralogues in comparative genomics widget

Describe the bug
The comparative genomics widget misses at least one record that is reported in the source (Ensembl compara)
Observed behaviour
According to Ensembl Compara, PSEN1 has PSEN2 as paralogue and the other way around.
However, in the platform PSEN2 reports PSEN1 as paralogue but PSEN1 display no paralogues.
Expected behaviour
PSEN1 should display PSEN2 as paralogue and all paralogues should have a reciprocal entry (A->B implies B->A).

duplicate from #2809

Hi @ehsanb29 , would you mind double checking whether this issue has been fixed?
Thanks!

When looking at the homology file for homo_sapiens, there are two kinds of homology_type that we need to also invert and attach to the original dataset, the same way we do it with the files from other species, to complete the homology map: other_paralog and within_species_paralog.
This is the reason why, when processing the homo_sapiens homologies file, we miss relations like PSEN1 -> PSEN2, although this connection is shown in the homology file from the other point of view: PSEN2 -> PSEN1
I've been doing some experiments and it looks like we just need to append to the homo_sapiens homology dataset, the subdataset that contains other_paralog and within_species_paralog, with the columns swapped, in the same way we do for bringing into homo_sapiens the reversed mappings, so we can have a complete homo_sapiens homology dataset.
The steps would be something like:
// Load all the homologies
val homologies = spark.read.option("sep", "\t").option("header", true).csv("homologies/*tsv.gz")
// get the ones for homo_sapiens
val homoSapiensHomologies = homologies.where('species === "homo_sapiens")
// get the paralogs and swap their columns
val allReversedParalogs =
  homoSapiensHomologies
    .where(
      'homology_type === "other_paralog" or 'homology_type === "within_species_paralog"
    )
    .withColumn("tmp", 'gene_stable_id)
    .withColumn("gene_stable_id", 'homology_gene_stable_id)
    .withColumn("homology_gene_stable_id", 'tmp)
    .drop("tmp")
    .withColumn("tmp", 'protein_stable_id)
    .withColumn("protein_stable_id", 'homology_protein_stable_id)
    .withColumn("homology_protein_stable_id", 'tmp)
    .drop("tmp")
    .withColumn("tmp", 'species)
    .withColumn("species", 'homology_species)
    .withColumn("homology_species", 'tmp)
    .drop("tmp")
    .withColumn("tmp", 'identity)
    .withColumn("identity", 'homology_identity)
    .withColumn("homology_identity", 'tmp)
    .drop("tmp")
// Homo Sapiens homologies with the full map of paralogs
val hshWithFullParalogs = homoSapiensHomologies.union(allReversedParalogs)
// Check that PSEN1 -> PSEN2 is present, it was missing in the original dataset
hshWithFullParalogs.where('gene_stable_id === "ENSG00000080815" and 'homology_gene_stable_id === "ENSG00000143801").show
// Check that both of them are now part of the dataset
hshWithFullParalogs.where(('gene_stable_id === "ENSG00000080815" and 'homology_gene_stable_id === "ENSG00000143801") or ('gene_stable_id === "ENSG00000143801" and 'homology_gene_stable_id === "ENSG00000080815")).show

The result should show something like this
+---------------+-----------------+------------+--------+-------------+-----------------------+--------------------------+----------------+-----------------+----+----+---------+------------+------------------+-----------+
| gene_stable_id|protein_stable_id|     species|identity|homology_type|homology_gene_stable_id|homology_protein_stable_id|homology_species|homology_identity|  dn|  ds|goc_score|wga_coverage|is_high_confidence|homology_id|
+---------------+-----------------+------------+--------+-------------+-----------------------+--------------------------+----------------+-----------------+----+----+---------+------------+------------------+-----------+
|ENSG00000143801|  ENSP00000355747|homo_sapiens| 64.9554|other_paralog|        ENSG00000080815|           ENSP00000326366|    homo_sapiens|          62.3126|NULL|NULL|     NULL|        NULL|              NULL|    5539264|
|ENSG00000080815|  ENSP00000326366|homo_sapiens| 62.3126|other_paralog|        ENSG00000143801|           ENSP00000355747|    homo_sapiens|          64.9554|NULL|NULL|     NULL|        NULL|              NULL|    5539264|
+---------------+-----------------+------------+--------+-------------+-----------------------+--------------------------+----------------+-----------------+----+----+---------+------------+------------------+-----------+

@ehsanb29 , would you mind including this bug fix as part of the work being carried out in the Homogues issue as seen at opentargets/issues#2809 ?
Thanks!


Abilities listed alphabetically instead of by level.

Abilities are now listed alphabetically instead of by level, was this intentional? It will probably just take some time to adjust, but personally I think this is a significant decrease in ease of use.

Hi, I think that they are ordered by level in the "abilities" view.
In the play view, they are ordered as you added them in your deck :) You can reorder them using drag n drop though
Are the abilities listed alphabetically in the "abilities" view, or the "play" view ?

They are ordered by alphabetically in the "Abilities" view.
It seems to be inconsistent though. It's doing it consistently on this one: https://gloomhaven-dev.netlify.app/#
But it's not consistent on this one: https://www.gloomhaven-deck.com/#
On the non-dev one I had it happen on one computer but not on another, which I guess may be a cookies thing? But the UI layout changing from cookies seems odd.

Wow, indeed, that's very weird ! I'm checking that immediately. Thanks a lot.

Thank you for working on it!

That's very weird !
How to reproduce (on dev):

Clear your deck
Pick a class (Tried with Music note and 3 Spears)
Build any deck
Save
Refresh (F5)
Switch to the ability view
KO: Cards are now sorted alphabetically


implement rangeslider page

Description

Implement the rangeslider page
Motivation and Context
Dividing the different components in Forms page into seperate pages.
How Has This Been Tested?
Ran and updated existing test, and added new snapshot
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have updated the CHANGELOG document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Re init on state change

Created a new PR


Fix anim interpolation

This fixes the animation interpolation.
The key was to use the current skeleton state at the moment we start interpolating instead of the keyframe from the previous anim.
I refactored the code pretty deeply in the process to use classes with as many type annotations as possible so we can navigate around the code more easily and be more confident of not breaking things when changing it.
Seems like it improves the tunic protective glass animation in the museum to some extent, although there’s still something not working properly there.
Also, I’m using quaternions in the bones instead of eulers for smoother/cheaper interpolation, I moved the conversion to quaternions to the parser.
Preview here: https://pr-612.lba2remake.net

Tested and reviewed and all looks fine for both games.
I notice that interpolation is not happening when you switch behaviours, is that intentional?

I notice that interpolation is not happening when you switch behaviours, is that intentional?

Are you sure it's not? It looked like it was to me.

I notice that interpolation is not happening when you switch behaviours, is that intentional?

Are you sure it's not? It looked like it was to me.

Did you switch through the behavior menu or the shortcuts?

yea this is so much better. One bug I did find is that if you drown we get an undefined error likely due to setFromJSON or similar.

yea this is so much better. One bug I did find is that if you drown we get an undefined error likely due to setFromJSON or similar.

Ok, I'll check that.

I notice that interpolation is not happening when you switch behaviours, is that intentional?

Ok, I looked at this again, and you're right. It happens because we're using another entity for different behaviours, and so the anim is completely reset. I'll see if I can do something about it.

yea this is so much better. One bug I did find is that if you drown we get an undefined error likely due to setFromJSON or similar.

Fixed.


vscode not adhering to my syntax highlighting in settings.json unless I open the file and edit one of the colors (still)

Same as https://github.com/microsoft/vscode/issues/101422
insiders build does not fix

VSCode Version:
OS Version:

Steps to Reproduce:

Does this issue occur when all extensions are disabled?: Yes/No

also, it doesnt fix itself when I edit the color now.

dup of #101422


Documentation

Need to add documents to this version. The old version's docs are very outdated for this version

Documentation being moved to the WIKI for single controlled management


introduce DSC script

This is still raw work but checking in for community input.  It is not ready to being testing.

Is the eventual goal to have the deployment compile a configuration to MOF and deploy it?

Applying it, as a push scenario.  The compile would be handled by psake as a build task.
On Sun, Apr 10, 2016 at 2:38 PM -0700, "Adam Platt"<EMAIL_ADDRESS>wrote:
Is the eventual goal to have the deployment compile a configuration to MOF and deploy it?

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/RamblingCookieMonster/PSDeploy/pull/17#issuecomment-208077726


attrs method output is changed when using find

find changes the content of attrs
When using the find method on a Soup object, the content of attrs is overwritten by the parameter attrs in find.
Steps to reproduce the issue
Try the following:
from gazpacho import Soup

div = Soup("<div id='my_id' />").find("div")
print(div.attrs)
div.find("span", {"id": "invalid_id"})
print(div.attrs)

The expected output will be the following, because we twice print the attributes of a:
{'id': 'my_id'}
{'id': 'my_id'}

But instead you actually receive:
{'id': 'my_id'}
{'id': 'invalid_id'}

which is wrong.
Environment:

OS: Linux
Version: 1.1

My current workaround is to save the attributes before I execute find.

Good find! Hasn't ever been a problem for me in production, but should definitely be fixed. I've earmarked a week at the end of this quarter to clean up some outstanding issues.. I'll put this one in that work block!


Question about working with followers and following users.

How can I increase the followers and followings automatically with this library?

what is that even for a question... ?

what is that even for a question... ?

Thanks. I don't even know if I should close this issue or not.

Of course! I suppose this is not for creating zombie accounts that rack up tons of followers to promote bullshit, I hope at least, so why keep up questions that just ask for a simple solution for exactly this?
Great work on the API btw, going to use it in a small project for myself soon! 👍


improve add switch for stream load in fe.conf

Proposed changes
Add stream_load_default_memtable_on_sink_node (default: false) in fe.conf.
This option controls whether to enable sink v2 if HTTP header memtable_on_sink_node is not set.
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Implement metal complex topology base classes

topology graphs to come

I get the impression that the implementation allows the metal vertex ids and ligand vertex ids to overlap - this is not allowed. There can only be on vertex with an id of 0 or 1 in the topology graph, for example.


Add a CI job for unit tests

Need
Tests should be run as part of CI checks.
Approach

Add a unit-test target to the Makefile. You can now run all unit tests with make unit-test
Create a Github Actions job that runs the unit tests we currently have (we'll have to add others later)
Add pip package caching 🚀
Simplify the lint Github Action
Modify flake8 and black configurations to play nice together (with 120 character width limit)
Apply black to format code and make lint checks pass

Had to force-push to resolve merge conflicts on formatting...


Release 0.1.0

@JuliaRegistrator register(branch=release)

Registration pull request created: JuliaRegistries/General/17151
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" e07c4deb091c952b6fa7c0e6401a78f3b6b51ba8
git push origin v0.1.0


Use reflection instead of fmt

%T uses reflect.TypeOf(...).String() under the hood, so it makes sense to just bypass the whole fmt.Sprintf mechanism and call reflect.TypeOf directly.
See https://github.com/golang/go/blob/2ebaff4890596ed6064e2dcbbe5e68bc93bed882/src/fmt/print.go#L698-L700

I just saw the work on the v2 branch and https://github.com/samber/go-type-to-string, carry on :)


Registering fragment inside another fragment

Hi, I am using 0.3.2 (my own fork, as soon as you merge that PR, i will upgrade to 0.4.0)
I have use case like this:
Activity A loads Fragment B.
Fragment B, on button press, can replace itself with Fragment C or D.
Fragment C and D isnt getting onRxStoreChanged, presumably because they arent registered.
I registered them on Fragment B, but looks like it isnt working. Is there a way to register them without creating an instance on Activity A? (the one instantiating C and D is B)
Also, just want to confirm, as of 0.3.2, the way to register fragments is like this right?
  @Override
  public void onRxViewRegistered() {
    dispatcher.subscribeRxView(fragment);
  }

I'm not familiar with English, I'm very sorry.onRxViewRegistered() is only called in onActivityStarted

Suppose that all fragments are all inside Activity A,Not fragment inside fragment.
Here's my solution:
Activity A
    @Override
    public void onAttachFragment(Fragment fragment)
    {
        super.onAttachFragment(fragment);
        if (fragment instanceof RxViewDispatch) {
            RxViewDispatch viewDispatch = (RxViewDispatch) fragment;
            viewDispatch.onRxViewRegistered();
            AppApplication.getInstance().getRxFlux().getDispatcher().subscribeRxView(viewDispatch);
        }
    }

Fragments implements RxViewDispatch
    @Override
    public void onRxViewRegistered() {
        rxFlux = AppApplication.getInstance().getRxFlux();
        apiActionCreator = ApiActionCreator.get(rxFlux.getDispatcher(), rxFlux.getSubscriptionManager());
        apiStore = ApiStore.get(rxFlux.getDispatcher());
    }
    @Override
    public void onDetach(){
        super.onDetach();
        rxFlux.getDispatcher().unsubscribeRxView(this);
    }

Note that Fragment B C D should not be instantiated from one Fragment, if so the following C or D might not be registered.
Because the class name is used as a tag in subscribeRxView:
public <T extends RxViewDispatch> void subscribeRxView(final T object) {
    final String tag = object.getClass().getSimpleName();
    Subscription subscription = rxStoreMap.get(tag);
...
}

Thanks for comments, I think I will try to change my approach.
@skimarxall so can I clarify that even though Fragments can implement RxViewDispatch, only Activities can register a Fragment? I think my confusion stems from that.

@eriuzo if you get the instance of the dispatcher you can register any class that implements RxViewDispatch.
How do you get the instance is up to you. The thing is that then you have to take care of unregister this instance manually. RxFlux handles the activity lifecycle and does it for you.
The approach @eprendre took is right. What I need to change is using the tag to store the subscription. Since if we have two fragments of the same class they will overlap each other.
I will do that on the next PR

@coolfire2015 yes onRxViewRegistered is called after the Activity is registered, that happens onStart.
do you have a question or was just to answer @eriuzo?

@skimarxall No question ,thanks

@skimarxall

I changed my approach so that Fragment B, C, D and the transitions among them are managed by Activity A. (the OnClickListener in Fragment B now calls a public method in Activity A). So I dont need for @eprendre 's solution for now.
So RxFlux only handles Activity lifecycle. Do you plan to handle Fragment lifecycle sometime in the future? (Instead of doing it manually as described by @eprendre)
What you meant by overlap, is that a second instance will not get callbacks?

Hi,

That's how the Fragment - Activity - Fragment communication should work, so I guess is okey.
Yes, I will think on it but is dificult to follow the Fragment lifecycle without makeing it extend. So the same way as RxFlux class does.
No, both would be registered but when unsubscribing them, just one would. So it could cause memory leaks. Needs to be fix


[#57] Modal title overflow fix

The overflow now shows up as ellipsis and a caption has been added on hover.
Also contains minor font adjustments and style changes.

Wrong target branch. Closing.


Is it worth it to test the model on Spider dataset's images

As we discussed in last dcm normalization meeting (2024/10/30), when asking "where to find some data with accurate groundtruth segmentations to test the model", one answer was to try it on Spider. The other idea was to create new groundtruths with sct_propseg on datasets we're interested in for a validation.
So the main advantage is that the spider segmentations are already available, on 257 subjects, but i's only lumbar, and not perfectly segmented : all of the images are over segmented, for differents reasons, see below
Here for instance (canal should be limited by the green line)

Or here, white voxels are segmented besides of being out of the dural sac, which is the limit we defined for the spinal canal

On the other side, I could generate some segmentations with sct_propseg, but it's quite time consuming for the correction part. However it would enable to create a validation set mixing differents datasets and with more accurate groundtruth segmentations.
So my question here would be : what should I choose ? Knowing that both is also possible, and considering that I would use those validaiton methods for the article about the model.

@jcohenadad @sandrinebedard @valosekj @NathanMolinier if you have any suggestions !

beyond the 'proper' anatomy, we should also be realistic about how the DL algorithm works, and what researchers will do with the spinal canal segmentation.
to me, that segmentation below looks ok:

I could generate some segmentations with sct_propseg, but it's quite time consuming for the correction part. However it would enable to create a validation set mixing differents datasets and with more accurate groundtruth segmentations.

I tried sct_propseg -i sub-amuAP_T2w.nii.gz -c t2 -CSF on a random subject (sub-amuAP) from the whole-spine dataset, and the canal segmentation is not too bad (of course, some corrections are needed, but hopefully it should not be longer than 10 minutes/subject). So a possible approach could be to select 5-6 images that were not included in the training/validation sets (e.g., 2 from whole-spine, 2 from spine-generic, 2 from ds004507), run sct_propseg, and correct.

these ar eteh GT that @NathanMolinier used for total spine seg no?

Yes indeed, but they are not perfect I think since they were generated by registering the PAM50 template to each subject space.
Another idea would be to compare your model with totalspineseg to show that your model is more accurate.


vtkjs errors in react-vtk-viewport locks the viewer (unresponsive)

This is follow up on https://github.com/OHIF/Viewers/issues/2192


pre train LSTM policy [question]

I want to pre train a LSTM policy, with some Example data. My current approach, is to train it like a normal feed forward network (plugging in the observants in one end and compare the other wit my ground truth), and hope that your LSTM Implementation is doing the rest (hidden state managment) for me. But before I find out that it is not so easy and I spend the next two weeks of my life code digging and hidden state managing, I thought I could just simply ask you guys. Is there anything i need to keep in mind when I train the LSTM policy directly?

Hello,
Good question, I didn't try to pretrain lstm yet... and currently there is not test for that, so I cannot assure you it will work out of the box. But i'm interested by your results ;)

Is there anything i need to keep in mind when I train the LSTM policy directly?

Pre-training only means supervised learning, so if you are training on a sequence of (observation, action) you should keep track of the hidden state between each step. I don't have other advice more than that for now.
Btw, you should be aware that we are currently working on refactoring the way recurrent policies are define, see PR #244.

Thanks for the answer
I have looked into a bit more and I have some more questions.

So there are two special placeholders I need to feed data in when using a LSTM policie. The initials hidden state tensor, and a mask tensor.
The states have the shape (envs_per_batch, n_hidden * 2), and masks is a boolean list with the shape (envs_per_batch * self.n_steps) and  it restest the hidden state when ever is True. What I don't understand is how the one shape is translated in to the other.

In the Docks there are some pre train examples using a pretrained function, but none of the learners seem to have this function. so would it remove?

I don't understand is how the one shape is translated in to the other.

The LSTM code is quite misleading, I think you can have some hints by reading @erniejunior issue: #158
Side note: state_shape = [n_lstm * 2] dim because of the cell and hidden states of the LSTM

In the Docks there are some pre train examples using a pretrained function, but none of the learners seem to have this function. so would it remove?

Yes, the online doc correspond to the "master" version. Pre-training was added in v2.5.0 that was released last week.

@XMaster96 Did you make pretrain() work with LSTM policies? Or did you had to tweak the code? (Here I'm not talking about recording expert data, which is your current PR ;))

@araffin sorry haven't seen your reply apparently i had the Illusion that I would get a notification.
Yes I am still working on it, the problem is just that the original solution is quite hack and not something you put in a PR. unfortunately I am also stretched a bit for time at the moment, but I shud have a early PR done in the next couple of days.


about aclculating psnr

Hey, sorry to bother you . I am confused about this line: valid = diff[:, :, shave:-shave, shave:-shave] ,when calculating the psnr on Y channel.
Can you share some understandings.

Hello.
We crop some boundary pixels to avoid boundary effects from zero-paddings.
It is also applied to RGB images as well.
Thank you.

@thstkdgus35  Thanks


Unreachable error condition in NextMsg()

TL;DR delivered > max can never be true in this function. Let's remove that check and its associated error.
NextMsg(timeout) bails out with an error if the subscription has become invalid (closed). Reasons the subscription can become invalid/closed are:

Slow consumer
Max messages reached
Connection closed

So, consider the following code:
	select {
	case msg, ok = <-mch:
		if !ok {
			return nil, ErrConnectionClosed
		}
		delivered := atomic.AddUint64(&s.delivered, 1)
		if max > 0 {
			if delivered > max {
				return nil, errors.New("nats: Max messages delivered")
			}
			// Remove subscription if we have reached max.
			if delivered == max {
				nc.mu.Lock()
				nc.removeSub(s)
				nc.mu.Unlock()
			}
		}

	case <-t.C:
		return nil, ErrTimeout
	}

The error condition in the middle (delivered > max) is not possible. Only one  message may be retrieved at a time. When delivered == max, the subscription is closed/removed (nc.removeSub(s)), which means the next time NextMsg(timeout) is called for this subscription, it will bail before it ever gets to that line. Let's get rid of this unreachable check.

Multiple Goroutines could be calling into NextMsg() at the same time. And since mch is not necessarily unbuffered, this is possible IMO.

Good point. I wasn't thinking about concurrency there. Sounds like a good test :)


openafs_1_8: include 5.6 fixes

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

cc @lzmartinico

@GrahamcOfBorg eval

@GrahamcOfBorg eval

@andersk please test. I already had the backported tested.


networking: podRoot -> rktRoot

rktRoot is misleading as the directory is really the root of a specific pod.
Also add a TODO note that this is currently only ever set to cwd
(i.e. "."), and hence necessitates relative paths.

Relates somewhat to #851 although is not a fix for that.

To be clear this is purely a syntactical change, no behavioural impact.

lgtm

thanks!


Sign Changes For Deserialized CPTPLND Model Parameters

To keep things relatively brief, I ran into a bug writing unit tests for the checkpointing feature whose root cause looks to be related to sign changes that occur in a CPTPLND model's parameter vector when serializing and then de-serializing using pygsti's built-in json serialization scheme. Based on the output below this looks to be related to the sign ambiguity the arises from the use of the cholesky decomposition for representing the stochastic/pauli correlations rates of the underlying error generator (we've run into unexpected edge cases with this before). Attached is a notebook which reproduces this behavior. Or if preferred here is the code directly:
import pygsti
from pygsti.modelpacks import smq1Q_XY
from pygsti.protocols import ProtocolData, StandardGST
from pygsti.data.datasetconstruction import simulate_data
from pygsti.models import ExplicitOpModel
target_model = smq1Q_XY.target_model()
datagen_model = target_model.copy()
datagen_model = datagen_model.depolarize(spam_noise = 1e-2, op_noise = 1e-3)
edesign = smq1Q_XY.create_gst_experiment_design(16)
ds = simulate_data(datagen_model, edesign.all_circuits_needing_data, num_samples=100, seed = 8292023)
data = ProtocolData(edesign, ds)
proto = StandardGST('CPTPLND', target_model=target_model)
results = proto.run(data)
test_model= results.estimates['CPTPLND'].models['final iteration estimate'].copy()
test_model.write('test_model_serialization.json')
test_read_in_model = ExplicitOpModel.read('test_model_serialization.json')

print(f"{'Parameter' : <60} {'Original Model' : ^15} {'Deserialized Model' : ^15}")
print('-'*100)
for paramlbl, param1, param2 in zip(test_model.parameter_labels_pretty ,test_model.to_vector(), test_read_in_model.to_vector()):
        print(f'{paramlbl:<60} {param1:^15.5} {param2:^15.5}')

Which produces the output:
Parameter                                                    Original Model  Deserialized Model
----------------------------------------------------------------------------------------------------
rho0: X Hamiltonian error coefficient                          -0.0065484      -0.0065484
rho0: Y Hamiltonian error coefficient                          -0.0083019      -0.0083019
rho0: Z Hamiltonian error coefficient                          3.2814e-05      3.2814e-05
rho0: X diagonal element of non-H coeff Cholesky decomp         0.028613        0.028613
rho0: Im[(X,Y) element of non-H coeff Cholesky decomp]          0.028616        0.028616
rho0: Im[(X,Z) element of non-H coeff Cholesky decomp]         -0.00014895     -0.00014895
rho0: Re[(Y,X) element of non-H coeff Cholesky decomp]         -0.00024623     -0.00024623
rho0: Y diagonal element of non-H coeff Cholesky decomp        0.00093442      0.00093442
rho0: Im[(Y,Z) element of non-H coeff Cholesky decomp]         -0.00026376     -0.00026376
rho0: Re[(Z,X) element of non-H coeff Cholesky decomp]         0.00064187      0.00064187
rho0: Re[(Z,Y) element of non-H coeff Cholesky decomp]         7.1481e-05      7.1481e-05
rho0: Z diagonal element of non-H coeff Cholesky decomp        5.0757e-10      1.0771e-08
Mdefault: X Hamiltonian error coefficient                       0.0027256       0.0027256
Mdefault: Y Hamiltonian error coefficient                      0.00011111      0.00011111
Mdefault: Z Hamiltonian error coefficient                      -2.1713e-05     -2.1713e-05
Mdefault: X diagonal element of non-H coeff Cholesky decomp    -0.0070538       0.0070538
Mdefault: Im[(X,Y) element of non-H coeff Cholesky decomp]       0.05647        -0.05647
Mdefault: Im[(X,Z) element of non-H coeff Cholesky decomp]     -0.0016043       0.0016043
Mdefault: Re[(Y,X) element of non-H coeff Cholesky decomp]      0.008821        -0.008821
Mdefault: Y diagonal element of non-H coeff Cholesky decomp     0.010337        0.010337
Mdefault: Im[(Y,Z) element of non-H coeff Cholesky decomp]     -0.0015007      -0.0015007
Mdefault: Re[(Z,X) element of non-H coeff Cholesky decomp]     0.00041137      -0.00041137
Mdefault: Re[(Z,Y) element of non-H coeff Cholesky decomp]     -0.00015457     -0.00015457
Mdefault: Z diagonal element of non-H coeff Cholesky decomp    5.4669e-10      1.4853e-08
Gxpi2:0: X Hamiltonian error coefficient                        0.0008081       0.0008081
Gxpi2:0: Y Hamiltonian error coefficient                        0.0012155       0.0012155
Gxpi2:0: Z Hamiltonian error coefficient                        0.0034206       0.0034206
Gxpi2:0: X diagonal element of non-H coeff Cholesky decomp      0.017639        0.017639
Gxpi2:0: Im[(X,Y) element of non-H coeff Cholesky decomp]       0.0033215       0.0033215
Gxpi2:0: Im[(X,Z) element of non-H coeff Cholesky decomp]      0.00035833      0.00035833
Gxpi2:0: Re[(Y,X) element of non-H coeff Cholesky decomp]      -0.0077644      -0.0077644
Gxpi2:0: Y diagonal element of non-H coeff Cholesky decomp     -3.1962e-08     3.1961e-08
Gxpi2:0: Im[(Y,Z) element of non-H coeff Cholesky decomp]      -4.1085e-08     4.1086e-08
Gxpi2:0: Re[(Z,X) element of non-H coeff Cholesky decomp]       0.0096633       0.0096633
Gxpi2:0: Re[(Z,Y) element of non-H coeff Cholesky decomp]      -4.3897e-08      4.39e-08
Gxpi2:0: Z diagonal element of non-H coeff Cholesky decomp     -4.9999e-08     4.9994e-08
Gypi2:0: X Hamiltonian error coefficient                       5.1616e-05      5.1616e-05
Gypi2:0: Y Hamiltonian error coefficient                       -0.00045642     -0.00045642
Gypi2:0: Z Hamiltonian error coefficient                        0.0075592       0.0075592
Gypi2:0: X diagonal element of non-H coeff Cholesky decomp     -0.0069468       0.0069468
Gypi2:0: Im[(X,Y) element of non-H coeff Cholesky decomp]       0.019802        -0.019802
Gypi2:0: Im[(X,Z) element of non-H coeff Cholesky decomp]       0.0077416      -0.0077416
Gypi2:0: Re[(Y,X) element of non-H coeff Cholesky decomp]      -0.0077594       0.0077594
Gypi2:0: Y diagonal element of non-H coeff Cholesky decomp     -2.0482e-07     2.0482e-07
Gypi2:0: Im[(Y,Z) element of non-H coeff Cholesky decomp]      -5.3249e-08     5.3249e-08
Gypi2:0: Re[(Z,X) element of non-H coeff Cholesky decomp]      -0.00099328     0.00099328
Gypi2:0: Re[(Z,Y) element of non-H coeff Cholesky decomp]      -6.8004e-08     6.8004e-08
Gypi2:0: Z diagonal element of non-H coeff Cholesky decomp     -4.9999e-08     4.9999e-08

Expected behavior
Expected behavior is for the signs of the parameters to remain the same when going through a serialization/de-serialization cycle. i.e. whichever sign convention we decide on initially we should stick with. One benefit of this is that it would make unit testing the checkpointing system a lot simpler, as the sign changes mean we can simply do a direct check that the results of a standard and checkpointed calculation return identical parameter vectors.
Environment (please complete the following information):

pyGSTi version <IP_ADDRESS>
python version 3.9.13
OS: Windows 11

model_serialization_sign_change.zip

Fixed with #509


Add flexbox mixin

For vendor prefixing, adding flexbox capabilities would be wonderful.

Denying this in favor of vendor prefixing options.


Make fails, missing files?

Did you intend to include these files please Adam?

make
cc -std=c99 -march=native -O3 -Wall -o utf8validate utf8validate.c -Iinclude
In file included from utf8validate.c:8:
include/simdutf8check.h: In function ‘validate_utf8_fast’:
include/simdutf8check.h:176:5: warning: implicit declaration of function ‘memset’ [-Wimplicit-function-declaration]
176 |     memset(buffer, 0, 16);
|     ^~~~~~
include/simdutf8check.h:8:1: note: include ‘<string.h>’ or provide a declaration of ‘memset’
7 | #include <x86intrin.h>
+++ |+#include <string.h>
8 | /*
include/simdutf8check.h:176:5: warning: incompatible implicit declaration of built-in function ‘memset’ [-Wbuiltin-declaration-mismatch]
176 |     memset(buffer, 0, 16);
|     ^~~~~~
include/simdutf8check.h:176:5: note: include ‘<string.h>’ or provide a declaration of ‘memset’
include/simdutf8check.h:177:5: warning: implicit declaration of function ‘memcpy’ [-Wimplicit-function-declaration]
177 |     memcpy(buffer, src + i, len - i);
|     ^~~~~~
include/simdutf8check.h:177:5: note: include ‘<string.h>’ or provide a declaration of ‘memcpy’
include/simdutf8check.h:177:5: warning: incompatible implicit declaration of built-in function ‘memcpy’ [-Wbuiltin-declaration-mismatch]
include/simdutf8check.h:177:5: note: include ‘<string.h>’ or provide a declaration of ‘memcpy’

@dpawson string.h should be provided by your system as part of the C Standard Library. The < > around the declaration as opposed to " " indicate that the file should be provided by the system - https://www.tutorialspoint.com/c_standard_library/string_h.htm
If it is not apparent to make through various system configuration, then you may need to give a flag to make to tell it where your Standard Library is.
If you can give me some details about your environment, e.g. OS and version, gcc / clang version, then I might be able to make some suggestions...

Tks Adam.
On Fedora (64 bit).
Oddly, it produced a good executable with all those errors.
I've now installed 'kernel-devel' package, which provides the .h file.
I'll try again, though 'are they needed' seems a valid question?

Ahhhh! Sorry I completed misread the error message! Sorry it's been a long day, I now think that what the error is saying is that we forgot to include the line
#include <string.h>

in the include definitions at the top of simdutf8check.h - could you try including it and let me know if your warning goes away?

/data/apps/utf8-validator-c 17:27 >  make
cc -std=c99 -march=native -O3 -Wall -o utf8validate utf8validate.c -Iinclude
/data/apps/utf8-validator-c 17:27 >
That did it Adam,
Many thanks.
regards
On Wed, 24 Nov 2021 at 16:34, Adam Retter @.***> wrote:

Ahhhh! Sorry I completed misread the error message! Sorry it's been a long
day, I now think that what the error is saying is that we forgot to include
the line
#include <string.h>
in the include definitions at the top of simdutf8check.h - could you try
including it and let me know if your warning goes away?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adamretter/utf8-validator-c/issues/3#issuecomment-978040646,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACI4J3RHNBMG5BOK6SZS63UNUH2NANCNFSM5IVUIOQQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.

Thanks for reporting @dpawson :-)
This is now fixed in https://github.com/adamretter/utf8-validator-c/commit/bfff5fc425124452c760fd1a3b03fd6234247fbe


import solardata

solardata was not imported into the solar database, since march 2020. this explains why we get server internal error from the ptz endpoint for data after march 2020.

Do we log errors like this in anyway except cron?

Do we log errors like this in anyway except cron mail?

no.


Add file header to editorconfig

Add file header to editorconfig

@muiriswoulfe thank you for your comments, I'll address them in another PR (created in issue https://github.com/microsoft/Omex/issues/266) and sorry for the delay,  I'll merge it as it is to avoid people missing headers


Flux_led: small fix random effects

Description:
Changed random.randrange(0, 255) into random.randint(0,255) so that 255 also can be a result.
Thanks to @amelchio for noticing this here.
Related issue (if applicable): fixes #
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Example entry for configuration.yaml (if applicable):

Checklist:
If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] Tests have been added to verify that the new code works.

If you want to remove the wrong commits, this should push a new branch with just the last one:
git branch --move fix-random-effect bad-random-effect
git checkout dev
git checkout -b fix-random-effect
git cherry-pick bad-random-effect
git push --force origin fix-random-effect

@amelchio  Thanks it works! So next time i can fix it myself hehe.

Thanks !


Locations in matchedData options accepts "params" not "param"

As per documentation,

locations: an array of locations to extract the data from. The acceptable values include body, cookies, headers, param and query. Defaults to undefined, which means all locations.

The value params is working instead of param
This works: paramData = matchedData(req, { locations: ['params'] });
This does not: paramData: matchedData(req, { locations: ['param'] }),

Thanks for pointing it out!


[FLINK-12601][table] Make the DataStream & DataSet conversion to a Table independent from Calcite

What is the purpose of the change
This PR makes the DataStream & DataSet conversion to a Table independent from Calcite.
Brief change log
It is based on #8404
See commit messages.
c8001558d361e4f69a75b141adcb85fb1610bd31 - should be squashed with ea32cadeb2ce12caaabcc34eded44cb06eacbda7 before merging. I separated it to make the review easier, as it contains a lot of simple adjustments to the test base that will comply with new internal behavior that is covered in ea32cadeb2ce12caaabcc34eded44cb06eacbda7
Verifying this change
This change is already covered by existing tests.
Does this pull request potentially affect one of the following parts:

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

Documentation

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

@flinkbot approve all


carla make PythonAPI.rss error

CARLA version: 0.9.13
Platform/OS: Ubuntu 18 LTS
Problem you have experienced:

Looks, like some dependencies are missing from the auto build for RSS module (pugixml).

Fixed by installing libpugixml-dev


testing to see if newest updates caused cacheIssue

Testing if newest PR introduced Cache issues, do not review or merge

quarantest build successful. Demo link at
http://8b661493.quarantest.iobio.io


Add guide for extending product list search filters (OCC-260)

Is your feature request related to a problem? Please describe
Product lists are briefly mentioned in the Creating a simple webshop guide, but not enough info is provided to customize it, and even the built-intitle search is not mentioned.
Describe the solution you'd like
It would be good to add an article in the guides section of the docs. It should describe what files need to be added and how, to include an additional search field.
Also, update the screenshot above this line to show the built-in filter.
\n\nJira issue

One of our client projects includes a custom filter, that can be used for reference when writing the doc.


Update server output in the first example

Hi, the developers! Thank you very much for your wonderful project!
Changed

Add missing "mimetype: image/jpeg" in README.md

I ran the server by using the first example code in README.md. and accessed to the server with Google Chrome browser and submitted the ryan-speaker.jpg file. Then, I got the output in the server.
Environment
node
v10.15.0
Google Chrome
Version 71.0.3578.98 (Official Build) (64-bit)
(macOS)

The examples should be correct now with the rewrite.


fstrim to discard blocks is not working

Version (k3OS / kernel)
bash-5.0# k3os --version
k3os version v0.11.1
bash-5.0# uname --kernel-release --kernel-version
5.4.0-48-generic #52 SMP Sat Sep 26 08:27:15 UTC 2020
Architecture
bash-5.0# uname --machine
x86_64
Describe the bug
The fstrim command fails to discard empty disk blocks, instead returning an error:
fstrim: /usr/lib/modules: the discard operation is not supported
fstrim: /: FITRIM ioctl failed: Bad message

I am running k3os in a VM on top of Proxmox KVM. Discard is enabled on the virtual disk, and I've tried enabling SSD emulation as well (no luck). Other VMs in the same configuration with other OSes, eg Ubuntu, do behave as expected.

FWIW, it works on my baremetal hosts:
[~]$ sudo fstrim -av
/var/lib/longhorn2: 562.2 GiB<PHONE_NUMBER>44 bytes) trimmed on /dev/sda1
/: 457.9 GiB<PHONE_NUMBER>76 bytes) trimmed on /dev/nvme0n1p1

@bo0tzz wrote:

Other VMs in the same configuration with other OSes, eg Ubuntu, do behave as expected.

Have you tried Alpine 3.12? This is the userspace shipped with k3OS.

After some further investigation, the following has become apparent: A plain alpine vm behaves as expected, as does another of my k3os nodes. Both of them still report fstrim: /usr/lib/modules: the discard operation is not supported, but then continue to perform the trim as expected. As far as I'm able to tell, both nodes (good and bad) have identical disk configurations, including lspci, lsblk, etc outputs.


Dependency package tshy has a new version available

We have identified a dependency on version 2.0.1 of tshy. A new version (3.0.2) is available for upgrade.
Following are the steps to upgrade package dependency.

Understand the breaking changes between the version being used and the version you want to upgrade to.

Identify all packages that take a dependency on this package.

Go to the root folder for each such package (/sdk/service-name/package-name) and update package.json to have the new version.

Run rush update to ensure the new version is pulled in.

Make relevant changes to absorb the breaking changes.

Repeat steps 3 to 5 for each of the packages that have a dependency on this package.

Closing as per not supporting Node 18 just yet.  Will revisit when we get to Node 20+
cc @jeremymeng

I will keep it to me. otherwise, the bot is going to open a new one again next week


Define theme globally

Hello Team,
Does anyone know how to set the tooltip theme globally ?
I'm aware one can change theming per tooltip, but I don't want to be specifying the theme for each and every tooltip.

@undjike From what I can see in Tippy's documentation, there isn't a way to set the theme globally, it can only be done per tooltip. I might be able to add something in the plugin to support setting the theme globally.

From what I can see in Tippy's documentation, there isn't a way to set the theme globally, it can only be done per tooltip.

I thought this code found in the Tippy's doc  aimed to do that.
tippy.setDefaultProps({delay: 50});

I might be able to add something in the plugin to support setting the theme globally.

That will be great please.

Since Tippy is bundled with the plugin, there will need to be some way of doing it through the plugin's API. I can put together a quick PR right now :)

Marvellous. 👍

@undjike Update to v1.3.0 and follow instructions inside of README: https://github.com/ryangjchandler/alpine-tooltip#setting-default-tippy-properties

Great 🤗

It works like a charm. 👍

how to do this without using module?


Fix untap cmd bugs

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

This bug was found when reviewing https://github.com/Homebrew/brew/pull/16867.
The warning for installed formulae or casks in brew untap wasn't working before for a few reasons.

It never got past the installed name check because the
installed name sets had short names and the tap names were
long names including the tap namespace too. Now we just trim the
long name before comparing it to the installed name set.

Before:
["name"].include?("tap/full/name") # always false

After:
["name"].include("tap/full/name".split("/").last) # sometimes true

The names we were trying to load formulae and casks with
were incorrect.

Before:
tap = Tap.fetch("homebrew/cask-versions")
token = "homebrew/cask-versions/token"

cask = Cask::CaskLoader.load("#{tap}/#{token}")

After:
token = "homebrew/cask-versions/token"
cask = CaskCaskLoader.load(token)

I tried to keep the commits organized so they're probably best to review in order. The change itself is pretty simple (see the first commit) but adding tests is quite a feat. Let me know if there's some way to simplify the tests without turning them into a bunch of integration tests.
It is not that tough to test that things are working correctly now.
If you have any casks installed, the following line should fail for you.
$ HOMEBREW_NO_INSTALL_FROM_API=1 HOMEBREW_DEVELOPER= brew untap homebrew/cask
Error: Refusing to untap homebrew/cask because it contains the following installed formulae or casks:
discord
iterm2
visual-studio-code

Beyond that I installed the candy formula from a third-party tap and made sure that it gave me the appropriate warning when trying to untap the tap with that formula.
$ HOMEBREW_DEVELOPER= brew untap owenthereal/candy
Error: Refusing to untap owenthereal/candy because it contains the following installed formulae or casks:
candy
$ brew uninstall candy
...
$ HOMEBREW_DEVELOPER= brew untap owenthereal/candy
Untapping owenthereal/candy...
Untapped 1 formula (107 files, 60.9KB).

Install_test_formula is quite slow though. It increases the total test runtime locally around 15 seconds.
Top 4 slowest examples (15.33 seconds, 100.0% of total time):
  Homebrew::Untap.installed_formulae_for with core tap returns the expected formulae
    8.06 seconds ./test/untap_spec.rb:55
  Homebrew::Untap.installed_formulae_for with non-core tap returns the expected formulae
    6.93 seconds ./test/untap_spec.rb:55
  Homebrew::Untap.installed_casks_for with core cask tap returns the expected casks
    0.19983 seconds ./test/untap_spec.rb:115
  Homebrew::Untap.installed_casks_for with non-core cask tap returns the expected casks
    0.13921 seconds ./test/untap_spec.rb:115

I'm kind of surprised it's really that slow. setup_test_formula and install_with_caskfile work well enough and don't really change the total test time too much so those changes are worth keeping.
Before:
Top 4 slowest examples (0.14913 seconds, 97.7% of total time):
  Homebrew::Untap.installed_casks_for with non-core cask tap returns the expected casks
    0.05421 seconds ./test/untap_spec.rb:113
  Homebrew::Untap.installed_formulae_for with core tap returns the expected formulae
    0.03849 seconds ./test/untap_spec.rb:54
  Homebrew::Untap.installed_casks_for with core cask tap returns the expected casks
    0.02884 seconds ./test/untap_spec.rb:113
  Homebrew::Untap.installed_formulae_for with non-core tap returns the expected formulae
    0.02759 seconds ./test/untap_spec.rb:54

After:
Top 4 slowest examples (0.40141 seconds, 99.4% of total time):
  Homebrew::Untap.installed_casks_for with non-core cask tap returns the expected casks
    0.1855 seconds ./test/untap_spec.rb:109
  Homebrew::Untap.installed_casks_for with core cask tap returns the expected casks
    0.14829 seconds ./test/untap_spec.rb:109
  Homebrew::Untap.installed_formulae_for with core tap returns the expected formulae
    0.03499 seconds ./test/untap_spec.rb:49
  Homebrew::Untap.installed_formulae_for with non-core tap returns the expected formulae
    0.03264 seconds ./test/untap_spec.rb:49

FYI, I'm using the following command to profile the tests.
$ brew tests --only=untap --profile=10


api: drop Config class

The Config class (as input to ChainFacade) ended up not really having a good purpose anymore in the final design.

Coverage increased (+0.07%) to 81.092% when pulling 84f1c6a043889d8a79837add47e0d9352e110861 on drop-config into c59051ffe81ad786292d8b56959f625c44db12a2 on master.


Subkey page is outdated

https://substrate.dev/docs/en/next/development/tools/subkey
i.e. example under:

You can inspect password protected keys either by passing the --password flag or using /// at the end of the mnemonic:

Björn let me know if we need to expand the examples. I tried with the latest subkey and I was able to generate the next:
$ subkey --password "correct horse battery staple" generate
Secret phrase `across inject subway chef clean emotion degree inmate sweet educate raven alien` is account:
  Secret seed:      0x7c1a6f4b7d30d008f9cc15c4b59fedecff394c5141e78c397f33b2b814136ff8
  Public key (hex): 0xd0e0d1a5d24910749794753a371b20a91db94a9419cb19f02b18027b5ea67964
  Account ID:       0xd0e0d1a5d24910749794753a371b20a91db94a9419cb19f02b18027b5ea67964
  SS58 Address:     5GnabtZxTQHr1GAQtK3odBMB2aM5bCkAq92bG6nAHWSWQZKr

Using the generated Secret phrase:
$ subkey inspect "across inject subway chef clean emotion degree inmate sweet educate raven alien///correct horse battery staple"
Secret Key URI `across inject subway chef clean emotion degree inmate sweet educate raven alien///correct horse battery staple` is account:
  Secret seed:      0x7c1a6f4b7d30d008f9cc15c4b59fedecff394c5141e78c397f33b2b814136ff8
  Public key (hex): 0xd0e0d1a5d24910749794753a371b20a91db94a9419cb19f02b18027b5ea67964
  Account ID:       0xd0e0d1a5d24910749794753a371b20a91db94a9419cb19f02b18027b5ea67964
  SS58 Address:     5GnabtZxTQHr1GAQtK3odBMB2aM5bCkAq92bG6nAHWSWQZKr

$ subkey --password "correct horse battery staple" inspect "across inject subway chef clean emotion degree inmate sweet educate raven alien"
Secret phrase `across inject subway chef clean emotion degree inmate sweet educate raven alien` is account:
  Secret seed:      0x7c1a6f4b7d30d008f9cc15c4b59fedecff394c5141e78c397f33b2b814136ff8
  Public key (hex): 0xd0e0d1a5d24910749794753a371b20a91db94a9419cb19f02b18027b5ea67964
  Account ID:       0xd0e0d1a5d24910749794753a371b20a91db94a9419cb19f02b18027b5ea67964
  SS58 Address:     5GnabtZxTQHr1GAQtK3odBMB2aM5bCkAq92bG6nAHWSWQZKr

If I use the Secret phrase without the password it generates a different address.
$ subkey inspect "across inject subway chef clean emotion degree inmate sweet educate raven alien"
Secret phrase `across inject subway chef clean emotion degree inmate sweet educate raven alien` is account:
  Secret seed:      0xf3534715c530db8743746ff662cbc69fb1b95aa8dfb17a008e0098f237bb2cfd
  Public key (hex): 0xce91133e42ba4d46e7ea8144e1b1bcf82f5ba2c6b9bedf2623c958faae491d4f
  Account ID:       0xce91133e42ba4d46e7ea8144e1b1bcf82f5ba2c6b9bedf2623c958faae491d4f
  SS58 Address:     5GjYpP7s5T71RS5ntAPFGEENtC9b7pUT9EDwMn5r2xVpJDEa

I'll push an update to make it more clear and use the same secret phrase. They are not consistent and it could be confusing.


dummy, test bazel master on darwin

@GrahamcOfBorg build bazel.tests

@GrahamcOfBorg build bazel.tests


⚠ Bofrost.fr has degraded performance

In 64f4c7c, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1005 ms

Resolved: Bofrost.fr performance has improved in 1b410af.


Homebridge Warning : TLS to IP Address Deprecation

(node:12323) [DEP0123] DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version.

I am getting the same problem. There is a way to set the TV hostname?

I upgraded the dependencies with the latest patch (v2.0.2). Can you tell me if the warning still shows up for you?


Fix server never starting up sometimes, webhook npe

Summary

Wait for APIResourceSchemas cache to be synced along with APIExports and APIBindings
Fix NPE in webhook code

Related issue(s)
Fixes #1634

Good find!
/lgtm
/approve

/hold
Fixing some stuff I missed

I'm seeing lots of variability with the server maybe starting, maybe not when I add in waiting for APIResourceSchemas to sync. I'd like more time to understand the exact behavior, so in the meantime, I've opened #1639 with just the webhook npe fix.

Closing this for the time being. I may come back to it if it looks like we need it. But it's not mergeable in its current form.
/close


chore: release 1.2.194

:robot: I have created a release *beep* *boop*
1.2.194 (2022-12-27)
Features

docs: new article for build chapter: storage layout (lang:ru) (9afe73c)
docs: new article for build chapter: build process (lang:ru) (7c332ee)
docs: updated usage/build/stapel section (lang:en+ru) (0c504a4)

Bug Fixes

giterminism: false warning about ignoring Dockerfile when using non-root project directory (303a6e4)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/werf/werf/releases/tag/v1.2.194 :sunflower:


pytest tests are not properly displayed if test name contains upper letters

Hello,
I've encountered a little bug recently in the "Tests" tab. I am not 100% sure that the bug is related to vscode or to the python extension.
Environment:

VSCode Version: 1.34.0
OS Version: Windows_NT x64 6.1.7601
Python extension version : 2019.6.24221
settings.json :

{
    "python.testing.pytestArgs": [
        "tests"
    ],
    "python.testing.unittestEnabled": false,
    "python.testing.nosetestsEnabled": false,
    "python.testing.pytestEnabled": true
}

Bug :
When a test file contains an upper letter, it is not displayed properly in the test tab. After running if passed or failed, it is displayed with a "grey question mark".
Steps to Reproduce:

Create an empty project (note : use a conda environment where pytest is installed)
Create a "tests" folder
2.1 Create a test_working.py file

 import pytest

def test_this_one_works():
    assert 1==1

2.2 Create a test_NotWorking.py file with the same code
 import pytest

def test_this_one_works():
    assert 1==1

In the Test tab of vscode, run Discover Tests
If everything ran properly, you should see the following architecture :
-(?) tests

(?) test_notworking.py (with lower case!!!)

(?) test_this_one_does_not_work

(?) test_working.py

(?) test_this_one_works

In the Test tab of vscode, run Run All Tests.
Now I have :
-(green tick ok) tests

(?) test_notworking.py <- BUG  - EXPECTED BEHAVIOUR : should have a green tick and have name in upper case

(?) test_this_one_does_not_work <- BUG - EXPECTED BEHAVIOUR : should have a green tick and have name in upper case

(green tick ok) test_working.py (with lower case!!!)

(green tick ok) test_this_one_works

Remarks :

the tests seem to be ran whatever is displayed (the bug only concerns the user interface) : indeed in the bottom line (where my python version and my environment are shown), I see an icon "two tests passed".
when i run pytest tests in the command line, everything is fine.

Conclusion :
This bugs is not critical at all since it only concerns te UI, but in my old projects I can't see the tests in the UI (while it used to work perfectly fine few weeks ago). I definitely do not want to change the names of the scripts (the tests scripts are a mirror of the scripts names of my project).
Any hope this would be easy to fix?
Many thanks for reading and any further help !
Galileo

Please provide a screenshot that shows the problem.

Hello @weinand,
many thanks for the fast answer. You can see two red boxes in pictures below : at the bottom of my IDE, two tests are marked as passed, but there is no green tick near the "test_NotWorking.py", and its name has been converted into lower case.

I'm at your disposal to provide as many additional information as needed.

This is an issue with the test extension you are using. Please file the issue in their repository.


runtime/pprof: TestStackBarrierProfiling flaky on linux-arm

On build.golang.org at the moment, linux-arm builds have failed 6 times on the front page, all due to this TestStackBarrierProfiling failure:
--- FAIL: TestStackBarrierProfiling (5.08s)
	pprof_test.go:342: subprocess failed with exit status 1:
		--- FAIL: TestStackBarrierProfiling (5.02s)
			pprof_test.go:97: profile too short: [0x0 0x3 0x0 0x2710 0x0 0x0 0x1 0x0]
		FAIL
FAIL
FAIL	runtime/pprof	15.412s

http://build.golang.org/log/e65672824d6a674ea5d3281ae0c52a269283446f
http://build.golang.org/log/82d27007b1060f62d3ed9ef7c80dd0deb1fbfe8a
http://build.golang.org/log/8fe20cf43733befab66e42326f23727d1d923f07
http://build.golang.org/log/544dd7f74f4fcc8ec46b6ec8c254337146cf7f09
http://build.golang.org/log/979e69618860a68ed8f91c98613d1f4cf3346037
http://build.golang.org/log/92ffe2d467cb2306b9758d1d7672ba8c86d4b140

This has happened a few times before this test was ever introduced, though they're probably unrelated:
2015-02-27T23:31:36-c2025c4/windows-amd64-gce
2015-03-13T22:46:56-f52b234/windows-amd64-gce
2015-09-02T05:58:52-5f2cda5/windows-amd64-2003kardianos
This particular failure really just means that there weren't any samples. @minux, @davecheney, any idea what could be causing zero profiling samples in TestStackBarrierProfiling specifically on linux/arm?

This is happening on trybots, which suggests that these are scaleway VMs. Is that right, @bradfitz?
Maybe the scaleway VMs have a profiling issue. Have we seen this on real hardware?

They are on Scaleway but Scaleway has no virtualization. Every instance is the same size and on physical hardware.

To reproduce:
VM=$(gomote create linux-arm)
gomote push $VM
gomote run $VM /bin/sh -c 'PATH=$PWD/go/bin:$PATH; cd go/src && ./make.bash && cd runtime/pprof && go test -c'
gomote run $VM /bin/sh -c 'PATH=$PWD/go/bin:$PATH; cd go/src/runtime/pprof; while GODEBUG=gcstackbarrierall=1 GOGC=1 ./pprof.test -test.run TestStackBarrierProfiling -test.v; do true; done'

It usually only takes a few iterations.
It appears there's nothing particularly special about the iterations that do fail. The successful ones are on the order of two to ten samples, despite running for 5 seconds. There's some distribution around that, so sometimes it gets zero samples.
This failure requires all three of GOGC=1, TestStackBarrierProfiling, and arm. On arm, without GOGC=1 or with TestMathBigDivide, we get ~100 samples (which is still ~5x less than expected, but at least it isn't almost zero). On amd64, the test gets 600–700 samples.

According to strace (run on an ARM Chromebook; on gomote strace makes it unreproducible), we're making what appear to be reasonable calls to setitimer and rt_sigprocmask, yet when the test fails the kernel hasn't sent us any SIGPROFs (it's not just that we're failing to process them).
This appears to be related to STW GC phases. The test spends ~50% of its time in GC and most of that is in STW phases. Forcing full STW with GODEBUG=gcstoptheworld=1 significantly reduces the number of collected samples. Even with GOGC=100, it usually only collects 10–20 samples. With STW and GOGC=1, the test always fails.
GOMAXPROCS also significantly affects the test. Setting GOMAXPROCS=1 fixes the test, even with STW GC, and yields ~500 samples in 5 seconds, which is the expected number. GOMAXPROCS=2 yields ~100 samples in 5 seconds. Usually I'm running with GOMAXPROCS=4.
Clearly the kernel doesn't know the runtime is in a STW GC phase, so there's something different about the process' behavior when it's in STW GC that's interacting with the kernel's profiling signals.

This has something to do with sleeping. If I force getfull to osyield instead of usleep(100) when it's out of work and disable the usleep(100) in runqgrab, all of these problems go away and I start getting 600–700 samples, just like on amd64. Disabling one or the other isn't sufficient.

This is a result of ARM's poor timer hardware and some strange design decisions in the Linux kernel.
First, Linux/ARM (at least the 3.2 kernel on the Scaleway machines the builders use [1]) is totally incapable of sleeping for 100 microseconds. A usleep(100) gives up the entire 10ms scheduling quantum, even if there's nothing else to run. This is probably because, according to /proc/timer_list, all of the timers have a resolution of 10ms (compare this to, say, linux/amd64, where the resolution is 1ns).
This alone doesn't explain why we aren't getting profiling signals; we still rack up about 2.3 seconds of CPU time during the 5 second test. However, ITIMER_PROF is fired by update_process_times, which checks to see if the current process' user plus system CPU time has passed the firing threshold. update_process_times is called by the system tick (specifically tick_nohz_handler in this case). We usleep roughly 1,200 across the various threads (there are ~4 active threads, so that's ~3 wall clock seconds of 10ms sleeps, which adds up almost perfectly with the 2.3 seconds of CPU time), so it's likely we usleep in every single scheduling quantum and hence always give away our time slice. As a result, there's never a running process when update_process_times runs. Even though the process racks up more than enough CPU time according to /proc/self/stat, update_process_times just never looks at it and thus never fires a SIGPROF.
[1] Scaleway kernel configuration is here: https://github.com/scaleway/kernel-tools/blob/master/armv7l/3.2.34-std/.config . Notably, CONFIG_HZ=100, which is where the 10ms scheduling quantum comes from, and CONFIG_HIGH_RES_TIMERS is not set.
/cc @dvyukov @RLH in case either of you have insights on what to do about this 100us sleeps.

What about OpenBSD? Same?
e.g. https://storage.googleapis.com/go-build-log/0d6af514/openbsd-386-gce56_34e7441c.log

What about OpenBSD?

Probably. I can't say about the signal firing aspect without digging in to the OpenBSD kernel, but I tested usleep(100) and it takes 20 ms on OpenBSD (!).

What about OpenBSD?

Yes, the logic in OpenBSD for triggering signalling profiles has exactly the same problem Linux's does. I bet Solaris does the same thing.
I ran https://go-review.googlesource.com/18251 through the trybots to see what else has poor usleep resolution and this seems to be the whole list.
(FWIW, I also checked the timer support on my Android phone and it actually supports 1ns resolution like linux/amd64, so it's not all linux/arm that's necessarily broken.)

One solution is simply to ignore this problem, say that profiling won't work very well on these platforms, and wait for them to catch up. This sounds like a cop-out, but I think it's reasonable because:

The linux/arm builders are using an old kernel (in fact, the oldest supported Scaleway kernel). Every newer Scaleway kernel supports high-res timers. (https://github.com/scaleway/kernel-tools/tree/master/armv7l)
As far as I can tell, every Raspberry Pi kernel (both v1 and v2 and even the "cut-down" kernels) has supported high-res timers. (https://github.com/raspberrypi/linux/tree/rpi-4.4.y/arch/arm/configs bcmrpi_defconfig for v1, bcm2709_defconfig for v2 and true all the way back to 3.2)
OpenBSD and Solaris are second-class ports and there's evidence that only some Solaris platforms actually have trouble with short sleeps (so those, too, will probably go away).
It's 2016. 10 ms is an eternity and it's reasonable to expect decent timer support.

That said, I would like to eliminate the usleep(100) from getfull because it's bad for other reasons. However, the usleep in runqgrab is a good idea (assuming the OS can do it), which makes that one much harder to eliminate.
Another alternative is to try to detect if usleep(100) actually works when the runtime starts up, but I don't know how to do this reliably on a system that may be loaded.

Per discussion yesterday, let's disable the tests and then document the
issue and wait for obsolete operating systems to fix themselves.

I updated the title but I'm going to create a whole new issue instead.

I've moved eliminating the usleep(100) from getfull (for reasons in addition to this issue) to #13842.
Should we close this issue as resolved, or do we want to hold it open until we can eliminate (or at least narrow down) the list of excluded platforms in TestStackBarrierProfiling?

I sent https://golang.org/cl/18257 for the documentation.
On Wed, Jan 6, 2016 at 10:28 AM, Russ Cox<EMAIL_ADDRESS>wrote:

Per discussion yesterday, let's disable the tests and then document the
issue and wait for obsolete operating systems to fix themselves.

Fine to close.


reverted hand mesh change so it reappears on toggle

Overview
Reverted a change that prevented the hand mesh from updating and reappearing after being toggled
Changes

Fixes: #7871

@Troy-Ferrell the change I made reverted a change you made to when MRTK decides to update its hand mesh. I'm not too clear on the context of the original change (it looks like its for performance reasons), but is it general expensive to update the mesh on every call? From what I can tell, root of the error is the mesh not getting redrawn after being turned off due to the code not triggering the meshChanged flag

/azp run


Validate should fail when no roles are configured

In YACE, when the environment configured role is desired, no roles configuration is added in each job. The Load function is responsible for configuring in the Roles field an empty role struct.
However, when using yace as library, this has to be done manually. Even more, Validate succeeds if no roles at all are configured, making YACE to run without even scraping anything due do that main loops iterate over all roles.
This PR makes Validate fail when no roles are configured (not even the empty one).

Thanks!


Missing typescript definitions

Could you a d.ts typescript definitions file?

I made a complete TypeScript rewrite. Added the definitions in https://github.com/riebel/pixi-tiledmap/releases/tag/1.10.0


Add T.35 metadata support.

This currently only adds a Rust API. Note that this is a breaking
change as it extends the publicly visible "params" struct.
The T.35 metadata support in AV1 is very flexible - this is
intended in particular for T.35 metadata attached to frames,
in the style of the AV1 HDR10+ metadata specification:
https://aomediacodec.github.io/av1-hdr10plus/

Coverage decreased (-0.4%) to 85.043% when pulling 26c3e3b6c0844badfc69dd569a6f79d0cb4f4a48 on tdaede:t35 into 7e5c3f24e3a7977b7d3ea1f108c884859050d984 on xiph:master.

Does this extend to DV support? Asking for a friend. This is amazing btw.

It probably works for DV, it is not something I have looked at though.

If we're going to do a major release soon where we are ok with API breakage then let's land this.

Let's land it :)

Codecov Report

Merging #2968 (5552007) into master (5518c59) will decrease coverage by 0.03%.
The diff coverage is 72.88%.

@@            Coverage Diff             @@
##           master    #2968      +/-   ##
==========================================
- Coverage   86.58%   86.55%   -0.04%
==========================================
  Files          87       87
  Lines       33714    33822     +108
==========================================
+ Hits        29192    29275      +83
- Misses       4522     4547      +25

Impacted Files
Coverage Δ

src/api/context.rs
41.26% <ø> (ø)

src/api/lookahead.rs
42.21% <0.00%> (-2.19%)
:arrow_down:

src/encoder.rs
87.41% <50.00%> (-0.27%)
:arrow_down:

src/header.rs
68.93% <84.61%> (+0.26%)
:arrow_up:

src/api/internal.rs
97.53% <100.00%> (-0.15%)
:arrow_down:

src/api/test.rs
99.23% <100.00%> (+0.01%)
:arrow_up:

src/api/util.rs
59.45% <100.00%> (+0.55%)
:arrow_up:

src/frame/mod.rs
100.00% <100.00%> (+4.00%)
:arrow_up:

src/tiling/tile_state.rs
89.13% <0.00%> (-0.73%)
:arrow_down:

... and 5 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Wallet primitive serialization

I added a trait and implementations of synthetic key derivation for secret keys and public keys, similar to what I had on the wallet-dev branch.


ol.Collection with ol.source.Cluster performance

I am displaying 1000+ features on the map. Every n seconds I'm making an ajax request for brand new set of data, clearing everything on the map and then adding new features. Before I used plain js array as container for the features and everything worked ok. Then I decided to use ol.Collection instead. The performance dropped drastically from few milliseconds to few seconds. The most weird part is, that everything works fine at first load, then after ol.Collection.clear() it goes down. I tried different ways of clearing the source as well as collection, but to no avail. As a source I am using ol.source.Cluster. The worst scenario is using ol.Collection together with ol.source.Cluster. Much better, but not perfect is using ol.Collection with ol.source.Vector. This last scenario takes roughly tens of milliseconds. So I thing that the primary cause of the problem is the ol.Collection, but ol.source.Cluster is significantly spicing the things up and the UI is stuck for several seconds. Test cases with console output are provided below.
plain array + ol.source.Cluster (working well)
http://jsfiddle.net/aj0bmaqr/1/
ol.Collection + ol.source.Cluster (huge performance hit)
http://jsfiddle.net/5zfw49gz/2/
Note: You need to zoom in to see more features, then the performance is worst.

Each time the ol.Collection is changed (i.e. items are added or removed) then ol.source.Cluster will re-run the cluster operation.  If you  clear() an ol.Collection that is used by an ol.source.Cluster() it will perform a cluster operation once for each item that is being removed.  This does not happen when you use a plain array since it does not fire any events on additions or removals.

The performance issue is not when the ol.Collection is clearing. It's exactly when it is filled again, either by push method for each feature or by extend of temp plain array. But not when it is filled for the first time, only each time afterwards. There is a console with output, you can see that the time measured in milliseconds is only computed for adding feature to collection. And for the first time it takes couple of milliseconds but then it goes to several seconds.

I have a similar  problem when i make a lot of push/remove/geometry edit on ol.Collection combined with ol.source.Cluster. I think the problem is because for every single(one by one) mentioned action, ol.Colection triggers an event(add, remove, change) which is caught by the cluster which makes an internal extensive task - ol.source.Cluster.prototype.refresh_(). A solution is to add methods which doesn't  trigger these events or capabilities to remove the default events, and let the user to manual make a refresh after all operations are made. In this case all changes are processed at once, not one by one.
There is a related question asked by me on stackoverflow : https://stackoverflow.com/questions/44257236/disable-ol4-some-default-event-listeners?noredirect=1#comment75567490_44257236

I recreated the issue over a month ago with more specific description and fiddle usecases.
I can get along with the fact, that the collection gets slower with each new item in it. But this is not what bothers me that much.  You can completely clear the collection and it still gets slower.  There must be some object-event leak undetected by clear method. The only solution is to create completely new collection and that requires you to recreate also the cluster.

I have this problem also, and i might have an explanation for it too. When your create a new cluster, and add elements, it might not be yet attached to map when you do those operations(in your case clear), thus all events are ignored or easy to pass. Keep in mind that when you do ol.Collection.clear(), you will end up triggering an event for each removed element (see  this.dispatchEvent(new ol.Collection.Event(ol.CollectionEventType.REMOVE, prev)) from ol.Collection.removeAt() which is called from .clear method for each element) which leads to my previous mentioned issues.

Closing in favor of #6768. My advice: Don't use ol.Collection on an ol.source.Vector when all you need to do is replace the whole set of features. Do the following:
cluster.getSource().clear();
cluster.getSource().addFeatures(newFeatures);