useGithubAPI().getVersions() should not need auth

Motivation
According to the comments on the getVersion method:

GitHub tags API returns in reverse alphabetical order so we have to use their graphql endpoint, [which] sadly requires auth :/

Why don't we just use the GitHub tags API and sort the tags according to semver? This should work for a majority of cases, and we can always be more clever if we need to.

I've written of proof of concept. It looks super ugly but it seems to work okay for the repos I have tested
async function getVersions(user, repo) {
  const url = `https://api.github.com/repos/${user}/${repo}/git/refs/tags`

  const req = await fetch(url)
  const res = await req.json()
  let tags = res.map((tag)=>tag.ref.slice(10)) // map object to just tag name

  const regex = /\d+.\d+.\d+/gm // extract semver (x.x.x) from tag name
  tags = tags.sort((a, b) => {
    a = a.match(regex)
    b = b.match(regex)

    // all invalid semver gets sorted at the start, is this a good idea? idk
    if(a === null) return -1;
    if(b === null) return 1;

    a = a[0].split(".").map((str)=>parseInt(str))
    b = b[0].split(".").map((str)=>parseInt(str))

    if(a[0] !== b[0]) return a[0] - b[0]
    if(a[1] !== b[1]) return a[1] - b[1]
    if(a[2] !== b[2]) return a[2] - b[2]

    return 0
  })

  return tags
}

This also has the added advantage (in my opinion) of actually sorting by semver. If I understand the current code setup correctly, this is not being done. This means that on the golang repo in the current implementation, the versions would look like:
[
    // ...earlier versions
    "go1.18.6", "go1.19.1", "go.1.18.7", "go1.19.2", "go.1.18.8", "go1.19.3"
]

which in my opinion is very unintuitive.
If there is no interest, feel free to close.
Tests

On this repo, it returns this which looks perfect
[
  "v0.1.0",   "v0.1.1",   "v0.1.2",   "v0.2.0",   "v0.3.0",   "v0.3.1",
  "v0.3.2",   "v0.3.3",   "v0.3.4",   "v0.3.5",   "v0.3.6",   "v0.3.7",
  "v0.3.8",   "v0.3.9",   "v0.4.0",   "v0.4.1",   "v0.4.2",   "v0.4.3",
  "v0.5.0",   "v0.5.1",   "v0.5.2",   "v0.5.3",   "v0.5.4",   "v0.5.5",
  "v0.5.6",   "v0.6.0",   "v0.6.1",   "v0.6.2",   "v0.6.3",   "v0.6.4",
  "v0.6.5",   "v0.6.6",   "v0.6.7",   "v0.6.8",   "v0.6.9",   "v0.6.10",
  "v0.7.0",   "v0.7.1",   "v0.8.0",   "v0.8.1",   "v0.8.2",   "v0.8.3",
  "v0.8.4",   "v0.8.5",   "v0.8.6",   "v0.8.7",   "v0.8.8",   "v0.8.9",
  "v0.8.10",  "v0.8.11",  "v0.8.12",  "v0.9.0",   "v0.9.1",   "v0.9.2",
  "v0.10.0",  "v0.10.1",  "v0.10.2",  "v0.10.3",  "v0.10.4",  "v0.10.5",
  "v0.10.6",  "v0.10.7",  "v0.10.8",  "v0.11.0",  "v0.11.1",  "v0.11.2",
  "v0.11.3",  "v0.11.4",  "v0.11.5",  "v0.11.6",  "v0.11.8",  "v0.11.9",
  "v0.11.10", "v0.11.11", "v0.11.13", "v0.11.14", "v0.12.0",  "v0.12.1",
  "v0.13.0",  "v0.13.1",  "v0.13.2",  "v0.13.3",  "v0.13.4",  "v0.13.5",
  "v0.13.6",  "v0.13.7",  "v0.13.8",  "v0.13.9",  "v0.13.10", "v0.13.11",
  "v0.14.0",  "v0.14.1",  "v0.14.2",  "v0.14.3",  "v0.14.4",  "v0.14.5"
]

On the golang repo, which is just super problematic, it looks like this (which is okay, we could probably do some smarter parsing):
[
	// unparsed, put at start
	"weekly.2012-03-27","weekly.2012-03-22","weekly.2012-03-13","weekly.2012-03-04","weekly.2012-02-22","weekly.2012-02-14",
	"weekly.2012-02-07","weekly.2012-01-27","weekly.2012-01-20","weekly.2012-01-15","weekly.2011-12-22","weekly.2011-12-14",
	"weekly.2011-12-06","weekly.2011-12-02","weekly.2011-12-01","weekly.2011-11-18","weekly.2011-11-09","weekly.2011-11-08",
	"weekly.2011-11-02","weekly.2011-11-01","weekly.2011-10-26","weekly.2011-10-25","weekly.2011-10-18","weekly.2011-10-06",
	"weekly.2011-09-21","weekly.2011-09-16","weekly.2011-09-07","weekly.2011-09-01","weekly.2011-08-17","weekly.2011-08-10",
	"weekly.2011-07-29","weekly.2011-07-19","weekly.2011-07-07","weekly.2011-06-23","weekly.2011-06-16","weekly.2011-06-09",
	"weekly.2011-06-02","weekly.2011-05-22","weekly.2011-04-27","weekly.2011-04-13","weekly.2011-04-04","weekly.2011-03-28",
	"weekly.2011-03-15","weekly.2011-03-07.1","weekly.2011-03-07","weekly.2011-02-24","weekly.2011-02-15","weekly.2011-02-01.1",
	"weekly.2011-02-01","weekly.2011-01-20","weekly.2011-01-19","weekly.2011-01-12","weekly.2011-01-06","weekly.2010-12-22",
	"weekly.2010-12-15.1","weekly.2010-12-15","weekly.2010-12-08","weekly.2010-12-02","weekly.2010-11-23","weekly.2010-11-10",
	"weekly.2010-11-02","weekly.2010-10-27","weekly.2010-10-20","weekly.2010-10-13.1","weekly.2010-10-13","weekly.2010-09-29",
	"weekly.2010-09-22","weekly.2010-09-15","weekly.2010-09-06","weekly.2010-08-25","weekly.2010-08-11","weekly.2010-08-04",
	"weekly.2010-07-29","weekly.2010-07-14","weekly.2010-07-01","weekly.2010-06-21","weekly.2010-06-09","weekly.2010-05-27",
	"weekly.2010-05-04","weekly.2010-04-27","weekly.2010-04-13","weekly.2010-03-30","weekly.2010-03-22","weekly.2010-03-15",
	"weekly.2010-03-04","weekly.2010-02-23","weekly.2010-02-17","weekly.2010-02-04","weekly.2010-01-27","weekly.2010-01-13",
	"weekly.2010-01-05","weekly.2009-12-22","weekly.2009-12-09","weekly.2009-12-07","weekly.2009-11-17","weekly.2009-11-12",
	"weekly.2009-11-10.1","weekly.2009-11-10","weekly.2009-11-06","weekly","release.r60.3","release.r60.2",
	"release.r60.1","release.r60","release.r59","release.r58.2","release.r58.1","release.r58",
	"release.r57.2","release.r57.1","release.r57","release.r56","go1.19","go1.19rc2",
	"go1.19rc1","go1.19beta1","go1.18","go1.18rc1","go1.18beta2","go1.18beta1",
	"go1.17","go1.17rc2","go1.17rc1","go1.17beta1","go1.16","go1.16rc1",
	"go1.16beta1","go1.15","go1.15rc2","go1.15rc1","go1.15beta1","go1.14",
	"go1.14rc1","go1.14beta1","go1.13","go1.13rc2","go1.13rc1","go1.13beta1",
	"go1.12","go1.12rc1","go1.12beta2","go1.12beta1","go1.11","go1.11rc2",
	"go1.11rc1","go1.11beta3","go1.11beta2","go1.11beta1","go1.10","go1.10rc2",
	"go1.10rc1","go1.10beta2","go1.10beta1","go1.9","go1.9rc2","go1.9rc1",
	"go1.9beta2","go1.9beta1","go1.8","go1.8rc3","go1.8rc2","go1.8rc1",
	"go1.8beta2","go1.8beta1","go1.7","go1.7rc6","go1.7rc5","go1.7rc4",
	"go1.7rc3","go1.7rc2","go1.7rc1","go1.7beta2","go1.7beta1","go1.6",
	"go1.6rc2","go1.6rc1","go1.6beta2","go1.6beta1","go1.5","go1.5rc1",
	"go1.5beta3","go1.5beta2","go1.5beta1","go1.4","go1.4rc2","go1.4rc1",
	"go1.4beta1","go1.3","go1.3rc2","go1.3rc1","go1.3beta2","go1.3beta1",
	"go1.2","go1.2rc5","go1.2rc4","go1.2rc3","go1.2rc2","go1.1",
	"go1.1rc3","go1.1rc2","go1",

	// parsed, sorted at end
	"go1.0.1","go1.0.2","go1.0.3",
	"go1.1.1","go1.1.2","go1.2.1","go1.2.2","go1.3.1","go1.3.2",
	"go1.3.3","go1.4.1","go1.4.2","go1.4.3","go1.5.1","go1.5.2",
	"go1.5.3","go1.5.4","go1.6.1","go1.6.2","go1.6.3","go1.6.4",
	"go1.7.1","go1.7.2","go1.7.3","go1.7.4","go1.7.5","go1.7.6",
	"go1.8.1","go1.8.2","go1.8.3","go1.8.4","go1.8.5rc4","go1.8.5rc5",
	"go1.8.5","go1.8.6","go1.8.7","go1.9.1","go1.9.2","go1.9.3",
	"go1.9.4","go1.9.5","go1.9.6","go1.9.7","go1.10.1","go1.10.2",
	"go1.10.3","go1.10.4","go1.10.5","go1.10.6","go1.10.7","go1.10.8",
	"go1.11.1","go1.11.2","go1.11.3","go1.11.4","go1.11.5","go1.11.6",
	"go1.11.7","go1.11.8","go1.11.9","go1.11.10","go1.11.11","go1.11.12",
	"go1.11.13","go1.12.1","go1.12.2","go1.12.3","go1.12.4","go1.12.5",
	"go1.12.6","go1.12.7","go1.12.8","go1.12.9","go1.12.10","go1.12.11",
	"go1.12.12","go1.12.13","go1.12.14","go1.12.15","go1.12.16","go1.12.17",
	"go1.13.1","go1.13.2","go1.13.3","go1.13.4","go1.13.5","go1.13.6",
	"go1.13.7","go1.13.8","go1.13.9","go1.13.10","go1.13.11","go1.13.12",
	"go1.13.13","go1.13.14","go1.13.15","go1.14.1","go1.14.2","go1.14.3",
	"go1.14.4","go1.14.5","go1.14.6","go1.14.7","go1.14.8","go1.14.9",
	"go1.14.10","go1.14.11","go1.14.12","go1.14.13","go1.14.14","go1.14.15",
	"go1.15.1","go1.15.2","go1.15.3","go1.15.4","go1.15.5","go1.15.6",
	"go1.15.7","go1.15.8","go1.15.9","go1.15.10","go1.15.11","go1.15.12",
	"go1.15.13","go1.15.14","go1.15.15","go1.16.1","go1.16.2","go1.16.3",
	"go1.16.4","go1.16.5","go1.16.6","go1.16.7","go1.16.8","go1.16.9",
	"go1.16.10","go1.16.11","go1.16.12","go1.16.13","go1.16.14","go1.16.15",
	"go1.17.1","go1.17.2","go1.17.3","go1.17.4","go1.17.5","go1.17.6",
	"go1.17.7","go1.17.8","go1.17.9","go1.17.10","go1.17.11","go1.17.12",
	"go1.17.13","go1.18.1","go1.18.2","go1.18.3","go1.18.4","go1.18.5",
	"go1.18.6","go1.18.7","go1.18.8","go1.19.1","go1.19.2","go1.19.3",
]

