Undo type check in BSR#registerIfAbsent()

Reverts a type check recently added that would throw an error with a descriptive message when an attempt was made to register a build service with a name that was already in use but the types were different.
The message was helpful but it broke scenarios where people wouldn't be affected by ClassCastExceptions due to our classloader model (such as build services that are just event listeners).
Fixes: #23204

@bot-gradle test and merge

I've triggered a build for you.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

I've triggered a build for you.


Add room persistence and fix bugs

Major changes

Matches now match by a random hash generated from the matching-service-api. The hash is propagated to both the client and the matching-service - the client uses this hash to query the storage blob. Resultingly, the match result now also stores the user ID of the person who initiated the match under the match hash.
The collab service now adds persistence to the room via a 3rd Redis instance - this room currently does not expire, at all, allowing for infinite reconnects. This should be a good to change.
Matches are now immediately destroyed the moment the collab service takes over the room, as the room is "moved" to the persistent service.
The client no longer has a pop-up to tell them of a successful match. Instead, the client is immediately redirected to the collab service. To implement this, a disable property is added to the PeerprepButton element, to prevent users from clicking the button during redirection.

Known Bugs

Closing the room does not destroy the persistent room right now.
Changing to a random hash exposed an existing bug where a user could have matched to a cancelled user and be redirected to a collab service. It is more serious on this merge, as the user can match with themselves due to the matching hash being unique between subsequent calls. A viable fix would be to have the cancellation call propagate to the matching-service-api, as cancellation on the frontend does not do anything right now.

Issues have not been raised from this commit yet. To anyone merging this, please help raise them!

https://github.com/CS3219-AY2425S1/cs3219-ay2425s1-project-g14/tree/post-ms6


Linear scale: use suggested limits as defaults

Fixes: #6811

Added a test, used valueOrDefault and removed redundant !isNaN checks.


linen api:  no check on  variables and param shapes coherence

Problem you have encountered:
When performing transfer of params to a module it is possible to feed the module with params that do not have proper shape
from flax import linen as nn
from jax.config import config
from jax import random

config.enable_omnistaging()

key1, key2 = random.split(random.PRNGKey(0), 2)
x = random.uniform(key1, (1,3,3,1))

conv_module_5 =nn.Conv(features=5,kernel_size=(3,3))
param_features_5 = conv_module_5.init(key2, x)

conv_module_3 =nn.Conv(features=3,kernel_size=(3,3))

 # this should raise an error
y = conv_module_3.apply(param_features_5, x)

assert y.shape[3] == 3, "module output has improper shape"

What you expected to happen:
I would expect an error while feeding the conv_module_3 with improper shape.
Steps to reproduce:
Here is a colab
https://colab.research.google.com/drive/1Y7WOXjxgkYPldyzPQBcP5PdtEY6EPEAX?usp=sharing

Thanks for the report @mortner31 -- this is due to the logic in https://github.com/google/flax/blob/76d580dbc157ac8065be46665e17790c74f92ed5/flax/linen/module.py#L422, where we don't assume any special treatment for the additional arguments passed to the initializer function (other than the RNG).
Current Flax actually has the check that you're asking for, by hardcoding that the first argument is a shape. That harms generality a bit, and was even discussed for current Flax in #160 -- note that in that issue:

One thing is that we'd lose the shape checking in Module.params, but that seems like the kind of check which should be part of a test anyway.

