Consolidate contributors instructions into CONTRIBUTING.md

I've taken out contribution instructions from README.md and consolidated them into CONTRIBUTING.md.
Expanded the "Creating Pull Requests" section with pertinent instructions from the Wiki and linked to the Wiki article for reference to the full instructions.

Is there a reason you remove the "Code Not Working" section?  We have that up top since you can see the "Contribution Guidelines" when you are submitting an issue.

Code not working? section has been relabeled as Found a bug? for purposes of documentation flow:

An overview of the process (e.g. check the board, pick an issue, if you found a bug that is not on the board follow the found a bug steps ...etc).
Once you start working on an issue, you follow contributors guideline of creating a fork, branching, linting, committing, pushing ...etc
Getting started guide (prerequisites, npm install, touch .env ...etc)
Found a bug information & instructions
Creating Pull Requests information & instructions

Potential Enhancements:

Table of Contents for quick/easy navigation
Add Creating and Maintaining Local Fork section and copy the instructions from the Wiki.

Let me know if you still prefer to re-order CONTRIBUTING.md.

There are basically two different audiences here:

Interested developers, for whom your organization is perfect.
Hapless campers, fumbling around because their code broke and they forgot about the Help room.  That's why we have that section up top.  No idea if it does any good, but there is no chance the'll read through in the middle.

@SaintPeter an average camper would not even think to check CONTRIBUTING.md, or would even be intimidated by it.
An alternative solution would be to add it to README.md, which makes sense since consumers/users of the app (aka campers) are the ones most likely finding and reporting bugs/issues.

Maybe so.  Ok, I'll accept this as is and we'll work on adding info elsewhere.
Thank you for the excellent job!

I'll start working on adding some info to README.md about Code not working


Unable to create bounding box using hand_rects

Hi,
I've followed the instructions as per issue #1507 that alters the build file and outputs, however I am still getting an issue of
File "test-mediapipe-hands.py", line 37, in
for rect in results.hands_rects:
AttributeError: type object 'SolutionOutputs' has no attribute 'hands_rects'
This is running from a Conda 3.8 env and allows for the main examples to be run however runs into issues when the hand bounding boxes are attempted to be included.

hand_rects or hands_rects?

I thought I might have made a rather major mistake so I checked but even using hand_rects it gives this error:
File "test-mediapipe-hands.py", line 37, in
for rect in results.hand_rects:
AttributeError: type object 'SolutionOutputs' has no attribute 'hand_rects'

Other people reported back that is working. So I am not sure what's going wrong here. Can you go to python/site-packages/mediapipe/python/solutions/hands.py to verify if hand_rects is indeed added to the outputs list?

For the hands.py I've got the following code saved for the outputs
min_tracking_confidence,
},
outputs=['multi_hand_landmarks', 'multi_handedness', 'hand_rects']
)
and to display those results I have this code
results = hands.process(cv2.cvtColor(image, cv2.COLOR_BGR2RGB))
for rect in results.hand_rects:
print(rects)

Have also tried to reset the env but keep running into the issue of gen_protos not having permissions to alter the protoc directory which then stops the bdist wheel command being effective

is the hand_rects attribute from an earlier version perhaps? I cannot find any documentation on this.

Have also tried to reset the env but keep running into the issue of gen_protos not having permissions to alter the protoc directory which then stops the bdist wheel command being effective

I have the exact same problem


⚠ Bofrost.lu has degraded performance

In cad6eb7, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1408 ms

Resolved: Bofrost.lu performance has improved in 93a89e9.


Compile first_package example failed by 1.16.2

Steps to Reproduce Issue

brew tap mystenlabs/tap
brew install mystenlabs/tap/sui
write a new package: https://docs.sui.io/guides/developer/first-app/write-package
code copy from: https://github.com/MystenLabs/sui/tree/main/examples/move/first_package
sui move build
mainnet build ok, but devnet and testnet build failed

Expected Result

build successfully

Actual Result
Specify what the actual unexpected outcome was.

System Information

OS: mac m1
Compiler: sui 1.16.2-11511718

If I replace sui with manual installation with devnet or testnet, it will function normally. Why does sui need to be compiled from source code in so many different versions? What is the reason for this design?

@lispking Thanks for reporting this. The issue is that brew installs the most stable version, which corresponds to mainnet. Rarely, the testnet and devnet might introduce changes that break the CLI mainnet, which is what happened now because of the move verifier that was updated. We're actively working on ways to prevent this issue happening in the future.
As of now, we're updating brew to use the testnet version of the CLI.

@lispking Thanks for reporting this. The issue is that brew installs the most stable version, which corresponds to mainnet. Rarely, the testnet and devnet might introduce changes that break the CLI mainnet, which is what happened now because of the move verifier that was updated. We're actively working on ways to prevent this issue happening in the future.
As of now, we're updating brew to use the testnet version of the CLI.

Hello, is there any update regarding this error? What should I do now to avoid this error? Are there any command-line instructions or guidance? I've been stuck on this issue for two days.

@lispking Thanks for reporting this. The issue is that brew installs the most stable version, which corresponds to mainnet. Rarely, the testnet and devnet might introduce changes that break the CLI mainnet, which is what happened now because of the move verifier that was updated. We're actively working on ways to prevent this issue happening in the future.
As of now, we're updating brew to use the testnet version of the CLI.

Hello, is there any update regarding this error? What should I do now to avoid this error? Are there any command-line instructions or guidance? I've been stuck on this issue for two days.

The design of Sui is such that, at present, it is necessary to switch between different environments to compile code.
For example, if you plan to deploy contracts to devnet, you will need to use the Sui from the devnet environment for compilation.
Please note that contracts compiled in the devnet environment can only be deployed to devnet.
If you need to deploy contracts to testnet, you will need to switch to the testnet environment and recompile using the Sui from there. In this way, the issue is resolved.

Personally, I find such a design to be quite cumbersome for the software itself.
I would recommend consolidating the three environmental packages into one and introducing a command-line parameter, perhaps named --network, to address this issue.
By handling the environmental complexities within the tool, we can spare all developers from having to navigate this clunky switching process.

Hello, is there any update regarding this error? What should I do now to avoid this error? Are there any command-line instructions or guidance? I've been stuck on this issue for two days.

@jojoo-eth
The design of Sui is such that, at present, it is necessary to switch between different environments to compile code.
For example, if you plan to deploy contracts to devnet, you will need to use the Sui from the devnet environment for compilation.
Please note that contracts compiled in the devnet environment can only be deployed to devnet.
If you need to deploy contracts to testnet, you will need to switch to the testnet environment and recompile using the Sui from there. In this way, the issue is resolved.

thanks, I resolved it following the guidance from this rider. https://github.com/MystenLabs/sui/issues/16063#issuecomment-1923303380

Personally, I find such a design to be quite cumbersome for the software itself.
I would recommend consolidating the three environmental packages into one and introducing a command-line parameter, perhaps named --network, to address this issue.
By handling the environmental complexities within the tool, we can spare all developers from having to navigate this clunky switching process.

@jojoo-eth I prefer this design, or perhaps in the compilation process, the branch suitable for the Move.toml configuration file is found, which automatically switches if the network is testnet.
cc @stefan-mysten

Thanks for the feedback @lispking. I added this on our internal discussion.


Should esbuild.install --if-missing check also if outdated

Or should I add a --update-only flag?
What do you thing?

Checking the version is a good idea. Can you please send a PR?

I had some free time and I will push it. :)

Ohh, my PR is up. By checking Esbuild.configured_version() we will unexpectedly update for users if the latest_known version within esbuild is updated and no version is configured.

@cw789 I think that behaviour is the desired one, after all, esbuild is under a lock file too. Otherwise people on the same esbuild version will get different outputs depending if they ran mix esbuild.install in a previous version, no?

You're right. Got my head around. Thanks for learning.

Thank you for double checking and once again, sorry for the double effort. :)


chore(typescript): upgrade and switch to nodenext

@petermetz
When implementing Iroha V2 support in cactus I encountered some problems with @iroha2/client package. Their team provided some solution, but they require the use of moduleResolution of nodenext. This also requires upgrade of TS to 4.7. We will opt for a package that supports our current moduleResolution/typescript but, just in case and for the future, what is your opinion regarding such change?
Here's info on nodenext modules: https://www.typescriptlang.org/docs/handbook/esm-node.html

I strongly support us upgrading our Typescript compiler version in general (they seem to be improving the language very fast and in a direction that I like personally).

Hello @petermetz Can you assign me on this one? Thanks

Hello @petermetz Can you assign me on this one? Thanks

@aldousalvarez Assigned it to you just now, thank you very much! Please provide an initial report here about how much effort would it be roughly to upgrade the compiler and then we can discuss if it's a huge task to be broken up to parts or just a small one.

Hello @petermetz here is the initial report about how much effort it would be to upgrade typescript to 4.7 and switch the moduleResolution to nodeNext
•	Upgrading the typescript to 4.7
Minor updates on some of the files with few upgrades on its dependencies.
•	Migrating the moduleResolution to nodeNext
Based on the solution from ECMAScript Modules in Node.js, majority of encountered errors are due to new implementation of import policies. Here are some of the changes that bring a few high-level features that you can see below:
-type in package.json and New Extensions Node.js supports a new setting in package.json called type. "type" can be set to either "module" or "commonjs".
{
"name": "my-package",
"type": "module",
"//": "...",
"dependencies": {
}
}
This setting controls whether .js files are interpreted as ES modules or CommonJS modules, and defaults to CommonJS when not set. When a file is considered an ES module, a few different rules come into play compared to CommonJS:

import/export statements and top-level await can be used
relative import paths need full extensions (e.g we have to write import "./foo.js" instead of import "./foo")
imports might resolve differently from dependencies in node_modules
certain global-like values like require() and __dirname cannot be used directly
CommonJS modules get imported under certain special rules

After switching to nodeNext the errors come in batches with 8 to 12 dependecy errors. I have modified/updated 83 files and added 1 file to declare a package so that it would be imported.
As of now files has been tested using "yarn run test:unit" and "yarn run test:integration". Based on the latest commit all the test results are equal on the test:unit (15 suits and 151 asserts passed to 15 suits and 151 asserts passed) and with more passing results in test:integration (79 suits and 1491 asserts passed to 80 suits and 1499 asserts passed).
EXAMPLE OF THE CHANGES  APPLIED:

Before:
import { AppModule } from "./app/app.module";
import { environment } from "./environments/environment";
After
import { AppModule } from "./app/app.module.js";
import { environment } from "./environments/environment.js";

Before
import { RuntimeError } from "run-time-error";
After
const { RuntimeError } = require("run-time-error");

(Similar solution used with this issue)
Before
const { version } = await import(packageFilePath);

After
const packageFilePathJson = JSON.parse(
readFileSync(packageFilePath, "utf8"),
);
const { version } = packageFilePathJson;

Before
import {
NodeSSH,
Config as SshConfig,
SSHExecCommandOptions,
SSHExecCommandResponse,
} from "node-ssh";
After
import {
NodeSSH,
ConfigGiven as SshConfig,
ExecOptions as SSHExecCommandOptions,
ExecResult as SSHExecCommandResponse,
} from "node-ssh";

Also tried to use the new "type"; "module" into some of the packages:

examples/cactus-example-carbon-accounting-frontend/package.json
examples/cactus-example-supply-chain-frontend/package.json

Update from the latest commit:
yarn run test:integration is now having more passing results (from 80 suits and 1499 asserts passed to 83 suites and 1558 asserts passed). based on 79 suits and 1491 asserts passed from clean testing without any changes

@aldousalvarez Thank you for the detailed report, this helps a lot! The related PR is huge at the moment so I'll ask a few more questions over there to see if we could break it down into smaller pieces.

FYI: I opened this follow-up task for us to re-enable the useUnknownInCatchVariables flag https://github.com/hyperledger/cacti/issues/2463


Implement inverse_f_cdf() Presto function