We originally used tags, but you have to paginate all of the tags, which can be 20 pages. Without a token GitHub limit you to 10 requests a minute, so you still need a token.
Also this only effects builds which most users will not do, so I feel requiring a token is acceptable.
I would prefer not to need a token, I just don’t see how we can achieve this.

With the GitHub tags API, I don't see any option for pagination. I'm pretty sure the /repos/:user/:repo/git/refs/tags endpoint returns all tags in one go. 10 requests a minute seems like way more than we need if we don't do pagination?

Last time I was in here /repos/:user/:repo/git/refs/tags was paginated returning at most 100 tags. Maybe I'm wrong though.
Certainly if we can do it without auth I'm all for it. I just don't think we can based on last time I tried.

oh interesting. So I’m cool with getVersions using /repos/:user/:repo/git/refs/tags if there no GITHUB_TOKEN is provided.
Rationale: we only use this for builds currently, and making this change additive is safe.


Packages for conda-forge

@rusty1s and other developers,
I'm excited to see that PyTorch Geometric can already be installed with conda (https://github.com/rusty1s/pytorch_geometric#anaconda) and seems to be compatible with conda-forge.
Do you have any specific reason not to contribute the packages directly to conda-forge?
There has already been some effort to create PyTorch Geometric packages for conda-forge (https://github.com/conda-forge/pytorch_geometric-feedstock, ping @oblute @rluria14).
For context, we are expanding OpenMM (https://github.com/openmm/openmm) capabilities to use ML for molecular simulations (https://github.com/openmm/openmm-torch). The common problem is that many packages from PyPI and other conda channels are binary incompatible and it makes hard to use them. conda-forge solves many of these issues.
Recently, we have migrated OpenMM to conda-forge. If you are interested, @jchodera could connect you with the right people in the conda-forge community.

It looks like there is a PR to update to the latest pytorch-geometric release that appears to be stalled due to a pinned dependency that causes an ABI consistency. It may be a simple matter to update to the latest versions of everything to eliminate the ABI incompatibility?

Thanks for reaching out. I actually didn‘t know about the efforts of putting PyTorch Geometric into conda-forge. This is great to see.
I actually put my repos in my own channel because it is quite cumbersome to deal with different CUDA versions and PyTorch ABI issues, as this allows me to update packages more conveniently whenever a new update/PyTorch version/CUDA support is available. If you think this is well doable in conda-forge, I‘m happy to join forces. However, it is unclear to me what the advantages are of putting repos into conda-forge rather than my own channel, as PyTorch is doing the same as well.

@rusty1s : The conda-forge ecosystem aims to make it easier to solve compatibility issues (like the ABI compatibility problems) by using a harmonized compiler suite for all packages built in the conda-forge channels. There is an elegant feedstock-based automatic mechanism for keeping packages up to date when new releases are cut. Recently, we've made significant progress in building GPU-enabled packages that use CUDA/OpenCL for tools like OpenMM.
A brief overview of advantages of migrating tools like pytorch to conda-forge is given here, but one of the principal advantages is that it makes it possible to build conda-installable packages that depend on your library (here, PyTorch Geometric) since it can be pulled from conda-forge as a dependency. This isn't possible if it lives in a separate channel without more complicated installation procedures (like distributing an environment.yml or having users manually install dependencies).

Oh, I should note that these aren't exclusive distribution mechanisms! It's perfectly reasonable to have both conda-forge and non-conda-forge channels at the same time. But there are significant advantages to the conda-forge ecosystem in making it easy to build tools/applications on top of other libraries within conda-forge.

Hi,
An incomplete conda-forge package is available via https://github.com/conda-forge/torch-scatter-feedstock
I agree that having availability through own mechanisms definitely makes targeting all OS's easier (e.g., windows pytorch is only available through the pytorch channel), and I feel that having both options is definitely feasible. I am more than happy to help, of course.

Thanks. Is there a roadmap for what is missing in conda-forge/torch-scatter-feedback or where you might need help? I'm happy to help if time allows.

There isn't a roadmap, per say.
As far as missing items go, I had to use this line [ref] to ensure the conda-forge builds worked correctly:
skip: true  # [win or (linux and cuda_compiler_version in (undefined, 'None', '10.2'))]

But this basically means that only OSX CPU builds are getting taken up, and nothing else. I tried multiple variants to get Windows and Linux builds to work but didn't go far.

Tracking this here: https://github.com/conda-forge/torch-scatter-feedstock/issues/3

This should be operational: https://anaconda.org/conda-forge/torch-scatter

@sarthakpati thanks for your effort!
Do you have plant to make packages for PyTorch Geometric and its other dependencies?

I had a quick look and it does seem to be pretty involved. I won't be able to get to it any time soon but I am happy to help out if you are starting this on your own.


Integration Test - Release - 2022/01/10 09:05:37

Auto create for integration test. IssueCommandFlow

#pri1

Just type '#pri3'

#pri2

#pri3

#assign PRMergerTest1

#assign NonAllowedUser

The following users don't have valid GitHub IDs, or are not collaborators on this repo: nonalloweduser

#reassign PRMergerTest2

#reassign NonAllowedUser

#please-close

The following users don't have valid GitHub IDs, or are not collaborators on this repo: nonalloweduser

GitHub user PRMergerTest2 has been removed from the MicrosoftDocs organization, so they were automatically removed as an assignee.

#unassign PRMergerTest1

#unassign NonAllowedUser


can't find module tensorflow after building 'quantize_graph'

Hi,
I followed this blog post in order build the tool for quantizing graph (tensorflow/contrib/quantization/tools/quantize_graph).
I had a clean working version of tensorflow installed properly.
I used this command in order to build the quantization tool :
bazel build tensorflow/contrib/quantization/tools:quantize_graph
It seems that the build went ok :
INFO: Found 1 target...
Target //tensorflow/contrib/quantization/tools:quantize_graph up-to-date:
bazel-bin/tensorflow/contrib/quantization/tools/quantize_graph
INFO: Elapsed time: 20.105s, Critical Path: 16.60s
However after that finished when i open python and try to import tensorflow i get an error message :
ImportError: No module named tensorflow
Environment info
Operating System: Ubuntu 16.04
Installed from source, without GPU support :

commit hash = 37256f4857cdadefa09e0505f4acc91ffbf626e2
bazel version =
Build label: 0.3.1
Build target: bazel-out/local-fastbuild/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Fri Jul 29 09:09:52 2016<PHONE_NUMBER>)
Build timestamp:<PHONE_NUMBER>
Build timestamp as int:<PHONE_NUMBER>

i get the same behaviour when trying to build the freeze_graph tool :
bazel build tensorflow/python/tools:freeze_graph

It looks like you need to follow the install steps again. Feel free to reopen the issue if you still have the problem.


[To be tested] Add the "win" runtime in all Desktop & Test project.json

It solve the build for me on VS 2015 Update 1 RC
I let the "win-anycpu" runtime everywhere it was already present, but I don't know if it build under Non-Update1 VS.
@AArnott if you can you test on non-Update1 ? Otherwise i'll do it tomorrow from work (Still didn't update). This PR is also there to see how appveyor behave with such a configuration.

It works for me on my VS2015 RTM box. :) Thanks for doing this.


Particles dont work on large distance

The default range is 32 blocks. This can be changed with the visibleRange parameter.


make pod label update event handle in order within a queue

Please provide a description of this PR:

@hzxuzhonghu: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
08b4d63feaf01b8a1d07fd3c268ec4d452c59e95
link
true
/test unit-tests-arm64

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

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
08b4d63feaf01b8a1d07fd3c268ec4d452c59e95
link
true
/test unit-tests-arm64

release-notes_istio
08b4d63feaf01b8a1d07fd3c268ec4d452c59e95
link
true
/test release-notes

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

@hzxuzhonghu: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
eb676bfa1f7ae351d0db36cf67040a1b3fcb2845
link
true
/test release-notes

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

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
eb676bfa1f7ae351d0db36cf67040a1b3fcb2845
link
true
/test release-notes

lint_istio
eb676bfa1f7ae351d0db36cf67040a1b3fcb2845
link
true
/test lint

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

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
eb676bfa1f7ae351d0db36cf67040a1b3fcb2845
link
true
/test lint

release-notes_istio
93f668e482e13d4c2cbd8f2b79d2f2aac5926b17
link
true
/test release-notes

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

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
93f668e482e13d4c2cbd8f2b79d2f2aac5926b17
link
true
/test release-notes

integ-ambient_istio
93f668e482e13d4c2cbd8f2b79d2f2aac5926b17
link
true
/test integ-ambient

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

/retest


wrong instructions in readme.txt

in readme.txt:

Run sudo ./install.sh

should be:

Run ./install.sh

according to README.md
also note that is the old way to install, and should "fail gracefully" or (better) adapt

What do you mean should "fail gracefully" or (better) adapt?

the documented install procedure should adapt. I know you have changed the installer so it can be done without sudo/root, so maybe its a moot point.
I have to wait to get back to this, but as long as the text in the README.md is correct, that will be fine


Create a basic search input field with a basic results list

NB! This should be really basic, and the main goal is to just connect Next.js with Algolia using react-instantsearch.
Acceptance criteria

Connection to algolia is working on localhost
Connection to algolia is working in production
When you click the magnifier icon, a basic search panel is visible
A basic unstyled search field is added to the search panel
A basic result component is added to the search panel

To test

Open the search panel by clicking the icon
Type "c" in the input field
Some hits are showing (the red colour for the actual hit in the ingress text is just added for testing purposes)

It looks like this. We don't want to refine more as this was supposed to be simple, but let's rather add new and more specific issues.

#envis-devs It would be nice if someone can verify the setup on localhost :thumbsup: See env.local.template.


Document running Docker on RaspberryPI

Problem
Document running Docker on RaspberryPI
Solution
Many blogs are out there, some of which are quite old, that talk about ways to get Docker running on a RaspberryPI.  We should put together better documentation in a central place on how to run Docker on various common OS distros used on RaspberryPI (raspbian, snappy ubuntu, etc.)

@icecrime I think the article should mention that it is "experimental" and not officially supported (or has that changed?)

I'd be happy to work on this one....

@aetherical great! Make sure to mention closes #11580 in the description of your pull request

Guys, We have already worked out one way to deploy Docker in Raspberry Pi with Arm11