(I'm not sure I agree with the point above -- being realistic, much research code doesn't have tests and it's unfortunate to require tests to catch issues that could be caught earlier)
So now I'm no longer sure I support #160, and perhaps you're right and we should special case the first argument to self.param (and probably self.variable at that point?) to be a shape, and bring back the shape equality check.
But should we do that by re-adding a shape argument explicitly? Or by inspecting the first argument of *init_args (in case there are arguments?). I'm not totally sure.
Another possibility, which I'm not sure entirely about, is to add an else clause here: https://github.com/google/flax/blob/76d580dbc157ac8065be46665e17790c74f92ed5/flax/core/scope.py#L255, to say -- even if the variable is present, run the initializer function with a fake PRNG, just to see that you get the same shape. IIUC, because shapes are known during tracing, that code will not be present in the compiled JAXPR, meaning the accelerator code won't be impacted. But compilation will become a bit slower. We could also consider something like this in "DEBUG" mode.
Roping in @jheek who thought a lot about this when building current Flax.

cc @levskaya for opinions as well.

Actually I think we can make the check more powerful than the original one. Before we forced a static shape argument and checked that with the shape of the type. This had a number of issues:

The shape could not be determined by the init function
Shape checks could not be more complex than a single array. So no possibility shape check a pytree for example.

What we can do instead is use jax.eval_shape to check whether the initializer would still return a result with the same shape and dtype. The only complexity here is that we should make sure the check doesn't actually require or split PRNG sequences.

@jheek -- that sounds pretty good! Is this something you're working on?

This is also related to #86

This is also related to #160

Oh, I believe this was resolved in #530


Problems view should be refreshed when files are moved

VSCode Version: Code - Insiders 1.3.0-insider (a2b9738a942237b59cb920940b93a0206f1b61d0, 2016-07-01T19:24:33.352Z)
OS Version: Linux x64 4.4.0-28-generic, Ubuntu 16.04

Steps to Reproduce:

Get a file with errors in the problems view
Move the file to another folder via drag and drop in explorer
Open problems
Click one of the problems

This issue was moved to Microsoft/vscode-eslint#96


[MINOR][SQL] Check json_tuple does not truncate results

What changes were proposed in this pull request?
I propose to add a test from the commit https://github.com/apache/spark/commit/a9365221133caadffbbbbce1aae1ace799a588a3 for 2.4. I extended the test by a few more lengths of requested field to cover more code branches in Jackson Core. In particular, the optimization calls Jackson's method https://github.com/FasterXML/jackson-core/blob/42b8b566845e8f8d77537f51187a439029ed9bff/src/main/java/com/fasterxml/jackson/core/json/UTF8JsonGenerator.java#L742-L746 where the internal buffer size is 8000. In this way:

2000 to check 2000+2000+2000 < 8000
2800 from the 2.4 commit. It covers the specific case: https://github.com/FasterXML/jackson-core/blob/42b8b566845e8f8d77537f51187a439029ed9bff/src/main/java/com/fasterxml/jackson/core/json/UTF8JsonGenerator.java#L746
8000-1, 8000, 8000+1 are sizes around the size of the internal buffer
65535 to test an outstanding large field.

Why are the changes needed?
To be sure that the current implementation and future versions of Spark don't have the bug fixed in 2.4.
Does this PR introduce any user-facing change?
No
How was this patch tested?
By running JsonFunctionsSuite.

Test build #114176 has started for PR 26613 at commit f19de63.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/19028/
Test PASSed.

Test build #114176 has finished for PR 26613 at commit f19de63.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/114176/
Test PASSed.


Unit Testing

Simple Test Suites for all Components. Now you cant commit any changes that would break the render.
@JesseRWeigel Merge previous PRs first.
Anyone can make PR with more testing. I am newbie in case of testing.
 It is nice to see all the passing tests when I commit.


Should the containerd-config.toml file have discard_unpacked_layers set to true by default

Environment:

AWS Region: All
Instance Type(s): All
EKS Platform version (use aws eks describe-cluster --name <name> --query cluster.platformVersion): Any version using containerd
Kubernetes version (use aws eks describe-cluster --name <name> --query cluster.version): Any version using containerd
AMI Version: Any version using containerd
Kernel (e.g. uname -a): NA
Release information (run cat /etc/eks/release on a node):

BASE_AMI_ID="ami-044dcf122cb58da69"
BUILD_TIME="Mon Jul  3 03:32:16 UTC 2023"
BUILD_KERNEL="5.4.247-162.350.amzn2.x86_64"
ARCH="x86_64"

Issue:
The issue here is that the configuration used for containerd can result in significantly increased disk usage because containerd will store both the packed and unpacked layers which in the case where the image does not compress well as a tarball can result in increased utilization of the root volume.  To see this in action you can used these commands [1] to make a dockerfile as the random data will not compress well.
The workaround is to create your own containerd config file then add discard_unpacked_layers = true to the plugins."io.containerd.grpc.v1.cri".containerd section.  Then pass this to the bootstrap command using the --containerd-config-file after putting the file on the instance, usually by downloading from S3 although a custom AMI could also be used.  However, this seems like a lot of work just to bring containerd in line with the space usage of docker.  Which bring us to the question, should the containerd-config.toml file have discard_unpacked_layers set to true by default?

[1]
mkdir /var/lib/docker/cstest
cd /var/lib/docker/cstest
dd if=/dev/urandom of=testfile.img bs=$((1024*1024)) count=1007
dd if=/dev/urandom of=testfile2.img bs=$((1024*1024)) count=2015
dd if=/dev/urandom of=testfile3.img bs=$((1024*1024)) count=2015
cat > Dockerfile <<EOF
FROM ubuntu
COPY ./testfile.img /testfile.img
COPY ./testfile2.img /testfile2.img
COPY ./testfile3.img /testfile3.img
CMD ["/bin/bash","cat testfile.img"]
EOF

I think it makes sense to enable this by default. You'd only need the unpacked layers if you plan to push the image later on; which shouldn't be a common case on a Kubernetes node.


Identity sample has broken links to source code

The sample app for the Chrome Identity API has broken links to source code on GitHub.
For example, here's one of the in-app links (which gives a 404):
https://github.com/GoogleChrome/chrome-app-samples/tree/master/identity/identity.js#L44-L87
Instead of the above, the correct link seems to be this:
https://github.com/GoogleChrome/chrome-app-samples/blob/master/samples/identity/identity.js#L44-L87

Hello Sascha,
You're right, I'm gonna fix URL at https://github.com/GoogleChrome/chrome-app-samples/blob/eda97b55e66198fcf889eb9a4e7e2e755c92bdfe/samples/identity/sample_support/show_snippets.js#L69

Oh, I'll gladly send you a patch... just a few minutes, pull request is coming.

Thanks Sascha,
It looks like this file is pulled from somewhere else: https://github.com/GoogleChrome/chrome-app-samples/blob/eda97b55e66198fcf889eb9a4e7e2e755c92bdfe/samples/identity/sample_support/README.md
ATTENTION contributors: this directory (sample_support) should not be changed. It is automatically updated and should not contain anything that is specific to this sample.

@mangini might know the upstream source for chrome-app-samples/samples/identity/sample_support?

Fixed, thanks!

Thank you Renato!
Just updated webstore item at https://chrome.google.com/webstore/detail/identity-api-sample/oficlfehfenioickohognhdhmmcpceil


feat: add pyproject.toml file

I want to import your package into my project instead of forking it.

Fix this comment : https://github.com/sarperavci/CloudflareBypassForScraping/issues/5#issuecomment-2166083435


Scrape official state of New Mexico vaccine data

Public URL: https://cvvaccine.nmhealth.org/public-dashboard.html
REST API: https://cvvaccine.nmhealth.org/api/GetCounties

Going to merge with my changes but when you have a minute (@jrybacek) will you sanity check my change of the variable... Their naming convention is a strange one relative to other dashboards and I just want to get a second pair of eyes to confirm.


Initial contents and basic theme

please check below image files' dimensions.
android-chrome-512x512.png, apple-touch-icon.png

I fix it and checked all dez images.


argoCD vault plugin does not connect to TLS enable vault

argoCD` vault plugin does not connect to TLS enable vault
I am trying to connect to Enterprise version of Hashicorp vault using argocd vault plugin.
Here is my application.yaml looks like, as per the error message its clear that communication is broken due to  certificate signed by unknown authority
Error:
Unable to create application: application spec for vault-test is invalid: InvalidSpecError: Unable to generate manifests in vault-test: rpc error: code = Unknown desc = argocd-vault-plugin generate ./ failed exit status 1: Error: Put https://iacvault-temp.iachelloworld.dev.abc.com:8200/v1/auth/kubernetes/login: x509: certificate signed by unknown authority Usage: argocd-vault-plugin generate  [flags] Flags: -c, --config-path string path to a file containing Vault configuration (YAML, JSON, envfile) to use -h, --help help for generate -s, --secret-name string name of a Kubernetes Secret in the argocd namespace containing Vault configuration data in the argocd namespace of your ArgoCD host (Only available when used in ArgoCD). The namespace can be overridden by using the format : --verbose-sensitive-output enable verbose mode for detailed info to help with debugging. Includes sensitive data (credentials), logged to stderr
`apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: 'vault-test'
spec:
destination:
server:  'https://kubernetes.default.svc/'
source:
repoURL: 'https://bitbucket.abc.com/scm/~ping/cicd.git'
path: vault-test
targetRevision: HEAD
plugin:
name: argocd-vault-plugin
env:
- name: AVP_K8S_ROLE
value: vplugin
- name: AVP_TYPE
value: vault
- name: VAULT_ADDR
value: 'https://iacvault-temp.iachelloworld.dev.abc.com:8200/'
- name: AVP_AUTH_TYPE
value: k8s
project: 'default'
`

Related issues:
https://github.com/argoproj-labs/argocd-vault-plugin/issues/456
https://github.com/argoproj-labs/argocd-vault-plugin/issues/52
You can use any Vault environment variables such as:
VAULT_CACERT
VAULT_CAPATH
VAULT_CLIENT_CERT
VAULT_CLIENT_KEY

can be closed


Fix JSON golden test warnings.

Issue Number
None.
Summary
This PR fixes the WARNING: Encoding new random samples do not match warnings currently produced by our JSON golden tests.
These warnings can appear if either of the following conditions is true:

The underlying type has widened, and the JSON golden file no longer reflects all aspects of the type.

Example: a new optional field is added to a record type, but the JSON golden file does not include examples with that field.
Example: a field type has changed from Natural to Integer, but the JSON golden file does not include examples with negative values for that field.

The distribution of values produced by the QuickCheck generator for that type has changed.

Process Followed

Identify the set of types for which JSON golden data files are out-of-date:
$ cabal run cardano-wallet:test:unit -- --match "produces the same JSON" | grep -i warning
WARNING: Encoding new random samples do not match lib/wallet/test/data/Cardano/Wallet/Api/Foo.json.
WARNING: Encoding new random samples do not match lib/wallet/test/data/Cardano/Wallet/Api/Bar.json.
WARNING: Encoding new random samples do not match lib/wallet/test/data/Cardano/Wallet/Api/Baz.json.
...

Delete the out-of-date files:
$ rm lib/wallet/test/data/Cardano/Wallet/Api/Foo.json
$ rm lib/wallet/test/data/Cardano/Wallet/Api/Bar.json
$ rm lib/wallet/test/data/Cardano/Wallet/Api/Baz.json
...

Generate new golden files:
$ CREATE_MISSING_GOLDEN=TRUE cabal run cardano-wallet:test:unit -- --match "produces the same JSON"

Verify that the warnings no longer appear:
$ cabal run cardano-wallet:test:unit -- --match "produces the same JSON" | grep -i warning
(no output)

Manually verify that the updated JSON golden files are correct.

bors r+


Instructions

Hi,
could you please add more instructions how to use it?
Thanks

I made a wiki of py2rb usage example.
Will this be your helpful?


Update conferences.md - React Rally

Added React Rally 2023 conference to upcoming conferences list both current and beta docs

Closed due to newer PR


Problems with learming Vulkan

Hello. Can you present SFML (or SDL) version, with single file (main.cpp) realization?
And please, sort descriptions declaration sequentionally.
Allowed: functions, GLM, GLI, SFML or SDL,  single file (main) .
Need hello triangle sample.

College homework?

I just plan to write more complex example - smallpt.

After I finish my exams ( so, next week ) I'll work on and post some Vulkan examples that use only GLFW ( and assimp for 3d objects ), but I've still not decided if it will be pure C11 or C++14 with classes and GLM.

assimp is too huge, for static objects, I would recommend https://github.com/syoyo/tinyobjloader

I have no problems with assimp. I have problems with understand vulkan. I
compare with directx 12, and can't understand what is "pool"?! In DirectX
we can get cbv offset, and use part. In Vulkan I can't understand system. I
think directx 12 idea slightly simpler.

And... I look to vulkan from dx12 point, because 6 month I learned only
dx12 code. So I can understand only with accurate comparsion with directx
12.

@acterhd : If you need a single file example, please take a look at the cube.c and tri.c examples from the LunarGSDK.

@acterhd : Also take a look at this great article by Baldur Karlsson : Vulkan in 30 minuts
Perfect starting point if you want to learn Vulkan from the ground up

I want C++ wrapper for Vulkan API...

@acterhd : Please take a look at this : https://developer.nvidia.com/open-source-vulkan-c-api


fix: dependencies 2023-10-16

Contributes to

:tada: This PR is included in version 1.0.13 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


TypeError: Cannot read property 'pb' of undefined

When trying to connect my local copy of CP to new bluemix blockchain instance running v.6 I get the following error while running gulp command:
chain_setup.js successfully got registrar. Enrolling with secret: 4acb17630f
chain_setup.js Successfully enrolled registrar
chain_setup.js using registrar to deploy chaincode
chain_setup.js will wait for 80 seconds after deployment for chaincode to startup
chain_setup.js Deploying commercial paper chaincode as: WebAppAdmin
chain_setup.js Deployment request: {"fcn":"init","args":["a","100"],"chaincodePath":"chaincode/","certificatePath":"/certs/peer/cert.pem"}
**C:\Users\IBM_ADMIN\git\cp-web\node_modules\hfc\lib\hfc.js:1011
tx.pb.setNonce(self.nonce);
^
TypeError: Cannot read property 'pb' of undefined
at C:\Users\IBM_ADMIN\git\cp-web\node_modules\hfc\lib\hfc.js:1011:19
at TransactionContext.getMyTCert (C:\Users\IBM_ADMIN\git\cp-web\node_modules\hfc\lib\hfc.js:1057:20)
at TransactionContext.execute (C:\Users\IBM_ADMIN\git\cp-web\node_modules\hfc\lib\hfc.js:1004:14)
at C:\Users\IBM_ADMIN\git\cp-web\node_modules\hfc\lib\hfc.js:943:29
at C:\Users\IBM_ADMIN\git\cp-web\node_modules\hfc\lib\hfc.js:1155:24
at C:\Users\IBM_ADMIN\git\cp-web\node_modules\hfc\lib\hfc.js:1279:28
at WriteStream. (C:\Users\IBM_ADMIN\git\cp-web\node_modules\hfc\lib\sdk_util.js:163:16)
at emitOne (events.js:101:20)
at WriteStream.emit (events.js:188:7)
at WriteStream. (fs.js:2109:12)**
Please advise

I believe I may have seen this earlier today when I was trying to deploy the 2.0 branch of the cp-web app to my v0.5.3 network.  Sadly, I deleted the network and redeployed a new 0.6.1 network so can't easily verify now.  Can you verify the branch of cp-web you cloned and that your mycreds.json file is pointing to your new 0.6.1 network?

I'm using master branch and yes I confirmed my credentials are from the new blockchain service using 0.6.1

Pulled in the latest changes from Nov. 11th and now I'm getting the following after running npm install (I'm on Windows 7) ...
C:\Users\IBM_ADMIN\git\cp-web>npm install

<EMAIL_ADDRESS>install C:\Users\IBM_ADMIN\git\cp-web\node_modules\hashtable
node-gyp configure build

C:\Users\IBM_ADMIN\git\cp-web\node_modules\hashtable>if not defined npm_config_node_gyp (node "C:\Users\IBM_ADMIN\AppData\Roaming\npm\node_modules\npm\bin\node-gyp-bin\.
...\node_modules\node-gyp\bin\node-gyp.js" configure build )  else (node "" configure build )
gyp ERR! configure error
gyp ERR! stack Error: Can't find Python executable "python", you can set the PYTHON env variable.
gyp ERR! stack     at failNoPython (C:\Users\IBM_ADMIN\AppData\Roaming\npm\node_modules\npm\node_modules\node-gyp\lib\configure.js:449:14)
gyp ERR! stack     at C:\Users\IBM_ADMIN\AppData\Roaming\npm\node_modules\npm\node_modules\node-gyp\lib\configure.js:404:11
gyp ERR! stack     at C:\Users\IBM_ADMIN\AppData\Roaming\npm\node_modules\npm\node_modules\graceful-fs\polyfills.js:264:29
gyp ERR! stack     at FSReqWrap.oncomplete (fs.js:123:15)
gyp ERR! System Windows_NT 6.1.7601
gyp ERR! command "C:\Program Files (x86)\nodejs\node.exe" "C:\Users\IBM_ADMIN\AppData\Roaming\npm\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" "c
onfigure" "build"
gyp ERR! cwd C:\Users\IBM_ADMIN\git\cp-web\node_modules\hashtable
gyp ERR! node -v v6.9.1
gyp ERR! node-gyp -v v3.4.0

The above error means that it wasn't able to find the python executable. Following might help:
http://stackoverflow.com/a/15126180/3853465

I actually ended up following http://stackoverflow.com/questions/21365714/nodejs-error-installing-with-npm, by running 'npm install --global --production windows-build-tools' and that seemed to resolve the issues I was seeing.  I'm now able to connect my local cp-web application to my blockchain bluemix v.6.1 service and launch the http://localhost:3000/login

Thank you for the update


Migrate "infra-mirror-bucket" project from govuk-aws

This migrates the related terraform to manage the govuk-mirror buckets from https://github.com/alphagov/govuk-aws.
This changes the IAM User used by GCP to a federated IAM Role that can be assume. This helps eliminate the need for long lived credentials.

Apart of https://github.com/alphagov/govuk-infrastructure/issues/1127

We can ignore the failure in staging - as it'll just create the new resources, instead of importing.


Enable gather fusion by default

After https://github.com/iree-org/iree/pull/19227 landed, gather fusion should be supported by all backends and can be enabled by default.

cc @manupak

@MaheshRavishankar here's the PR enabling gather fusion

I didnt think SDXL had a gather... Thanks! cc @manupak  looks like gather fusion causes an error with sdxl... can you take a look at the issue with gather fusion on SDXL... (might be unrelated though)

I ve filed the issue why this fails here : https://github.com/iree-org/iree/issues/19353
We can continue the discussion there.

Update: @IanWood1 its a warp reduction pipeline issue where its picking the reduction size as the tile size currently. Im not sure why we did not see this when gather fusion is disabled.

update :  so its creating a tile_size buffer in shared memory and use a single thread to perform the gather into it.
This is a deficiency in WarpReduction pipeline it seems. We might just want to disable gather fusion for WarpReduction for now. @Groverkss is working on getting matvec working via VectorDistribute


Add random spatial and intensity transforms

It would be very helpful to have support for various spatial and intensity transforms, similar to what is already available in torchio transforms and MONAI. Supporting torchio in eisen-extras may be the most sensible way to go, imo.
The specific transforms I am interested in include:

random affine (3D, 4D)
random elastic deformation (3D, 4D)
random shift and crop (3D, 4D)
random noise, ideally with specified distribution (3D, 4D)
random flips (3D, 4D)

Note: 4D in my definition means supporting multichannel data (e.g. T1 and T2 channel) and applying the same 3D transform to each channel.

Let me know if you need anything :)

Awesome, thanks!

@fepegar would you be okay with having wrappers that facilitate use of TorchIo transforms into Eisen? I would ideally propose to place them in Eisen-extras and introduce TorchIo as a requirement for eisen-extras

Yes, that sounds good. I'm also happy to adapt some aspects of the library if that would help integration.

Hi Fernando, just wanted to ask, did you make any progress on the wrapper implementation? I may take a stab at it if you haven't started yet.

Hi @jordanpn, I've obviously misunderstood the plan here, I didn't know you were expecting me to work on this.

Totally my fault here. I was supposed to get this done. I will try it tomorrow morning because I have been on vacation. Let’s get it done. I would love your help for review of the PR! Thanks for the patience

Thank you, I am happy to help with the PR review and testing!

Thanks @jordanpn . @fepegar could we talk on slack or email? I might have a couple questions!

This is the slack link https://join.slack.com/t/eisen-ai/shared_invite/enQtOTIwOTg0ODc2MDY3LWE5MGVlNTgxZTBmNjM5NGU2OWRhYzdiMzAzNzRmMGZlZWJlZmEzZDcyNWE4ZTQ5OGM4NDk5N2E5NTEyYzE3NGI

Please refer to this PR https://github.com/eisen-ai/eisen-extras/pull/1

Hi,
This is excellent framework. I have one question, How can I prepare json file for custom dataset to use your framework.
Thanks

The typical form for a json dataset is a list of dictionaries. Each entry of the list contains a dictionary. In the dictionary you can store whatever you want. Typically we store paths to files. Eg. [{“image”: “path-to-image.jpg”, “label”: 7}, ...]


Some suggestions and feedback on the use of dog models

First of all, thank you very much for updating and supporting this dog model, because I really liked this dog model in v49 version。However, during the process of playing with friends, it was found that when the player turned into a dog model, the first person perspective screen would constantly shake, affecting the player's operations when searching for things and fighting monsters; Secondly, when players pick up items, the size of the items is slightly small, as well as the height of the dog model's perspective. We hope the author can adopt these issues, and also hope that the author can appropriately reduce the height of the dog model's perspective in later updates to fit the gameplay of the dog model

Thanks for the feedback! I'm happy to look into these things!
To help me look into this further, could you

Attach a screenshot showing the item sizing issue
Attach a screenshot showing the height issue
Attach the mod hash you've been using with your friends

Thanks for playing!

May I ask if this mod hash refers to our mod data log?

Oh sorry I could have been more clear! I just need to know what other mods you have installed!
If you use a modpack with your friends, you can let me know the modpack name
If you use r2modman, you can export a code for your mod list and paste that for me

If you do neither of these, just let me know the names of the other mods you use and the version of this mod you're using!

First of all, thank you very much for your careful explanation. The following two pictures show the first perspective height when I am in the employee form and the first perspective height when I am in the dog form during normal gameplay. After switching models, the perspective did not change in height.

The following notebook contains all the mod versions in the integration package that I personally created！
mod version.txt

First of all, thank you very much for your careful explanation. The following two pictures show the first perspective height when I am in the employee form and the first perspective height when I am in the dog form during normal gameplay.

After switching models, the perspective did not change in height.

The following notebook contains all the modules versions in the integration package that I have created myself. Some modules use older versions, and my idea is that older versions may have fewer bugs and be relatively stable. I have tried other versions of the puppy model before, but they all had screen shaking and no changes in height
mod version.txt

Thanks so much for all the detailed information! I'll get this set up so I can look into it further!
Some initial thoughts based on the mod list and the screenshots are:

It looks like when in dog mode, the camera height does not get adjusted but the item anchor (where the model holds items) does get updated, so that's why the held items look so much smaller. I think that if we're able to figure out why the camera height isn't getting adjusted, that will fix the item size issue too!
It looks like your mod list includes ModelReplacementAPI which I believe the original mod said conflicts with PlayerDogModel, so I'll have to see if that might be causing the camera issue or the shaking issue! If you are curious, it might be worth trying to disable ModelReplacementAPI  (and whichever mods use it) and see if that results in any changes! I will be trying this too

Thank you for your hard work. I have tried to create a new integration package that does not include the ModelReplacement API. However, when I am in the puppy model, the screen still shakes. Please study and test it more to bring more exciting versions for the future

Good news! I was able to track down the incompatibility for the camera height / item size issue! It seems like it's an issue with CruiserImproved. I would recommend disabling that mod for now, and I would still recommend uninstalling ModelReplacementAPI since I don't think your mod list is using it for anything! I can look into why CruiserImproved was causing this camera issue.
Here's a video showing your mod list running without CruiserImproved and ModelReplacementAPI:
https://github.com/user-attachments/assets/f2f96122-a3ec-4147-b97e-9ddbae3b407d
Please let me know if this helps and if the screen shake issue continues!

Thank you very much for your investigation and analysis. After retesting and deleting the mod, I have indeed resolved the issues of screen shake and first person perspective height. The CruiserImproved mod does indeed affect the first person perspective of players in the puppy model. I hope the author can conduct more in-depth analysis and debugging of the mod in the future to adapt to it

Another update, I figured out why CruiserImproved is causing this issue: it's because they have a patch which resets the camera position every frame.
To use CruiserImproved and PlayerDogModel_Plus at the same time, you should update both of these config settings in DiggC.CruiserImproved.cfg:

Allow Leaning = false
Seat Boost Scale = 0

So my recommendation right now is:

Uninstall ModelReplacementAPI
Update the config settings for CruiserImproved

Allow Leaning = false
Seat Boost Scale = 0

What I can do in the meantime is submit a PR to CruiserImproved so that it will only adjust the camera position when you are in a vehicle! That would prevent the conflict with PlayerDogModel_Plus. I will post the link to the PR when it is available and then hopefully the author for CruiserImproved will test and approve it!
Thanks for your help!

Okay, we look forward to receiving updates and adjustment notifications from you in the future

Raised a PR to fix this issue in CruiserImproved here!

Rejected the PR since the author confirmed that they have their own solution planned for a future update.

In the meantime, please use the workaround provided above and watch for a future update to CruiserImproved!
Closing this issue.


details in data.json

#1
Added my details in data.json file in the specified format.

Hey this is a beginner only repo as mentioned so your contribution can't be accepted. You can surely contribute by making your personalized profile card. Closing the issue.


update config vars + index

Amend due to new placement of config vars in the dash. @shaunmulligan @dfunckt

LGTM

Has lunr_index.json conflicts now. Soon they'll be gone completely as we move to Heroku and will generate it on the server instead of on the client. For now you have to rebase the branch, and during the conflict resolution regenerate the index. I can do it to speedup the process.

Done


fix: add a check whether queyr is already running

:tada: This PR is included in version 0.20.0 :tada:
The release is available on:

Visual Studio Marketplace
GitHub release

Your semantic-release bot :package::rocket:


Model loaded from a SavedModel format in a distribution strategy has weights whose names are not unique

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): colab
TensorFlow installed from (source or binary): colab
TensorFlow version (use command below): 2.2 and 2.4
Python version: 3.6
CUDA/cuDNN version: problem is on CPU and GPU
GPU model and memory: colab

Describe the current behavior
I am using a distribution strategy to train my model on several GPUs, and using the ModelCheckpointCallback to save my model.
I train my model in 2 steps, in the first I use the SavedModel format and in the second, I want to save my model using the HDF5 format.
However, I encounter a problem when loading my saved model in a distribution strategy, where the names of the different weights of my model are stripped down the last part (i.e. for example 'kernel:0').
Therefore, my model has several weights with the same name and cannot be saved in the HDF5 format.
Describe the expected behavior
I would like my model to be loaded in the distribution strategy with the proper names.
Standalone code to reproduce the issue
You can find a colab to illustrate this issue here.
Other info / logs
For reference the typical error that you get is RuntimeError: Unable to create link (name already exists), with the full traceback being:
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-10-debcda389c22> in <module>()
      1 # and as a consequence, we cannot save the weights of our model
----> 2 new_model.save_weights('new_model_weights.hdf5')

3 frames
/usr/local/lib/python3.6/dist-packages/tensorflow/python/keras/engine/training.py in save_weights(self, filepath, overwrite, save_format, options)
   2106     if save_format == 'h5':
   2107       with h5py.File(filepath, 'w') as f:
-> 2108         hdf5_format.save_weights_to_hdf5_group(f, self.layers)
   2109     else:
   2110       if context.executing_eagerly():

/usr/local/lib/python3.6/dist-packages/tensorflow/python/keras/saving/hdf5_format.py in save_weights_to_hdf5_group(f, layers)
    640     save_attributes_to_hdf5_group(g, 'weight_names', weight_names)
    641     for name, val in zip(weight_names, weight_values):
--> 642       param_dset = g.create_dataset(name, val.shape, dtype=val.dtype)
    643       if not val.shape:
    644         # scalar

/usr/local/lib/python3.6/dist-packages/h5py/_hl/group.py in create_dataset(self, name, shape, dtype, data, **kwds)
    137             dset = dataset.Dataset(dsid)
    138             if name is not None:
--> 139                 self[name] = dset
    140             return dset
    141

/usr/local/lib/python3.6/dist-packages/h5py/_hl/group.py in __setitem__(self, name, obj)
    371
    372             if isinstance(obj, HLObject):
--> 373                 h5o.link(obj.id, self.id, name, lcpl=lcpl, lapl=self._lapl)
    374
    375             elif isinstance(obj, SoftLink):

h5py/_objects.pyx in h5py._objects.with_phil.wrapper()

h5py/_objects.pyx in h5py._objects.with_phil.wrapper()

h5py/h5o.pyx in h5py.h5o.link()

RuntimeError: Unable to create link (name already exists)

However, this issue is different than this one because originally the weights do have different names (and even when saved, the weights have different names, it's just that loading them inside the distribution strategy erases that).

Was able to reproduce the issue with TF v2.3, TF v2.4 and TF-nightly. Please find the gist of it here. Thanks!

Was able to reproduce the issue with TF v2.3, TF v2.4 and TF-nightly. Please find the gist of it here. Thanks!

You need to disable eager execution then it is able to create unique names i was able to run it
tf.compat.v1.disable_eager_execution()

Was able to reproduce the issue with TF v2.3, TF v2.4 and TF-nightly. Please find the gist of it here. Thanks!

In this colab we just need to disable eager execution and it works fine and i was able to run through it.

@SwathiAunooru good catch!
It indeed works in eager mode.
However the names of the weights are still off. This time they are not identical, but they are still not what they were before, which might prove infefficient for debugging should it happen
I also don't know how easy it is to switch between eager mode and graph mode when loading/saving weights (is it possible?).

Was able to replicate the issue in TF 2.6.0-dev20210603,please find the gist here..Thanks !


Member & Project Directory

Is your feature request related to a problem? Please describe.
I want to meet other builders and learn about their projects. How do I know who is in Build DAO & learn more about Build DAO supported projects all in one place?
Describe the solution you'd like
A page with an opt-in member directory (e.g. list of profile previews) and admin curated project list. Users should be able to opt-in or out of being shown in the directory at any time from their profile page. Project data could be pull from project account profiles in socialDB, assuming all projects have a dedicated account.
Describe alternatives you've considered
Using Telegram topics & maybe even bots, but Telegram isn't featured prominently on the gateway so visibility & effectiveness at leveraging our on-chain presence would be substantially reduced.
Additional context
The gateway has some social features in the feed & profile, but discovering other members & projects is difficult.

+1
Rather than builders requesting to join the community group of a particular Sputnik DAO, let’s use Near Social graphs to cultivate an open web of trust. For onboarding purposes, contributors may either “follow” or connect with fellow builders in other ways. This process can be facilitated by a reusable widget, like this one by Eugene the Dream:
→ near.social/mob.near/widget/People
Our adapted version showcases a list of builder profiles:
→ https://near.social/james.near/widget/explore.builders
It features creators of the latest widgets tagged with #build.
const filterData = Social.keys("*/widget/*/metadata/tags/build", "final");

Open Question
There are many ways to get lists of builders. How should Build DAO facilitate connections?

Builders who interacted with DevHub: near.social/hack.near/widget/devhub.community
Builders ranked by total stars across their widgets: near.social/hack.near/widget/devs
Widgets ranked by stars: near.social/hack.near/widget/widgets
Builder dashboard: near.social/lord1.near/widget/component-total
Regional communities dashboard: https://near.social/indonesiaguild.near/widget/RCDashboard-WIP
List of all BOS widget builders with profiles: https://near.social/devs.near/widget/devs.Rank
Build DAO members: near.social/create.near/widget/DAO.Members
Build DAO followers: near.social/create.near/widget/DAO.Followers
Most forked widgets: near.social/hack.near/widget/top.widgets.forked

Developers on Jutsu.ai: https://near.social/hack.near/widget/devs.jutsu
Build DAO dashboard: https://flipsidecrypto.xyz/Lordking/build-dao-build-dao-acWrot
and more!

Groups Feature
Discussion: https://github.com/near/near-discovery/discussions/342
Visualization: https://near.social/mob.near/widget/MainPage.N.Post.Page?accountId=james.near&blockHeight=102009993
Sample: https://near.social/devs.near/widget/every.group


feat: adds Algorand as Formula

Adds Algorand as a formula
Adds CI to automatically update the formula to the latest algorand stable version (checks twice a day)
Removes macOS-12 for macOS-15 (due to deprecation), and does some small formatting

@aorumbayev

Looks good but please update README to include instructions on how to install the formula and note that repo hosts a cask for algokit-cli and a formulae for algod (worth noting that algorand formulae specifically installs algod in case some folks might be confused on generic 'algorand' term as a formulae name)

Good point, I've added instructions/information now.


Add support for subcommands for all remaining asset types (after Node) as well as for agg by asset type itself

Adds disk, lb, cloud, network, cm subcommands for cost by asset. Also adds GPU cost to node, and adds asset general subcommand for cost by all asset types.

@kaelanspatel, Is this PR still relevant or can I close it out?


Opening a flutter modal over a screen that contains an animated lottie makes the modal transparent. Flutter version 3.19.1

Steps to reproduce
Create a page with a lottie
Open a modal on the top of that page
You will still be able to see the lottie animation in background as the modal looks trasparent
Expected results
The modal should cover the widgets in the background
Actual results
The modal is transparent over the lottie animation
Code sample
Code sample
[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
[Paste your output here]

Hi @spiderion, what platform(s) are you seeing this issue on? Was this an issue piror to flutter 3.19.1 or did it manifest on 3.19?
Please also provide a complete minimal reproducible code sample so that we can investigate this issue.
Thank you

Hi @danagbemava-nc, I am only seeing this issue on IOS. No, I was not facing the issue on 3.16.9.
I don't know if can create a specific minimal code to reproduce it but please if you can't manage to reproduce I will try to make the effort.
I am now using a previous version of Flutter as this is a bug that I can't push live to my users.
Thanks.

Hi @spiderion, using the lottie example app and the showDialog method, I can't seem to reproduce the issue. See the recording below.
We would appreciate if you could provide a complete minimal reproducible code sample so that we can investigate this issue.
Thank you
https://github.com/flutter/flutter/assets/88313112/d951c0ea-e023-4b69-acc3-88af2924f813

code sample
import 'package:flutter/material.dart';
import 'package:lottie/lottie.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      home: HomeWidget(),
    );
  }
}

class HomeWidget extends StatelessWidget {
  const HomeWidget({
    super.key,
  });

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Lottie.network(
          'https://raw.githubusercontent.com/xvrh/lottie-flutter/master/example/assets/Mobilo/A.json',
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () async {
          showDialog<void>(
            context: context,
            builder: (BuildContext context) {
              return AlertDialog(
                title: const Text('Basic dialog title'),
                content: const Text(
                  'A dialog is a type of modal window that\n'
                  'appears in front of app content to\n'
                  'provide critical information, or prompt\n'
                  'for a decision to be made.',
                ),
                actions: <Widget>[
                  TextButton(
                    style: TextButton.styleFrom(
                      textStyle: Theme.of(context).textTheme.labelLarge,
                    ),
                    child: const Text('Disable'),
                    onPressed: () {
                      Navigator.of(context).pop();
                    },
                  ),
                  TextButton(
                    style: TextButton.styleFrom(
                      textStyle: Theme.of(context).textTheme.labelLarge,
                    ),
                    child: const Text('Enable'),
                    onPressed: () {
                      Navigator.of(context).pop();
                    },
                  ),
                ],
              );
            },
          );
        },
      ),
    );
  }
}

Hi @danagbemava-nc , Thanks for the effort to try to reproduce the issue.
I was referring to a showModalBottomSheet
I will try to create a code so you can reproduce asap.
Thanks

Hi Again, In the meantime that I  am creating the reproducible code I would like to show a video of the issue.
https://github.com/flutter/flutter/assets/36972396/89e61f34-55cf-4a0d-9efe-70c9827a7f8f

Hi @danagbemava-nc  I can't manage to create a code to reproduce this issue. It happens in a specific page in my app after the upgrade. But I can't manage to extract the code in another section and reproduce the issue. The issue only happens there. If I manage to reproduce I will let you know.

More details,
The issue only happens when the lottie is wrapped by a Transform widget:
Transform(
alignment: Alignment.center,
transform: Matrix4.rotationY(math.pi),
child: Lottie.asset(
'assets/lottie/angel_shaded.json',
),
)
If I remove the transform the issue doesn't happen.
Can you check maybe there was a change in the transform that is causing the issue.
@danagbemava-nc

Hi @spiderion, can you provide the asset you're using? A complete sample would also help us. I added a transform to the code sample I shared earlier in https://github.com/flutter/flutter/issues/144189#issuecomment-1972604147 and also replaced the dialog with a bottom sheet but the issue does not reproduce.

full code sample
import 'dart:math' as math;

import 'package:flutter/material.dart';
import 'package:lottie/lottie.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      home: HomeWidget(),
    );
  }
}

class HomeWidget extends StatelessWidget {
  const HomeWidget({
    super.key,
  });

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Transform(
          transform: Matrix4.rotationY(math.pi),
          alignment: Alignment.center,
          child: Lottie.network(
            'https://raw.githubusercontent.com/xvrh/lottie-flutter/master/example/assets/Mobilo/A.json',
          ),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () async {
          showModalBottomSheet<void>(
            context: context,
            builder: (BuildContext context) {
              return SizedBox(
                height: MediaQuery.sizeOf(context).height * 0.5,
                child: Center(
                  child: Column(
                    mainAxisAlignment: MainAxisAlignment.center,
                    mainAxisSize: MainAxisSize.min,
                    children: <Widget>[
                      const Text('Modal BottomSheet'),
                      ElevatedButton(
                        child: const Text('Close BottomSheet'),
                        onPressed: () => Navigator.pop(context),
                      ),
                    ],
                  ),
                ),
              );
            },
          );
        },
      ),
    );
  }
}


Add method to check whether Stty is available.

First of all, I'm not CLI expert and this is just my personal use case, also my english is so poor but I'll do my best. :grin:
Currently I have a project that use climate to nicely interact from CLI, including installation process. e.g. Asking your hostname, database host, database username etc. It works fine when I run the command directly from my terminal. But when I add the same command to Composer post-create-project-cmd hooks, I got errors that said
standard input: Inappropriate ioctl for device

I've also make a video (indonesian language) to tell about this problem.
Finaly I found a method from Symfony/Console component that could determine whether STTY is available or not. I just try to implement this on my projek-xyz/ci-console@babaa758 and it works.
Now I think it's would be great if climate have this feature built in.

Hi @feryardiant, thanks for your interest in CLImate. I can see how you're using the hasSttyAvailable() method in your project, can you explain why it should be part of CLImate?

Hi @duncan3dc!
Wow, it's been 2 years since I post this PR & almost 2 months I'm late replying your respond. Anyway, the main reason why I (personaly) need this should be part of CLImate is bacause somehow we (or maybe just me) need to use CLImate in uninteractive shell. e.g. Authomate install command or integrate it with composer (like i did in my video above), or etc.
Anyway, right now I'm no longer using CI for my projects since I move to Laravel back then, so I can't follow along CLImate updates & I don't really know if it's already implemented or not, sorry. But still I really hope it have this feature built-in.
Cheers

I understand what you mean now, but I think this feature needs more. For instance it should be handled automatically by CLImate (similar to how symfony/console does) rather than having to condition every call to CLImate (like in your example).
I'm going to close this PR for now, until somebody can implement that


HHH-15179 - Moving support for MySQL versions older than 5.7

HHH-15179 - Moving support for MySQL versions older than 5.7 into community dialects
Signed-off-by: Jan Schatteman<EMAIL_ADDRESS>

As discussed, the legacy versions are a simple (adapted) copy, no inheriting from the current counterparts, since that leads to undesired side-effects (e.g. the parent dialect adds things to certain registries that the legacy version does not support, and the overriden versions always call super())

Added the MariaDB changes as a commit on top of this PR, since they're dependent.

It seems that after you copied and renamed the original dialect to the hibernate-community-dialects module, you altered the legacy dialects/translators in ways that are wrong. You removed certain version checks or code blocks.
Please compare every legacy dialect and translator with a compare tool against the original dialect and translator from main, and make sure that the file contents match except for changes due to class renames. It seems that some of the changes you did were actually supposed to be done in some way for the dialect and translator in the hibernate-core module.

I actually do that, but if what you say is true then I have prob. messed up the sides of the compare somehow; I'll recheck evrything for MariaDB.

Some minor changes to dialect related tests


[TIR] Fix typo in code example

Fixing small typo in ‘python/tvm/te/operation.py’

I think you might need to add some simple description in the PR for the CI to pass.

@tvm-bot rerun


correct test by using accurate settings

fixes: https://github.com/kiali/kiali/issues/3259

test passes


Task/bump product version

Hello, Can you pls tell me when is this release planned and with which OCP/ODF version? So I can make changes to the odf-operator accordingly here https://github.com/red-hat-storage/odf-operator/blob/main/bundle/manifests/odf-operator-manager-config_v1_configmap.yaml#L15


Idea: Refactor Debug Mode

Idea is to use the same logic for Debug as the one we are using for Run Jest (create a CLI Command).
Instead of opening the normal terminal open the integrated debug terminal, but we use the same logic as we use for Run Jest.
this would simplify and align the logic in the extension.

@domsleee what do you think about this idea?

from my research there is no other way to just open the debug terminal (like you can do it from the vscode ui) with the API.
the only way is the one we currently have implemented.


eris gateway

Eris-DB has to evolve from an explicit chain implementation to a gateway functionality such that an increasingly rich landscape of blockchain technologies can be normalised through a modular gateway.

introduce separation of consensus engine, application manager, and gateway rpc
support tendermint 0.6 in-process
support ErisMint 0.12 in-process
support Eris-DB RPC; Tendermint RPC

So... I'm not sure I'm going to code review this as is... this is organisational right?


Permit Environment Template

We want to allow users to simply ready-made policy templates in their environment. Examples of templates are GitHub, E-commerce, Banking, etc.
Acceptance criteria:

Command permit env template apply is listing the available templates and allow the users to apply them

What kind of template do you need?

The idea is to use the Terraform Permit Provider, create some template, and let the user choose one and apply it on environment.
https://github.com/permitio/terraform-provider-permit-io


Unsupported gnome 3.34

watch out for the shell theme adjustments on this update
Here's the JournalCtl output that I thought that was relevant.
https://gist.github.com/Lord-Guckavin/4b60d3e2f652d08a276b4c402f93ea30

"actor" is deprecated, I cannot find the documentation about it, or what to do.
I found this code : https://github.com/jwrdegoede/TopIcons-plus/commit/454e3dc157ea1d91fffb6c0b3728ecdee6206860

Yeah I just swiped a chunk of my the log that I thought might help but wasn't fully sure. I've jumped back to gnome 3.32 for the mean time.

From what I can tell, you just have to remove the actor prop. Not on gnome-shell, so I can't do much for now.

This might help with interpreting the debugs?
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559

Cheers Karneds and Zagortenay, massive legends the both of you.


Added ESLint and Prettier Format for Nest Frontend, Added Husky Setup

Added ESLint, Prettier format and completed Husky setup to run pre-commit tests.
Added Instructions for all of them in README.md file.
https://github.com/OWASP/Nest/issues/78

@tsu-ki could you address the rest of comments and request re-review when ready?
Thank you!

@tsu-ki could you address the rest of comments and request re-review when ready? Thank you!

I apologise for not addressing the concerns before, I've replied to each of the review and would be glad if you or Harsh could suggest any more probable changes. thanks!


Version 1.0.0

Just a small suggestion, could the version number be upped to 1.0.0 or if you want 6.0.0?
This is because the ^0.0.3 won't update patches automatically but ^1.0.0 does.

^0.1.0 does to


Try non-scaling-stroke.

Works quite nicely.

Big boost for zooming perf.
Nice effect when zoomed right out.
Lose the shape a tiny bit. (hex starts to look like a circle).
Lose "shadow-margin" (between border and shadow) unless quite zoomed
in.

Only nit is stacks:

becomes

Here is master to compare:

But then again, zoomed out that far, it's hard to maintain any distinction.

I think the stacks are quite identifiable w/ their heavy shadows!
Other issues:

non-scaling edges start to look a bit heavy when zoomed-out.
having a lot of text on the canvas (if we don't truncate it when zoomed out), slows things down.

non-scaling edges start to look a bit heavy when zoomed-out.

Scaled edges look slicker up to a point, when they become barely perceptible. Non-scaled edges keep giving you an impression on the connectedness up to a high zoom-out, but at some point become heavier than the nodes. How about keeping non-scaled edges, but make them slightly paler on high zoom levels (e.g. via a CSS class on the chart element).

having a lot of text on the canvas (if we don't truncate it when zoomed out), slows things down.

We could be realistic about readability and just hide them on high zoom-outs.

Can we rewrite this using feature flags? Then we can see it in the wild.

Perhaps!

Re-implemented with feature flag
Activate via
localStorage['scope-experimental:non-scaling-stroke'] = true

PTAL @foot

Nice one. LGTM.
+1 this feature.

Okay it doesn't work perfectly w/ clouds right now... still LGTM but if you wanna try and fix that too..

Actually i can have a quick play now.

it doesn't work perfectly w/ clouds

Based on the pic, that is a bit of an understatement!

npm install svgpath
var svgpath = require('svgpath');

const MAX = [1920, 1408];
const CLOUD_PATH = 'M 1920,384 Q 1920,225 1807.5,112.5 1695,0 1536,0 H 448 '
  + 'Q 263,0 131.5,131.5 0,263 0,448 0,580 71,689.5 142,799 258,853 '
  + 'q -2,28 -2,43 0,212 150,362 150,150 362,150 158,0 286.5,-88 128.5,-88 '
  + '187.5,-230 70,62 166,62 106,0 181,-75 75,-75 75,-181 0,-75 -41,-138 '
  + '129,-30 213,-134.5 84,-104.5 84,-239.5 z';

const factor = 32 / 1920;
var transformed = svgpath(CLOUD_PATH)
  .scale(factor)
  .round(3);

console.log(transformed.toString());
console.log([[0, MAX[0] * factor], [0, MAX[1] * factor]]);

So... what should we do with this PR? :)
I rebased it locally because I was curious to see how it would look like (as cloud border width was not an issue anymore), but I don't think it's possible to come up with a border good width which would be neither too thin on maximal zoom nor too thick on minimal zoom.
What I tried instead was to draw two overlapping borders, a normal one and a non-scaling one with 20% of the normal one's width. The result is that the border scales normally unless you zoom out a lot in which case a non-scaling border becomes dominant and serves as a lower-bound cap on the line thickness.
One objection might be that it would be more expensive to render two borders instead of just one, but that would only happen with the flag on and what matters more IMO is that still nothing would have to be rerendered when zooming in and out (unlike if we tried to achieve the same effect with only one border).
Is the suggestion too hacky? :D

I suggest to revisit the premise of this PR: are non-scaling strokes an improvement? To me they bring a bit calm during zooms, which I consider good as it's less distracting. If the edge cases (particularly for the edges) are problematic, then we can simply not apply the feature in extreme zoom factors.

I personally wouldn't like to see non-scaling strokes applied to edges at all, as they'd take too much attention and would be hard to read on extreme zoom-out anyway.
As for the nodes, not applying them at extreme zooms might look better, but I think we'd still need to make sure the transition is smooth. @davkal would you mind if I took over this story or at least pushed the rebased version (+ some of the changes I suggested for you guys to take a look at)?

Should we close this?

Yes, this will be addressed when developing other features.


Exiting Quake window crashes WT if another "regular" window exists

Windows Terminal version
1.21.1772.0
Windows build number
10.0.22631.0
Other Software
Powershell v7.4.5
Steps to reproduce

Bind "Show/Hide Quake window" to a hotkey
Launch wt
Launch a quake window with the hotkey
Exit the quake window with exit

Expected Behavior
The Quake window should exit gracefully, returning me to the "regular" window.
Actual Behavior
The window contents are removed, leaving a window border onscreen. This is shortly followed by a logged 0xc0000005 and both windows disappear.

Feedback Hub: https://aka.ms/AArxq46

I am, but I didn't come across any open issues mentioning that?


Blur event in select2 v4.x

How do I trap the blur event in Select2 v4.0 - select2:blur does not work - suppose its disabled for some reason.

Duplicate of https://github.com/select2/select2/issues/3152 which was merged into https://github.com/select2/select2/issues/1908.


'lxc config show remote:': go ahead and show remote config

Signed-off-by: Serge Hallyn<EMAIL_ADDRESS>

make i18n please :)


Convert the Initial Technical Documentation to an editable format

[x] Crack the PDFs from Edalex

[x] Convert Google Docs

[x] Convert into Markdown

Google Doc - https://drive.google.com/drive/folders/0B7YKK2RF_OXNandnSEJ0elpVSUE

Documentation has been moved into GitHub -- Will post the last document for Setting up Dev Environment once Diego/Benito confirm the final changes.


feat: add scroll duration

add scroll duration props
fix scrollTop compatible bugs: sometimes  should get scrollTop by document.body.scrollTop and sometimes by document.documentElement.scrollTop
change toggle backTop btn from v-if to v-show, maybe this toggle may occur often

Please make sure these boxes are checked before submitting your PR, thank you!

[ ] Make sure you follow Element's contributing guide (中文 | English | Español | Français).
[ ] Make sure you are merging your commits to dev branch.
[ ] Add some descriptions and refer relative issues for you PR.

it is good!i agree


[Bug Report] Dialog's lock-scroll attribute dosen't work in iPhone's Safari browser

Element UI version
1.4.11
OS/Browsers version
ios 11.1.2
Vue version
2.5.8
Reproduction Link
https://jsfiddle.net/mmx38qxw/46/#&togetherjs=BxyCiHH98g
Steps to reproduce
当在dialog中嵌套表单的时候，当表单的内容较多时，一点开dialog，滑动dialog中的表单，dialog不动，body滑动
What is Expected?
滑动dialog的时候，body锁定
What is actually happening?
点开dialog，滑动dialog，dialog不动，body滑动

Element is designed for desktop admin sites. We discourage people to use it on mobile devices.

.el-popup-parent--hidden {     overflow: scroll;     -webkit-overflow-scrolling: touch   }
Hope that help.

Element is designed for desktop admin sites. We discourage people to use it on mobile devices.

I see this answer again and again, but people will use it on mobile. So we hope you will make it responsive in the feature


220722 more coverage

Codecov Report

Merging #58 (ee8a9fa) into version/0.14.0 (c1880a4) will increase coverage by 0.37%.
The diff coverage is 100.00%.

@@                Coverage Diff                 @@
##           version/0.14.0      #58      +/-   ##
==================================================
+ Coverage           95.81%   96.18%   +0.37%
==================================================
  Files                  32       32
  Lines                3203     3202       -1
  Branches              711      716       +5
==================================================
+ Hits                 3069     3080      +11
+ Misses                132      121      -11
+ Partials                2        1       -1

Impacted Files
Coverage Δ

src/singletoneConstants.ts
100.00% <ø> (+6.89%)
:arrow_up:

src/builder.ts
100.00% <100.00%> (ø)

src/models/Condition.ts
87.33% <100.00%> (+0.84%)
:arrow_up:

src/models/types.ts
100.00% <100.00%> (+12.50%)
:arrow_up:

src/steps/BaseStep.ts
97.63% <100.00%> (+0.04%)
:arrow_up:

src/steps/Step.ts
100.00% <100.00%> (+0.31%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c1880a4...ee8a9fa. Read the comment docs.


Fixed missing token in example

Fixed missing VALUE token in an example provided for token generation in Block mappings.

Thanks, merged!


create model shard spanner service

This is the last PR for internal APIs related to VID Model distribution

This change is


Proper versioning, changelogs, and releasing

To be frank, this is an issue that should have been addressed before the semester started but better late than never!
Our workflow w.r.t. versioning has worked like this up to this point:

Work work work.
When students need to receive the updates, bump up the minor version
(eg. 0.3.2 -> 0.3.3) and release on Pypi.
Repeat.

Ideally, our workflow would look more like:

Add features to master, being careful not to introduce backwards-incompatible
changes until major releases (eg. 0.6.1 -> 1.0.0).
After each feature is merged, add a description in a changelog for each release.
When we deem it's time for a release:
Push the release to Pypi
Push a new version of the docs (so that someone working with a specific version
has the correct docs for that version).
Push the release to a Github branch.

Any thoughts on this @papajohn @deculler @stefanv @henryem @rjboczar @alvinwan ?

I think we probably have another semester of our current workflow before we
can behave like datascience is a stable software package.
On Sun, Nov 29, 2015 at 6:17 PM, Sam Lau<EMAIL_ADDRESS>wrote:

To be frank, this is an issue that should have been addressed before the
semester started but better late than never!
Our workflow w.r.t. versioning has worked like this up to this point:

Work work work.
When students need to receive the updates, bump up the minor
version (eg. 0.3.2 -> 0.3.3) and release on Pypi.
Repeat.

Ideally, our workflow would look more like:

Add features to master, being careful not to introduce
backwards-incompatible changes until major releases (eg. 0.6.1 -> 1.0.0
).
After each feature is merged, add a description in a changelog for
each release.
When we deem it's time for a release:

Push the release to Pypi
Push a new version of the docs (so that someone working with a
specific version has the correct docs for that version).
Push the release to a Github branch.

Any thoughts on this @papajohn https://github.com/papajohn @deculler
https://github.com/deculler @stefanv https://github.com/stefanv
@henryem https://github.com/henryem @rjboczar
https://github.com/rjboczar @alvinwan https://github.com/alvinwan ?
—
Reply to this email directly or view it on GitHub
https://github.com/dsten/datascience/issues/156.

As you mention above, we typically  assocate different parts of the version number with different kinds of changes.  E.g., in a major.minor.revision system, it is quite typical to use revision for bug-fixes, minor for new releases, and major for API-breaking changes.  For young projects, such as this, API's are sometimes broken for minor versions, although the sooner you can settle on a stable API the better.  Also, it is very helpful to users to document all breaking API changes.
As for the docs, here is an example of how we host the different version for scikit-image (see sidebar):
http://scikit-image.org/docs/stable/
It is possible to have Travis-CI automatically build packages.  @matthew-brett has a lot of experience with all of this.

Once we have a staff for next semester (probably next week), let's get
together and see what parts of the scikit-image model we can adopt without
too much overhead. The output looks great. Thanks for pushing on this
issue, Sam.
On Tue, Dec 1, 2015 at 1:10 AM, Stefan van der Walt <
<EMAIL_ADDRESS>wrote:

As you mention above, we typically assocate different parts of the version
number with different kinds of changes. E.g., in a major.minor.revision
system, it is quite typical to use revision for bug-fixes, minor for new
releases, and major for API-breaking changes. For young projects, such as
this, API's are sometimes broken for minor versions, although the sooner
you can settle on a stable API the better. Also, it is very helpful to
users to document all breaking API changes.
As for the docs, here is an example of how we host the different version
for scikit-image (see sidebar):
http://scikit-image.org/docs/stable/
It is possible to have Travis-CI automatically build packages.
@matthew-brett https://github.com/matthew-brett has a lot of experience
with all of this.
—
Reply to this email directly or view it on GitHub
https://github.com/dsten/datascience/issues/156#issuecomment-160901229.

This is resolved in release v0.4.0 which put the docs on http://datascience.rtfd.org/ with versioning. Still some rough edges but this will let us move forward.


Greenkeeper/semantic release 17.0.6

:tada: This PR is included in version 3.0.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


New, orthogonal and complete time conversion API

Before pushing a big refactoring of the organization of #17155, it seems prudent to extract the bits that weren't controversial and see if we can merge those in isolation.
First up is the time conversion API.  This is the code as it appears in the original, with two additions:

The automatic conversion generator is extended to emit nanosecond conversions, and the test rig is updated accordingly for coverage.  This is done as a separate commit for simplicity, but I can fold it in if people want.

The older conversion utilities have been deprecated and replaced throughout the tree with the new calls instead of leaving the usages in place.

@carlescufi / @nashif  - I've lost track of exactly who the gatekeepeers are supposed to be on this work.  Please add appropriate reviewers.
Closes #12509

Note there are some checkpatch false positives with the way __DEPRECATED_MACRO works, and some 80 character lines that are due to the automated changes (and seem in most cases to be pre-existing).  I don't currently plan on cleaning those up manually but will if requested.

We don't want documentation errors, please fix those.
I'm OK with leaving the other checkpatch stuff as-is.

New version fixes the comment that refers to future commits, and the needless u64_t cast in the converted expression.

@pabigot is there anything in this PR you disagree with, or (pending a passing CI result) can we merge this to make some incremental progress on our goals?

@pabigot is there anything in this PR you disagree with, or (pending a passing CI result) can we merge this to make some incremental progress on our goals?

Sorry, it took a while to go through everything carefully.
I believe the changes I've listed are small enough to be easy to do.  The primary motivation is avoiding subtle changes in behavior from what we currently have with the existing API.
With those changes this can be merged.  However, this is not a blocker for the next step we've actually asked for to progress on #17155, which is a PR that will give us a more clear understanding of the impact of changing the timeout representation in existing API isolated from functional and behavioral changes..

OK, I've squashed the ns addition into the original commit (as I offered to do at the top) and reordered the remaining commits to match what I believe you want.
As to the other requests:
Signedness of the API:  This API has been in review without discussion for three months now.  It is, indeed, a new API, pedantic compatibility isn't the intent nor the requirement.  In fact, when it was added, the issue of sign was discussed in the kernel call, and there were very strong opinions voiced (and while my memory isn't perfect, I swear yours was one of them) that this should be an unsigned API going forward.  Changing this now seems likely to turn into another needless bike shed.  Please reconsider.
Replacement of the old API calls:  I don't really understand the criticism here.  This is a very straightforward change, trivially accomplished.  It doesn't seem reasonable to reject it purely because of the tool that was used to accomplish the task.  The code should stand alone, and either it's correct or it's not.  That's the point of doing code review at all, right?   Note that this, too, was requested at once point of the old PR, and didn't seem to be controversial at the time even if I demured at adding it at the time.

I have no objections to the new transformation functions taking and returning unsigned values (though I noted we need to be aware of the impact of passing negative values to it).
I do object to quietly changing the sign and rank of integer values used in expressions throughout the code without verifying that  those expressions produce the same result for the different value/type.  We presume the previous code was correct; with the replacement we don't know.
A simple way to be sure that the behavior is unchanged is to retain the old API and casting the result to the type previously returned in its re-implementation, allowing people to take advantage of the features of the new API intentionally.
I simply don't see a benefit in switching to the new API that warrants the risk.
Also sys_clock_hw_cycles_per_tick() is a lot more understandable than k_ticks_to_cyc_floor_32(1).  IMO.

The tests all continuing to pass isn't validation enough?  Are there further tests you want to see written?  What risk exactly are you talking about, the risk to out-of-tree code?
Is the "cycles_per_tick" API request a firm requirement?  I can add that back if you insist.  Personally I find that to be a dangerous value to expose to users (for exactly the reason that motivated this patch) and would prefer they use the new conversion API directly instead of trying to roll their own division and getting it wrong.
FWIW: The use of the "1" parameter is because the old code was, in fact, rolling its own conversion instead of using a native conversion API (which it didn't have, of course).  Would you prefer that I go back and fix those locations?
And finally: is there a reason that changes like that can't be addressed as straightforward maintenance at some point in the future so they don't endlessly block new work?

The tests all continuing to pass isn't validation enough?

Well, no.  Are you sure all changed locations are exercised by a test that runs?  If they are, do those tests cover the range of inputs to the expression that will be observed in real applications?  Is there an impact to code size let alone correctness because expressions are now calculated with 64-bit values?
I like the new conversion APIs.  They're a great improvement.  If the new API were available and used we wouldn't have had to do a last-minute fix of #18739.
But as you did in the penultimate commit, and I proposed to be modified for consistency with the original sign/size behavior, we can implement the existing API correctly and safely using the new conversion functions.
Having done that, why is it important to replace all the existing uses of API with new calls that produce different types/values right now?  Can't that be done at some point in the future when people have had a chance to assess the new capabilities and take advantage of them in the context of what their code needs to do?

@pabigot, I ask again, can you please remove your -1?  We really need to get moving on this, I'm now working on code that needs to be continually rebased on top of three separate pull requests.  Your remaining criticism is all of the "opinion" form and I just don't see a good reason for this to block merge.
At some point, you just need to take what's offered.  Blocking patches forever helps no one.

Having done that, why is it important to replace all the existing uses of API with new calls that produce different types/values right now? Can't that be done at some point in the future when people have had a chance to assess the new capabilities and take advantage of them in the context of what their code needs to do?

This doesn't justify a -1 IMO, this seems like FUD to me.
Let's get this in so we can make progress, if issues come up we can deal with them, release isn't for another 6-7 weeks.

The impact of switching to unsigned values and 64-bit values where signed 32-bit values were used affects expression evaluation and can cause behavior changes.  No justification for the change has been provided, reverting it is trivial, and the change is a risk.  That is the primary -1.
The deprecation of API including sys_* functions was not part of #17155, has not been discussed widely, and has not been justified.  That's a secondary -1.
I've provided patches in https://github.com/pabigot/zephyr/commits/pr-nodep/19591 that address my concerns; all you would need to do is squash those in, and drop the deprecation commit and I'll approve this.
If you don't want to address my concerns, the current procedure is to bring it to dev-review for community discussion.  I've added it to the agenda for Thursday.

The impact of switching to unsigned values and 64-bit values where signed 32-bit values were used affects expression evaluation and can cause behavior changes. No justification for the change has been provided, reverting it is trivial, and the change is a risk. That is the primary -1.
The deprecation of API including sys_* functions was not part of #17155, has not been discussed widely, and has not been justified. That's a secondary -1.
I've provided patches in pabigot/zephyr:19591@pr-nodep (commits) that address my concerns; all you would need to do is squash those in, and drop the deprecation commit and I'll approve this.
If you don't want to address my concerns, the current procedure is to bring it to dev-review for community discussion. I've added it to the agenda for Thursday.

Thanks, this concise summary makes your position a lot clearer.

Because of signed to unsigned change in this PR kernel API is changing it's behavior when negative timeouts are provided and kernel API does not seem to specify how negative timeouts should be handled (e.g. in k_sleep). It's possible that timeouts may be negative when they are results of subtraction (like k_sleep(target - now) when target is already behind). For example i've tried k_sleep(-10) on qemu_cortex_m3. On master it expires immediately, on this branch it freezes.
On the other hand i don't think we should have legacy and new API's in so i'm for deprecating legacy one and moving forward. One option is to add some explicit handling of negative timeouts in the kernel API (example: https://github.com/zephyrproject-rtos/zephyr/pull/19591#discussion_r333437022)

One side comment. During playing with k_sleep and negative numbers I've noticed that k_sleep(K_FOREVER) returns immediately. Is K_FOREVER intended to be used for k_sleep?

@nordic-krch @pizi-nordic I think you have a point about putting a priority on defining and handling negative timeouts.  I would still like to see the time conversion routines in this PR merged and made available.  It seems we can't use them in the existing API (even with the casts I proposed) because they transform negative inputs into non-negative outputs, but they're very useful when you do know the values are non-negative, particularly because they handle intermediate overflow correctly.   That would allow fixes like (t < 0) ? 0 : (s32_t)k_ms_to_ticks_ceil32(t)) at points of use where we do know what to do with negative timeouts.
What that suggests for this PR is that it should drop back to just the first two commits.
I still feel the best path to addressing any change in timeouts, though, is through the "Replace integer timeout representation" task in #19655 which specifically should not have any effect on behavior because it's just wrapping the s32_t in a struct (and dealing with the massive tree-wide fallout of that change).  I don't think that can be done for 2.1, but it should commence "soonish" and a protocol followed so that when master opens up for 2.2 merges the change is already in place.
Once we have the opaque structure it becomes far simpler to figure out how to represent and denote signed and unsigned timeouts, and to detect the cases where it actually matters.  We can actually reduce the impact of the change by intentionally continuing to store timeouts in drivers (like CAN) in standard units like milliseconds, deferring the translation to ticks to the point where the kernel needs them in a native clock.

Imo, handling of negative timeouts should be fixed in kernel API before that can go in.

This is just the time unit conversion API though, it's not the timeout change.  You'll approve this PR if I change the conversion API to use signed arguments and results?   Personally I don't even really care, but at this point the bike shed is on like it's ninth coat of paint...

Is K_FOREVER intended to be used for k_sleep?

It hasn't historically worked, no.  The most recent variant of the timeout PR changes the argument to a k_timeout_t, so yes, the full timeout API will work with k_sleep(), including arbitrary units and absolute timeouts.  And there is a new k_msleep() API to preserve the older "just sleep for N milliseconds" behavior that does not support the timeout semantics.

@andyross the issue is that behavior of timeout api changed with new conversion. functions like k_timer_start accepts s32_t duration in milliseconds. After this change k_timer_start(..., -10) has different behavior than before. Previously it expired immediately, now it blocks. Even though conceptual documentation states to not use negative value (at least for k_timer), api doxygen does not mention it so it may be used as a feature like here: https://github.com/zephyrproject-rtos/zephyr/pull/19591#discussion_r333415287
In case of timeout argument in functions like k_poll if someone uses negative values and hits -1 then it is interpreted as K_FOREVER but -2 is expire now (due to: https://github.com/zephyrproject-rtos/zephyr/blob/8ef64e09c927e97550f69f8e7d8e146b3df90b77/kernel/timeout.c#L88). So it is already slick.
The question is if there will be following changes that will fix it and if they will be in the same release window. If yes then maybe we can leave with just updating doxygen and state there that timeout must be positive and move forward to opaque struct.

@nordic-krch and @pabigot were kind enough to illustrate me on the details of this Pull Request and their concerns with it. I have discussed them and here is my personal opinion on the changes proposed.
Change of semantics for all kernel APIs that take s32_t timeout.
The current behavior, as far as I can tell, is undocumented when it comes to passing anything that is * not*:

A positive value
K_NO_WAIT
K_FOREVER

This PR changes that undocumented behavior from "negative values smaller than -1 are equivalent to K_NO_WAIT and return immediately" to "negative values smaller than -1 are treated as absolute values and will therefore block for a long time". Since the behavior of kernel APIs that take timeouts  with negative timeout values smaller than -1 is currently not documented I would be glad to approve this PR if:

We document that negative values smaller than -1 are invalid
or
The above + we add an _ASSERT() to make sure we catch users passing negative values smaller than -1
or
We change the APIs implementations so that any negative value smaller than -1 is converted to 0 internally.

Conversion macro usage
From my understanding, all the macros that have been converted from taking an s32_t to an unsigned value were internal ones (either prefixed by _ or __ or z_) and so this change does not require any justification or previous warning to developers.
I would be happy to merge the PR without additional changes.
Current in-tree users of both the kernel APIs and the conversion macros
I believe we need to lead by example, so making sure that all the in-tree code that uses either kernel APIs that take a signed timeout or the conversion macros should be checked to make sure that this PR does not break them. This means that before we merge this PR we should do the following:

Analyze current users of kernel APIs that take timeouts to see if the undocumented behavior of "negative values smaller than -1 mean no wait" is being implicitly used or assumed. I know that @nordic-krch already found [this example]https://github.com/zephyrproject-rtos/zephyr/pull/19591/files#diff-251453e7816dab6b2db2e1a223260310R153) which needs fixing.
Analyze current users of the conversion macros so that we make sure that the new behavior when providing negative values smaller than -1 does not lead to new bugs.

I would approve this PR if it consisted only of the first two commits adding the uniform conversion routines--though as I'd suggested earlier I will immediately submit a PR to not inhibit generating the 32-bit us and ns conversion routines, because I have cases where I need them.
My concerns in https://github.com/zephyrproject-rtos/zephyr/pull/19591#issuecomment-539630054 remain unchanged:

In MISRA terms the signedness and size changes result in changes to the essential type of existing expressions, with unknown effect on existing code.  The "before we merge" steps from @carlescufi could mitigate that concern, though IMO they should involve the code owners as domain experts.
I still don't feel deprecating the existing sys_*/SYS_* API is well motivated.

I would very much rather those were addressed in a separate PR so we could get the non-controversial conversion functions into the baseline where we could be making immediate use of them, rather than be blocked waiting for more rework and subsequent review from affected code owners.
But in the interests of getting some progress I've removed my NACK.

OK, dust this off for one last try at getting it merged.  Rebased again.
Note that there turns out to be a pretty good performance reason for leaving the conversion API (the thing being merged here) unsigned: for obvious reasons, we want the rounding control to be explicit and correct.  But we also want the conversions generated, where possible, to be implemented with a single operation (i.e. on systems where the two frequencies are integer multiples of each other).  That doesn't work with division and negative numbers.  You can't get a floor/ceil/round behavior with a signed division without testing the sign of the operands (truncation to zero isn't the same thing, and in this context would be buggy).
I'll leave the timeout (not this pull request) series defined in terms of signed values, however, and include the tests as requested.  But conversions need to operate on unsigned quantities I think.

@andyross can you respond to https://github.com/zephyrproject-rtos/zephyr/pull/19591#issuecomment-544957921?
It's mainly about documenting negative timeout values and catching if it is misued.

Removed myself. I don't need to be a gatekeeper here.

@andyross can you respond to #19591 (comment)?
It's mainly about documenting negative timeout values and catching if it is misued.

I agree. @andyross, I wrote a small summary of items I'd like to see addressed in this PR, but you don't seem to have addressed those so far.

Returning to this again.  This isn't the timeout patch.  No change in timeout behavior is happening here.  This is only the conversion API, which I was trying to get merged early since for a long time it seemed uncontroversial.
I guess I need more specific guidance about exactly what needs to be changed in this PR.  I can't do the requested fixes here, they're comments on a different PR.

@andyross

No change in timeout behavior is happening here.

That's not true. Because conversion API is used in the kernel to convert input s32_t ms timeout to ticks. If negative number is provided behavior changes.

It is true, though...  The old ad-hoc conversion routines only notionally took a signed argument, the rounding and truncation logic being applied (both in and outside of the conversions) was assuming positive arguments.  The patch here isn't changing any of that logic, the instructions emitted are going to be exactly the same.  It's just cleaning up the API to make clear what's happening.
But that seems like a digression anyway, and another argument.  What you wanted to see, I thought, were documentation changes, and I genuinely don't know where to put them in this PR.
Can you please be really, really, hyper-specific about exactly what you want to see here before you'll agree to merge this?  I mean seriously: treat my like I'm six and tell me where to type the bytes you want to see.  I'm just completely out of ideas on how to please everyone.
(It needs yet another rebase too, obviously.  But at this point I'm out of energy to try to keep maintaining this out of tree.)

No change in timeout behavior is happening here.

That's not true. Because conversion API is used in the kernel to convert input s32_t ms timeout to ticks. If negative number is provided behavior changes.

I agree with @andyross on this point.  I can't confirm a behavior change with k_sleep(), k_poll(), or k_timer_start() (for initial delay) resulting from how this PR changes the processing of negative durations.  Tested on nrf52840_pca10055, nucleo_l476rg, efr32mg_sltb004a, and sam_e70_xplained.
I can confirm problems with negative durations on qemu_cortex_m3, but they are not introduced by changes related to this PR so may be considered a bug in the way those delays are handled by qemu.
My reasons for abstaining from approve/reject are unrelated to these specifically identified concerns, and have not changed from https://github.com/zephyrproject-rtos/zephyr/pull/19591#issuecomment-539630054.  A reworked PR that I would approve is in https://github.com/pabigot/zephyr/commits/nordic/19591 though it still has a small risk resulting from performing translations on unsigned values.

I see the change in behavior. Lets look at k_sleep because it has simple implementation which is:
ticks = k_ms_to_ticks_ceil32(ms);
ticks = z_tick_sleep(ticks);

where ms and ticks are signed values. There is a range of values where conversion will result in the change of sign and it depends on system tick frequency. For example if SYS_CLOCK_TICKS_PER_SEC=100 (like in qemu_cortex_m3) then k_ms_to_tocks_ceil32(-10) gives 429496729. As a result k_sleep(-10) on qemu_cortex_m3 freezes and on master returns immediately.

@andyross

Can you please be really, really, hyper-specific about exactly what you want to see here

@carlescufi pointed it out here: https://github.com/zephyrproject-rtos/zephyr/pull/19591#issuecomment-544957921
As for me, I would like to see clarification in the kernel API (timeouts and k_sleep) that even though timeout argument is s32_t negative values are not accepted. Imo, this clarification is needed because this PR changes negative timeouts behavior (not all, but in some cases). Currently, as argument is s32_t, user may assume (i would assume) that if i pass negative number then it will be interpretted as the past and it will expire immediately.
assert is welcomed as well. Note that z_impl_k_timer_start has such assert and pend(), z_impl_k_sleep() and z_impl_k_usleep()  in sched.c don't.

Currently, as argument is s32_t, user may assume (i would assume) that if i pass negative number then it will be interpretted as the past and it will expire immediately.

K_FOREVER is defined as (-1) so I don't think that's an obvious assumption.

@jhedberg of course that it's not obvious assumption (that's why i wrote user may assume). Even if it's not assumption, it's the implementation:
first K_FOREVER is excluded:
https://github.com/zephyrproject-rtos/zephyr/blob/556f3cbaaa3977b0c84bd4ea8a7d35c0b21b2433/kernel/sched.c#L370
then everything signed smaller that 1 is treated as 1 tick ahead:
https://github.com/zephyrproject-rtos/zephyr/blob/556f3cbaaa3977b0c84bd4ea8a7d35c0b21b2433/kernel/timeout.c#L88

@nordic-krch I think I misunderstood you - I thought you were suggesting to change something in the implementation (either old or new) wrt. this. Clearly documenting which values which are invalid and will result in undefined behaviour sounds like a good thing to me.

There are SYS_CLOCK_TICKS_PER_SEC values which will cause trouble for wide range of values. For example setting it to 1001 will result in positive result for all small negative values.

Yes, this is the clue: I can confirm the breakage with negative timeouts in this situation.  Reviewing and updating the documentation what a timeout is, taking into account future changes such as a requirement that they go through something like K_MSEC() rather than be bare integers, seems appropriate.  I'm not convinced that should block getting the core functionality of safe low-level conversion functions in.  (I still prefer the reduced approach of https://github.com/pabigot/zephyr/commits/nordic/19591 which doesn't deprecate API or change it in a way that could increase MISRA essential type violations.)

@andyross if kernal API doxygen update apart from stating that timeout must be non-negative would include K_MSEC macro requirement (as suggest by @pabigot) then it may require longer review and thus independent PR.
Alternatively, you could change all Waiting period to wait for and similar to Non-negative waiting period to wait for that would clarify that negative numbers shall not be used.
Additionally, i would insist to add asserts in 3 places (mentioned here: https://github.com/zephyrproject-rtos/zephyr/pull/19591#issuecomment-550186139) (unless im mistaken and there is more) to catch any negative arguments in timeout API.

I still don't get it.  The API has never accepted negative values (other than special tokens).  It's never worked with negative values.   None of the code in this pull request changes what happens with any of those timeout parameters when you pass acceptable values.
(Now, I agree that this misfeature is sort of a flaw, and that we should have clearer behavior about exactly how timeout parameters are specified.  That, after all, was part of the reason behind the timeout change from which this PR was split).
Your complaint, as I see it, reduces to the fact that if you use the new conversion routines with a value that used to be invalid, that the new invalid behavior might not match the old invalid behavior.  And I don't see that I can fix that in this pull request, with either documentation or anything else.
I mean, maybe you're asking that I merge this back into the pull request with the timeout changes?  This got split out specifically because of complaints that it was too large and I thought maybe I could get this in, as no one had ever argued about this part.  But that seems not to be the case either.
Please reconsider.  At this stage that's all I can ask.

@andyross

The API has never accepted negative values

Where is that stated? argument is s32_t and nowhere is stated that only limited range is accepted.
i've prepared #20439.

@nashif @andyross can we merge this as-is or can CI actually pass?

dont merge yet, this needs a rebase

OK, rebased to fix the use of a deprecated macro that crossed with this since it was written.  Should be good to go.


Xref-queries always 404

It's not possible to perform cross-reference queries (version 1.0.3, Python 3.6.1). For instance the query:
https://pubchem.ncbi.nlm.nih.gov/rest/pug/substance/xref/PatentID/US6187568B1/sids/JSON
Can be formulated as:
import pubchempy as pcp
response = pcp.request('US6187568B1', 'PatentID', 'substance', operation='sids', searchtype='xref')

However, this request 404:s since the ID is sent as payload data instead of inserted in the URL here.

A fix would be to change these lines to:
if namespace in ['listkey', 'formula', 'sourceid'] or searchtype == 'xref' or (searchtype and namespace == 'cid') or domain == 'sources':
    urlid = quote(identifier.encode('utf8'))

Then it would be nice to be able to use the short-hand:
sids = pcp.get_sids('US6187568B1', 'PatentID', 'substance', searchtype='xref'),
But doing this produces the wrong query since the operation is explicitly set None in get when setting searchtype.
However, passing on searchtype breaks TestRequest.test_listkey_requests