@kagamiori @kgpai : Please can you provide us instructions to run ExpressionFuzzer with PrestoQueryRunner. It would be great to validate this function results during this PR time itself to avoid overwork.

@kagamiori @kgpai : Please can you provide us instructions to run ExpressionFuzzer with PrestoQueryRunner. It would be great to validate this function results during this PR time itself to avoid overwork.

Sure, I'll write and share an instruction tomorrow.

Hi @aditi-pandit and @svm1, here is the instructions for running expression fuzzer with PrestoQueryRunner in general and on specific functions: https://github.com/facebookincubator/velox/issues/11354. Please give it a try and let us know if you come across any problem. Thanks!


Update home.html

The formatting of the code is very important for home.html. Only those PRs will be accepted which have proper comments and purpose


Avoid non-public classes in the type declarations

lxml's author here. I've been following the development of type annotation packages for lxml, and it seems a general difficulty to express the interface of objects returned from the API functions that generate or select XML trees and elements. Users of these annotation packages end up importing non-public classes from lxml's modules, such as _Element. This is generally frowned upon as bad style and is usually also rejected by code checkers.
I personally think that  Protocols can solve this. I think a set of protocols is really what lxml's element API is, it's a bunch of objects and classes that implement a common or slightly different interface. It's usually not relevant what their inheritance relationship is, all that really matters is their specific interface. Thus, they seem best represented as protocols.
Could types-lxml switch to representing and declaring elements as protocols?

The cat is already out of bag for too many years. I suppose too many real world code are already using isinstance(), issubclass() etc to check against elements. Placing a big change like this can be disruptive to existing user base, and I guess you don't want that yourself.

Nominal typing is already too hardwired into the stub package. Switching to Protocol perhaps need a codebase written from scratch, and test out if the idea really works. It's not something done with just a few patches.

Protocol probably doesn't solve all problems with existing lxml api. A prominent example is that protocols and method overloads don't play nicely with each other. And there are some incompatible class overrides to be reckoned (such as subclass containing readonly attributes when base class one is read-write)

My take is that it requires another code base, and experiment would likely fail.


So Iv'e downloaded     kubescape-macos-latest    to my macbook, now what?

I have downloaded the file from from github.    It has no file extension.   What do I use to open it?

@airwalk-mj  What file did you download? If you downloaded the executable, simply run it.


Customized augmentation questions

Hello,
I analyzed the issue #326, but still not everything is clear to me, so I would like to ask three additional questions regarding augmentation:

What should I do to augment my data using transformations other than horizontal flip?
I have created a new function:

def get_transform_alex(augment):
        """This is the new transform"""
        if augment:
            transform = A.Compose([
                A.RGBShift(r_shift_limit=30, g_shift_limit=30, b_shift_limit=30, p=0.3),
                ToTensorV2()
            ], bbox_params=A.BboxParams(format='pascal_voc',label_fields=["category_ids"]))

        else:
            transform = ToTensorV2()

        return transform

which uses RGB shift instead of horizontal flip, and in the next step I used it during the creation of my model like this:
m = main.deepforest(transforms=get_transform_alex)
train_ds = m.load_dataset(csv_file, root_dir=root_dir, augment=True)

however what I obtain is still the image flipped horizontally.

Does DeepForest allow to create a few separate transformations of the data e.g. horizontal flip and vertical flip (not one after another in the pipeline using Compose)?

If I create a model which includes transformation, will it be applied to my test images at the prediction step e.g. while using predict_tile() function?

I would be greateful for your help,
Aleksandra