I was going to contribute here but with #12519 it looks like it has been done already. Does this issue need to stay open?

@alexellis good question; perhaps after we have official binaries for rPi

I have a fair amount of experience using Docker with the Raspberry PI ARMv6 and ARMv7 chipset. Is there any need for a short document or jump off? Does #12519 cover what was wanted?

I have around 22 tutorials on running Docker on the Raspberry Pi / ARM.
Is there any potential for a link-back or mention if we cannot agree on how to best write instructions for ARM/Pi in the official docs?
http://blog.alexellis.io/tag/raspberry-pi/

Let me ping @mstanleyjones, she's on the docs team

We already have instructions for Raspbian but they are pretty old. If this is a goal, it would be nice to polish these and bring them up to date.


ObjectProperty vs xsd:anyURI

You have a bunch of props (I guess all subprops of gs1:linkType, but maybe more) like this:
gs1:activityIdeas a rdf:Property, owl:ObjectProperty ;
    rdfs:range xsd:anyURI ;

However, xsd:anyURI is a literal, so it can't be used with owl:ObjectProperty.
I never understood the utility of xsd:anyURI, eg see discussion with FIBO people https://github.com/edmcouncil/fibo/discussions/1367

it does allow spaces, whereas a true URL does not

So either remove rdfs:range xsd:anyURI (my preference), or the owl:ObjectProperty designation.

@philarcher @mgh128 : I see the same in this doc: GS1 Digital Link: Semantics
Extracting the meaning of identity and data relationships expressed in GS1 Digital Link URI syntax.
To Be 1.2, Draft 0.5, 23 November 2020
sec 3.10 Link type semantics
GS1 defines its link types in the Web Vocabulary [WebVoc]. In terms of semantics, we define a
super property of gs1:linkType that has a domain of owl:Thing and a range of xsd:anyURI, i.e. it
is very generic. Each GS1 link type is a sub property of this and typically has further restrictions.
Such declaration would make digital links unable to point to RDF nodes with extra information, which goes contrary to EPCIS 2 plans to put master data at such URLs.
Similar problem in EPCIS: https://github.com/gs1/EPCIS/issues/206


Fix errors in SIFT tests

This PR fixes two errors with the sift tests:

Fix error with array.sum() for new versions of pyopencl
Do not perform test_matching if there is no "feature" module

Also, another (equivalent but more numerically stable) least squares routine is used for the linear alignment.

Hi Pierre,
About the commit 61f057b:
The test of matching of matching should be run even if the result cannot be checked to ensure no bugs is hidden there. Moreover the "L1 norm" is cheap enough so that it could be done in pure Python at little additional cost.

OK, we revert to this behavior with 8e18d66886e15b36ba8ce883d4d5c0f7b8f7abca

LGTM


New Output Folder

What is the purpose of your issue?

[ ] Bug
[x] Feature Request
[ ] Question
[ ] Other

Description

after downloading and converting the music file when finished automatically save into the output folder given by the user, by default it should be the music playlist name.
$ spotdl --playlist https://open.spotify.com/user/nocopyrightsounds/playlist/7sZbq8QGyMnhKPcLJvCUFD
INFO: Writing 62 tracks to ncs-releases.txt
$ spotdl --list ncs-releases.txt -O /root/Music/Ncs-Release/
INFO: Saving Music to `/root/Music/Ncs-Release/`

Log

https://github.com/ritiek/spotify-downloader/wiki/FAQ#how-to-specify-a-custom-folder-where-tracks-should-be-downloaded

Also see https://github.com/ritiek/spotify-downloader/wiki/Advanced-usage#set-custom-filenames.
Use / for a creating a directory, example: {artist}/{track_name}.


Enable configuring for scrollable element in scrollThen

https://github.com/ef4/liquid-fire/blob/master/app/transitions/scroll-then.js#L9
I'd like to modify the element that is being scrolled. Right now it's hard-coded at html which is probably a good default, but I'd like to pass in a more relevant container element.
CC @nathanhammond @chadhietala

This seems like it should be configurable, but yet again I'm not too aware of the liquid fire internals and the things it does to setup for animating.

It's configurable in the sense that you can duplicate this transition and make it configurable in your own version. A better question is if that's something that @ef4 would like to be pushed upstream, possibly into this transition. :)
Two ways it could be made configurable:

additional positional argument (could break people).
element property in the options hash.

@ultimatedelman I'd start by creating a transition just for your use case by cloning and modifying this one. Once that works as you'd like, I'd drop it into liquid-fire and see if all tests continue to pass. If so, then @ef4 can make a determination about whether he wants to pull that upstream.


[BEAM-8208] [website] update Python container build invocation

R: @Hannah-Jiang

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

LGTM, thanks for improving it.


[Bug][Master] Master cannot fault tolerant when multiple Masters start at the same time

**For better global communication, Please describe it in English. If you feel the description in English is not clear, then you can append description in Chinese(just for Mandarin(CN)), thx! **
Describe the bug
If multiple Masters are started at the same time, it will cause global fault tolerance logic errors. Multiple Masters that are online at the same time are recognized, fault tolerant will be skipped
多个Master同时启动，会导致全局容错逻辑错误，识别到多个同时在线的Master，会跳过容错

Expected behavior
Master registration Zookeeper and start fault tolerance at the same time
Master 注册Zookeeper和启动容错同时进行
Which version of Dolphin Scheduler:
-[1.3.*]

I'll fix it


Timestore API feature request

I've had a look at the proposed time series for the new store and it looks the same as the old time series store to me.
With the old time series store that I'm writing apps agains at the moment, it is not possible to query based on parameters (e.g. value == 1). In my current app i am using motion sensor data from the hue motion sensors and i want to work out which room is most occupied over the day. As it stands I have to retrieve all the data from a day and process this inside the app when what I really want is only the times when the sensor has been activated. To reduce data exposure I would suggest that parameter based querying of time series data is support. This is a common feature in all modern time series data stores e.g. influxdb - https://docs.influxdata.com/influxdb/v1.3/
For more complex data sets (not just 1/0) it also be useful to specify standard aggregations (mean min max mode etc) and resolutions when querying. Expecting the app to do all this processing seems nonsensical and against the databox ethos to me.
In the future I would expect that the SLA for an app would restrict the query parameters available based on user preference at the point of installation.

cc// @mor1 @cgreenhalgh @jptmoore any thoughts?
This seems to me like something many apps may need to do, not sure how easy it would be to support this on unbounded JSON blobs, maybe adding a new numerical type to the time series API would make some of this more tractable.

Overall in architectural terms I'm with James here even if we can't achieve this immediately in the first release, the idea of the stores is to avoid giving all the data to the app to have to process. We discussed in the call/meeting as well that timeseries stores should have basic stats functionalities, and also in research terms evaluating these for different application types should make for a nice paper in addition to adhering to the minimal exposure principles of Databox.

I think that there are several value-schema-specific areas of functionality that should be added in future:

indexes and querying based on a numerical value or parts of a composite (JSON-style) value (cf mongo, etc.)
stats and granularity for queries over numerical values (only?!)
ditto for geo-location
other type-specific fuzzing/granularity? e.g. word counts in text, date/time granularity (e.g. date of birth vs year of birth), post codes, addresses, hashing of unique IDs (accounts, phone numbers, mac addresses, ...), ...

In all cases the store seems to need to know type information in advance, explicitly or implicitly. So potentially these could be:

aspects of one big timeseries API, where some kind of value schema is provided up-front
or several distinct sub-types of timeseries API, where the appropriate one is used, implicitly defining schema constraints (which makes it harder to mix and match them, e.g. within a single compound value)

So perhaps the first approach would be better in principle.


Flex Object CSV storage doesn't work (Grav\Framework\File\Formatter\CsvFormatter)

Using the class Grav\Framework\File\Formatter\CsvFormatter throws an error.

Even after adding the media types on the system.yaml and mime.yaml, since it seems the errors comes from a hard-coded part of the parent class of the SimpleStorage.

The export of CSV however, works.
The code I'm using for storage is straight out of the documentation:
config:
  data:
    storage:
      class: 'Grav\Framework\Flex\Storage\SimpleStorage'
      options:
        folder: user-data://flex-objects/stores.csv
        formatter:
          class: 'Grav\Framework\File\Formatter\CsvFormatter'
          options:
            file_extension: [".csv", ".tsv"]
            delimiter: "," # Delimiter to separate the values
            mime: "text/x-csv" # MIME type for downloading file

Do you think it has to do with trying to save the file with an appended "/" to the end of it? Look at this other issue discussed:
https://github.com/getgrav/grav-plugin-data-manager/issues/43#issuecomment-1147121498

HI, I have the same error. I don't know why a / is appended to temp file name at row 251 of data-manager.php
$csv_file = File::instance($tmp . '/', $tmp_file);

The fix is remove . '/':
$csv_file = File::instance($tmp, $tmp_file);


Fix typo

1. Why is this change necessary?
The class in question has a different name than the docs call it.
2. What does this change do, exactly?
Correct the class name.
3. Describe each step to reproduce the issue or behaviour.
Read the docs.
4. Please link to the relevant issues (if any).
None.
5. Checklist

[ ] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[ ] I have written or adjusted the documentation according to my changes
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

please combine your both PRs https://github.com/shopware/platform/pull/716

@mitelg Done.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/NEXT-8560
Please use this issue to track the state of your pull request.

thanks for your contribution @jkrzefski  :+1: :tada: :blue_heart:


Add JSPM dependency support

Greets,
I like this project! I'm curious how hard it would be to add JSPM (www.jspm.io) support. It's a package manager on the edge of popularity and having increasing uptake. While it manages / installs NPM and Github repos it would be awesome to add to David support for NPM packages. Below is the package.json for one of my repos (Backbone-ES6):
{
  "name": "backbone-es6",
  "version": "0.1.0",
  "homepage": "https://github.com/typhonjs/backbone-es6",
  "description": "A fork of Backbone converting it to ES6.",
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "https://github.com/typhonjs/backbone-es6/"
  },
  "bugs": {
    "url": "https://github.com/typhonjs/backbone-es6/issues"
  },
  "jspm": {
    "main": "src/ModuleRuntime.js",
    "devDependencies": {
      "babel"<EMAIL_ADDRESS>      "babel-runtime"<EMAIL_ADDRESS>      "core-js"<EMAIL_ADDRESS>      "jquery"<EMAIL_ADDRESS>      "underscore"<EMAIL_ADDRESS>    }
  },
  "devDependencies": {
    "bluebird": "^2.10.2",
    "jspm": "^0.16.13",
    "gulp": "^3.9.0",
    "gulp-esdoc": "^0.1.0",
    "gulp-eslint": "^1.0.0"
  }
}

As you can see under the jspm hash is a devDependencies entry. Entries preceded by npm: are NPM packages. There can also be a dependencies entry as well. If detected I'd imagine David could have additional tabs and badges for JSPM dependencies and JSPM devDependencies listed for a project page.
Extra credit would be supporting Github dependency version checking, but that is a bit much of an ask. NPM packages are preferred in JSPM, so it would be fantastic to see that supported.
I can perhaps take a look, but not immediately, so I'm just throwing out this idea as possible future support / feature to be tracked.
Cheers!

+1

+1

+1


fix: gas optimization branch

Description
Add a description of your changes here.
Is this PR related with an open issue?
Related to Issue #
Types of changes

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

Checklist:

[ ] Follows the code style of this project.
[ ] Tests Cover Changes
[ ] Documentation

Funny gif

@aaitor Couple of more things:

Cache _msgSender() before using in multiple places, also try to cache anything that is read from storage, for further multiple usage;
Get memory array from _tokens[_key] and loop over it. Also note, that you are pushing into the same _tokens[_key] array, and depending on how the compiler treats the _tokens[_key].length, you might parse elements that were just added.
Think about the algorithm whether it's possible to reduce the loop size or pre-collect data / use maps?

I pushed a new contract without the time expiration feature (so no track of expiring blocks needed). It comes with a significant reduction on gas cost:

This new contract NFT1155SubscriptionWithoutBlocks is adapted to the functionality you needed and don't include the overhead of the blocks control and storage.


Failed to build reference-lapack-3.8.0

Environment
Windows 10 x64 Pro 17134.48
Visual studio 2015 update3, version 14.0.25431.01
Intel fortran 2018, Package ID: w_comp_lib_2018.0.124
I get the following errors trying to install reference-lapack-3.8.0:
PS: C:\Users\JsuKya\Desktop\vcpkg>
PS>.\vcpkg install reference-lapack:x64-windows
The following packages will be built and installed:
reference-lapack[core]:x64-windows
Starting package 1/1: reference-lapack:x64-windows
Building package reference-lapack[core]:x64-windows...
-- CURRENT_INSTALLED_DIR=C:/Users/JsuKya/Desktop/vcpkg/installed/x64-windows
-- DOWNLOADS=C:/Users/JsuKya/Desktop/vcpkg/downloads
-- CURRENT_PACKAGES_DIR=C:/Users/JsuKya/Desktop/vcpkg/packages/reference-lapack_x64-windows
-- CURRENT_BUILDTREES_DIR=C:/Users/JsuKya/Desktop/vcpkg/buildtrees/reference-lapack
-- CURRENT_PORT_DIR=C:/Users/JsuKya/Desktop/vcpkg/ports/reference-lapack/.
-- Using cached C:/Users/JsuKya/Desktop/vcpkg/downloads/Reference-LAPACK-lapack-v3.8.0.tar.gz
-- Testing integrity of cached file...
-- Testing integrity of cached file... OK
-- Extracting done
-- Applying patch C:/Users/JsuKya/Desktop/vcpkg/ports/reference-lapack/fix-include-order.patch
-- Applying patch failed. This is expected if this patch was previously applied.
-- Applying patch C:/Users/JsuKya/Desktop/vcpkg/ports/reference-lapack/fix-include-order.patch done
-- Applying patch C:/Users/JsuKya/Desktop/vcpkg/ports/reference-lapack/fix-try-compile-fortran-flags.patch
-- Applying patch failed. This is expected if this patch was previously applied.
-- Applying patch C:/Users/JsuKya/Desktop/vcpkg/ports/reference-lapack/fix-try-compile-fortran-flags.patch done
-- Applying patch C:/Users/JsuKya/Desktop/vcpkg/ports/reference-lapack/fix-unresolved-symbol.patch
-- Applying patch failed. This is expected if this patch was previously applied.
-- Applying patch C:/Users/JsuKya/Desktop/vcpkg/ports/reference-lapack/fix-unresolved-symbol.patch done
-- Using cached C:/Users/JsuKya/Desktop/vcpkg/downloads/ninja-1.8.2.g972a7.kitware.dyndep-1_i686-pc-windows-msvc.zip
-- Testing integrity of cached file...
-- Testing integrity of cached file... OK
-- Using cached C:/Users/JsuKya/Desktop/vcpkg/downloads/ninja-1.8.2.g972a7.kitware.dyndep-1_i686-pc-windows-msvc.zip
-- Testing integrity of cached file...
-- Testing integrity of cached file... OK
-- Configuring x64-windows
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:56 (message):
Command failed: ninja;-v
Working Directory: C:/Users/JsuKya/Desktop/vcpkg/buildtrees/reference-lapack/x64-windows-rel/vcpkg-parallel-configure
See logs for more information:
Call Stack (most recent call first):
scripts/cmake/vcpkg_configure_cmake.cmake:239 (vcpkg_execute_required_process)
ports/reference-lapack/portfile.cmake:23 (vcpkg_configure_cmake)
scripts/ports.cmake:72 (include)
Error: Building package reference-lapack:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: reference-lapack:x64-windows
Vcpkg version: 0.0.108-2018-04-17-977e5315f21d920058932f17125d8470f4fb9ea3
The build.ninja file:
rule CreateProcess
command = $process
build ../CMakeCache.txt: CreateProcess
process = cmd /c "cd .. && "D:/Program Files/CMake/bin/cmake.exe" "C:/Users/JsuKya/Desktop/vcpkg/buildtrees/reference-lapack/src/lapack-3.8.0" "-DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=ON" "-DBUILD_TESTING=OFF" "-DCBLAS=ON" "-DLAPACKE=ON" "-DCMAKE_MAKE_PROGRAM=NINJA-NOTFOUND" "-DBUILD_SHARED_LIBS=ON" "-DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=C:/Users/JsuKya/Desktop/vcpkg/scripts/toolchains/windows.cmake" "-DVCPKG_TARGET_TRIPLET=x64-windows" "-DVCPKG_PLATFORM_TOOLSET=v140" "-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON" "-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON" "-DCMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY=ON" "-DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP=TRUE" "-DCMAKE_VERBOSE_MAKEFILE=ON" "-DVCPKG_APPLOCAL_DEPS=OFF" "-DCMAKE_TOOLCHAIN_FILE=C:/Users/JsuKya/Desktop/vcpkg/scripts/buildsystems/vcpkg.cmake" "-DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=ON" "-DVCPKG_CXX_FLAGS=" "-DVCPKG_CXX_FLAGS_RELEASE=" "-DVCPKG_CXX_FLAGS_DEBUG=" "-DVCPKG_C_FLAGS=" "-DVCPKG_C_FLAGS_RELEASE=" "-DVCPKG_C_FLAGS_DEBUG=" "-DVCPKG_CRT_LINKAGE=dynamic" "-DVCPKG_LINKER_FLAGS=" "-DCMAKE_INSTALL_LIBDIR:STRING=lib" "-DCMAKE_INSTALL_BINDIR:STRING=bin" "-DVCPKG_FORTRAN_COMPILER=Intel" "-DVCPKG_FORTRAN_ENABLED=ON" "-G" "Ninja" "-DCMAKE_BUILD_TYPE=Release" "-DCMAKE_INSTALL_PREFIX=C:/Users/JsuKya/Desktop/vcpkg/packages/reference-lapack_x64-windows""
build ../../x64-windows-dbg/CMakeCache.txt: CreateProcess
process = cmd /c "cd ../../x64-windows-dbg && "D:/Program Files/CMake/bin/cmake.exe" "C:/Users/JsuKya/Desktop/vcpkg/buildtrees/reference-lapack/src/lapack-3.8.0" "-DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=ON" "-DBUILD_TESTING=OFF" "-DCBLAS=ON" "-DLAPACKE=ON" "-DCMAKE_MAKE_PROGRAM=NINJA-NOTFOUND" "-DBUILD_SHARED_LIBS=ON" "-DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=C:/Users/JsuKya/Desktop/vcpkg/scripts/toolchains/windows.cmake" "-DVCPKG_TARGET_TRIPLET=x64-windows" "-DVCPKG_PLATFORM_TOOLSET=v140" "-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON" "-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON" "-DCMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY=ON" "-DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP=TRUE" "-DCMAKE_VERBOSE_MAKEFILE=ON" "-DVCPKG_APPLOCAL_DEPS=OFF" "-DCMAKE_TOOLCHAIN_FILE=C:/Users/JsuKya/Desktop/vcpkg/scripts/buildsystems/vcpkg.cmake" "-DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=ON" "-DVCPKG_CXX_FLAGS=" "-DVCPKG_CXX_FLAGS_RELEASE=" "-DVCPKG_CXX_FLAGS_DEBUG=" "-DVCPKG_C_FLAGS=" "-DVCPKG_C_FLAGS_RELEASE=" "-DVCPKG_C_FLAGS_DEBUG=" "-DVCPKG_CRT_LINKAGE=dynamic" "-DVCPKG_LINKER_FLAGS=" "-DCMAKE_INSTALL_LIBDIR:STRING=lib" "-DCMAKE_INSTALL_BINDIR:STRING=bin" "-DVCPKG_FORTRAN_COMPILER=Intel" "-DVCPKG_FORTRAN_ENABLED=ON" "-G" "Ninja" "-DCMAKE_BUILD_TYPE=Debug" "-DCMAKE_INSTALL_PREFIX=C:/Users/JsuKya/Desktop/vcpkg/packages/reference-lapack_x64-windows/debug""

"-DCMAKE_MAKE_PROGRAM=NINJA-NOTFOUND"

@Voskrese But I have ninja in the ".\vcpkg\downloads\tools\ninja" path.
w_comp_lib_2018.0.124 is the detailed version of intel fortran.

In the utility on the githab from Microsoft there is no support for Fortran

We can’t reopen this issue until a PR is opened, unfortunately, consider making a pull request!


[4005], [4113] TraineeSummaryView for funding epic