I would like to add an update to the post above:
I am not sure if this was previously a result of my mistake or need for reinstallation of the package, but now the augmentation works correctly. The only thing needed to be done is to create an augmentation function (similar to get_transform_alex above) and point to it when creating a model (line above m = main.deepforest(transforms=get_transform_alex).
As my training dataset is very small, I also experimented with generating more than 1 transformed image for each input training image. I discovered it gives better results. Please feel free to use the function I created:
def get_transform_alex(augment):
        """This is the new transform"""
        if augment:
            trans = A.Compose([
                A.RandomCrop(width=380, height=380),
                A.HorizontalFlip(),
                A.RandomRotate90(),
                ToTensorV2()
            ], bbox_params=A.BboxParams(format='pascal_voc',label_fields=["category_ids"]))

            n = 5
            transforms = [trans for _ in range(n)]
            transform = A.Compose(transforms)
            transform = ToTensorV2()

        else:
            transform = ToTensorV2()

        return transform

(And please don't forget to add a bit more RAM to your machine for this task - it may be a bit more computationally demanding.)


Deprecate current for-comprehension API

https://github.com/vavr-io/vavr/issues/2441
https://github.com/vavr-io/vavr/issues/2346

Codecov Report

Merging #2528 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #2528   +/-   ##
=========================================
  Coverage     93.04%   93.04%
  Complexity     5299     5299
=========================================
  Files            89       89
  Lines         12761    12761
  Branches       1606     1606
=========================================
  Hits          11874    11874
  Misses          702      702
  Partials        185      185

Impacted Files
Coverage Δ
Complexity Δ

src-gen/main/java/io/vavr/API.java
86.76% <ø> (ø)
231 <0> (ø)
:arrow_down:

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 dcd4565...14cbec8. Read the comment docs.


[auto-merge] branch-22.02 to branch-22.04 [skip ci] [bot]

auto-merge triggered by github actions on branch-22.02 to create a PR keeping branch-22.04 up-to-date. If this PR is unable to be merged due to conflicts, it will remain open until manually fix.

FAILURE - Unable to auto-merge. Manual operation is required.
{'message': 'Base branch was modified. Review and try the merge again.', 'documentation_url': 'https://docs.github.com/rest/reference/pulls#merge-a-pull-request'}

Please use the following steps to fix the merge conflicts manually:
# Assume upstream is NVIDIA/spark-rapids remote
git fetch upstream branch-22.02 branch-22.04
git checkout -b fix-auto-merge-conflict-4756 upstream/branch-22.04
git merge upstream/branch-22.02
# Fix any merge conflicts caused by this merge
git commit -am "Merge branch-22.02 into branch-22.04"
git push <personal fork> fix-auto-merge-conflict-4756
# Open a PR targets NVIDIA/spark-rapids branch-22.04

IMPORTANT: Before merging this PR, be sure to change the merging strategy to Create a merge commit (repo admin only).
Once this PR is merged, the auto-merge PR should automatically be closed since it contains the same commit hashes

Fixing this.


[ITensors] [BUG] Precompilation fails on main when developing ITensors.jl

Description of bug
I am a bit puzzled as to why this fails but when try to develop ITensors.jl and compiling the module from a fresh installation.
Minimal code demonstrating the bug or unexpected behavior
Minimal non-runnable code
julia> ]

(@v1.7) pkg> dev ITensors
     Cloning git-repo `https://github.com/ITensor/ITensors.jl.git`
   Resolving package versions...
    Updating `~/.julia/environments/v1.7/Project.toml`
  [9136182c] ~ ITensors v0.3.10 ⇒ v0.3.10 `~/.julia/dev/ITensors`
    Updating `~/.julia/environments/v1.7/Manifest.toml`
  [9136182c] ~ ITensors v0.3.10 ⇒ v0.3.10 `~/.julia/dev/ITensors`

shell> cd
/home/jan

shell> cd .julia/dev/ITensors/
/home/jan/.julia/dev/ITensors

(@v1.7) pkg> activate .

(ITensors) pkg> update
    Updating registry at `~/.julia/registries/General.toml`
    Updating `~/.julia/dev/ITensors/Project.toml`
  [c3b6d118] + BitIntegers v0.2.6
  [d360d2e6] + ChainRulesCore v1.14.0
  [34da2185] + Compat v3.43.0
  [85a47980] + Dictionaries v0.3.20
  [f67ccb44] + HDF5 v0.15.7
  [28f27b66] + IsApprox v0.1.4
  [0b1a1467] + KrylovKit v0.5.4
  [7a12625a] + LinearMaps v3.6.1
  [23ae76d9] + NDTensors v0.1.37
  [9b87118b] + PackageCompiler v2.0.5
  [ae029012] + Requires v1.3.0
  [d3ce8812] + SerializedElementArrays v0.1.0
  [90137ffa] + StaticArrays v1.4.4
  [5e0ebb24] + Strided v1.2.2
  [a759f4b9] + TimerOutputs v0.5.18
  [9d95972d] + TupleTools v1.3.0
  [bd1ec220] + Zeros v0.3.0
  [700de1a5] + ZygoteRules v0.2.2
    Updating `~/.julia/dev/ITensors/Manifest.toml`
  [c3b6d118] + BitIntegers v0.2.6
  [a74b3585] + Blosc v0.7.3
  [d360d2e6] + ChainRulesCore v1.14.0
  [34da2185] + Compat v3.43.0
  [85a47980] + Dictionaries v0.3.20
  [e2ba6199] + ExprTools v0.1.8
  [f67ccb44] + HDF5 v0.15.7
  [313cdc1a] + Indexing v1.1.1
  [28f27b66] + IsApprox v0.1.4
  [692b3bcd] + JLLWrappers v1.4.1
  [0b1a1467] + KrylovKit v0.5.4
  [7a12625a] + LinearMaps v3.6.1
  [1914dd2f] + MacroTools v0.5.9
  [23ae76d9] + NDTensors v0.1.37
  [9b87118b] + PackageCompiler v2.0.5
  [21216c6a] + Preferences v1.3.0
  [05181044] + RelocatableFolders v0.1.3
  [ae029012] + Requires v1.3.0
  [6c6a2e73] + Scratch v1.1.0
  [d3ce8812] + SerializedElementArrays v0.1.0
  [90137ffa] + StaticArrays v1.4.4
  [5e0ebb24] + Strided v1.2.2
  [a759f4b9] + TimerOutputs v0.5.18
  [9d95972d] + TupleTools v1.3.0
  [bd1ec220] + Zeros v0.3.0
  [700de1a5] + ZygoteRules v0.2.2
  [0b7ba130] + Blosc_jll v1.21.1+0
  [0234f1f7] + HDF5_jll v1.12.1+0
  [5ced341a] + Lz4_jll v1.9.3+0
  [458c3c95] + OpenSSL_jll v1.1.14+0
  [3161d3a3] + Zstd_jll v1.5.2+0
  [0dad84c5] + ArgTools
  [56f22d72] + Artifacts
  [2a0f44e3] + Base64
  [ade2ca70] + Dates
  [8bb1440f] + DelimitedFiles
  [8ba89e20] + Distributed
  [f43a241f] + Downloads
  [b77e0a4c] + InteractiveUtils
  [4af54fe1] + LazyArtifacts
  [b27032c2] + LibCURL
  [76f85450] + LibGit2
  [8f399da3] + Libdl
  [37e2e46d] + LinearAlgebra
  [56ddb016] + Logging
  [d6f4376e] + Markdown
  [a63ad114] + Mmap
  [ca575930] + NetworkOptions
  [44cfe95a] + Pkg
  [de0858da] + Printf
  [3fa0cd96] + REPL
  [9a3f8284] + Random
  [ea8e919c] + SHA
  [9e88b42a] + Serialization
  [1a1011a3] + SharedArrays
  [6462fe0b] + Sockets
  [2f01184e] + SparseArrays
  [10745b16] + Statistics
  [fa267f1f] + TOML
  [a4e569a6] + Tar
  [8dfed614] + Test
  [cf7118a7] + UUIDs
  [4ec0a83e] + Unicode
  [e66e0078] + CompilerSupportLibraries_jll
  [deac9b47] + LibCURL_jll
  [29816b5a] + LibSSH2_jll
  [c8ffd9c3] + MbedTLS_jll
  [14a3606d] + MozillaCACerts_jll
  [4536629a] + OpenBLAS_jll
  [83775a58] + Zlib_jll
  [8e850b90] + libblastrampoline_jll
  [8e850ede] + nghttp2_jll
  [3f19e933] + p7zip_jll
Precompiling project...
  ✗ ITensors
  0 dependencies successfully precompiled in 5 seconds (37 already precompiled)
  1 dependency errored. To see a full report either run `import Pkg; Pkg.precompile()` or load the package

julia> using Pkg; Pkg.precompile()
Precompiling project...
  ✗ ITensors
  0 dependencies successfully precompiled in 5 seconds (37 already precompiled)

ERROR: The following 1 direct dependency failed to precompile:

ITensors [9136182c-28ba-11e9-034c-db9fb085ebd5]

Failed to precompile ITensors [9136182c-28ba-11e9-034c-db9fb085ebd5] to /home/jan/.julia/compiled/v1.7/ITensors/jl_kdJ5Q0.

I don't understand why the following example of using add (as opposed to dev) in a new fresh test environment works:
Code and output of non-failing example when add instead of dev is used
Output of minimal runnable code
(@v1.7) pkg> activate .
  Activating project at `~/test`

(test) pkg> status
      Status `~/test/Project.toml`
  [9136182c] ITensors v0.3.10

(test) pkg> precompile

julia> using ITensors

julia> i=Index(3)
(dim=3|id=344)

julia> randomITensor(i,i')
ITensor ord=2 (dim=3|id=344) (dim=3|id=344)'
NDTensors.Dense{Float64, Vector{Float64}}

Version information

Output from versioninfo():

julia> versioninfo()
Julia Version 1.7.2
Commit bf53498635 (2022-02-06 15:21 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-12.0.1 (ORCJIT, skylake)

Output from using Pkg; Pkg.status("ITensors") in ~/test/

(@v1.7) pkg> activate .
  Activating project at `~/test`

(test) pkg> status
      Status `~/test/Project.toml`
  [9136182c] ITensors v0.3.10

Output from using Pkg; Pkg.status("ITensors") in ~/.julia/dev/ITensors

(@v1.7) pkg> activate .
  Activating project at `~/.julia/dev/ITensors`

julia> using Pkg; Pkg.status("ITensors")
     Project ITensors v0.3.10
  No Matches in `~/.julia/dev/ITensors/Project.toml`

(ITensors) pkg> update
    Updating registry at `~/.julia/registries/General.toml`
  No Changes to `~/.julia/dev/ITensors/Project.toml`
  No Changes to `~/.julia/dev/ITensors/Manifest.toml`
Precompiling project...
  ✗ ITensors
  0 dependencies successfully precompiled in 5 seconds (37 already precompiled)
  1 dependency errored. To see a full report either run `import Pkg; Pkg.precompile()` or load the package

I am not sure whether the dependencies are correct since e.g. the HDF5 package is kept at [f67ccb44] + HDF5 v0.15.7 and is not updated to 0.16.x ...
This is the manifest file in the clean ~/test/ environment:
 Manifest.toml
# This file is machine-generated - editing it directly is not advised

julia_version = "1.7.2"
manifest_format = "2.0"

[[deps.ArgTools]]
uuid = "0dad84c5-d112-42e6-8d28-ef12dabb789f"

[[deps.Artifacts]]
uuid = "56f22d72-fd6d-98f1-02f0-08ddc0907c33"

[[deps.Base64]]
uuid = "2a0f44e3-6c83-55bd-87e4-b1978d98bd5f"

[[deps.BitIntegers]]
deps = ["Random"]
git-tree-sha1 = "5a814467bda636f3dde5c4ef83c30dd0a19928e0"
uuid = "c3b6d118-76ef-56ca-8cc7-ebb389d030a1"
version = "0.2.6"

[[deps.Blosc]]
deps = ["Blosc_jll"]
git-tree-sha1 = "310b77648d38c223d947ff3f50f511d08690b8d5"
uuid = "a74b3585-a348-5f62-a45c-50e91977d574"
version = "0.7.3"

[[deps.Blosc_jll]]
deps = ["Artifacts", "JLLWrappers", "Libdl", "Lz4_jll", "Pkg", "Zlib_jll", "Zstd_jll"]
git-tree-sha1 = "91d6baa911283650df649d0aea7c28639273ae7b"
uuid = "0b7ba130-8d10-5ba8-a3d6-c5182647fed9"
version = "1.21.1+0"

[[deps.ChainRulesCore]]
deps = ["Compat", "LinearAlgebra", "SparseArrays"]
git-tree-sha1 = "9950387274246d08af38f6eef8cb5480862a435f"
uuid = "d360d2e6-b24c-11e9-a2a3-2a2ae2dbcce4"
version = "1.14.0"

[[deps.Compat]]
deps = ["Base64", "Dates", "DelimitedFiles", "Distributed", "InteractiveUtils", "LibGit2", "Libdl", "LinearAlgebra", "Markdown", "Mmap", "Pkg", "Printf", "REPL", "Random", "SHA", "Serialization", "SharedArrays", "Sockets", "SparseArrays", "Statistics", "Test", "UUIDs", "Unicode"]
git-tree-sha1 = "b153278a25dd42c65abbf4e62344f9d22e59191b"
uuid = "34da2185-b29b-5c13-b0c7-acf172513d20"
version = "3.43.0"

[[deps.CompilerSupportLibraries_jll]]
deps = ["Artifacts", "Libdl"]
uuid = "e66e0078-7015-5450-92f7-15fbd957f2ae"

[[deps.Dates]]
deps = ["Printf"]
uuid = "ade2ca70-3891-5945-98fb-dc099432e06a"

[[deps.DelimitedFiles]]
deps = ["Mmap"]
uuid = "8bb1440f-4735-579b-a4ab-409b98df4dab"

[[deps.Dictionaries]]
deps = ["Indexing", "Random"]
git-tree-sha1 = "0340cee29e3456a7de968736ceeb705d591875a2"
uuid = "85a47980-9c8c-11e8-2b9f-f7ca1fa99fb4"
version = "0.3.20"

[[deps.Distributed]]
deps = ["Random", "Serialization", "Sockets"]
uuid = "8ba89e20-285c-5b6f-9357-94700520ee1b"

[[deps.Downloads]]
deps = ["ArgTools", "LibCURL", "NetworkOptions"]
uuid = "f43a241f-c20a-4ad4-852c-f6b1247861c6"

[[deps.ExprTools]]
git-tree-sha1 = "56559bbef6ca5ea0c0818fa5c90320398a6fbf8d"
uuid = "e2ba6199-217a-4e67-a87a-7c52f15ade04"
version = "0.1.8"

[[deps.HDF5]]
deps = ["Blosc", "Compat", "HDF5_jll", "Libdl", "Mmap", "Random", "Requires"]
git-tree-sha1 = "698c099c6613d7b7f151832868728f426abe698b"
uuid = "f67ccb44-e63f-5c2f-98bd-6dc0ccc4ba2f"
version = "0.15.7"

[[deps.HDF5_jll]]
deps = ["Artifacts", "JLLWrappers", "LibCURL_jll", "Libdl", "OpenSSL_jll", "Pkg", "Zlib_jll"]
git-tree-sha1 = "bab67c0d1c4662d2c4be8c6007751b0b6111de5c"
uuid = "0234f1f7-429e-5d53-9886-15a909be8d59"
version = "1.12.1+0"

[[deps.ITensors]]
deps = ["BitIntegers", "ChainRulesCore", "Compat", "Dictionaries", "HDF5", "IsApprox", "KrylovKit", "LinearAlgebra", "LinearMaps", "NDTensors", "PackageCompiler", "Pkg", "Printf", "Random", "Requires", "SerializedElementArrays", "StaticArrays", "Strided", "TimerOutputs", "TupleTools", "Zeros", "ZygoteRules"]
git-tree-sha1 = "f69ba9534f878c8383336feb9228e57c397113e0"
uuid = "9136182c-28ba-11e9-034c-db9fb085ebd5"
version = "0.3.10"

[[deps.Indexing]]
git-tree-sha1 = "ce1566720fd6b19ff3411404d4b977acd4814f9f"
uuid = "313cdc1a-70c2-5d6a-ae34-0150d3930a38"
version = "1.1.1"

[[deps.InteractiveUtils]]
deps = ["Markdown"]
uuid = "b77e0a4c-d291-57a0-90e8-8db25a27a240"

[[deps.IsApprox]]
deps = ["LinearAlgebra"]
git-tree-sha1 = "fcf3bcf04bea6483b9d0aa95cef3963ffb4281be"
uuid = "28f27b66-4bd8-47e7-9110-e2746eb8bed7"
version = "0.1.4"

[[deps.JLLWrappers]]
deps = ["Preferences"]
git-tree-sha1 = "abc9885a7ca2052a736a600f7fa66209f96506e1"
uuid = "692b3bcd-3c85-4b1f-b108-f13ce0eb3210"
version = "1.4.1"

[[deps.KrylovKit]]
deps = ["LinearAlgebra", "Printf"]
git-tree-sha1 = "49b0c1dd5c292870577b8f58c51072bd558febb9"
uuid = "0b1a1467-8014-51b9-945f-bf0ae24f4b77"
version = "0.5.4"

[[deps.LazyArtifacts]]
deps = ["Artifacts", "Pkg"]
uuid = "4af54fe1-eca0-43a8-85a7-787d91b784e3"

[[deps.LibCURL]]
deps = ["LibCURL_jll", "MozillaCACerts_jll"]
uuid = "b27032c2-a3e7-50c8-80cd-2d36dbcbfd21"

[[deps.LibCURL_jll]]
deps = ["Artifacts", "LibSSH2_jll", "Libdl", "MbedTLS_jll", "Zlib_jll", "nghttp2_jll"]
uuid = "deac9b47-8bc7-5906-a0fe-35ac56dc84c0"

[[deps.LibGit2]]
deps = ["Base64", "NetworkOptions", "Printf", "SHA"]
uuid = "76f85450-5226-5b5a-8eaa-529ad045b433"

[[deps.LibSSH2_jll]]
deps = ["Artifacts", "Libdl", "MbedTLS_jll"]
uuid = "29816b5a-b9ab-546f-933c-edad1886dfa8"

[[deps.Libdl]]
uuid = "8f399da3-3557-5675-b5ff-fb832c97cbdb"

[[deps.LinearAlgebra]]
deps = ["Libdl", "libblastrampoline_jll"]
uuid = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e"

[[deps.LinearMaps]]
deps = ["LinearAlgebra", "SparseArrays", "Statistics"]
git-tree-sha1 = "1693d6d0dfefd24ee97ffc5ea91f1cd2cf77ef6e"
uuid = "7a12625a-238d-50fd-b39a-03d52299707e"
version = "3.6.1"

[[deps.Logging]]
uuid = "56ddb016-857b-54e1-b83d-db4d58db5568"

[[deps.Lz4_jll]]
deps = ["Artifacts", "JLLWrappers", "Libdl", "Pkg"]
git-tree-sha1 = "5d494bc6e85c4c9b626ee0cab05daa4085486ab1"
uuid = "5ced341a-0733-55b8-9ab6-a4889d929147"
version = "1.9.3+0"

[[deps.MacroTools]]
deps = ["Markdown", "Random"]
git-tree-sha1 = "3d3e902b31198a27340d0bf00d6ac452866021cf"
uuid = "1914dd2f-81c6-5fcd-8719-6d5c9610ff09"
version = "0.5.9"

[[deps.Markdown]]
deps = ["Base64"]
uuid = "d6f4376e-aef5-505a-96c1-9c027394607a"

[[deps.MbedTLS_jll]]
deps = ["Artifacts", "Libdl"]
uuid = "c8ffd9c3-330d-5841-b78e-0817d7145fa1"

[[deps.Mmap]]
uuid = "a63ad114-7e13-5084-954f-fe012c677804"

[[deps.MozillaCACerts_jll]]
uuid = "14a3606d-f60d-562e-9121-12d972cd8159"

[[deps.NDTensors]]
deps = ["Compat", "Dictionaries", "HDF5", "LinearAlgebra", "Random", "Requires", "StaticArrays", "Strided", "TimerOutputs", "TupleTools"]
git-tree-sha1 = "4fd50190d68f7ee24cf7ea6fd3c5ddbf6351caf8"
uuid = "23ae76d9-e61a-49c4-8f12-3f1a16adf9cf"
version = "0.1.37"

[[deps.NetworkOptions]]
uuid = "ca575930-c2e3-43a9-ace4-1e988b2c1908"

[[deps.OpenBLAS_jll]]
deps = ["Artifacts", "CompilerSupportLibraries_jll", "Libdl"]
uuid = "4536629a-c528-5b80-bd46-f80d51c5b363"

[[deps.OpenSSL_jll]]
deps = ["Artifacts", "JLLWrappers", "Libdl", "Pkg"]
git-tree-sha1 = "ab05aa4cc89736e95915b01e7279e61b1bfe33b8"
uuid = "458c3c95-2e84-50aa-8efc-19380b2a3a95"
version = "1.1.14+0"

[[deps.PackageCompiler]]
deps = ["Artifacts", "LazyArtifacts", "Libdl", "Pkg", "Printf", "RelocatableFolders", "UUIDs"]
git-tree-sha1 = "4ad92047603f8e955503f92767577b32508c39af"
uuid = "9b87118b-4619-50d2-8e1e-99f35a4d4d9d"
version = "2.0.5"

[[deps.Pkg]]
deps = ["Artifacts", "Dates", "Downloads", "LibGit2", "Libdl", "Logging", "Markdown", "Printf", "REPL", "Random", "SHA", "Serialization", "TOML", "Tar", "UUIDs", "p7zip_jll"]
uuid = "44cfe95a-1eb2-52ea-b672-e2afdf69b78f"

[[deps.Preferences]]
deps = ["TOML"]
git-tree-sha1 = "47e5f437cc0e7ef2ce8406ce1e7e24d44915f88d"
uuid = "21216c6a-2e73-6563-6e65-726566657250"
version = "1.3.0"

[[deps.Printf]]
deps = ["Unicode"]
uuid = "de0858da-6303-5e67-8744-51eddeeeb8d7"

[[deps.REPL]]
deps = ["InteractiveUtils", "Markdown", "Sockets", "Unicode"]
uuid = "3fa0cd96-eef1-5676-8a61-b3b8758bbffb"

[[deps.Random]]
deps = ["SHA", "Serialization"]
uuid = "9a3f8284-a2c9-5f02-9a11-845980a1fd5c"

[[deps.RelocatableFolders]]
deps = ["SHA", "Scratch"]
git-tree-sha1 = "cdbd3b1338c72ce29d9584fdbe9e9b70eeb5adca"
uuid = "05181044-ff0b-4ac5-8273-598c1e38db00"
version = "0.1.3"

[[deps.Requires]]
deps = ["UUIDs"]
git-tree-sha1 = "838a3a4188e2ded87a4f9f184b4b0d78a1e91cb7"
uuid = "ae029012-a4dd-5104-9daa-d747884805df"
version = "1.3.0"

[[deps.SHA]]
uuid = "ea8e919c-243c-51af-8825-aaa63cd721ce"

[[deps.Scratch]]
deps = ["Dates"]
git-tree-sha1 = "0b4b7f1393cff97c33891da2a0bf69c6ed241fda"
uuid = "6c6a2e73-6563-6170-7368-637461726353"
version = "1.1.0"

[[deps.Serialization]]
uuid = "9e88b42a-f829-5b0c-bbe9-9e923198166b"

[[deps.SerializedElementArrays]]
deps = ["Serialization"]
git-tree-sha1 = "8e73e49eaebf73486446a3c1eede403bff259826"
uuid = "d3ce8812-9567-47e9-a7b5-65a6d70a3065"
version = "0.1.0"

[[deps.SharedArrays]]
deps = ["Distributed", "Mmap", "Random", "Serialization"]
uuid = "1a1011a3-84de-559e-8e89-a11a2f7dc383"

[[deps.Sockets]]
uuid = "6462fe0b-24de-5631-8697-dd941f90decc"

[[deps.SparseArrays]]
deps = ["LinearAlgebra", "Random"]
uuid = "2f01184e-e22b-5df5-ae63-d93ebab69eaf"

[[deps.StaticArrays]]
deps = ["LinearAlgebra", "Random", "Statistics"]
git-tree-sha1 = "cd56bf18ed715e8b09f06ef8c6b781e6cdc49911"
uuid = "90137ffa-7385-5640-81b9-e52037218182"
version = "1.4.4"

[[deps.Statistics]]
deps = ["LinearAlgebra", "SparseArrays"]
uuid = "10745b16-79ce-11e8-11f9-7d13ad32a3b2"

[[deps.Strided]]
deps = ["LinearAlgebra", "TupleTools"]
git-tree-sha1 = "632001471b256ceac6912c3e64d4b5c65154b216"
uuid = "5e0ebb24-38b0-5f93-81fe-25c709ecae67"
version = "1.2.2"

[[deps.TOML]]
deps = ["Dates"]
uuid = "fa267f1f-6049-4f14-aa54-33bafae1ed76"

[[deps.Tar]]
deps = ["ArgTools", "SHA"]
uuid = "a4e569a6-e804-4fa4-b0f3-eef7a1d5b13e"

[[deps.Test]]
deps = ["InteractiveUtils", "Logging", "Random", "Serialization"]
uuid = "8dfed614-e22c-5e08-85e1-65c5234f0b40"

[[deps.TimerOutputs]]
deps = ["ExprTools", "Printf"]
git-tree-sha1 = "d3bfa83f95c706485de9ae755a23a6ce5b1c30a3"
uuid = "a759f4b9-e2f1-59dc-863e-4aeb61b1ea8f"
version = "0.5.18"

[[deps.TupleTools]]
git-tree-sha1 = "3c712976c47707ff893cf6ba4354aa14db1d8938"
uuid = "9d95972d-f1c8-5527-a6e0-b4b365fa01f6"
version = "1.3.0"

[[deps.UUIDs]]
deps = ["Random", "SHA"]
uuid = "cf7118a7-6976-5b1a-9a39-7adc72f591a4"

[[deps.Unicode]]
uuid = "4ec0a83e-493e-50e2-b9ac-8f72acf5a8f5"

[[deps.Zeros]]
deps = ["Test"]
git-tree-sha1 = "7eb4fd47c304c078425bf57da99a56606150d7d4"
uuid = "bd1ec220-6eb4-527a-9b49-e79c3db6233b"
version = "0.3.0"

[[deps.Zlib_jll]]
deps = ["Libdl"]
uuid = "83775a58-1f1d-513f-b197-d71354ab007a"

[[deps.Zstd_jll]]
deps = ["Artifacts", "JLLWrappers", "Libdl", "Pkg"]
git-tree-sha1 = "e45044cd873ded54b6a5bac0eb5c971392cf1927"
uuid = "3161d3a3-bdf6-5164-811a-617609db77b4"
version = "1.5.2+0"

[[deps.ZygoteRules]]
deps = ["MacroTools"]
git-tree-sha1 = "8c1a8e4dfacb1fd631745552c8db35d0deb09ea0"
uuid = "700de1a5-db45-46bc-99cf-38207098b444"
version = "0.2.2"

[[deps.libblastrampoline_jll]]
deps = ["Artifacts", "Libdl", "OpenBLAS_jll"]
uuid = "8e850b90-86db-534c-a0d3-1478176c7d93"

[[deps.nghttp2_jll]]
deps = ["Artifacts", "Libdl"]
uuid = "8e850ede-7688-5339-a07c-302acd2aaf8d"

[[deps.p7zip_jll]]
deps = ["Artifacts", "Libdl"]
uuid = "3f19e933-33d8-53b3-aaab-bd5110c3b7a0"

Am I somehow on the wrong branch?? Is main not meant to start off the be developed??

If I simply revert the changes of https://github.com/ITensor/ITensors.jl/commit/cecd72d4b53ef6e0eb4d20dc41936ebc5782d34d concerning the following lines, that is deleting NDTensors. in front of the function name:
https://github.com/ITensor/ITensors.jl/blob/40fc8deaf94a75e8ae6c00e97d6cf234fdf14a57/src/qn/qnindex.jl#L11
https://github.com/ITensor/ITensors.jl/blob/40fc8deaf94a75e8ae6c00e97d6cf234fdf14a57/src/qn/qnindex.jl#L362
Then I can precompile this version of ITensors. However, I am not sure if this is the intended behaviour of these functions, although we now find the warning WARNING: could not import NDTensors.setblock! into ITensors
julia> pwd()
"/home/jan/.julia/dev/ITensors"

julia> using Pkg

julia> Pkg.activate("./")
  Activating project at `~/.julia/dev/ITensors`

julia> Pkg.precompile()
Precompiling project...
  1 dependency successfully precompiled in 8 seconds (37 already precompiled)

julia> using ITensors
[ Info: Precompiling ITensors [9136182c-28ba-11e9-034c-db9fb085ebd5]
WARNING: could not import NDTensors.setblock! into ITensors

Very interestingly omitting  NDTensors. in this line leads to an error:
https://github.com/ITensor/ITensors.jl/blob/40fc8deaf94a75e8ae6c00e97d6cf234fdf14a57/src/qn/qnindex.jl#L206
julia> Pkg.precompile()
Precompiling project...
  ✗ ITensors
  0 dependencies successfully precompiled in 5 seconds (37 already precompiled)

ERROR: The following 1 direct dependency failed to precompile:

ITensors [9136182c-28ba-11e9-034c-db9fb085ebd5]

Failed to precompile ITensors [9136182c-28ba-11e9-034c-db9fb085ebd5] to /home/jan/.julia/compiled/v1.7/ITensors/jl_jj0ACM.
WARNING: could not import NDTensors.setblock! into ITensors
ERROR: LoadError: error in method definition: function NDTensors.eachblock must be explicitly imported to be extended
Stacktrace:
  [1] top-level scope
    @ none:0
  [2] top-level scope
    @ ~/.julia/dev/ITensors/src/qn/qnindex.jl:206
  [3] include(mod::Module, _path::String)
    @ Base ./Base.jl:418
  [4] include(x::String)
    @ ITensors ~/.julia/dev/ITensors/src/ITensors.jl:47
  [5] top-level scope
    @ ~/.julia/dev/ITensors/src/ITensors.jl:140
  [6] include
    @ ./Base.jl:418 [inlined]
  [7] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt64}}, source::Nothing)
    @ Base ./loading.jl:1318
  [8] top-level scope
    @ none:1
  [9] eval
    @ ./boot.jl:373 [inlined]
 [10] eval(x::Expr)
    @ Base.MainInclude ./client.jl:453
 [11] top-level scope
    @ none:1
in expression starting at /home/jan/.julia/dev/ITensors/src/qn/qnindex.jl:206
in expression starting at /home/jan/.julia/dev/ITensors/src/ITensors.jl:1
Stacktrace:
 [1] pkgerror(msg::String)
   @ Pkg.Types /usr/share/julia/stdlib/v1.7/Pkg/src/Types.jl:68
 [2] precompile(ctx::Pkg.Types.Context; internal_call::Bool, strict::Bool, warn_loaded::Bool, already_instantiated::Bool, kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ Pkg.API /usr/share/julia/stdlib/v1.7/Pkg/src/API.jl:1362
 [3] precompile
   @ /usr/share/julia/stdlib/v1.7/Pkg/src/API.jl:1013 [inlined]
 [4] #precompile#220
   @ /usr/share/julia/stdlib/v1.7/Pkg/src/API.jl:1011 [inlined]
 [5] precompile()
   @ Pkg.API /usr/share/julia/stdlib/v1.7/Pkg/src/API.jl:1011
 [6] top-level scope
   @ REPL[13]:1

If I simply revert the changes of cecd72d concerning the following lines, that is deleting NDTensors. in front of the function name:
https://github.com/ITensor/ITensors.jl/blob/40fc8deaf94a75e8ae6c00e97d6cf234fdf14a57/src/qn/qnindex.jl#L11
https://github.com/ITensor/ITensors.jl/blob/40fc8deaf94a75e8ae6c00e97d6cf234fdf14a57/src/qn/qnindex.jl#L362

This cannot be the solution as I cannot run the following basic function randomMPS() with conserved QNs:
julia> using ITensors

julia> N = 12
12

julia> sites_qn = siteinds("S=1", N; conserve_qns = true);

julia> psi0_qn = randomMPS(sites_qn, [if isodd(n)
                       "Up"
                   else
                       "Dn"
                   end for n = 1:N]; linkdims = 2)
ERROR: LoadError: BoundsError
Stacktrace:
  [1] _deleteat!(a::Vector{Pair{QN, Int64}}, inds::Vector{Int64}, dltd::Base.Nowhere)
    @ Base ./array.jl:1490
  [2] _deleteat!
    @ ./array.jl:1475 [inlined]
  [3] deleteat!
    @ ./array.jl:1469 [inlined]
  [4] deleteat!
    @ ~/.julia/dev/ITensors/src/qn/qnindex.jl:383 [inlined]
  [5] svd(T::NDTensors.BlockSparseTensor{Float64, 2, Tuple{Index{Vector{Pair{QN, Int64}}}, Index{Vector{Pair{QN, Int64}}}}, NDTensors.BlockSparse{Float64, Vector{Float64}, 2}}; kwargs::Base.Pairs{Symbol, Any, Tuple{Symbol, Symbol}, NamedTuple{(:maxdim, :utags), Tuple{Int64, String}}})
    @ NDTensors ~/.julia/packages/NDTensors/hSwie/src/blocksparse/linearalgebra.jl:113
  [6] svd(A::ITensor, Linds::Vector{Index{Vector{Pair{QN, Int64}}}}; kwargs::Base.Pairs{Symbol, Any, Tuple{Symbol, Symbol}, NamedTuple{(:maxdim, :utags), Tuple{Int64, String}}})
    @ ITensors ~/.julia/dev/ITensors/src/decomp.jl:109
  [7] randomizeMPS!(M::MPS, sites::Vector{Index{Vector{Pair{QN, Int64}}}}, linkdim::Int64)
    @ ITensors ~/.julia/dev/ITensors/src/mps/mps.jl:116
  [8] #randomMPS#863
    @ ~/.julia/dev/ITensors/src/mps/mps.jl:215 [inlined]
  [9] #randomMPS#862
    @ ~/.julia/dev/ITensors/src/mps/mps.jl:209 [inlined]
 [10] top-level scope
    @ ~/.julia/dev/ITensors/src/packagecompile/script_to_watch.jl:66
in expression starting at /home/jan/.julia/dev/ITensors/src/packagecompile/script_to_watch.jl:1

Hi, thanks for letting us know. I'm not sure exactly the reason for the issues you are seeing but in my experience when precompilation fails, I'm still able to use ITensors.jl after logging out of the REPL and restarting it. Is that the case for you if you start over on the main branch and revert any changes you made? (Also yes we are developing on the branch named main.)
Regarding conflicts with other dependencies, I've had some trouble with this at times also, primarily because the Julia package manager is not always very explicit about which packages are blocking others from being upgraded. But you can find out more information about that by following some of the steps outlined here:
https://itensor.github.io/ITensors.jl/stable/faq/JuliaPkg.html

So sorry guys for the fuss! I simply reverted to commit https://github.com/ITensor/ITensors.jl/commit/1ebc7a38b2193590097121526aa881e54518fc4f which was tagged v0.3.10 and implemented my proposed feature from there on.
I reckon a merge with main will be uncomplicated...
Anyhow, I'd rather discuss the proposed feature that I implemented; it's about the compilation of the system image.
For that I'll head over to the PR https://github.com/ITensor/ITensors.jl/pull/911

@jtschneider has this issue been resolved?

@jtschneider has this issue been resolved?
yes


promoto my app to v0.0.3

please, merge this to deploy my app!

/approve
looks good to me!

/assign @cheesydev

/lgtm


Don't try to retrieve the PR number if this run isn't due to a PR.

#19 worked great in CI, but failed when the PR was merged because it relied on the existence of a PR number during the CI run.
Side note: This does mean that PRs that pass because of a B***case-repo: (redacted so it doesn't catch on this pr... 🤦 ) configuration will fail when the PR is merged. I'm not sure there's much we can do about that, though - this is just part of the "chicken and egg" problem.
PR Checklist:

[x] All new features have been tested
[x] All new features have been documented
[x] I have read the CONTRIBUTING.md file
[x] I will abide by the code of conduct

Side note: This does mean that PRs that pass because of a B***case-repo: (redacted so it doesn't catch on this pr... facepalm ) configuration will fail when the PR is merged. I'm not sure there's much we can do about that, though - this is just part of the "chicken and egg" problem.

Related to this....I think that GitHub recently released their implementation of a merge queue. If my understanding is correct, it will only run CI on the merge branch and not repeat it on the main branch. While heavy handed perhaps in our case....it may remove this problem at least.

if [[ -z "${PR_BODY}" && -n "${{ github.event.pull_request.number }}" ]]

or similar instead.

Good call - old UNIX habits die hard :-)
As for the merge queue changes - I saw those get announced, but it wasn't immediately clear to me that it would help us. My read was that it would minimize the number of builds if you were landing multiple PRs at the same time, but in the simple case of merging a single PR, it wouldn't help much. The merge queue might help a little in the "Monday morning Dependabot backlog" case - but that's not enough of a problem that I've been motivated to investigate further.
If you feel like investigating this more, I'm happy to incorporate any suggestions you have.

As for the merge queue changes - I saw those get announced, but it wasn't immediately clear to me that it would help us.

Yeah; I'm ignoring the prevalent purpose of a merge queue and mostly focusing on one aspect. That is, since a merge queue seems to require that a PR's CI must pass while also incorporating all commits in the target branch, it will not re-run CI once the PR is merged in to the target branch (....since it effectively already ran those tests). Although, it isn't entirely clear to me if that's how it actually works...

since a merge queue seems to require that a PR's CI must pass while also incorporating all commits in the target branch, it will not re-run CI once the PR is merged in to the target branch (....since it effectively already ran those tests)

If I understand the docs correctly, some of this is already the case with the normal pull_request workflow. It doesn't run directly against the PR branch, but on a merged commit showing what would happen if the PR was to be merged at that moment. But without a merge queue, by the time the PR actually is merged, the main branch may have moved on, so it may be necessary to run CI again.


Installation Issues

I use the M1 Max Macbook Pro with Python 3.9.13 and find installation almost impossible. I have tried several times and get exactly the same thing:
source /opt/homebrew/Caskroom/miniforge/base/bin/activate tensorflow
user@MacBook-Pro CrunchDao % source /opt/homebrew/Caskroom/miniforge/base/bin/activate tensorflow
(tensorflow) user@MacBook-Pro CrunchDao % pip install git+https://github.com/adamerose/pandasgui.git
Collecting git+https://github.com/adamerose/pandasgui.git
Cloning https://github.com/adamerose/pandasgui.git to /private/var/folders/zz/kp45w8ds4rv3m5nhzcfkprf80000gn/T/pip-req-build-a05lwipx
Running command git clone --filter=blob:none --quiet https://github.com/adamerose/pandasgui.git /private/var/folders/zz/kp45w8ds4rv3m5nhzcfkprf80000gn/T/pip-req-build-a05lwipx
Resolved https://github.com/adamerose/pandasgui.git to commit e71a97c5809b4e31d878ae08f06cc0a1ea6dc88f
Preparing metadata (setup.py) ... done
Requirement already satisfied: pandas in /opt/homebrew/Caskroom/miniforge/base/envs/tensorflow/lib/python3.9/site-packages (from pandasgui==0.2.13) (1.5.3)
Requirement already satisfied: numpy in /opt/homebrew/Caskroom/miniforge/base/envs/tensorflow/lib/python3.9/site-packages (from pandasgui==0.2.13) (1.22.4)
Collecting PyQt5
Using cached PyQt5-5.15.9.tar.gz (3.2 MB)
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... -
As you can see it stops at preparing metadata. I left for a few hours and it eventually came back with Preparing metadata (pyproject.toml) ... killed
Please assist in this matter. Thanks

use brew to install PyQt5 first.
brew install pyqt@5
copy all library files under<EMAIL_ADDRESS>to your Python library path
then pip install pandasgui


KAFKA-5587: Remove channel only after staged receives are delivered

When idle connections are closed, ensure that channels with staged receives are retained in closingChannels until all staged receives are completed. Also ensure that only one staged receive is completed in each poll, even when channels are closed.

@ijuma @junrao Can you review, please? Thank you...
In a busy cluster with lots of leader changes, produce requests may take a long time, causing channels to be muted for a long time, resulting in channel expiry even when there are staged receives. At the moment, a staged receive can be completed and the channel removed from the selector through expiry, resulting in NullPointerException in the broker. This can cause requests received from other clients in the poll to be dropped, causing correlation id mismatch in these clients (requiring a restart).
This PR performs maybeCloseOldestConnection before addToCompletedReceives, so that channel expiry is handled in the same way as other close(). It also removes addToCompletedReceives within close() to ensure that only one receive is completed for each channel per poll. I have added unit tests to check both these scenarios.

Great find Rajini! I'll take a closer look.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/6072/
Test PASSed (JDK 7 and Scala 2.11).

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/6057/
Test PASSed (JDK 8 and Scala 2.12).

@ijuma Thank you for reviewing so quickly! Made some updates and left comments for the others.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/6075/
Test PASSed (JDK 7 and Scala 2.11).

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/6060/
Test PASSed (JDK 8 and Scala 2.12).

Merged to trunk and 0.11.0 after adding the assertion requested by @junrao. @rajinisivaram, maybe you can submit a follow-up for Jun's suggestion:
Also, in SocketServer, it may be better to catch unexpected exceptions within the loop of socket key iteration in places like processCompletedReceives(). That way, if we hit an unexpected exception, it only affects a single key. This can be done in a separate patch though.

It turns out that the additional assertion is problematic, I reverted it via https://github.com/apache/kafka/pull/3543
@rajinisivaram said:

@ijuma The assertion is not safe, since all the responses may not be received in a single poll when the connection is closed. At some point, I will write mock selector tests which can control behaviour better, but for now, the tests verify that stagedReceives are completed, but this may be less than the maxStagedReceives


Windows 8.1 not completing update process

Here are the steps that occur when I use the node-webkit-updater on Windows 8.1:

app detects a new version available
new version is downloaded & unzipped to temp directory
app closes
the new app in temp directory doesn't run
the new app doesn't get copied from the temp directory to the app's exec/install directory

Basically the app will download the updated version and then quit, but won't relaunch the downloaded new version.

Did you try using gui.Shell.openItem?

I'm basically using the example code, on OSX it is able to detect, download, update and relaunch my app, however on Windows it only seems to detect and download my app but never performs the update and relaunch.

Instead of upd.run(execPath, null);, try gui.Shell.openItem(execPath).

Thanks @adam-lynch, I'll give it a try and let you know how it goes.

I'm getting the same result with gui.Shell.openItem(execPath); it works on OSX but fails on Windows 8.1.

Is execPath what you'd expect? (The path to the .exe of the new update)

I have problem on Windows 8.1 too,
I check my code,and found :
1、app detects a new version available
2、new version is downloaded & unzipped to temp directory
3、app closes
4、the new app in temp directory run
5、the new app doesn't get copied from the temp directory to the app's exec/install directory, And I check the old version folder ,it was occupied by the new app run from temp directory.

I resolved my problem by create a bat file and gui.Shell.openItem() to run my update app as a new instance of nw.
var pathName = path.dirname(newAppPath)
var installName = pathName	+ "/install.bat"
fs.writeFileSync(installName,newAppPath+" "+ upd.getAppPath() + " "+upd.getAppExec(), "UTF-8",{'flags': 'w+'});
gui.Shell.openItem(installName)
gui.App.quit();

@Michael00767

And I check the old version folder ,it was occupied by the new app run from temp directory.

This sounds like it is being copied?
I'm not sure you need to do what you're doing.

@adam-lynch
Here is what I'm seeing when retrieving the various paths (on Windows 8.1):
newAppPath = C:\Users\hermwong\AppData\Local\Temp\PhoneGap-Desktop-Beta-0.1.4-win\PhoneGap.exe
upd.getAppExec() = C:\Program Files (x86)\Adobe\PhoneGap\PhoneGap Desktop\
upd.getAppPath() = C:\Program Files (x86)\Adobe\PhoneGap\PhoneGap Desktop\
When I execute:  upd.runInstaller(newAppPath, [copyPath, execPath],{});, my App crashes

I've attached the screenshot of the error message from the App crash.

Uncaught node.js Error

Error: spawn ENOENT
    at exports._errnoException (util.js:742:11)
    at Process.ChildProcess._handle.onexit (child_process.js:1027:32)
    at child_process.js:1110:20
    at process._tickCallback (node.js:382:11)

Hey guys!! This is an awesome app! I have local copy totally slaughtered so I can't test this quickly.. But I think I know the problem...
when you call -> upd.run(execPath, null);  spawn gets a spawn("string", null, {xxx}); I think is not liking it! Try upd.run(execPath, []);  or change updater.js so it gets a [] as a second parameter instead of null

Has anyone found a confirmed way to work around this bug? I'm experiencing the same trouble on Windows 10—the .zip file downloads and extracts, but the new process never starts up when the old version quits.

Hmm @hermwong this is weird. The result of getAppPath and getAppPath should never be the same on Windows. See here https://github.com/edjafarov/node-webkit-updater/blob/master/app/updater.js#L138 that getAppExec is the result of joining getAppPath (the parent directory of the app) and the app's basename (therefore it's just process.execPath really).

did you try what I mentioned @amsoell ? child_process.spawn signature is (String[, Array][, Object]), and the updater ends up invoking with (, null, ). It's a 5 minutes check man https://github.com/edjafarov/node-webkit-updater/blob/master/examples/basic.js#L29


Consolidate insert/bulkInsert implementations

PR consolidates the insert and bulkInsert implementations between PdoAdapter and PostgresAdapter so that we once again only have the function implemented in PdoAdapter, while retaining the override behavior added in #2195. Doing this as a precursor to #2297 so that it's easier to fix the bug where only need to change the functions in PdoAdapter and not in other places as well.

Docs? What changed for bulk insert?


scripts to run the frontend and the server seperately or at once

Created the scripts to run the frontend and the backend of the app separately of together from the root of the application,
script to run the frontend: npm start
script to run the server: npm run server
script to run both together: npm run dev

it can be used to run more than one scripts at once, so I am using it to run the frontend and backend at once , like instead of saying npm start then also using np run server that I prepared for the backend, we can just directly run npm run dev that is using concurrently to run but the start and run server command


Nmcguffey sbus topic authrule param

Description

Pipeline Reference

Pipeline

Type of Change

[ ] Update to CI Environment or utilities (Non-module affecting changes)
[ ] Azure Verified Module updates:

[ ] Bugfix containing backwards-compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:

[ ] Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
[ ] The bug was found by the module author, and no one has opened an issue to report it yet.

[ ] Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
[ ] Breaking changes and I have bumped the MAJOR version in version.json.
[ ] Update to documentation

Checklist

[ ] I'm sure there are no other open Pull Requests for the same update/change
[ ] I have run Set-AVMModule locally to generate the supporting module files.
[ ] My corresponding pipelines / checks run clean and green without any errors or warnings

There are the following issues to be fixed:
C:\source\repos\IpContrib\bicep-registry-modules\avm\res\service-bus\namespace\network-rule-set\main.bicep(35,39) : Warning use-safe-access: Use the safe access (.?) operator instead of checking object contents with the 'contains' function. [https://aka.ms/bicep/linter/use-safe-access]
C:\source\repos\IpContrib\bicep-registry-modules\avm\res\service-bus\namespace\topic\main.bicep(143,15) : Warning use-safe-access: Use the safe access (.?) operator instead of checking object contents with the 'contains' function. [https://aka.ms/bicep/linter/use-safe-access]
C:\source\repos\IpContrib\bicep-registry-modules\avm\res\service-bus\namespace\network-rule-set\main.bicep(35,39) : Warning use-safe-access: Use the safe access (.?) operator instead of checking object contents with the 'contains' function. [https://aka.ms/bicep/linter/use-safe-access]
C:\source\repos\IpContrib\bicep-registry-modules\avm\res\service-bus\namespace\main.bicep(200,13) : Warning BCP036: The property "type" expected a value of type "'None' | 'SystemAssigned' | 'SystemAssigned, UserAssigned' | 'UserAssigned' | null" but the provided value in source declaration "identity" is of type "'SystemAssigned' | 'SystemAssigned,UserAssigned' | 'UserAssigned' | null". If this is a resource type definition inaccuracy, report it using https://aka.ms/bicep-type-issues. [https://aka.ms/bicep/core-diagnostics#BCP036]
C:\source\repos\IpContrib\bicep-registry-modules\avm\res\service-bus\namespace\topic\main.bicep(143,15) : Warning use-safe-access: Use the safe access (.?) operator instead of checking object contents with the 'contains' function. [https://aka.ms/bicep/linter/use-safe-access]

@elanzel - is this not a duplicate of #3505

@elanzel - is this not a duplicate of #3505

It's a duplicate of #3505 which is a duplicate of #2909 ➿


build with jdk 19

Motivation:
we can enable jdk 19 builds and test out project loom features
Modifications:

include jdk 19 in the GitHub action build matrix

Result:

Closes #4465
loom features can be enabled during tests

Gradle 7.6 has been released. https://docs.gradle.org/7.6/release-notes.html
We may continue to upgrade to Java 19.

https://github.com/line/gradle-scripts/pull/139 is merged. 😉

It is likely that the flaky Scala build is fixed.
We need to check it more but it looks promising. 😆

Yay 😎   Procrastinating paid off 🥳

Any comments on this @minwoox?

Thanks again @Jimexist for the initial work of this PR. 🙇♂🙇♂


fix some problems in paper and url service

url: Modified url format
paper: When it was compatible with the URL, it was found that the parameters of downloadUrl did not match the Android version and was modified.
Removed the download and acquisition of release.apk and beta.apk, they can be obtained directly through port 5000

记得更新接口文档

我有一个疑问，为什么你的 commit 记录包含着已经合入仓库的commit？


Confusing inactive download buttons

I checked https://dex.decred.org/ and my first instinct was to hit the sexy Download buttons expecting I would get the new standalone version.
They are kind of disabled but still "blue enough" and are tempting to click (there is no "bluer" button in view to have a contrast to see that they are disabled). Then I noticed the "NOTE" above, realized they are disabled and not clickable by design, and figured I need to click that link.
I know this is a silly "bug" but maybe user navigation can be made smoother here. A few ideas:

Add word "Decrediton" to each of the 3 Decrediton download tiles to communicate what exactly will be downloaded

OR group Decrediton downloads under a visible Decrediton with DEX client header or something

Make 3 tiles for Decrediton downloads totally gray to give no false hope of being clickable
Add 4th download tile for the standalone version (with a note that OS and architecture will be picked in the next step).

This allows to also remove the less visible "Click here to download the standalone DCRDEX application instead  ↓" link below. It is less visible because it's a line of text and not a big download tile.
Each download option having a tile may look more consistent and intuitive.

This is temporary because the old Decrediton downloads were causing major problem.  They will be replaced and reactivated asap.  https://github.com/decred/dexweb/pull/30
I hope this does not become a recurring issue where we have to disable them often, but I like all of your bullet point suggestions.  I would support those changes.


Use a loop in ObjectIdentifier::new

Replace the hardcoded if's with a while loop in ObjectIdentifier::new.
Note: While loops can be used in const fn since Rust 1.46.0.

I checked and the loop, at the very least, works in csnmp's MSRV (1.67).
Merged -- thanks for the contribution!


⚠ ClamAV has degraded performance

In f815910, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 60 ms

Resolved: ClamAV performance has improved in f18c4ea.


HttpBaseStream Gzip extract - NotSupportedException

Hi, looks like when trying to decompress a gzip through httpStream it throws NotSupportedException on Position when setting EntryStartPosition. what is the purpose of settings this field? how can i mitigate the problem? Thanks!
System.NotSupportedException: Specified method is not supported.
   at System.Net.Http.HttpBaseStream.get_Position()
   at SharpCompress.IO.RewindableStream.get_Position()
   at SharpCompress.Common.GZip.GZipFilePart..ctor(Stream stream, ArchiveEncoding archiveEncoding)
   at SharpCompress.Common.GZip.GZipEntry.GetEntries(Stream stream, OptionsBase options)+MoveNext()

P.S i'd prefer to not save the file to disk and read it again as FileStream if possible
If that's not possible which types require random access? i know that .tar.gz works perfectly fine through http for example, Thanks in advance!

You'll have to show me how you're calling things.
GZipFilePart does check CanSeek but Rewindable is meant to buffer unbufferable streams so shouldn't be used here.

Actually, I take that back, GZipFilePart has a usage of Position no matter seeking.  That should be changed

I'm not familiar with the internals of how Gzip works, but again, why do we need EntryStartPosition? isn't there only one entry always in .gz? maybe i can help :)


Object Explorer does not provide UI indication when connection retry in-progress

Azure Data Studio Version: master

Steps to Reproduce:

Connect to a server
Disable the network
Expand a node

Expected: Expansion will timeout after a while, but if the connection is failing and being retried the user is notified regarding the delay.
Actual: Connection will timeout and be retried and timeout again.  The delay can take a long time and the user doesn't know why.

Cleaning out some older issues that we don't plan to fix near term.


How to load plotly and ag-grid JS files in offline environment

I am running pywebio in an offline environment, all pywebio functions work but datatables and plotly charts are not able to load due to being unable to pull data from the CDN. Is there a way to pre-load these JS files into the application? @wang0618

PyWebIO use requirejs to load the plotly and ag-grid JS files. PyWebIO init the requirejs in this:
https://github.com/pywebio/PyWebIO/blob/185333a0bd2a0906f95d16ade55ced6150b517ae/pywebio/platform/tpl/index.html#L79-L86
So, you can use pywebio.session.run_js() to reconfig the requirejs in your pywebio app to let requirejs load those js files from your application server.
Here is an example to download those js file to app server and use them to replace the default ones:
import json
import urllib.request

import plotly.express as px
import pywebio
from pywebio.output import put_html, put_datatable

def main():
    pywebio.session.run_js("""
    require.config({
        paths: {
            'plotly': "static/plotly.min",
            "ag-grid": "static/ag-grid-community.min",
            "ag-grid-enterprise": "static/ag-grid-enterprise.min",
        },
    });
    """)

    df = px.data.gapminder().query("country=='Canada'")
    fig = px.line(df, x="year", y="lifeExp", title='Life expectancy in Canada')
    html = fig.to_html(include_plotlyjs="require", full_html=False)
    put_html(html)

    with urllib.request.urlopen('https://fakerapi.it/api/v1/persons?_quantity=30') as f:
        data = json.load(f)['data']

    put_datatable(data)

if __name__ == '__main__':
    """
    mkdir static
    curl https://cdn.plot.ly/plotly-2.12.1.min.js > static/plotly.min.js
    curl<EMAIL_ADDRESS>> static/ag-grid-community.min.js
    curl<EMAIL_ADDRESS>> static/ag-grid-enterprise.min.js
    """
    pywebio.start_server(main, port=8080, static_dir='./static', cdn=False)

thank you! it works now.


Fix duplicated rows in zkapp_account_precondition table

Added shell script which generated two sql scripts for patching database:

zkapp_precondition_script.sql - Removes duplicated rows in zkapp_account_precondition
zkapp_update_body_script.sql - Updates zkapp_account_update_body table which has foreign key to zkapp_account_precondition table

Moreover i've updated zkapp_tables.sql script and added unique constraint so that whenever we bypass Ocaml code and manipulate data directly db constraint will complain
Lastly added update script which adds constraint if we want to patch existing database.
In order to fix current schemas in ITN we need to follow below steps:

run zkapp_duplicated_precondition/remove_duplicated_zkapp_account_precondition_rows.sh {schema}
run produced scripts in correct order: zkapp_precondition_script.sql, zkapp_update_body_script.sql
update constraint for zkapp_account_precondition table: add_constraint.sql

Closes #14777

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!approved-for-mainnet

!ci-build-me


book-store: Add missing trailing zero

Sorry, for this micro change. I just couldn't resist. If all the other numbers have up to 2 trailing zeros ...

Thanks @behrtam.


ViewModel example

The FAQs callout an example with ViewModels was coming soon, but I couldn't find an associated tracking issue 😄
I imagine it might look something like HiltSupport from the Hilt support FAQ?

Right now we have only experimental PR #303 with viewmodel support which you can use in your codebase. But it's not officially supported yet


GEOWAVE-398 & GEOWAVE-401.  DWITHIN corrected to handle the unit conv…

…ersion properly from distance (meters, km, etc.) to decimal degrees (EPSG:4326 long/lat).  There is still a degree of error difficult to compensate for when dealing polygons (e.g a country).  Future work will adopt a more accurate approach consistent with other LocationTech projects

Coverage increased (+0.07%) to 62.69% when pulling df0d9a08ef3b478128af72197e8e951e26df396e on GEOWAVE-398 into 441e24b53930cb52294a31e0af77362985531dce on master.

Coverage increased (+0.07%) to 62.69% when pulling df0d9a08ef3b478128af72197e8e951e26df396e on GEOWAVE-398 into 441e24b53930cb52294a31e0af77362985531dce on master.

Addressed one comment and left the other.  Thinking better to have a false positive than a negative.

Coverage increased (+0.07%) to 62.68% when pulling 7b8ccbf8db2f52ebff4c665f367daf411ae77078 on GEOWAVE-398 into 441e24b53930cb52294a31e0af77362985531dce on master.

Coverage increased (+0.07%) to 62.68% when pulling 7b8ccbf8db2f52ebff4c665f367daf411ae77078 on GEOWAVE-398 into 441e24b53930cb52294a31e0af77362985531dce on master.

Coverage increased (+0.07%) to 62.68% when pulling 7b8ccbf8db2f52ebff4c665f367daf411ae77078 on GEOWAVE-398 into 441e24b53930cb52294a31e0af77362985531dce on master.

Coverage increased (+0.07%) to 62.68% when pulling 7b8ccbf8db2f52ebff4c665f367daf411ae77078 on GEOWAVE-398 into 441e24b53930cb52294a31e0af77362985531dce on master.

Coverage increased (+0.19%) to 62.82% when pulling 9714f75fc0952fdf892bc9e117d9ec30f40a7087 on GEOWAVE-398 into b7a6de214a6653c6277ffc93c3d87359f7a00c2e on master.

Coverage increased (+0.07%) to 62.69% when pulling 9714f75fc0952fdf892bc9e117d9ec30f40a7087 on GEOWAVE-398 into b7a6de214a6653c6277ffc93c3d87359f7a00c2e on master.

Coverage increased (+0.15%) to 62.77% when pulling b16aff6cac4805655fb4a4d7cd57d25b0af5cc01 on GEOWAVE-398 into b7a6de214a6653c6277ffc93c3d87359f7a00c2e on master.


Add create_koji_session to koji_util

Coverage decreased (-0.006%) to 87.034% when pulling 9c238043522b9098475ca3c6d95f3b7a6d811ddb on lcarva:koji-util into 5105a67b13abbf194388321a35d49b100bec3867 on projectatomic:koji-util.


chore(editor): display deprecation message

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
ui deprecation

What is the current behavior? (You can also link to an open issue here)
editor is not stay updated and will be replaced by the vscode extension

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
no, the editor is deprecated

Other information:

replaced by #433


want paper

Hi:
I serch your paper in google ,but no answer.Could you share your paper《Histogram Matching Augmentation for Domain Adaptation》.
Thanks very much

Hi,
Find it here: https://arxiv.org/pdf/2012.13871.pdf

hello：
Thanks.I try this method,but my back-bone is not nnUnet.The result is not bad.
------------------ 原始邮件 ------------------
发件人:                                                                                "JunMa11/HM_DataAug"                                                                                @.>;
发送时间: 2021年3月13日(星期六) 凌晨2:12
@.>;
<EMAIL_ADDRESS>主题: Re: [JunMa11/HM_DataAug] want paper (#1)
Hi,
Find it here: https://arxiv.org/pdf/2012.13871.pdf
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


Implicit modifiers fall off from ValDefs

If I add the following in https://github.com/LPTK/squid-examples/blob/master/embedding-from-macros/src/test/scala/test/TestTest.scala
  val r2 = Test2.test {
    implicit val x = 42
  }

then it prints
[At compile time:]
	Original program: code"""{
  val x_0 = 42;
  ()
}"""
	Transformed program: code"""{
  val x_0 = 42;
  ()
}"""

i.e., x is not implicit anymore.

This is by design. Squid's normal mode of operation is to manipulate trees that are fully resolved: fully typed and fully applied (including implicits), so the fact that a local value be implicit has no incidence on the program after type checking.
That said, I assume you have a good use case for it. Perhaps you want to insert some code within the body of that let binding where some implicits are not resolved yet? If that's a necessity for you, I think we can keep track of the implicit modifier and generate code that contains it (this would likely be done there).
Let me know what's your stance on it.

Oh, I see!
Unfortunately, we need to keep the implicits unresolved in most parts of Emma's pipeline, and resolve them only at the end. (This is because some Flink implicits resolve to scary stuff that we can't handle at the moment, for example anonymous classes like new Foo {...})
So it would be good if Squid kept the implicit modifiers on the ValDefs, because then we could still resolve them at the end.

Okay, that makes some sense. However, you're probably going to have troubles if you try to handle these Flink functions in quasiquotes. Remember that Squid quasiquotes are type-checked and will require the implicit arguments to be inferred or provided.
A way around this (if you do need to manipulate these constructs explicitly) would be to define a mirror of each construct but without the implicit parameters, and only at the end of the day, when generating code, you change them back to the actual Flink functions. (The mirror could actually be macros that expand into the Flink function automatically on compiling the program using scalac.)
I'll look into the implicit val thing. Note that a workaround could be to encode implicit val a = t; ... as withImplicit(a) { ... } and either manually convert them back on code gen or use the macro trick mentioned above.

Thanks for looking into this! I'm thinking of an other workaround now, which avoids having to define the mirrors:
Let's say that the user's code is calling some Flink method:
x.flinkMethod

which has some problematic implicit parameter that, say, looks like this after resolution (before Emma's pipeline):
x.flinkMethod(new Foo{})

Instead of completely removing this implicit argument at the start of Emma's pipeline, maybe I could just replace it with a dummy argument like this:
x.flinkMethod((???): Foo)

And then Emma would pass such trees to Squid somewhere in the middle of our pipeline.
And later at the end of our pipeline Emma would remove these dummies and re-resolve them.
Do you think this could work?
Note that this workaround would still need Squid to keep the implicit modifiers on the ValDefs, so that we can resolve at the end of our pipeline.

@ggevay Sure, that should work fine. You can name the method:
def inferLater[A](): A = ???

and later transform its applications to:
def inferNow[A](implicit a: A): A = a

Good idea, thanks!


Support for Plasma Mobile and Phosh

Hello,
I have a working Kivy based app which I would like to run on FOSS mobiles OSes like Plasma Mobile and Phosh (here on Pinephone with Manjaro and Mobian). But there are 2 issues so far which make Kivy unusable on those platforms:

both OSes use Wayland, and I've tried to build Kivy with Wayland support (using various compilation option combination), and each time I have a black screen. The only way I could make it run is using the X11 backend (XWayland is running on those OSes), but this is not ideal.

the virtual keyboard is not usable. By default it is not activated and the OS virtual keyboard does not detect the input field (tested on Phosh). In addition it is way too small (can be of course mitigated by customizing VKeyboard kv, but it would be good to have sane defaults).
If I activate the virtual keyboard manually, the behaviour is funny with focus lost, and random touch events.

It would be great to have native Kivy support for those platforms, or at least some documentation on how to compile in way similar to what is done for Raspbery Pi.
Input field should activate the OS virtual keyboard, and focus should not be lost, touching the OS keyboard should not raise touch events in Kivy.
Thanks

Regarding the OS keyboard on input, Kivy needs to support text-input-v3 or text-input-v2 from wayland protocol
cf. https://social.tchncs.de/@Jbb/105680940679299415

small update: even with the following in KV:
<VKeyboard>:
    size_hint_y: 0.5
    font_size: 40

The VKeyboard is unusable. Keys are appearing twice, trying to backspace will remove the keyboard.

One more nice thing to have: Add arm64 wheels to the distribution so installing kivy directly on those phones via pip/pipenv will not require the build step which takes forever on those lower powered devices.

It is possible to write Kivy apps to run on Phosh, but you may need to add some workarounds to your code.
Touches are registered as two touches on the touch screens of both the PinePhone running Phosh and the Librem 5.  You can workaround that behavior with a tiny bit of code that can protect against double presses like this:
import time
from kivy.app import App
class MainApp(App):
    over_press_timer = 0

    def some_touch_event_processor_like_a_button_or_vkey_press(self, *kwargs):
        if (time.time() - self.over_press_timer) > 0.3:
            self.over_press_timer = time.time()
            # put your touch processing logic here

You cannot use Phosh's native Squeekboard as a soft keyboard as it is VERY incompatible with Kivy.  You need to use managed keyboard_mode for InputText widgets.  You can use vkeyboard, but the default layouts are unusable on the small Librem 5 and PinePhone screens.  Instead you will need to create your own custom layouts.  I have an app that has 7 different keyboard layouts that my soft keyboard management code will swap among.  Last but not least you need to fix Kivy's vkeyboard key_background_disabled_normal/key_disabled_background_normal bug or typo so your app will not randomly crash (not technically a Phosh issue but important when using vkeyboard on a Phosh device).
from kivy.uix.vkeyboard import VKeyboard
soft_keyboard = VKeyboard()
soft_keyboard.key_background_disabled_normal = soft_keyboard.key_disabled_background_normal

There is also a touchscreen calibration issue on Phosh.  Kivy registers touches at the relative touch location of the touchscreen device rather than the widget render location on the screen.  This is because Kivy doesn't know about the 36 pixels Phosh uses at the top and bottom of the screen for its own icons and controls.  It doesn't make the app unusable, but it does mean that you have to reach a little higher and lower on the screen to activate a widget when the widget is near the top or bottom of the screen.   This can be fixed to some extent by intercepting collide_point calls and calibrating the y position parameter.  I am still looking for a more elegant solution to this issue.  If I come up with a better workaround I might post it to this issue thread.


fix: update all dependencies to the latest versions

Description

update all dependencies
use latest react-scripts with latest craco and latest react, react-dom
update code where packages have breaking changes

Related issue(s)
Fixes https://github.com/asyncapi/studio/issues/375

/rtm


Evaluation computer

In the challenge rules it's stated: "The computer that should be used to evaluate programs of candidates is a Linux OS machine with 2 CPU, 16GB of RAM."
Could you please give more details on the machine?
Is multi-threading allowed?

Hello,
At the moment we cannot provide more details on the machine (every thing should be done in the cloud). Multithreading is alllowed (2CPU will be available).

Hello,
Could we at least know the clock speed (GHz)? It's important information for many of the competing teams I guess.

Any news on this?
Could we send our executable few days/weeks before the deadline so you can run it and give us the feedback?

Hello,
Here are information regarding the testing environment:
Distribution : Debian 10 stable
CPU : Intel i7-6700K 4c / 8t 4GHz
RAM : 16GB

Thanks!


Connect Middleware ignores res.status set in controller when using res.json

The HTTP status code in res.json is set always set to 200. It should be possible to set a different code within the controller, though. Removing line 220 in connect_middleware.js (res.statusCode = 200) solves the issue without having any negative effect (as far as I see).
So... am I missing a sideeffect/wanted behavior or should the line be removed?
Cheers.

How about we set it only if you haven't already?

Makes sense. Cheers.

Hi, I'm currently using the v4.4 but this fix is not there, are you planning to included it in next releases?

Yes. This will be included in a new release soon.


Migrate wasmd v0.27.0

Summary

Cosmwasm v1.0.0 has been released.
Adapt wasmd corresponding to that version to x/wasm.
https://github.com/CosmWasm/wasmd/releases/tag/v0.27.0
https://github.com/CosmWasm/wasmd/compare/v0.19.0...v0.27.0
127/334 (6/10 15:00)
Problem Definition

Proposal

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

close due to the existence of a similar issue.
https://github.com/line/lbm-sdk/issues/555


Tracking Issue: upgrade to 128-bit amount values in notes

Following #1336, where we have decided to move to 128 bit amounts in our notes, we need to do the implementation. A few steps are as follows

[ ] Update the spec to specify how we handle bridged assets, where we will return an error if we can't fit an asset in a u128, and the exact encoding for the u128
[x] Implement a new Amount domain type that encapsulates a u128, and provides functionality for encoding the u128 as two u64s for use in our protobufs.
[x] Propagate the new Amount type throughout the codebase, replacing u64 where it was used previously.

@avahowell What's the current status of this issue?

We have the new amount type now, but it is still using a u64 internally

Following #1819, what's the status of this on the client side? We at least need to be able to record 128-bit values in sqlite in the rust view server (cc @aubrika).

@aubrika Could you summarize your opinions on our options here? I believe there was some relevant discussion in Discord recently that you may want to cross-link.

@aubrika Could you summarize your opinions on our options here? I believe there was some relevant discussion in Discord recently that you may want to cross-link.

I think storing the u128 as a BLOB in SQLite will make for easier type conversions than using two i64 columns & will still allow us to do sorting & range selects on the BLOB values. I don't think there's any issue yet for the needed storage changes but the needed changes shouldn't be too complicated.

@erwanor Can you take another look and just comment on current status? I suspect this work will need to be tracked on the next testnet, given @aubrika's comment above, but I defer to you on that.

One idea mentioned in sprint planning was to add another token to genesis with a high level of precision similar to eth (e18) to see what breaks. This could be done with a single note.

We'll also need to change the signature to Amount::value -> u128 and integrate that with the rest of the codebase

Sounds good, I think we'll generally want to avoid converting to u64s, and migrating our existing uses to use Amounts

This has been done for a while.


Fixed CheckInstallerPrefabTypes with Unity 2018.3 and later

Pull request checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been reviewed and added / updated if needed (for bug fixes / features)
[x] No compiler errors or warnings

Pull request type

Please check the type of change your PR introduces:

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

Issue Number
Not filed
What is the current behavior?

The obsolete check was used with Unity 2018.4, generating compiler warnings
The check used with Unity 2018.3 was generating failures for nested prefabs.
No check was performed for Unity 2019 or later

What is the new behavior?

The compiler warning is fixed
I switched to use PrefabUtility.IsPartOfPrefabAsset(installer.gameObject), which is the equivalent of the old check.
The newly used check works fine with Unity 2019 too.

Does this introduce a breaking change?

[ ] Yes
[x] No

Other information

We work with Extenject embedded in our projects, so didn't write tests for the bug about nested prefabs. Could use some help with that if you want that covered.

On which Unity version has this been tested?

[ ] 2020.4 LTS
[ ] 2020.3
[ ] 2020.2
[ ] 2020.1
[ ] 2019.4 LTS
[x] 2019.3
[ ] 2019.2
[ ] 2019.1
[x] 2018.4 LTS

Scripting backend:

[x] Mono
[ ] IL2CPP

Note: Every pull request is tested on the Continuous Integration (CI) system to confirm that it works in Unity.
Ideally, the pull request will pass ("be green"). This means that all tests pass and there are no errors. However, it is not uncommon for the CI infrastructure itself to fail on specific platforms or for so-called "flaky" tests to fail ("be red").  Each CI failure must be manually inspected to determine the cause.
CI starts automatically when you open a pull request, but only Releasers/Collaborators can restart a CI run. If you believe CI is giving a false negative, ask a Releaser to restart the tests.

Thanks!


vite websocket connection not working

https://github.com/marc3lsk/AspNetReactViteSpaYarp
In this repo I tried to make my client app with vite+react. When I run the dotnet app and navigate to its URL I can see my react app but it keeps reloading periodically. It seems that connection to vite WebSocket localhost:3000 is not working. How could this be fixed?

I was able to fix this issue by adjusting the vite config and startup script https://github.com/marc3lsk/AspNetReactViteSpaYarp/commit/3a4dc4580dfecedbf6a4a51c40b348b03b36f3a4
I figured it out thanks to this article https://blogs.taiga.nl/martijn/2021/02/24/integrating-vite-with-asp-net-core-a-winning-combination/

Thanks for sharing @marc3lsk! If you want, I can create a samples section in the readme and link to your repo.

No problem! I don't mind if you would like to use my repo as an example.


Add keyutils to CBL-Mariner base image

Is your feature request related to a problem? Please describe.
Bug reports have been filed against WSL2 because of failures of the Linux Kernel's Key Request Service.   The Key Request Service provides an upcall mechanism as documented in Documentation/security/keys/request-key.rst where the kernel executes an instance of /sbin/request-key for each request.   The request-key process is provided by the keyutils package.  If the /sbin/request-key process cannot be located in the mount namespace of the root filesystem, then the upcalls will fail with an -ENOENT error.   The Key Request service is used in support of keyring management, DNS queries, and id-mapping.
Describe the solution you'd like
Please install keyutils as part of the base image
Describe alternatives you've considered
Installation of keyutils in an WSL2 distro container does not work because the installed /sbin/request-key cannot be located in the mount namespace of the root filesystem.
Additional context
A working key request service is necessary to support various Linux kernel options including

CONFIG_CIFS_UPCALL, CONFIG_CIFS_DFS_UPCALL, CONFIG_CIFS_SWN_UPCALL: https://github.com/microsoft/WSL/issues/9540
CONFIG_AFS_FS: https://github.com/microsoft/WSL/issues/11458
CONFIG_NFS_USE_KERNEL_DNS
CONFIG_CEPH_LIB_USE_DNS_RESOLVER
NFS ID Mapper

It should be noted that the AzureLinux kernel config includes

CONFIG_DNS_RESOLVER=y
CONFIG_NFS_USE_KERNEL_DNS=y

which depend upon the presence of /sbin/request-key from the keyutils package.

I'd love this!

Not sure why this isn't in the wsl CBL?
https://github.com/microsoft/azurelinux/pull/6425

@jaltman Not sure why this isn't in the wsl CBL?
#6435

We can tdnf install keyutils with WSL CBL-Mariner.
Also, the kernel that runs WSL is by design of WSL not the one shipped with AzureLinux, but WSL2-Linux-Kernel
In other words, whatever distribution we use, be it ubuntu, fedora, AzureLinux via WSL, it will always have the WSL2-Linux-Kernel

We can tdnf install keyutils with WSL CBL-Mariner. Also, the kernel that runs WSL is by design of WSL not the one shipped with AzureLinux, but WSL2-Linux-Kernel In other words, whatever distribution we use, be it ubuntu, fedora, AzureLinux via WSL, it will always have the WSL2-Linux-Kernel

@mfrw it doesn't matter which kernel is being used.   All Linux kernels that support keyrings require the ability to issue an upcall by executing /sbin/request-key from the namespace of the root filesystem mount.   That means that /sbin/request-key must be present in the root filesystem's namespace.   When tdnf is used to install /sbin/request-key (as part of the keyutils package) into a container image filesystem the kernel cannot successfully execute /sbin/request-key.
What I am asking for in this request is that the keyutils package be added to the CBL-Mariner base image so that /sbin/request-key and its required configuration and associated helpers are available in the root filesystem namespace.
A simple test of the /sbin/request-key upcall is to execute
keyctl request2 user debug:foo "expired" @s

if /sbin/request-key is not present in the root filesystem it will fail with a "No such file or directory" error.  (-ENOENT).   This will be true even if /sbin/request-key is present in the Debian, Ubuntu, AzureLinux container image.


Add Dodo Labs - Stockalike Electron from SpaceDock

This pull request was automatically generated by SpaceDock on behalf of tygoo7, to add Dodo Labs - Stockalike Electron to CKAN.
Mod details:
name = /mod/1944/Dodo%20Labs%20-%20Stockalike%20Electron
author = tygoo7
abstract = Dodo Labs is a small parts pack that provides stockalike parts to create the Electron rocket by Rocket Lab.
license = All rights reserved
Homepage =
description = Current parts

Emu fairing (0.9375m)

Emu second stage tank (0.9375m)

Emu second stage engine (0.9375m)

Emu decoupler (0.9375m)

Emu first stage tank (0.9375m)

Emu engine shroud (0.9375m)

Emu first stage engine (0.9375m)

Known issues

None yet!

Planned Features

None yet, but I'm open to suggestions!

Please direct questions about this pull request to tygoo7.

This was added in #6686.


[FLINK-19392] Add the execution.runtime-mode

What is the purpose of the change
This PR adds the execution.runtime-mode, as described in FLIP-134, without exposing it yet to the user.
For now, we set the mode globally at the StreamGraphGenerator. An alternative would be to set it at each Transformation individually based on its predecessors. We went with the global option because, at least for now, we will schedule the whole graph either in STREAMING or in BATCH mode so the setting has to be global. In the future, if we consider mixed graphs where subgraphs are scheduled in BATCH mode and others in STREAMING, then we could consider setting the mode on each transformation individually.
In addition, this PR sets the Boundedness of some Legacy sources to BOUNDED (e.g. env.fromCollection()). If this were to be combined with runtime.execution-mode set to AUTOMATIC, it would change the already exposed semantics. Given that we do not want that, we have set the default runtime.execution-mode to STREAMING so that the Boundedness is ignored and the exposed semantics are the same as before.
Brief change log
The main additions are:

the logic in the StreamGraphGenerator.determineExecutionMode(), which determines the execution.runtime-mode based on either an explicit setting, or by looking at the Boundedness of the sources of the pipeline and

the setting of Boundedness for some of the source in the StreamExecutionEnvironment.

Verifying this change
Add the StreamGraphGeneratorRuntimeExecutionModeDetection class with the relevant tests.
Does this pull request potentially affect one of the following parts:

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

Documentation

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

Ah, one other thing. You title the main commit Add the execution.runtime-mode. We don't add any setting like that here, so the title could just be Detect runtime execution mode based on boundedness of sources.

Thanks for the review @aljoscha. I integrated your comments. Do you or @dawidwys have more?

After addressing:
https://github.com/apache/flink/pull/13502#discussion_r496575845
In the current state there is no field from where we can read the determined mode when transforming the Transformations. In the end we will need that, e.g. to create appropriate sink or add sorted inputs. I know you have some plans for that as well, so I am good with how it looks now. However I wanted to just mention it.

Thanks for the comments @dawidwys and @aljoscha .
@dawidwys you are right that there is no field currently but my IDE was giving me a warning and given that I will address it in a follow-up PR, I thought that for now it is safe to directly use the return value of the shouldExecuteInBatchMode().
@aljoscha do you have more comments?