Context
Trello ticket: https://trello.com/c/FprDewjh/4005-l-traineepaymentsummaryview
This PR is for the view object to support the funding epic. It contains the majority of the view logic for the bursaries and scholarships view (as named in the prototype: https://register-prototype.herokuapp.com/funding/bursaries-scholarships)
There is also an equivalent view for lead schools in the prototype: https://register-prototype.herokuapp.com/funding/grants
This PR should expose the data we need to it can be easily rendered in the view HTML.
Note: We've also included this migration ticket in this PR to change amount field on TraineeSummaryRowAmount to amount_in_pence for clarity.
Changes proposed in this pull request

Add three new factories: trainee_summary, trainee_summary_row and trainee_summary_row_amount
Add boolean method to the TraineeSummaryRowAmount model to make it easier to return tiered bursaries tiered_bursary? vs 'normal' bursaries untiered_bursary?
Set up logic in the TraineeSummaryView which contains classes PaymentSummary and PaymentSummaryRow to make rendering the summary cleaner on the front end
Add public methods bursary_breakdown_rows, scholarship_breakdown_rows, tiered_bursary_breakdown_rows and grant_breakdown_rows to render those tables as needed on the UI
Add migration to change amount field on funding_trainee_summary_row_amounts to amount_in_pence

Guidance to review

all the usual! Nothing special for this PR
please make sure the naming of things makes sense - I found this quite challenging
test you can follow the test set up and it makes sense
check out PR and run migration, make sure all looks ok

Important business

[ ] Does this PR introduce any PII fields that need to be overwritten or deleted in db/scripts/sanitise.sql?
[ ] Does this PR change the database schema? If so, have you updated the config/analytics.yml file and considered whether you need to send 'import_entity' events?

NB: Please notify the #twd_data_insights team and ask for a review if new fields are being added to analytics.yml

 [L] TraineePaymentSummaryView

 Change column name amount -> amount_in_pence on Funding::TraineeSummaryRowAmount


fix: fix bad magic link url

:tada: This PR is included in version 1.69.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Demo App

Hey @timrogers I am making a demo Rails app with Restforce.  Perhaps I thought it will be a good resource for people who are trying to use the gem.  Sometimes code is better than README files.  Here is the repo: https://github.com/antwonlee/restforce_demo_app  I just started working on it whenever I got some free time.  I will create a pull request adding it to README when its done.
It will have basic CRUD functionalities using Restforce to interact with Salesforce data (Accounts, Contacts, Opportunities, Leads).  It has a dev Salesforce instance too where people can see the set up there too.
I thought it would be a good idea to write a short instruction on Oauth process (how to get refresh_tokens, etc) as well so people are not drowning in Salesforce documentations.
Let me know what you think.

Seems like a very useful project. I would have used it when I began using Restforce if it had existed.

Awesome, I think there are few demo apps out there already—but I think I will document better and have basic CRUD functions for Accounts, Contacts, Opportunities, and Leads.  :sunglasses:

💯


[Polkadot Wiki Migration] Node Endpoints Page

This page is from the Polkadot Wiki, and will be heavily edited, updated, and appropriated as needed.

Page referenced: https://wiki.polkadot.network/docs/maintain-endpoints

@erin this is ready for you to review. I did a little reformat to make the endpoints copy paste friendly as well as some formatting and grammar stuff.

@dawnkelly09 please resolve merge conflicts too


chore: Comment super user cypress test

Description
Temporarily comment out super user cypress test
Type of change

Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions, so we can reproduce.
Please also list any relevant details for your test configuration.

Test A
Test B

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

/ok-to-test sha=8fb8e86


First draft of section on Tracy

@dendibakh I haven't built the book yet to check the layout. Just wanted to make sure you were happy with the content first :) Let me know if it needs more details.

Tracy is used for many applications other than making games. Examples include software for cloud streaming, medical microscopy, CAD, military simulation, and so on. Well-known companies outside the gaming industry that use Tracy include NVIDIA, Adobe, Amazon, Mozilla, TomTom, Netflix, Boston Dynamics, and CERN.
I do not agree with the statement that Tracy is specialized and VTune is for general use or a "go-to" solution. This seems to me to be heavily biased by what you are already familiar with. I see VTune as a highly specialized profiler for the following reasons:

You would use it to do deep analysis of microarchitectural performance counters that are otherwise unavailable in other profilers.
If you don't have an Intel CPU, you only get access to OS-level profiling features. Nothing provided by the CPU can be used.

In terms of sampling profiling, Tracy is both worse (because you can't attach to or launch an external process, or because the sampling is hard to find due to UI evolution) and better (for many reasons, for instance, see https://youtu.be/_hU7vw00MZ4?t=699 for a direct comparison to VTune) than the competition.
The main difference is that Tracy is also an instrumentation-based profiler. The main thing about working with this type of data, as opposed to sampling, is that you can clearly see when your otherwise fast function is occasionally slow. You can then drill down into what is happening in those rare cases to identify the cause.

Ok, maybe I'm wrong and Tracy is a "go-to" tool for profiling. Don't want to debate as I haven't seen the data on what people usually use.
This is a book about tuning SW for modern CPUs, so at the center is CPU performance, not system performance. We need insights into CPU microarchitecture.
But let me ask you @wolfpld, do you position Tracy as a competitor and a superior product to Vtune? This is an honest question, I know Vtune has flaws and in general, I'm a big proponent of open-source software. Don't get me wrong, I'm just genuinely trying to understand this. And I wish only the best for Tracy.
BTW, on AMD systems you would use UProf, not Vtune, on Apple platforms you would use Instruments. All those products are not perfect, but they have a specific purpose.

This is a book about tuning SW for modern CPUs, so at the center is CPU performance, not system performance. We need insights into CPU microarchitecture.

You cannot look at the performance of your application without taking into account everything else that is going on in the system. See https://youtu.be/uJkrFgriuOo?t=72

But let me ask you @wolfpld, do you position Tracy as a competitor and a superior product to Vtune?

I had no need to use VTune for a long time, because to me Tracy is superior. I don't follow how they develop the product, so it's hard for me to say anything about it. It certainly has its uses, and if you want to take a deep dive into various specialized perf counters, VTune is the only way to go.

BTW, on AMD systems you would use UProf

I could not use uProf at all. Any profiling session longer than a few seconds would lock the UI.

@theWatchmen, should we rename this section as something like "Specialized profilers"?

I was thinking something like "Manual Instrumentation Profilers" or simply "Instrumentation Profilers" might be a better description.

@theWatchmen, should we rename this section as something like "Specialized profilers"?

I was thinking something like "Manual Instrumentation Profilers" or simply "Instrumentation Profilers" might be a better description.

Just want to make sure I understand it correctly: zone statistics (call counts, time, histogram) are exact because Tracy traces EVERY zone entry/exit, but system-level data and source-code-level data are sampled.
If we use the title "Instrumentation profilers", will it confuse people into thinking that Tracy instruments all the code (recursively) inside a zone? While it's just a marker API, that is recognized by Tracy.

Thanks Marco, I will review your updates in a couple of days.
BTW, I plan a new section for marker APIs (in progress), which showcases libpfm, which is not as fancy as Tracy, it's a wrapper around Linux perf_events. https://github.com/dendibakh/perf-book/pull/20
Since the concept of marker APIs is already covered, maybe we should position Tracy as a specialized/hybrid profiler and focus on its features for game developers for example?

Since the concept of marker APIs is already covered, maybe we should position Tracy as a specialized/hybrid profiler and focus on its features for game developers for example?

Sure, that sounds good.

@theWatchmen, I made a few edits, mostly cosmetic. I also left [TODO] comments in the text, please address.

@theWatchmen , are you waiting for my review? I thought you were still working on it. :)

Hey Denis, the last commit addresses your comments about artificially adding a slow zone and show that in the chapter. Sorry, the commit message doesn't make that clear. I don't have further changes for now :)

Hey Denis, apologies for the delay in getting back to you! I should have addressed all the latest comment and I have updated the images :) Let me know if you have any further notes.

Cool! Thanks Marco, it looks great.
Leave it to me. I will make some cosmetic changes and show you the final version for review.
One question: on "Figure 50: Tracy frame time view", which bar corresponds to frame 101? Maybe draw an arrow...
Also, the timeline on that image looks confusing to me...
What do those numbers mean? :)

I've made some changes. @theWatchmen, please review. The rendered PDF book is here:
https://github.com/dendibakh/perf-book/actions/runs/5557247288?pr=19
P.S. Sorry for the forced push. I rebased on top of the current main branch.

One question: on "Figure 50: Tracy frame time view", which bar corresponds to frame 101? Maybe draw an arrow...
It's for the last bar in the graph. I have added a green rectangle to highlight it.

Also, the timeline on that image looks confusing to me... What do those numbers mean? :)
Those numbers are for the timeline below. I'll remove it.

P.S. Marco, can you please provide details of the machine you used? CPU, OS, compiler.
Done.

I read the section on the PDF version, looks good to me :)

I read the section on the PDF version, looks good to me :)

Awesome! Thanks, merging it...


Typo?

https://github.com/Auto-Mech/autochem/blob/87f50adc09c3f1170459c629697aadd74154c769/automol/cart/mat.py#L26
Is this a typo? It looks like you are taking the cross product of a vector with a vector of zeros., it should probably be:
mat[1] = numpy.cross(mat[2], mat[0])

Well it looks like y'all are working in the dev branch.


Mobile support

The plugin works great in Obsidian Windows version but although it installs ok but no functionality is working in Obsidian Android version. I really like to see it working on mobile as well. Thanks again.

Sorry to hear that it does not work, but on my site everything is working. What exactly happens if you open a link?

I just found an error on my side which caused the link not opening on mobile. It's working now.
So the only thing not working is getting the link to the current note heading/block copied using "Copy Advanced URI" in the note menu or using "Advanced Obsidian URI: copy URI for file" in Command Palette. When I trigger either of these two action, nothing gets copied to the clipboard.

Oh you are right. Will take a look.


Current maintainer?

What's the best way for issues and PRs to get dealt with? If ExtraHop's not maintaining this, maybe it could be transferred to https://github.com/metalsmith ?

@ashishsc I saw that you were the latest active member. Could you chip in on this? Holding back on creating a PR, since @woodyrew's wasn't looked at.

Hi guys, sorry we missed these pull requests, we really appreciate them! We'll review them in our coming sprint next week.

I replied
On Wed, Aug 17, 2016 at 10:55 AM Nicklas Møller<EMAIL_ADDRESS>wrote:

@ashishsc https://github.com/ashishsc I saw that you were the latest
active member. Could you chip in on this? Holding back on creating a PR,
since @woodyrew https://github.com/woodyrew's wasn't looked at.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ExtraHop/metalsmith-sitemap/issues/21#issuecomment-240492946,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACgRCkHLzTtEQs8L5aVY_gweey205p77ks5qg0r_gaJpZM4JmrkG
.

Thanks @ashishsc

Thank you :)


added CuboidAnnotation dataclass

LGTM fix the lint with an annotation and make everything green (it helps to install the pre-commit as described in the readme)


AUI-2105 HISTORY.md

Just started reviewing :) :octocat: Sent from GH.

I just ran gulp test-coverage and 3 tests failed on my machine.
should create event with default recorder duration
Unexpected error: 'undefined' is not an object (evaluating 'event._event.type')
should create event with dragged duration
Unexpected error: 'undefined' is not an object (evaluating 'event._event.type')
should create event with dragged duration in the past
Unexpected error: 'undefined' is not an object (evaluating 'event._event.type')

Just started reviewing :) :octocat: Sent from GH.

Just started reviewing :) :octocat: Sent from GH.

Pull request submitted to https://github.com/mairatma/alloy-ui/pull/327. :octocat: Sent from GH.


Technical Debt: Run Tests on each PR and Commit

Add a .travis.yml file to run unit tests and linting

Hi Nick!
Thaks a lot! I have just added Travis support.  I can't see how to linting with Travis, could you recomend me some tools for that?
Best regards.

Sure, I generally use eslint for linting purposes due to its support for linting ES6.
Here's a quick start repo I created for angular components but the same concepts should apply:
https://github.com/salte-io/salte-seed
If you want I can submit a PR tonight to implement some of the features in the repository I linked.

Hi Nick!
NP about description.  Yes! I would be great if you submit a PR with this!
Thanks a lot!


Support for plain text and json parts in a multipart-form upload

Support for plain text and json parts in a multipart-form upload
TL;DR:
I needed support for text / json parts in a multipart-form upload, added a single function to do so, and forked Alamofire here: https://github.com/chrisco314/Alamofire/tree/multipart_data_form_support_for_additional_data_types to do so.
Context:
I posted a question to SO here: http://stackoverflow.com/questions/31442411/alamofire-support-for-uploading-multipart-forms-with-text-and-file-parts in my efforts to figure out how to upload textual data in tandem with binary data, but got no response.
Implementation:
In the end, to achieve the compact form of:
form.appendBodyPart(Multipart.plain("patient", text:"\(last.id!)")!)

I needed to add a single override to MultipartFormData.swift:
/**
Creates a body part from the data and appends it to the multipart form data object.

The body part data will be encoded using the following format:

- `Content-Disposition: form-data; name=#{name}` (HTTP Header)
- Encoded file data
- Multipart form boundary

:param: headers The headers to encode into the `multipart-form` part.
:param: data The data to encode into the `multipart-form` part.
*/
public func appendBodyPart(#headers:[String: String], data: NSData) {

    let bodyStream = NSInputStream(data: data)
    let bodyContentLength = UInt64(data.length)
    let bodyPart = BodyPart(headers: headers, bodyStream: bodyStream, bodyContentLength: bodyContentLength)
    self.bodyParts.append(bodyPart)
}

This allowed me to add support for text and json data payloads through the code pasted below. The approach I took was to build up abstracted multipart-data parts through the use of typesafe enums and method chaining:
    class MultipartPlain : MultipartProtocol {

        init?(name:String, text:String) {

            // initialize header
            self.headers = MultipartHeader()
                .contentType(.Plain)
                .contentDisposition(.Name(name))

            // serialize body
            self.body = text.dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)
            if self.body == nil {
                return nil
            }
        }

        /// The headers used to generate a `text/plain` part in a `multipart/form-data` part
        let headers:MultipartHeader

        /// The body used to generate a `text/plain` part in a `multipart/form-data` part
        var body:NSData!
    }

The extension code in its entirety is:
import Alamofire

/**
Extension to the Alamofire MultipartFormData type to support direct
construction of `multipart/form-data` parts
*/
extension MultipartFormData {

    func appendBodyPart(part:MultipartProtocol) {

        let headers = part.headers
        let bodyStream = NSInputStream(data: part.body)
        let bodyContentLength = UInt64(part.body.length)
        appendBodyPart(headers:headers.headers, data:part.body)
    }
}

/**
Protocol that defines the behavior of `multipart/form-data` parts, allowing
extension to parts of different types, while hiding implementation details
*/
protocol MultipartProtocol {
    /// The headers used to generate a part in a `multipart/form-data` part
    var headers:MultipartHeader { get }

    /// The body used to generate a part in a `multipart/form-data` part
    var body:NSData! { get }
}

/**
Builds legal `multipart/form-data` parts, conforming to MultipartProtocol
*/
class Multipart {

    class func json(name:String, parameters:[String:AnyObject]) -> MultipartProtocol? {
        return MultipartJson(name:name, parameters: parameters) }

    class func plain(name:String, text:String) -> MultipartProtocol? {
        return MultipartPlain(name:name, text:text) }

    /**
    Constructs an `application/json` part in a `multipart/form-data` body
    */
    class MultipartJson : MultipartProtocol {

        init?(name:String, parameters:[String:AnyObject]) {

            // initialize header
            self.headers = MultipartHeader()
                .contentType(.JSON)
                .contentDisposition(.Name(name))

            // serialize body
            let options = NSJSONWritingOptions.allZeros
            var error:NSError?
            self.body = NSJSONSerialization.dataWithJSONObject(parameters, options: options, error: &error)

            if self.body == nil {
                return nil
            }
        }

        /// The headers used to generate an `application/json` part in a `multipart/form-data` part
        let headers:MultipartHeader

        /// The body used to generate an `application/json` part in a `multipart/form-data` part
        var body:NSData!
    }

    /**
    Constructs a `text/plain` part in a `multipart/form-data` body
    */
    class MultipartPlain : MultipartProtocol {

        init?(name:String, text:String) {

            // initialize header
            self.headers = MultipartHeader()
                .contentType(.Plain)
                .contentDisposition(.Name(name))

            // serialize body
            self.body = text.dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)
            if self.body == nil {
                return nil
            }
        }

        /// The headers used to generate a `text/plain` part in a `multipart/form-data` part
        let headers:MultipartHeader

        /// The body used to generate a `text/plain` part in a `multipart/form-data` part
        var body:NSData!
    }
}

/**
Defines legal `MIME` type values for the `Content-Type` header of `multipart/form-data`
*/
enum Mime : String {
    case MultipartMixed = "multipart/mixed"
    case JSON = "application/json"
    case Plain = "text/plain"
}

/**
Defines legal Disposition values for the `Content-Disposition` header of `multipart/form-data`
*/
enum Disposition {
    case FormData
    case Name(String)
    case FileName(String)

    var encoded:String {
        switch self {

        case FormData:
            return "form-data"

        case Name(let name):
            return "name=\"\(name)\""

        case FileName(let name):
            return "filename=\"\(name)\""
        }
    }
}

/**
Constructs `multipart/form-data` headers via the method chaining pattern.
*/
class MultipartHeader {

    enum Key : String {
        case ContentType = "Content-Type"
        case ContentDisposition = "Content-Disposition"
    }

    /**
    Defines the `Content-Type` header and returns the instance of MultipartHeader
    upon which this call is made

    :param: mimeType  The desired MIME type, as defined by the Mime enumeration

    :returns: The instance of Multipart header upon which this call is made
    */
    func contentType(mimeType:Mime) -> MultipartHeader {
        headers[Key.ContentType.rawValue] = "\(mimeType.rawValue)"
        return self
    }

    /**
    Defines the `Content-Disposition` header with a single disposition value and
    returns the instance of MultipartHeader upon which this call is made

    :param: mimeType  The desired MIME type, as defined by the Disposition enumeration

    :returns: The instance of Multipart header upon which this call is made
    */
    func contentDisposition(disposition:Disposition) -> MultipartHeader {

        headers[Key.ContentDisposition.rawValue] =
            Disposition.FormData.encoded + "; " + disposition.encoded
        return self
    }

    /**
    Defines the Content-Disposition header with multiple disposition value and
    returns the instance of MultipartHeader upon which this call is made

    :param: mimeType  The desired MIME type, as defined by the Disposition enumeration

    :returns: The instance of Multipart header upon which this call is made
    */
    func contentDisposition(values:Disposition...) -> MultipartHeader {

        headers[Key.ContentDisposition.rawValue] = Disposition.FormData.encoded + "; "
            + "; ".join(map(values) { (d:Disposition) in d.encoded})
        return self
    }

    /// The resulting set of `multipart/form-data` headers
    var headers:[String:String] = [Key.ContentDisposition.rawValue: Disposition.FormData.encoded]
}

extension MultipartHeader : Printable {
    var description:String {
        return "Headers: \n\t"
            + "\n\t".join(map(self.headers.keys) { key in "\(key): \(self.headers[key]!)" })
    }
}

Summary:
With the modest addition of the single function override above, I was able to add support for additional data types.  I hope that you can merge this change with your repository.  I also think that the extensions above for supporting additional types are clean, type-safe, and error resilient. I hope that it could help provide a path to extended type support.

Hi @chrisco314, first off, my apologies for not replying to your Stack Overflow question. I've been focusing mainly on the 1.3.0 release and haven't been able to spend as much time on Stack Overflow as I would like.
With that said, I'm fairly certain you should be able to do this already without any changes to Alamofire. Would it be possible for you to test a theory for me? Could you try to upload some JSON data to your server using the following approach?
multipartFormData.appendBodyPart(
    fileData: data,
    name: "name",
    fileName: "filename.json",
    mimeType: "application/json"
)

I'm fairly certain this method should do "exactly" what it is you are looking for. I'm also curious if your variation is the exact same call minus the filename argument in the Content-Disposition header. We've had a similar issue opened in #569 but we never heard back from @top2tech.
If you could verify whether that method works for your case that would be great. Additionally, it would also be useful to know if you are finding that the filename argument is optional. I'm having a difficult time determining from the RFC specs whether the filename is optional or not.

Short answer: No, I needed text/plain in the end
In more detail:
In the end, I needed to send plain text and not JSON (I did not have complete information when I started).  That meant that I had to manually create a "Multipart" object for text/plain, hence the method.  That method though, is as simple as it gets, is orthogonal, and could / would generally be the base two which others defer.
Approach taken
To achieve my final goal, I could have hacked a couple more one-off functions and been done, but the approach I took allowed me a typesafe and modular means of building up Multipart objects, and by chaining the headers - themselves comprised of any combination of values.  For example, I noticed two function overloads for Content-Disposition, but neither worked for me and it didn't seem right to keep writing new combinations.  To that end, I added the variadic overload that would allow the flexibility to add any combination of fields:
    func contentDisposition(values:Disposition...) -> MultipartHeader {

        headers[Key.ContentDisposition.rawValue] = Disposition.FormData.encoded + "; "
            + "; ".join(map(values) { (d:Disposition) in d.encoded})
        return self
    }

Improvements to the Api
While I am on the topic, I think the API for this functionality could be improved.  The multipartFormData callback feels neither necessary nor complete.  looking at the code, it only really just creates a generic MultipartFormData object and passes it back.  This could be done much more easily by having a default parameter on upload that constructed one.  The problem with the current form is that it turns out that calls to appendBodyPart can fail, and there is no way to stop the train at that point, you just get missing data on the server.
I am newer to functional programming, and I appreciate that you have kept your API dogma free, but going further (and cleaner), you could instead offer a failable initializers on MultipartFormData or method chaining that returns an optional self, to arrive at the following (more modular) approach:
Alamofire.upload(
    authorizedRequest(.Attachments, method: .POST,  authToken: authToken),
    multipartFormData: MultipartFormData(
        Multipart.plain("id", value:last.id),
        Multipart.json("someJsonData", details:details),
        Multipart.file(firstFile, name: "file1"),
        Multipart.file(secondFile, name: "file2")),
    encodingCompletion: { encodingResult in
        // ..
    })

or
Alamofire.upload(
    authorizedRequest(.Attachments, method: .POST,  authToken: authToken),
    multipartFormData: MultipartFormData()
        .appendBodyPart(Multipart.plain("id", value:last.id!))
        ?.appendBodyPart(Multipart.json("someJsonData", parameters:parameters))
        ?.appendBodyPart(fileURL: fileToUpload, name: "file1") {
        ?.appendBodyPart(fileURL: someOtherFile, name: "file2") {
    encodingCompletion: { encodingResult in
        // ..
    })

In the first case , you would use a variadic initializer taking optional values, and in the second use method chaining that returns optionals, to produce a final optional value that could then be accepted or rejected by upload depending on whether or not the optional MultipartFormData was valid.  To me, this is simpler, cleaner, as it is easy to construct, and fails immediately and decisively.  Both forms are equivalent, but I find the former to be simpler-looking, and more concise.
The use of optionals could also facilitate the functional / monad style of chaining, though the API would by no means be impacted by this, or carry any baggage to support it - it's just a potential bonus.  (I am by no means an expert in this area, I've just seen it used, and understand optionals to be the foundation for it)

Okay @chrisco314, let's take a step back for a sec.
I need you to help me diagnose the problem you are having before I'm going to consider redesigning the APIs. Could you please answer my original questions? Can you directly pass in your mimeType to the following method and still have it work? If not, could you please walk me through why?
multipartFormData.appendBodyPart(
    fileData: data,
    name: "name",
    fileName: "filename.json",
    mimeType: "application/json"
)

You do have a point, my issue when looking through that code initially though, was that it suggested a file, assumed a file, and hardcoded filename into the header.  In hindsight, I wish I had tested that, but thought at the time that it would cause problems with the server and felt that needed more control over the headers (for full disclosure, I have worked a lot with networking API's, but I was testing testing and inspecting headers with curl and nc -L).  To the point though, note that the function you suggest defers to this:
private func contentHeaders(#name: String, fileName: String, mimeType: String) -> [String: String] {
    return [
        "Content-Disposition": "form-data; name=\"\(name)\"; filename=\"\(fileName)\"",
        "Content-Type": "\(mimeType)"
    ]
}

To be fair, in my case, after I realized (in at least one case) that the server would not take json, I could have used this function that is implicitly hardcoded to assume text/plain, by virtue of it not taking a MIME type (which could then have just as easily taken data in String form):
public func appendBodyPart(#data: NSData, name: String) {
    let headers = contentHeaders(name: name)
    let bodyStream = NSInputStream(data: data)
    let bodyContentLength = UInt64(data.length)
    let bodyPart = BodyPart(headers: headers, bodyStream: bodyStream, bodyContentLength: bodyContentLength)

    self.bodyParts.append(bodyPart)
}

I think at that point, I already had my code written, and felt that I would need JSON later on.
I do think though that my original point remains with the proposed function though.  Since it assumes nothing at all - it can serve all needs.  Far from being a special case, it would be the absolute most general case, the function through which all related code-paths could flow.
In summary though, my the key point here is the function that you suggest is assuming too much, and in doing so, is less flexible and extensible, and can consequently the API can be more difficult and less intuitive to apply to a wider range of cases where servers need particular header attributes.  Instead of trying to anticipate future needs, you could instead make it simpler, more general, and adopt any good adaptations that come out of it as a bonus.
As a bit of an side, I still feel that my other points remain, that the means of configuring the MultipartFormData could be simpler while again being more general, and consequently more flexible. Frankly speaking, when using the multipart-form API, I was left with the impression that it deviated from the modular-construction form of the rest of the API - .GET / .POST etc. calls, that allowed you to build your own request object, and configure your headers.  To me, it was different enough that it felt like two libraries had been merged - it seemed to break the existing conventions.  I do think the approach of failable initializers presents a simpler, more intuitive alternative, and would not be hard to implement.
I do appreciate your hard work though; I don't mean this to sound like a criticism.  It can't be easy working through all the cases.
Thanks

Okay, so if I boil down your extremely verbose set of multiple answers, you are able to do what you need with either of the following methods:

appendBodyPart(fileData:name:fileName:mimeType:)

If you provide a dummy fileName value

appendBodyPart(data:name:)

If you override it and add a mimeType argument that would append a Content-Type header

As an initial takeaway, I'd say the appendBodyPart(data:name:) method most likely needs an optional mimeType parameter which will add the Content-Type header to the body part if it is passed in. That would certainly solve your main issue.

As for your proposed API changes, I really appreciate your feedback!
When designing the current implementation, the one thing that didn't feel exactly right was the fact that you can easily bury the errors that occur when appending a new body part if you aren't careful. Only some of the methods can actually fail, but if they fail without you handling them, your body part won't make it up to the server.
As for providing the closure in the upload method, that is simply to be able to create the data inline with the rest of the request. I'll consider adding another alternative API where you pass the MultipartFormData object in directly rather building it on the fly with a provided closure.
Overall, you have piqued my interest here so I will probably be making some changes to address some if not all of these issues. Once I push up a PR I'd appreciate some more feedback if you have time.
Cheers 🍻

Right, pretty close.  Apologies for the verbosity, I was trying to be unambiguous without being curt, here is the digest version:
On the topic of appendBodyPart (and for all code in general), don't assume more than you have to:

appendBodyPart(fileData:name:fileName:mimeType:) is unnecessarily specific in that it assumes a file
appendBodyPart(data:name:) is unnecessarily restrictive, it assumes a plain text payload
appendBodyPart(data:name:type:) would be unnecessarily restrictive as it would restrict other headers like content-transfer-encoding
don't try to anticipate all options, present and future, allow at least one "designated initializer" that assumes nothing and allows the caller to specify everything they need, make this the base call through which all others flow
and nitpicky, but general convention is that key comes before value, header comes before body, so the order of the parameters data, name seems unnatural

On the topic of upload:

don't add a callback unless it adds value (does asynchronous processing), in this case, it merely adds complexity and decreases flexibility
there are no obvious ways to do error handling when adding parts to MultipartFormData, the closure is unnecessary and prevents error handling, forcing an upload even when an error is known.  You can detect an error, but the train has left the station and you cannot stop it since the callback has no return value
keep things as simple as possible, user constructed instance type parameters are simpler than closures, upload overrides could provide pre-configured MultipartFormData instances
failable initializers offer a graceful way of chaining operations, while catching results, and without any baggage, allow more modern programming techniques - see Monads and "railway oriented programming"

And having since worked with download:

it takes unnecessary effort to get the final download name, see multiple posts (not of my own) on Stackoverflow, here is one example: http://stackoverflow.com/questions/26307170/alamofire-download-method-where-is-the-file-and-did-it-save-successfully

Cheers

Okay @chrisco314, I just pushed up PR #596 which addresses all the issues presented in this ticket. Please check it out and redirect all further comments to #596.
Proposals Implemented
I took about half of your suggestions in this ticket and implemented a variation of them.

Added an appendBodyPart(data:name:mimeType:) method which solves your root issue.
Added a base method that everything calls through that is completely wide open allowing for headers like Content-Transfer-Encoding.
Now internally tracking a body part error that is bubbled up immediately during encoding. This eliminates the possibility of uploading something to the server that is missing a body part.

Proposals Not Implemented
Some of the suggestions that I did not incorporate were:

Reordering the parameter names

The parameter names begin with either data, fileURL or stream to make it easier to work with autocomplete to narrow down your choices. Starting with name makes it difficult to pick out the one you are looking for. While I completely understand your logic, I disagree that this would be the best course of action.

Variadic Initializer and/or Chaining Optionals

Both of these approaches make the APIs clunky and more difficult to use IMO.

Multiple Enumerations and Chained Headers

This approach presents way too many ways for users to make mistakes. It also does not provide any flexibility since you cannot customize the behavior by extending enumeration cases.

Summary
Alamofire is intended to provide very clean, robust APIs to make networking easy, yet be flexible enough to allow users to customize any part of the networking stack, thus supporting a range of experience from novice to expert. Therefore, some of your suggestions aligned very well with our overalls goals which is exactly why they were implemented.
Thanks again for all your efforts here...Alamofire is certainly better for it!
Cheers 🍻

Hi
How to support multipart/mixed as content type?
Thanks

Hi @pavm035, multipart/mixed uploads are not supported at this time.


Cancel editing?

I'm using Sae, and I have a "Cancel" button that when pressed, I would like to collapse the Sae UI.
Thanks!

Fixed by toggling editable state!


npm ERR with iojs v1.6.2

npm ERR! Darwin 14.3.0
npm ERR! argv "/Users/zhulongzheng/.nvm/versions/io.js/v1.6.2/bin/iojs" "/Users/zhulongzheng/.nvm/versions/io.js/v1.6.2/bin/npm" "i"
npm ERR! node v1.6.2
npm ERR! npm  v2.7.1
npm ERR! code ELIFECYCLE

npm ERR<EMAIL_ADDRESS>install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.
npm ERR! This is most likely a problem with the contextify package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls contextify
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/zhulongzheng/code/test/learn-react/npm-debug.log

Hi @zhulongzheng! This is an error in contextify not in this repo. I'm not in the development of that package because this I close the issue.


User/sachinta/fix break away process creation attributes

Cherry-picking https://github.com/microsoft/WindowsAppSDK/commit/30a8d11711e626e8d044df81c0a2a8a8a3966cb2 from release/1.1-stable to main.

/azp run


[MNT] Implemented error boundary

Closes #95

NOTE: If this pull request is to be released, the release label must be applied once the review process is done to avoid the local and remote from going out of sync as a consequence of the bump version workflow run

Checklist
This section is for the PR reviewer

[x] PR has an interpretable title with a prefix ([ENH], [FIX], [REF], [TST], [CI], [MNT], [INF], [MODEL], [DOC]) (see our Contributing Guidelines for more info)
[x] PR has a label for the release changelog or skip-release (to be applied by maintainers only)
[x] PR links to GitHub issue with mention Closes #XXXX
[x] Tests pass
[x] Checks pass
[ ] If the PR changes the participant-level and/or the dataset-level result file, the query-tool-results files in the  neurobagel_examples repo have been regenerated

For new features:

[ ] Tests have been added

For bug fixes:

[ ] There is at least one test that would fail under the original bug conditions.

Summary by Sourcery
Implement an ErrorBoundary component to enhance error handling in the application by wrapping the main component, ensuring that errors are caught and displayed with a user-friendly message.
New Features:

Introduce an ErrorBoundary component to handle errors gracefully in the application.

Enhancements:

Wrap the main application component with the ErrorBoundary to catch and display errors.

Oh, @rmanaem I think we should release off of this PR so we can finally get the synced results files into the deployed app: #389


Adding all information of conic sections

I would like to add all the important information about conic sections(parabola, ellipse, hyperbola) .
As I'm a beginner this issue may take some time. So I would request you to kindly give me 5-6 days for completing the PR.
Please assign this issue to me.

Feel free to ask your doubts, if any
Deadline 26 March,2021 (11:59 PM IST)


Generalize ising_network to allow adding external field

Codecov Report

Merging #55 (272a72b) into main (622a575) will decrease coverage by 0.77%.
The diff coverage is 87.09%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main      #55      +/-   ##
==========================================
- Coverage   77.93%   77.16%   -0.77%
==========================================
  Files          55       55
  Lines        2900     2908       +8
==========================================
- Hits         2260     2244      -16
- Misses        640      664      +24

Impacted Files
Coverage Δ

src/specialitensornetworks.jl
80.39% <87.09%> (+3.64%)
:arrow_up:

src/beliefpropagation.jl
75.44% <0.00%> (-14.38%)
:arrow_down:

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


Revert label check

remove the label check temp before the labels confirmed

@grantomation has +1 on #3859


Unblock ihaskell and ipython-kernel

I see that there is now a revision for uuid.
Checklist:

[x] Meaningful commit message - please not Update build-constraints.yml

[x] At least 30 minutes have passed since Hackage upload

[ ] On your own machine, in a new directory, you have successfully run the following set of commands (replace $package with the name of the package that is submitted, $version is the version of the package you want to get into Stackage):
stack unpack $package-$version
cd $package-$version
stack init --resolver nightly
stack build --resolver nightly --haddock --test --bench --no-run-benchmarks

Merged, thanks

Thank you!


Item List does not immediately scrollto selection.

Operating system or device - Godot version:
Windows  - 2.1
Issue description (what happened, and what was expected):
I created an ItemList with a large number of elements.  I select one and press up-down to scroll out of the display bounds.  The scrollbar moves but the selection remains outside of the box.  After waiting one second, the list scrolls back to bring the selection into visibility.
** Steps to reproduce **
Run attached project.
Select item in list.
Press up/down arrows until selection is out of display bounds of ItemList.
Observe scroll bar moves immediately but display does not.
Observe that after a brief delay, the box display moves to bring the selected item in focus.
Link to minimal example project (optional but very welcome):
https://www.dropbox.com/s/mz1gb2k0oyq0cxf/Godot 2.1 ItemListScrolling bug demo.zip?dl=0

I can't seem to reproduce the "after brief delay" step.  However another issue I noticed is:
Reversing direction scrolls to bring the previously selected item in focus.
That is to say, in the example project:
12 is the last visible item in ItemList.
12 is selected.
Press down arrow.
13 is selected.
Scrollbar was updated and moves down.
13 is not visible. Unexpected behavior
Visible area did not change. Unexpected behavior
Press up arrow.
12 is selected.
13 is now visible. Unexpected behavior
Scrollbar was not updated.
In my testing, changing when ensure_current_is_visible() is called does not seem to fix the issue.  I will investigate ensure_current_is_visible() itself.

Fixed by #6513.


Test case mockup for parsing anc data.

Description
Parses ANC data and outputs fhir resources.

Included in feature-testcase-generator branch


We need to test that we can handle multiple multiConnects with multiple TCP sessions per multiConnect at the native level

In theory we have node tests that are to be written that will open up multi simultaneous MCSessions with multiple devices and then open multiple TCP streams with each device, send data and confirm it was received (usually via an echo test). But we really need to test this at the native level first so we can shake out any issue in an easier to debug environment.

Started implementation of echo test. I use AppContext's interface to establish MCPF connection.
I'm finishing. Now I'm finishing multipeer connectivity part. As soon as #881 will be merged into vNext it will be possible to use CocoaAsyncSocket for TCP connections management.

blocked on thaliproject/Thali_CordovaPlugin#881


Github Link doesnt work.

Issue Template
Only use this template if you are reporting a bug! Delete this if you are suggesting a feature.
Expected behaviour?
I put my github link in the github text area, and my short description in its area and the long description on its textarea. So basically the github link should be in its button and the descriptions should stay in their own text area.
Actual behaviour?
It makes the github link go into the short description and the short description into the full description. And then the full description is gone.
Steps to reproduce?
Put in a github link, a short description, and a full description into ur bot and it will happen.
Any additional information?

seems to be working might be only on ur side ¯_(ツ)_/¯

It has since been fixed.


Create sound effects for game

running around
bullet fire
bullet miss
bullet hit
explosion1
explosion2
ship sink
win
loss

Done!


Thumb stick sensitivity is way too high when respositioning weapons/scopes

Perhaps this down to peculiarities of my setup but when I'm trying to adjust the scope position in particular as soon as my right thumbstick leaves the deadzone its already moving so fast that it makes getting accuratly aligned scopes really hard and super annoying.
Could you add an INI setting to scale down the speed? Something like:

RepositionAdjustSpeedScale=1.000

I just worked out this actually an issue with Better Scopes VR and is easily fixed!
To anyone who finds this post in the future set:  retMoveInterval  to a smaller value in BetterScopes.ini

I could probably make that clearer.    I really need to up my documentation game lol
sorry I didn't respond quicker with the answer but glad you found it.


255 build missing the output folder option

:)

Fixed in https://github.com/smith-chem-wisc/MetaMorpheus/pull/925


deps: updates wazero to 1.0.0-pre.8

This updates wazero to 1.0.0-pre.8 which notably

Changes the Instantiate signature, which no longer requires
an explicit Runtime instance.

Signed-off-by: Edoardo Vacchi<EMAIL_ADDRESS>

thanks @evacchi for helping maintain waPC!

Updated to pre.9


audio/L24

Hi,
Your app is simply amazing, It's a shame it's not more famous!!
It's not an issue but more a request: Could you add the possibiliy to stream audio/L24 format because many renderers are now capable of this!
It would be nice to have this choice in the GUI!
Another point: is the WASAPI loopback capture based on the resolution of the sound card? It means if I set my output to 24bit/96KHz, the sound capture will be at this rate or do you resample everything to 16bit/44100Hz?
Thanks a lot!

Closing due to repo archival.


errors editing commit messages in git-for-windows

I'm running syntastic, installed via pathogen, via the git-for-windows bash shell.  I have vim configured to be my default editor, and editing code seems to work fine but as soon as I try to git commit anything, I get this error:

Cannot execute shell C:/Program Files/Git/usr/bin/bash
syntastic: error: your shell C:/Program Files/Git/usr/bin/bash can't handle traditional UNIX syntax for redirections

and then several following errors.  It would appear, from looking at the code this error comes from (https://github.com/scrooloose/syntastic/blob/dc516ef19de71409aadd7d104c5f92312940c11b/plugin/syntastic.vim#L60).  Backtracking a little, it turns out that syntastic#util#isRunningWindows() does not recognize the git-for-windows bash environment as being windows.

Your setup is broken, Vim's system() can't use C:/Program Files/Git/usr/bin/bash as a shell.  Fix that, and syntastic will start working.

My system command works just fine - to test this, I ran :call system("echo 123 > 4.s") then exited vim and found the 4.s file had been written with contents 123.
There is definitely something fishy here with it trying to use  C:/Program Files/Git/usr/bin/bash instead of /c/Program Files/Git/usr/bin/bash.  Do you know where it would get this path? Afaik it can't come from my $PATH since that seems to always use the /c/ style.

hm, I take that back.

So it seems my SHELL env variable has the wrong value when vim is invoked from git commit.  I'll work on tracking this down (and any pointers on why this might be would be appreciated), but this doesn't seem like a bug in syntastic but rather in my setup.

it looks like set shell=/usr/bin/bash fixes this for me.  Dunno why git is messing up the SHELL variable though.

For other people experiencing the same problem: I use the following snippet at the top of my vimrc to solve it:
if !has("gui_running")
    set shell=/usr/bin/bash
endif

This removes the error from the OP for me. However, after doing this, :echo $SHELL still says C:/Program Files/Git/usr/bin/bash when doing a git commit.


refactor(metarepos): remove redundant metric mr.build_commit_results.duration

What this PR does
Remove the redundant metric, which is mr.build_commit_results.duration.

Current dependencies on/for this PR:

main

PR #493

PR #494

PR #503   👈

This comment was auto-generated by Graphite.

Codecov Report
Patch coverage has no change and project coverage change: -0.12 :warning:

Comparison is base (ac82770) 62.28% compared to head (36b044b) 62.16%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@                 Coverage Diff                 @@
##           telemetry_flags     #503      +/-   ##
===================================================
- Coverage            62.28%   62.16%   -0.12%
===================================================
  Files                  133      133
  Lines                18447    18442       -5
===================================================
- Hits                 11489    11465      -24
- Misses                6387     6405      +18
- Partials               571      572       +1

Impacted Files
Coverage Δ

internal/metarepos/raft_metadata_repository.go
76.93% <ø> (-0.02%)
:arrow_down:

... and 7 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

@ijsong started a stack merge that includes this pull request via Graphite.

@ijsong merged this pull request with Graphite.


Gluten 2025 Roadmap

Description
2024 is almost gone. Time to define 2025 features. Here is some from my mind. Feel free to add more or comment
For more information about the achievements in 2024 Roadmap, please check https://github.com/apache/incubator-gluten/issues/4709
Velox backend:

[ ] Spark 4.0 support with minimal JDK 11 support, Deprecate Spark 3.2 and JDK 8
[ ] Switch to Upstream Velox's official release
[ ] Stage level resource management(#4392 )
[ ] Spill enhancement and performance (#3030 )
[ ] Hash table broadcast support in BHJ (https://docs.google.com/document/d/1upEby9aJnBcMKul7HS5agSr1zwFR63Iq4QL1nYxuFvU/edit?usp=sharing)
[ ] Dictionary support in shuffle
[ ] Multile core per task (#7810 )
[ ] Pyspark Support including Python UDF/Arrow UDF
[ ] Other Accelerator such as GPU, FPGA Support
[ ] Result Mismatch issues (#4652 )
[ ] Stability improvement
[ ] Spark Coverage including Operators and Functions
[ ] Full Datalake support
[ ] File Format support (Json)
[ ] Performance improvement: Spill, Sort, HashAgg, HashJoin, ColumnarShuffle, and others
[ ] Gluten Indicator
[ ] Gluten + Flink + Velox POC (experimental)

Community:

[ ] Major Release: 1.4/1.5/1.6/1.7 in Q1/Q2/Q3/Q4 2025
[ ] Minor Release: On Demand
[ ] Apache TLP Submission in Q4 2025

What about supporting Flink framework?

Any pan or discussion about flink?

@zhanglistar @Myracle
It waits for discussion.
Does someone want to open / host a discussion for the topic? cc @apache/gluten-committers

Do we need to do complex data type support and optimization such as row to column optimization for complex data type?

Do we need to do complex data type support and optimization such as row to column optimization for complex data type?

Yes, currently R2C with complex type is too expensive

What about support openEuler OS ?

What about support openEuler OS ?

Can vcpkg=on work on openEuler?


test(third-party): enzyme

What kind of change does this PR introduce?
Test/example for enzyme that serves as a quick check that it is indeed possible to use enzyme with next-page-tester.
This is a very basic example as "enzyme" should not be promoted by any means, but unfortunately a lot of users still use it.

What if we transformed this into an example in plain markdown (we might add an example folder)? A part the extra dev dependencies, I think that documenting enzyme usage as test doesn't feel fully right since we don't actively support it (expect for returning a React element), and if in future enzyme tests turned red, we wouldn't probably take any action.

What if we transformed this into an example in plain markdown (we might add an example folder)? A part the extra dev dependencies, I think that documenting enzyme usage as test doesn't feel fully right since we don't actively support it (expect for returning a React element), and if in future enzyme tests turned red, we wouldn't probably take any action.

This test should be passing as long as we are exporting page from the getPage. We are testing that page element works correctly through other means so it shouldn't be a problem. With this I just wanted to confirm that it indeed works. Fell free to transform it into another shape if you think it makes more sense. I'm just afraid of having examples that we are not testing.

This test should be passing as long as we are exporting page from the getPage. We are testing that page element works correctly through other means so it shouldn't be a problem. With this I just wanted to confirm that it indeed works. Fell free to transform it into another shape if you think it makes more sense. I'm just afraid of having examples that we are not testing.

hat id we added add a test case for returned page in get-page-return tests to ensure page is a React element? That's all we guarantee to Enzyme, after all, right?
Actually only page is missing in get-page-return tests.

hat id we added add a test case for returned page in get-page-return tests to ensure page is a React element? That's all we guarantee to Enzyme, after all, right?
Actually only page is missing in get-page-return tests.

Closed in favour of #97.

Closed in favour of #97.