change to equinix-metal-ccm and bump to 3.0.1

Signed-off-by: Avi Deitcher<EMAIL_ADDRESS>How to categorize this PR?

/area control-plane
/kind enhancement
/priority normal
/platform equinix-metal
What this PR does / why we need it:
Bump packet ccm 2.0.0 to equinix metal 3.0.0. Lots of changes and bugfixes.
Which issue(s) this PR fixes:
Partially fixes #112
Special notes for your reviewer:
2.0.0 -> 3.0.0 is much more than just a version bump.

The GitHub repo has changed from packethost/packet-ccm to equinix/cloud-provider-equinix-metal
The docker hub repo has changed from packethost/packet-ccm to equinix/cloud-provider-equinix-metal
The binary name has changed
The container name has changed
The env vars it consumes has changed

I tried to change more than just the chart manifest and deployment yaml to capture all of the above, but I might have gone too far with it. Discussed on slack with @rfranzke in the hope that he can find my errors.
Release note:

The version of the `cloud-controller-manager` was changed from `packet/2.0.0` to `equinix-metal/3.0.1`.

Thank you @deitch for your contribution. Before I can start building your PR, a member of the organization must set the required label(s) {'reviewed/ok-to-test'}. Once started, you can check the build status in the PR checks section below.

/assign
/reviewed ok-to-test
Shall #113 be closed in favour of this PR?

Shall #113 be closed in favour of this PR?

Yes.

Btw, in #113 I noticed another change that is not in this PR (https://github.com/gardener/gardener-extension-provider-packet/pull/113/files#diff-355cd453331851241bfa83c5df96eaab4237a45e303b17f7d2ce3aef4bef33b1R59-R61). Maybe it's not needed anymore, I just wanted to point it out in case it is.

Good point, and nice catch. It now has the option to use metallb, kube-vip, just do the bgp and annotations without controlling a loadbalancer directly, or none at all, so it does have to be enabled. Thank you!
Fixing right now.

Fixed that issue, thanks @rfranzke
Anything else that I missed, or went too far with?

Forgot to run make generate. Regenerated and pushed out to go through CI again.

@deitch The verify step is failing, I guess you have to run make install-requirements verify to fix it?

I ran make verify, here is the output:
$ make verify
> Check
Executing golangci-lint
Executing go vet
Executing gofmt/goimports
All checks successful
> Check Helm charts
Checking for chart symlink errors
Checking whether all charts can be rendered
Error: YAML parse error on packet-infra/templates/main.tf: error unmarshaling JSON: while decoding JSON: json: cannot unmarshal string into Go value of type releaseutil.SimpleHead

Use --debug flag to render out invalid YAML
make: *** [check] Error 1

That is odd, because I haven't changed anything in that file:
$ git diff master --name-only
CONTRIBUTING.md
charts/gardener-extension-provider-packet/templates/configmap-logging.yaml
charts/images.yaml
charts/internal/seed-controlplane/charts/cloud-provider-equinix-metal/Chart.yaml
charts/internal/seed-controlplane/charts/cloud-provider-equinix-metal/ccm-observability-dashboard.json
charts/internal/seed-controlplane/charts/cloud-provider-equinix-metal/templates/_helpers.tpl
charts/internal/seed-controlplane/charts/cloud-provider-equinix-metal/templates/configmap-observability.yaml
charts/internal/seed-controlplane/charts/cloud-provider-equinix-metal/templates/deployment.yaml
charts/internal/seed-controlplane/charts/cloud-provider-equinix-metal/templates/service.yaml
charts/internal/seed-controlplane/charts/cloud-provider-equinix-metal/templates/vpa.yaml
charts/internal/seed-controlplane/charts/cloud-provider-equinix-metal/values.yaml
charts/internal/shoot-system-components/charts/cloud-provider-equinix-metal/Chart.yaml
charts/internal/shoot-system-components/charts/cloud-provider-equinix-metal/templates/rbac-node-controller.yaml
charts/internal/shoot-system-components/charts/cloud-provider-equinix-metal/values.yaml
example/controller-registration.yaml
pkg/controller/controlplane/valuesprovider_test.go

And the file itself is pretty simple.
Could it be that there are dependencies on PACKET_API_KEY in the file (and elsewhere) that need to be converted to METAL_API_KEY? I am going to change those and see.

Nope, that isn't it. 🤷♂

Please, try with make generate.

Nope @vpnachev ; I had run make generate before, but I tried it again, as you suggested. It didn't change anything, and make verify has the same failure.
I ran it manually with --debug and got this:
/Users/adeitcher/Documents/Development/go/src/github.com/gardener/gardener-extension-provider-packet/vendor/github.com/gardener/gardener/hack/check-charts.sh ./charts
> Check Helm charts
Checking for chart symlink errors
Checking whether all charts can be rendered
install.go:172: [debug] Original chart version: ""
install.go:189: [debug] CHART PATH: /Users/adeitcher/Documents/Development/go/src/github.com/gardener/gardener-extension-provider-packet/charts/gardener-extension-provider-packet

install.go:172: [debug] Original chart version: ""
install.go:189: [debug] CHART PATH: /Users/adeitcher/Documents/Development/go/src/github.com/gardener/gardener-extension-provider-packet/charts/internal/machine-controller-manager/seed

install.go:172: [debug] Original chart version: ""
install.go:189: [debug] CHART PATH: /Users/adeitcher/Documents/Development/go/src/github.com/gardener/gardener-extension-provider-packet/charts/internal/machine-controller-manager/shoot

install.go:172: [debug] Original chart version: ""
install.go:189: [debug] CHART PATH: /Users/adeitcher/Documents/Development/go/src/github.com/gardener/gardener-extension-provider-packet/charts/internal/machineclass

install.go:172: [debug] Original chart version: ""
install.go:189: [debug] CHART PATH: /Users/adeitcher/Documents/Development/go/src/github.com/gardener/gardener-extension-provider-packet/charts/internal/packet-infra

Error: YAML parse error on packet-infra/templates/main.tf: error unmarshaling JSON: while decoding JSON: json: cannot unmarshal string into Go value of type releaseutil.SimpleHead
helm.go:94: [debug] error unmarshaling JSON: while decoding JSON: json: cannot unmarshal string into Go value of type releaseutil.SimpleHead
YAML parse error on packet-infra/templates/main.tf
helm.sh/helm/v3/pkg/releaseutil.(*manifestFile).sort
	/private/tmp/helm-20200901-67641-iy9ufs/pkg/releaseutil/manifest_sorter.go:146
helm.sh/helm/v3/pkg/releaseutil.SortManifests
	/private/tmp/helm-20200901-67641-iy9ufs/pkg/releaseutil/manifest_sorter.go:106
helm.sh/helm/v3/pkg/action.(*Configuration).renderResources
	/private/tmp/helm-20200901-67641-iy9ufs/pkg/action/action.go:162
helm.sh/helm/v3/pkg/action.(*Install).Run
	/private/tmp/helm-20200901-67641-iy9ufs/pkg/action/install.go:239
main.runInstall
	/private/tmp/helm-20200901-67641-iy9ufs/cmd/helm/install.go:242
main.newTemplateCmd.func2
	/private/tmp/helm-20200901-67641-iy9ufs/cmd/helm/template.go:70
github.com/spf13/cobra.(*Command).execute
	/Users/brew/Library/Caches/Homebrew/go_mod_cache/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:842
github.com/spf13/cobra.(*Command).ExecuteC
	/Users/brew/Library/Caches/Homebrew/go_mod_cache/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:950
github.com/spf13/cobra.(*Command).Execute
	/Users/brew/Library/Caches/Homebrew/go_mod_cache/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:887
main.main
	/private/tmp/helm-20200901-67641-iy9ufs/cmd/helm/helm.go:93
runtime.main
	/usr/local/Cellar/go/1.15/libexec/src/runtime/proc.go:204
runtime.goexit
	/usr/local/Cellar/go/1.15/libexec/src/runtime/asm_amd64.s:1374

It might be related to the macOS and the tools that are installed and used by default on your machine.
Could you try from a docker container, e.g. https://github.com/gardener/gardener-extension-provider-packet/pull/113#issuecomment-769626292

Happy to try it

I reran it inside the container. The only thing that make generate changes was example/controller-registration.yaml.
Now the helm chart verification passes, but a different part fails:
docker run -it --rm -v $PWD:/go/src/github.com/gardener/gardener-extension-provider-packet golang:1.15.5
Unable to find image 'golang:1.15.5' locally
1.15.5: Pulling from library/golang
756975cb9c7e: Pull complete
d77915b4e630: Pull complete
5f37a0a41b6b: Pull complete
96b2c1e36db5: Pull complete
145393847161: Pull complete
71dfa979a65c: Pull complete
88a83f11b30a: Pull complete
Digest: sha256:cf46c759511d0376c706a923f2800762948d4ea1a9290360720d5124a730ed63
Status: Downloaded newer image for golang:1.15.5
root@839b11c72563:/go# cd src/github.com/gardener/gardener-extension-provider-packet/
root@839b11c72563:/go/src/github.com/gardener/gardener-extension-provider-packet#
root@839b11c72563:/go/src/github.com/gardener/gardener-extension-provider-packet# make install-requirements
> Installing requirements
golangci/golangci-lint info checking GitHub for tag 'v1.27.0'
golangci/golangci-lint info found version: 1.27.0 for v1.27.0/linux/amd64
golangci/golangci-lint info installed /go/bin/golangci-lint
Downloading https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz
Preparing to install helm and tiller into /usr/local/bin
helm installed into /usr/local/bin/helm
tiller installed into /usr/local/bin/tiller
Run 'helm init' to configure helm.
root@839b11c72563:/go/src/github.com/gardener/gardener-extension-provider-packet# make generate
> Generate
Successfully generated controller registration at ../../example/controller-registration.yaml
I0223 08:52:13.062731    1203 main.go:127] parsing go packages in directory .
I0223 08:53:17.514717    1203 main.go:229] using package=github.com/gardener/gardener-extension-provider-packet/pkg/apis/config/v1alpha1
I0223 08:53:17.780013    1203 main.go:165] written to ../../../../hack/api-reference/config.md
Generating deepcopy funcs
Generating defaulters
Generating conversions
Generating deepcopy funcs
Generating defaulters
Generating conversions
I0223 08:59:17.770503    4585 main.go:127] parsing go packages in directory .
I0223 08:59:51.411245    4585 main.go:229] using package=github.com/gardener/gardener-extension-provider-packet/pkg/apis/packet/v1alpha1
I0223 08:59:51.583905    4585 main.go:165] written to ../../../../hack/api-reference/api.md
root@839b11c72563:/go/src/github.com/gardener/gardener-extension-provider-packet# make verify
> Check
Executing golangci-lint
Executing go vet
Executing gofmt/goimports
All checks successful
> Check Helm charts
Checking for chart symlink errors
Checking whether all charts can be rendered
All checks successful
> Format
setting up env vars
> Test
ok  	github.com/gardener/gardener-extension-provider-packet/pkg/apis/packet/helper	0.295s
ok  	github.com/gardener/gardener-extension-provider-packet/pkg/apis/packet/validation	0.085s
Running Suite: Controlplane Suite
=================================
Random Seed:<PHONE_NUMBER>
Will run 3 of 3 specs

•
------------------------------
• Failure [0.008 seconds]
ValuesProvider
/go/src/github.com/gardener/gardener-extension-provider-packet/pkg/controller/controlplane/valuesprovider_test.go:44
  #GetControlPlaneChartValues
  /go/src/github.com/gardener/gardener-extension-provider-packet/pkg/controller/controlplane/valuesprovider_test.go:160
    should return correct control plane chart values [It]
    /go/src/github.com/gardener/gardener-extension-provider-packet/pkg/controller/controlplane/valuesprovider_test.go:161

    Expected
        <map[string]interface {} | len:2>: {
            "packet-cloud-controller-manager": {
                "facility": "ewr1",
                "replicas": 1,
                "clusterName": "test",
                "kubernetesVersion": "1.13.4",
                "podNetwork": "<IP_ADDRESS>/19",
                "podAnnotations": {
                    "checksum/secret-cloud-controller-manager": "3d791b164a808638da9a8df03924be2a41e34cd664e42231c00fe369e3588272",
                    "checksum/secret-cloudprovider": "8bafb35ff1ac60275d62e1cbd495aceb511fb354f74a20f7d06ecb48b3a68432",
                },
            },
            "metallb": {},
        }
    to equal
        <map[string]interface {} | len:2>: {
            "cloud-provider-equinix-metal": {
                "facility": "ewr1",
                "replicas": 1,
                "clusterName": "test",
                "kubernetesVersion": "1.13.4",
                "podNetwork": "<IP_ADDRESS>/19",
                "podAnnotations": {
                    "checksum/secret-cloud-controller-manager": "3d791b164a808638da9a8df03924be2a41e34cd664e42231c00fe369e3588272",
                    "checksum/secret-cloudprovider": "8bafb35ff1ac60275d62e1cbd495aceb511fb354f74a20f7d06ecb48b3a68432",
                },
            },
            "metallb": {},
        }

    /go/src/github.com/gardener/gardener-extension-provider-packet/pkg/controller/controlplane/valuesprovider_test.go:176
------------------------------
•

Summarizing 1 Failure:

[Fail] ValuesProvider #GetControlPlaneChartValues [It] should return correct control plane chart values
/go/src/github.com/gardener/gardener-extension-provider-packet/pkg/controller/controlplane/valuesprovider_test.go:176

Ran 3 of 3 Specs in 0.012 seconds
FAIL! -- 2 Passed | 1 Failed | 0 Pending | 0 Skipped
--- FAIL: TestController (0.02s)
FAIL
FAIL	github.com/gardener/gardener-extension-provider-packet/pkg/controller/controlplane	0.550s
ok  	github.com/gardener/gardener-extension-provider-packet/pkg/controller/infrastructure	1.209s
ok  	github.com/gardener/gardener-extension-provider-packet/pkg/controller/worker	1.975s
ok  	github.com/gardener/gardener-extension-provider-packet/pkg/packet	0.213s
ok  	github.com/gardener/gardener-extension-provider-packet/pkg/webhook/controlplane	0.208s
ok  	github.com/gardener/gardener-extension-provider-packet/pkg/webhook/controlplaneexposure	0.214s
ok  	github.com/gardener/gardener-extension-provider-packet/pkg/webhook/shoot	0.333s
FAIL
make: *** [Makefile:115: test] Error 1

I still will commit the changed example and push it out.
🤷♂

Hey, CI is clean! 😄


Strip alignment and re-merge when user click save

TBD: what do if alignment is broken?

@larsgson Can you suggest how this can be tested?

@larsgson Can you suggest how this can be tested?

@elsylambert I have now worked on a button to indicate what goes on here - and also to list the words, once they have broken alignments. This is now part of the branch Abel is doing some more work with (for search & replace)
So actually the best approach for testing this I would see is; to note it down and then test it later, once we have this new upcoming branch merged

@elsylambert I think this issue has been solved and this can now be closed

When alignment is broken, the indicator shows on the menu icons and lists the broken alignments. Looks good.


README - better project description

@danse, @giupardeb, @aegroto please have a look

@vigliag let me know how you like it now.
I also added a list of contributors.

Approved.

whoops.... I merged it by mistake.
I actually have no idea how this happened. I just merged another branch into master and the pushed. But this branch was affected too....weird

well done! :) 👍


btdm_osi_funcs_register returns<PHONE_NUMBER> = fail

In current master,  btdm_osi_funcs_register(...) returns an error status during esp_bt_controller_init(...).
Can anyone tell me why? I thought maybe I had older component/esp32/lib versions but I've made sure they are up-to-date.  What are the reasons  btdm_osi_funcs_register can fail?
err return:<PHONE_NUMBER>
I think I have reasonable sdkconfig values and have 'make clean'

Nevermind.  A library difference (in component/bt/lib/libbtdm_app.a) snuck in.  I blame git merge. :-)


Title: Proper spacing and design improvement

Which pre-existing JavaScript project will you be working on?
Stopwatch
Describe your enhancement/improvement
In this stopwatch project proper spacing and design is not there , It should be improved
I am good and experienced in HTML , CSS and Javascript
so I request you to kindly assign me this issue
I will resolve this issue for sure
Thank You

Anything you need to say to the Reviewers
No response
Add any other context or relevant screenshots about the enhancement here.
No response

@technicalkuldeep Thank you for providing your insight but it is not required as of now.


Bump version of qiskit-metal pyEPR version for EPR sign fix

What are the issues this pull addresses (issue numbers / links)?
N/A
Did you add tests to cover your changes (yes/no)?
No
Did you update the documentation accordingly (yes/no)?
No
Did you read the CONTRIBUTING document (yes/no)?
Yes
Summary
This PR bumps the version numbers for qiskit metal and pyEPR to pull in a pyEPR fix to a bug that was causing EPR to always be positive.
Details and comments
Qiskit-metal version bumped from 0.1.0 to 0.1.1
pyEPR version bumped from <IP_ADDRESS> to <IP_ADDRESS>

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Fix issue 270: Replace AttachThreadInput with ShowWindow in set_focus()

AttachThreadInput fails when the foreground window does not have a message loop, namely cmd.exe. Using ShowWindow instead avoids the need for a lot of the existing handling to juggle threads.
While it was suggested in #270 that the mouse.move() calls may cause problems as well, I left it alone since it was outside the scope of this specific issue.

Current coverage is 95.01% (diff: 100%)

Merging #272 into master will increase coverage by 0.01%

@@             master       #272   diff @@
==========================================
  Files            49         49
  Lines         19443      19427    -16
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits          18471      18459    -12
+ Misses          972        968     -4
  Partials          0          0

Powered by Codecov. Last update b4229d3...f1f150f

Good job! The tests look stable.
Merging.


Add ability to run nearest neighbors, umap and louvain on a GPU using RAPIDS

This adds RAPIDS as an (experimental) option for running some of the graph algorithms on a GPU.
Example usage is demonstrated here: https://github.com/tomwhite/scanpy_usage/tree/rapids-gpu/1909_rapids_gpu
In summary:
    sc.pp.neighbors(adata, method='rapids')
    sc.tl.louvain(adata, flavor='rapids')
    sc.tl.umap(adata, method='rapids')

Timings (on 130K samples):

Step
CPU time (s)
GPU time (s)
Speedup

Neighbors
47
15
3x

Louvain
70
1
70x

UMAP
186
15
12x

Comments:

In general the output figures are quite different for each of the algorithms compared to regular Scanpy. (See the figures in the link above.)
RAPIDS uses exact nearest neighbors (using https://github.com/facebookresearch/faiss I think), whereas the default NNDescent algorithm in Scanpy is approximate.
Louvain community detection results in a different number of communities (28 vs 45). I'm not sure if it is possible to change the termination criteria or other parameters that would make the two outputs the same, or at least more similar.
UMAP is different too, and in particular it is bunched in one corner. There are a few very small clusters in the opposite corner, which looks like it might be a bug.
UMAP computes the nearest neighbors again from scratch - it can’t reuse the ones computed earlier since RAPIDS only exposes the fit/transform methods, and not simplicial_set_embedding that regular UMAP exposes.
In general it would be useful to understand what random number generators each of the alternatives use, how they can be controlled, and what prospects there are for achieving identical output (if any).
This is using RAPIDS version 0.7 since it is the version available on the Google Cloud image I used (https://cloud.google.com/deep-learning-vm/docs/images).

I think this looks good and simple enough. Could you please fix the CI errors?
Also there’s 3 added optional deps: cuml, cudf, and cugraph. I assume they’re all different CUDA packages. Could you add them into an extra in setup.py?
The RAPIDS umap branch doesn’t use a metric argument. Does it support metrics other than euclidean?

The RAPIDS umap branch doesn’t use a metric argument. Does it support metrics other than euclidean?

No, it only supports Euclidean distance currently.

@flying-sheep thanks for taking a look. I've fixed the CI errors now and added the deps as suggested.

The packages do need a GPU, unfortunately. There is no way to fallback to run on a CPU, so I don't think Travis can test them.

OK, too bad …


Loaded scripts in command pallete are not rendering file icons

Refs: #62093
Notice how when you open quick open to navigate to a file the icon is being nicely rendered.
This is not the case when I am navigating through loaded scripts in the command pallete and I would expect that the experience is the same.

@isidorn I think you mean "quick pick" when you say "command palette".
Since the "quick pick" based loaded scripts will go away as soon as the loaded scripts view supports filtering, I will not add any new features.


Add Vivaldi browser.

Please add Vivaldi browser.
https://vivaldi.com/

Up

We include only browsers that have a significant share of usage from the public. Outdated browser is not intended to feature all the browsers available but a quick glimpse of the most popular choices available. Thank you.


Multiprocessing with Pool won't work on Mac with M1 chip

Hi @nespinoza,
If I try to use nthreads option in juliet.fit for using multiprocessing with dynesty, I would get the following error:
RuntimeError:
        An attempt has been made to start a new process before the
        current process has finished its bootstrapping phase.

        This probably means that you are not using fork to start your
        child processes and you have forgotten to use the proper idiom
        in the main module:

            if __name__ == '__main__':
                freeze_support()
                ...

        The "freeze_support()" line can be omitted if the program
        is not going to be frozen to produce an executable.

At first, I thought it is the multiprocessing implemented in dynesty that is causing this issue. However, upon digging into the details I found that this has rather do with how multiprocessing is implemented in juliet: the culprit is line 1723. A proper way to do this (according to this StackOverflow answer) is following:
from multiprocessing import get_context
...
with contextlib.closing(get_context("fork").Pool(processes=self.nthreads - 1)) as executor:
    sampler = DynestySampler(self.loglike,\
        self.prior_transform_r,\
        self.data.nparams,
        pool=executor,
        queue_size=self.nthreads,
        **d_args)
    sampler.run_nested(**ds_args)
    results = sampler.results

(instead of directly calling Pool from multiprocessing, one should call it from multiprocessing.get_context("fork").Pool). Making this change would solve the above issue.
However, I am not opening a pull request since it looks like this issue is specific to Mac users with an M1 chip. And I have no idea how implementing this would affect other systems which don't have M1. Also since this is the issue with Pool implementation, it should also affect emcee and zeus samplers which also use Pool for multiprocessing (though I haven't tested for samplers other than dynesty).
Cheers,
Jayshil

Hi @Jayshil! Thanks for this. Can you confirm that the way you propose to do multiprocesing is the way to make this work? Also, to change this, would imply to also test on non-M1-chip computers to ensure this is not going to fix the M1-chip users, but make everyone else's code to break.
I'll leave it as an enhancement for now, but if this is investigated further, I would be happy to change the way in which pool is handled.
N.

Hi @nespinoza,
I am not really sure if this is the only way to make this work or not. There may be other ways to resolve this issue that I am unaware of. But I can confirm that this is at least one way to make it work for M1 chip computers (working smoothly on my machine). I also don't know if this would work for non-M1-chip computers or not. Unfortunately, I do not have enough time to thoroughly investigate this.
I think your suggestion is appropriate to leave this as an enhancement for now. This will let users know that there is an issue with pool in M1 chip Macs and there is a possible way to resolve this.
Cheers,
Jayshil

Hi @nespinoza,
A colleague of mine pointed out that instead of editing the juliet source code, one can simply add the following two lines in their code to make multiprocessing work with M1 chip macs:
import multiprocessing
multiprocessing.set_start_method('fork')

This is at least working with dynesty.
So, I suggest we leave juliet source code as it is, but put this "hack" somewhere in the documentation. We can close this issue after that.
Cheers,
Jayshil


Sim Agents: the compute of likelihood about the features in validation

For the validation, the result is not 1 when I try to submit the ground truth to compute the likelihood. Is there anything wrong?

Hi @QC625
If you are referring to the meta-metric value, since we are using a metric config with flag independent_timesteps: true, the likelihood computation will not be exactly 1 even by replaying the ground truth. If you look at the documentation in the metric code it should be clear why this is the case, otherwise let me know if you need further clarifications.
Just to double-check, when using the ground truth directly, are you seeing the ADE metrics to be roughly zero? If this is the case, then it's not an issue (it's just the intended scaling I was mentioning above), if it's not, you might actually have some errors / bugs somewhere in your code.
Hope this helps!
Nico

Hi @QC625, thanks a lot for the additional info!
Given that the ADE is zero, then yes, you are doing things correctly. As I was saying, values for the likelihoods metrics are not 1 because when independent_timesteps: true, we are taking all the values for the feature, say speed, over the whole 8s of simulation. Each log sample is then scored against this aggregated distribution of 32(samples) * 80 (steps), which means that the ground-truth  likelihood will not be 1. We have baseline experiments for validation and test, so there a theoretical limit to the likelihood metrics (less than 1).
For the validity issue, again, everything should be clear from the code documentation, but I'll try to recap here:
for every step (and for every object) we are computing the likelihood of the log sample against the simulated distribution. This will not happen for invalid objects, because we have no ground truth to score. But since we are not releasing any validity information (for the future) for the test set, submissions should assume the object to "continue" to be valid, and provide reasonable simulations anyway. If the object turns out to be invalid, these will not be used for scoring.
I also wanted to mention that we are going to have office hours tomorrow and on friday if you have further questions (see pinned post). Hope this helps!

OK, thanks!


Add source to the answer for default prompt

Why are these changes needed?
Add sources of context to RAG assistant's response.
https://discord.com/channels/1153072414184452236/1214380707208765480/1225516465260728450

Related issue number

Checks

[ ] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[ ] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[ ] I've made sure all auto checks have passed.

Codecov Report
Attention: Patch coverage is 0% with 21 lines in your changes are missing coverage. Please review.

Project coverage is 47.22%. Comparing base (e513a18) to head (e864b93).

Files
Patch %
Lines

autogen/retrieve_utils.py
0.00%
15 Missing :warning:

...gen/agentchat/contrib/retrieve_user_proxy_agent.py
0.00%
4 Missing :warning:

...ntchat/contrib/qdrant_retrieve_user_proxy_agent.py
0.00%
2 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2289      +/-   ##
==========================================
+ Coverage   38.14%   47.22%   +9.07%
==========================================
  Files          78       78
  Lines        7859     7869      +10
  Branches     1680     1819     +139
==========================================
+ Hits         2998     3716     +718
+ Misses       4611     3845     -766
- Partials      250      308      +58

Flag
Coverage Δ

unittest
14.20% <0.00%> (?)

unittests
46.20% <0.00%> (+8.07%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

@thinkall could you check this test error? https://github.com/microsoft/autogen/actions/runs/8609331985/job/23593097960?pr=2289#step:6:107

@thinkall there is a test failure https://github.com/microsoft/autogen/actions/runs/8609331985/job/23593097960?pr=2289


Feature/updatepolicy

What problem does this PR solve?

What is changed and how does it work?

Code changes

[ ] Has Go code change
[ ] Has CI related scripts change

Tests

[ ] Unit test
[ ] E2E test
[ ] Manual test
[ ] No code

Side effects

[ ] Breaking backward compatibility
[ ] Other side effects:

Related changes

[ ] Need to cherry-pick to the release branch
[ ] Need to update the documentation

Release Notes

Please refer to Release Notes Language Style Guide before writing the release note.

我并不能直接推你分支..能读不能推
你记得合一下
@mikechengwei

@tomatopunk nb


Make flagging script more flexible with respect to geography

Two new requirements that both require a more flexible approach to geography:

We would like to be able to run a flagging job against sales within an arbitrary geography or set of geographies (e.g. flag sales within a tri, municipality, or group of neighborhoods)
We would like to be able to group sales by arbitrary sets of geographies (e.g. a municipality or a group of neighborhoods)

I am assuming that we don't need to support multiple types of geography per run (e.g. we do need to allow a user to decide between running a flagging job on a tri or a municipality; but we don't need to allow a user to run a flagging job on both a tri and a municipality in the same run).
This will require changes to at least the following parts of the code:

The query in the flagging script(s)
The config parameters in input.yaml
The parameter output table

Depending on the degree of changes required by the design for this feature, it may be worth sketching out a proposed solution in writing for approval before getting started on the implementation.

(In progress)
While discussing potential data models with @jeancochrane, we identified assumptions which, if violated, would make the data model significantly more complicated for the user.


Added back-to-top button

Related Issue or bug

Info about Issue or bug

Fixes: #201
Describe the changes you've made
Removed excess of js from all the html files
Added required to common.html, home.html
created js/index.js
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce.
Describe if there is any unusual behaviour of your code(Write NA if there isn't)
A clear and concise description of it.
Checklist:

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[] I have made corresponding changes to the documentation.
[x] 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.
[ ] Any dependent changes have been merged and published in downstream modules.

Screenshots

Original
Updated

original screenshot
updated screenshot

I am trying to look for it but it is because of reboot.scss can You tell me where the file is ? In the meanwhile I will try to find a fix.


Move Helm chart to the current repository

It make sense to have the helm chart material in the github instead of in the kubernetes repository

Invalidate this issue as it will be published in the ibm chart repository.


feat(boarding-passes-summary): sort boarding passes by departure date

fixes #728LiveURL: https://smartfaq-fix-issue-728.surge.sh

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


_pickle.UnpicklingError: invalid load key, 'v'.

Thank you for your work. When I tried to use U-2-Net, the following error occurred with the pre-trained model you provided。
_pickle.UnpicklingError: invalid load key, 'v'.

Heya,
Make sure you have git lfs  installed and configured, so the actual model files will be downloaded rather than just a reference pointer to their location


Mounts /sys/kernel/security

Mounts /sys/kernel/security needed by AppArmor

The configurations were renamed. Please check the new name.


ISPN-15981 Wrap ScriptEngine init in blocking call

https://issues.redhat.com/browse/ISPN-15981

@tristantarrant I've added 14.0.x label. I think it is useful for ISPN 14 too. Remove it if you think otherwise :+1:

merged! thanks @tristantarrant !


Please do not display milliseconds in last modified field

I'm use Linux and python 3.4
The page's last modified fields look like this:

2016-04-08 18:55:59.502160

If it is not a feature, I think this will fix it:
flask_autoindex/entry.py:112
return datetime.fromtimestamp(os.path.getmtime(self.abspath)).replace(microsecond=0)
Sorry for my bad English

It will be available on tag v0.6.6
Thanks


isfinite() not supported

Hi,
I've got a shader which uses the isfinite() function from hlsl. This translates correctly to SPIR-V (or at least I think it does since it uses IsFinite in the SPIRV) but if I try to output glsl from it all it says is "// unimplemented op 158" and leaves my shader in an unusable state (it doesn't compile, not even incorrectly). Sample code:
float4 main ( float input )
{
    if(isfinite(input))
	{
		return float4(1, 0, 0, 0);
	}
	else
	{
		return float4(0, 0, 0, 0);
	}
}

SPIR-V has OpIsFinite, which is Kernel only according to SPIR-V specification.
SPIRV-Cross only supports the Shader model. Maybe you could use !isinf() && !isnan() instead?

Ah, I see. I can probably get away with using what you suggest, but it'd still be nice to have it translate properly. I'm guessing this is one for glslang as well?

Should be fixed in glslang, fixing it in SPIRV-Cross would be a kludgy workaround, but not hard if necessary.

While thinking about how the workaround would look like, I found an actual bug in SPIRV-Cross, so hey :p

Closing issue in wait for glslang.

I'm glad it was of help at least :)


Retry concerns for rails application, sidekiq-like behavior

I have some classes, which could be useful for someone using this great gem!
For example, you would like your jobs to be not-retryable by default, but be retryable only if some retry_options provided.
You could use the following modules/concerns to achieve this goal:
# Some failing job (app/jobs/dummy_job.rb)

class DummyJob < ActiveJob::Base
  include CommonJobOptions

  retry_options max_retries: 25

  def perform(*)
    raise RuntimeError
  end
end

# app/jobs/concerns/common_job_options.rb
# Concern for queueing jobs, which also includes sidekiq-like retry concern (CommonRetry)

module CommonJobOptions
  extend ActiveSupport::Concern
  include CommonRetry

  included do
    queue_as do
      self.class.name.underscore.upcase.to_sym
    end
  end
end

# app/jobs/concerns/common_retry.rb
# Concern to make job retryable conditionally (if retry_options provided)
# It is using variable_retry to emulate sidekiq-like behavior for job retrying

module CommonRetry
  extend ActiveSupport::Concern

  # @option options [Fixnum] :max_retries Number of retries
  # @option options [Array of constants] :fatal_exceptions Array of exceptions to be ignored
  # @option options [Array of constants] :retryable_exceptions Array of exceptions to be retried (only)
  # @option options [Proc] :delays_formula Callable function with arity 1
  # @option options [Array of ActiveSupport::Duration] :delays_array Array of delays
  #
  # @example
  #
  # class MyJob
  #   include CommonRetry
  #
  #   retry_options max_retries: 10, fatal_exceptions: [StandardError, RuntimeError]
  #
  #   or
  #
  #   retry_options max_retries: 5, retryable_exceptions: [TimeoutError]

  class_methods do
    def retry_options(options)
      return unless options[:max_retries].present?

      set_options(options)
      include(ActiveJob::Retry)
      variable_retry(delays: delays_array,
	                 retryable_exceptions: retryable_exceptions,
	                 fatal_exceptions: fatal_exceptions)
    end

    def set_options(options)
      @max_retries = options[:max_retries]
      @retryable_exceptions = options[:fatal_exceptions]
      @fatal_exceptions = options[:retryable_exceptions]
      @delays_formula = options[:delays_formula]
      @delays_array = options[:delays_array]
    end

    def delays_formula(count)
      @delays_formula || -> { ((count ** 4) + 15 + (rand(30)*(count+1))).seconds }
    end

    def delays_array
      @delays_array || (0...max_retries).to_a.map{ |i| delays_formula(i).call }
    end

    def max_retries
      @max_retries || 0
    end

    def retryable_exceptions
      @retryable_exceptions || nil
    end

    def fatal_exceptions
      @fatal_exceptions || []
    end
  end
end

# config/application.rb
config.autoload_paths += Dir["#{config.root}/app/jobs/concerns/"]

# config/sidekiq.yml

:concurrency: 2

:queues:
  - ['DUMMY_JOB', 2]

That's it. Using these concerns you can easily redefine behavior within concrete job using method retry_options with keys :max_retries, :fatal_exceptions, :retryable_exceptions, :delays_formula, :delays_array (see concern CommonRetry).
But if you would like to use default behavior, you can just include concern CommonJobOptions with retry_options max_retries: 5 (see DummyJob)

I think an easier way to achieve the random-delay behaviour here would be to write another BackoffStrategy (which just needs to define #should_retry?(attempt, exception) and #retry_delay(attempt, exception)). If you do this I'd be happy to accept it as a PR to this gem, with a shortcut to use as random_retry (as is done for the constant and variable strategies).

Many thanks for your response, I'll try to do my best

Disclaimer: I haven't even run this so may not work at all, but I think this would probably achieve what you want:
class ExponentialBackoffStrategy < ConstantBackoffStrategy
  def retry_delay(attempt, _exception)
    ((attempt ** 4) + 15 + (rand(30) * (attempt + 1))).seconds
  end
end

class MyJob < ActiveJob::Base
  include ActiveJob::Retry

  retry_with ExponentialBackoffStrategy.new(limit: max_retries, retryable_exceptions: ..., )
end

You'd probably also want a ExponentialOptionsValidator to make sure people don't try to set the delays key, but add some tests and should be golden. You'll probably also want a helper method like this one to be able to use the strategy as:
class MyJob < ActiveJob::Base
  include ActiveJob::Retry

  exponential_retry limit: 25
  ...
end

Excited for the PR ;) :dancer: :tada: :boom:


[2.5] [BUG] Unable to interact with downstream clusters after upgrading from 2.5.15 to 2.5.16

Backport rancher/rancher#38699

Closing issue based on internal convo with dev team about not being able to test due to hosted k8s versioning

https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar

https://cloud.google.com/kubernetes-engine/docs/release-schedule

https://learn.microsoft.com/en-us/azure/aks/supported-kubernetes-versions?tabs=azure-cli#aks-kubernetes-release-calendar


Release

Initial version (1.0.0) will contain main functionalities for automatic responses and time savers for maintainers.

[x] Hash check fails validator

[x] Download failed validator

[x] New manifest in PR validation

Hashes
Checkver
Needed properties

[x] "Excavator"

Iterative pushing done by auto-pr

[x] Polish README

[x] Synchronize terminology

[ ] Polish posted comments before first release

[ ] Release and tag initial version

[ ] 1.0.0 tag requirements

[x] Events folder

[x] All events needs to be in place

[ ] Issue handler

[x] hash check
[ ] download failed

[ ] Aria2 support

[x] PR

[ ] Commented

[ ] Fork
[ ] Normal

[ ] Created

[ ] Fork
[ ] Normal

[x] Excavator

[ ] Protect Master

[x] Create also stable branch, which will be almost equal with master

Users will not need to look for latest version
This may not be even point when deployed to marketplace

[ ] Icon lukesampson/scoop#2261

[ ] Register official action to marketplace

https://developer.github.com/marketplace/actions/publishing-an-action-in-the-github-marketplace/

[ ] Create all these actions inside @Ash258/GenericBucket

[ ] And all other official and my buckets

[x] JetBrains
[x] Sysinternals
[x] Ash258
[ ] Main
[ ] Extras
[ ] Java
[ ] Versions
[x] Internal corporate repositories

[x] Ixx
[x] Dxxxxxxxx
[x] Pxxxxx
[x] Qxxxxx
[x] Ixxx

Wait for reaction from variety of users if wiki will be needed for clarifying some comments (Maybe checklists in PR)


Unable to use database router with single writer and many readers

Description
Trying to use a database router that will help support many readers and a single writer. When adding a plugin like text, it fails with an exception.
Steps to reproduce
Setup a database router similar to the following:
class DatabaseRouter:
    """
    A router that is configured for a master/slave setup.
    """

    def db_for_read(self, model, **hints):
        """ Point all read operations to a read-slave. """
        return 'default'

    def db_for_write(self, model, **hints):
        """ Point all write operations to the master """
        return 'writer'

    def allow_relation(self, obj1, obj2, **hints):
        """ Because we have master-slave replication, any relation is allowed. """
        return True

    def allow_migrate(self, db, app_label, **hints):
        """
        All models that have not been migrated to another DB get
        migrated to master only. Read-replication takes care of
        populating the tables on the replicas.
        """
        if hints.get('target_db', None) == settings.WRITER_DB:
            return True
        if db == settings.WRITER_DB:
            return True
        return False

Expected behaviour
This should just work without issue AFAIK.
Actual behaviour
The following exception is observed:
web_1    | Traceback (most recent call last):
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/core/handlers/exception.py", line 41, in inner
web_1    |     response = get_response(request)
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 187, in _get_response
web_1    |     response = self.process_exception_by_middleware(e, request)
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 185, in _get_response
web_1    |     response = wrapped_callback(request, *callback_args, **callback_kwargs)
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/utils/decorators.py", line 149, in _wrapped_view
web_1    |     response = view_func(request, *args, **kwargs)
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/views/decorators/cache.py", line 57, in _wrapped_view_func
web_1    |     response = view_func(request, *args, **kwargs)
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/contrib/admin/sites.py", line 224, in inner
web_1    |     return view(request, *args, **kwargs)
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/views/decorators/clickjacking.py", line 39, in wrapped_view
web_1    |     resp = view_func(*args, **kwargs)
web_1    |   File "/usr/local/lib/python3.6/site-packages/cms/admin/placeholderadmin.py", line 341, in add_plugin
web_1    |     response = plugin_instance.add_view(request)
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/views/decorators/clickjacking.py", line 39, in wrapped_view
web_1    |     resp = view_func(*args, **kwargs)
web_1    |   File "/usr/local/lib/python3.6/site-packages/djangocms_text_ckeditor/cms_plugins.py", line 305, in add_view
web_1    |     request, form_url, extra_context
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/contrib/admin/options.py", line 1509, in add_view
web_1    |     return self.changeform_view(request, None, form_url, extra_context)
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/utils/decorators.py", line 67, in _wrapper
web_1    |     return bound_func(*args, **kwargs)
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/utils/decorators.py", line 149, in _wrapped_view
web_1    |     response = view_func(request, *args, **kwargs)
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/utils/decorators.py", line 63, in bound_func
web_1    |     return func.__get__(self, type(self))(*args2, **kwargs2)
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/contrib/admin/options.py", line 1409, in changeform_view
web_1    |     return self._changeform_view(request, object_id, form_url, extra_context)
web_1    |   File "/usr/local/lib/python3.6/site-packages/django/contrib/admin/options.py", line 1454, in _changeform_view
web_1    |     return self.response_add(request, new_object)
web_1    |   File "/usr/local/lib/python3.6/site-packages/cms/plugin_base.py", line 354, in response_add
web_1    |     return self.render_close_frame(request, obj)
web_1    |   File "/usr/local/lib/python3.6/site-packages/cms/plugin_base.py", line 300, in render_close_frame
web_1    |     'plugin_structure': get_plugin_tree_as_json(request, plugins),
web_1    |   File "/usr/local/lib/python3.6/site-packages/cms/toolbar/utils.py", line 70, in get_plugin_tree_as_json
web_1    |     plugin_tree = build_plugin_tree(plugins)
web_1    |   File "/usr/local/lib/python3.6/site-packages/cms/utils/plugins.py", line 138, in build_plugin_tree
web_1    |     root_depth = min(plugin.depth for plugin in plugins)
web_1    | ValueError: min() arg is an empty sequence

Additional information
Using python3.6 with django-cms==3.5.2.

Just to add to this, you don't actually need two DBs to reproduce just two separately configured ones that can still point the same database.
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'cms',
        'USER': 'foo',
        'PASSWORD': 'bar',
        'HOST': 'localhost',
        'PORT': 3306,
    },
    'writer': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'cms',
        'USER': 'foo',
        'PASSWORD': 'bar',
        'HOST': 'localhost',
        'PORT': 3306,
    },
}

DATABASE_ROUTERS = [
    'some.db.router',
]

In my opinion, this doesn't have to do anything with your database replication. Btw. what's the purpose of using the same database, as well for the master, as for their replicas? Anyway, it looks more like a version mismatch between django-CMS and djangocms-ckeditor. Did you check that?

It's a common pattern to spread requests out over many read-replicas and write to only a single master. It is even an documented example in the Django docs:
https://docs.djangoproject.com/en/2.1/topics/db/multi-db/#an-example
I'm mentioned that it is possible to reproduce using the same underlying database but defined multiple times in Django to make it easier for people to troubleshoot. Basically, you don't need to go setup a large DB infrastructure to see the same things I am. That said, in a production scenario they would be different.
I was able to get my router (see below) to a point where I could create plugins but this then broke creating new pages. It doesn't seem to even generate any exception that I can find, just eventually times out with a 502.
from django.conf import settings

class DatabaseRouter:
    def db_for_read(self, model, **hints):
        """ Route read operations. """

        # NOTE(awiddersheim): If no `instance` was passed in the `hints`,
        # send the operation to the read replicas. If an instance was
        # passed, fall through to the default router which will either
        # use the suggested database or route to the `default` which is
        # the `writer`.
        # https://docs.djangoproject.com/en/2.1/topics/db/multi-db/#hints
        if hints.get('instance') is None:
            return settings.READER_DB

    def allow_relation(self, obj1, obj2, **hints):
        """ Because we have replication, any relation is allowed. """
        return True

After spending a few hours tracing this back I think I see the issue, at least when adding plugins but there could be other places where this crops up with my specific use case and transactions specifically.
When adding a plugin eventually you hit this code in Django proper:
https://github.com/django/django/blob/master/django/contrib/admin/options.py#L1520-L1522
This starts a transaction for the djangocms_text_ckeditor.models.Text model for example on whatever the DB router says is the writer. In my use case it is the master DB in my single writer and many reader architecture. Later, in the django-cms code, a query set is used without specifically using the writer DB or without any hint provided for the DB router to use so it will get processed by the read-replicas while still in a transaction on the master:
https://github.com/divio/django-cms/blob/develop/cms/utils/plugins.py#L277
https://github.com/divio/django-cms/blob/develop/cms/plugin_base.py#L173-L174
Since this then queries the database without the on-going transaction, nothing is returned resulting in the exception above. If we were to change this line to be something like which more closely matches what Django proper is doing above, things work:
return cls.model._default_manager.using(router.db_for_write(cls)).all()

I'm far from a Django expert so I'm not sure if there are better ways to do this or if there is something I could change on my end to circumvent these issues without adjusting the django-cms code base to handle transactions better and my use case of single writer and many readers.

Because the django-cms is a third party I'm not familiar with how to do the transaction management with the readonly vs writing.

Was this resolved?
I came looking for MongoDB support but figured I'd be better off trying a router.


#153772162 implement e2e test

What does this PR do?
It increases the test coverage
Description of Task to be completed?
NA
How should this be manually tested?
NA
Any background context you want to provide?
NA
What are the relevant pivotal tracker stories?
NA
Screenshots (if appropriate)
NA
Questions:

Coverage increased (+0.4%) to 92.609% when pulling d12fddec0f1a6689da592b2540f20bd2b8c2dcf0 on chore/153772162/implement-e2e-test into ace29cf7d0476ce515d7dd90385c1b4223ea386b on master.

Coverage increased (+0.4%) to 92.609% when pulling 105e256310bf9ce19c4e258679ca66f80b3f0a67 on chore/153772162/implement-e2e-test into ace29cf7d0476ce515d7dd90385c1b4223ea386b on master.


Define some coding standards to use in the docs

Can we define some coding standards to use in the docs for how we import the API client, what we call it, what we name the return value from jobs etc? I mostly have no opinions about what these should actually be, just that they should be consistent.
There's probably a bunch of different conventions used in different bits of documentation, notebooks, sample code. Settling on something to help make examples consistent, correct and accessible to people with not very deep Python knowledge would be really helpful, before we start writing a bunch of new examples in all different styles.
I'm not too keen on throwing around the term API in this setting. I think it's confusing to end users coming from humanities, so if we could avoid using that term in the variable names I think I'd prefer that? - I'd appreciate input from @MariellaCC or Caitlin on the use of this term and how it feels to them, how well they understand what it actually means?
things we need to clarify
the snippet we put at the start of everything - @makkus which is the right API to be using?!?
# markus' docs example uses this
from kiara.interfaces.python_api import KiaraAPI

# some jupyter examples use this
from kiara.api import KiaraAPI

can/should we communicate something about applicable package versions at this point, for example a comment after the import saying what version was used for the example?
when we've imported that thing, there's a line that looks something like this. What do we call the api client thing?
# potentially bad because the package is called kiara?
kiara = KiaraAPI.instance()

# potentially bad because jargon
api = KiaraAPI.instance()

# would client be a useful word here?
kiara_client = KiaraAPI.instance()

Do we define arguments in a separate variable, or straight in the function call?
inputs = {"some":"thing"}
do_operation('name', inputs=inputs

# or
do_operation('name', inputs={"some":"thing"})

Do we tell users to use run_job or queue_job? I'm strongly in favour of run_job because it reduces a bunch of complexity, as long as we note somewhere that queue_job exists. See for example how much extra code in this queue_job example. In examples particularly, people never don't want to just wait for the thing to finish.
What do we call the return value from a run_job? We usually bind this to a variable, it would be useful to pick a consistent name/name scheme. result? results (is there more than one result?)? <operation_name>_result? in this pattern:
# ...
results = api.run_job("import.local.file", inputs=inputs)

Do we use type hints in code examples? probably not, unless they really make things clearer? Again, what do @MariellaCC and Caitlin think about this - are type hints familiar/useful to you?

from kiara.api import KiaraAPI

That one is better to use in docs (both point to the same Python class).

api = KiaraAPI.instance()

That's my personal preference, it's jargon, but it's also correct (plus the Python class is called that). And if someone doesn't know what an api is but using Python, then they probably also don't have a very firm concept of 'client'.

Do we tell users to use run_job or queue_job? I'm strongly in favour of run_job because it reduces a bunch of complexity, as long as we note somewhere that queue_job exists. See for example how much extra code https://github.com/DHARPA-Project/kiara-website/issues/9#issuecomment-1814232313. In examples particularly, people never don't want to just wait for the thing to finish.

I think we always used run_job. I only mentioned queue_job because it's relevant for an interactive client. Unless that is the case, I would always use run.

result? results (is there more than one result?)? <operation_name>_result?

Depends on the operation, most have one, some have multiple output fields. The Python object is a map-like thing though, so my feeling is that 'results' is more correct in more cases (since you always have to slice away the single field you are interested in, even if only one result field is contained).

Best guess at best practice example code, I'll edit this as we discuss/decide more things. using the import file process as an example usecase
from kiara.api import KiaraAPI  # version 0.5.0 and newer
# call the thing API
api = KiaraAPI.instance()

# as yet undecided whether this is useful, but it probably is?
inputs = {
    "path": "./myfile.csv",
    "quite": "often",
    "there's": "lots",
    "of_things": "here",
}

# always use run_job
# call the thing results because there's usually lots of values returned
results = api.run_job('import.local.file', inputs=inputs)

# no type hint here
imported_file = results['file']

Jupyter users @MariellaCC, @CBurge95 are you happy with that? does it match with how you tend to write your notebooks, is anything unclear?

Just a weigh in on terms here (from the humanities/history front) but I think it depends where you are planning on using this language: I'm generalising but I think those using CLI will likely already be comfortable with APIs, what this means and more importantly, how it works, but those in a UI or basic python environment (aka Jupyter) are much less likely to follow this beyond a surface level (i.e. an API helps you get information from one system into another system). Quick wizz round those currently in the office suggests that using this term is going to be less than helpful, and I (personally at least!!) think that naming it api versus kiara is technical accuracy at the expense of wider understanding. This is obviously not to say that we don't explain and/or document the fact that kiara (in this instance) is the name for the api.

And if someone doesn't know what an api is but using Python, then they probably also don't have a very firm concept of 'client'.

At least for my part, this is correct. I think some assumptions might be being made about the average user/average coding ability of someone in digital humanities, and how this is then impacting language decisions in both docs and kiara itself. Obviously this is not new, but I think the less complex/more informative we can make the whole process, the more welcoming and useable it is likely to be.

@makkus is there a technical reason why kiara is a bad name for binding KiaraAPI.instance() to? I'm not familiar enough with the details of python's module system to know whether I need to care about a naming collision here?
If there's no technical reason not to, I'd prefer calling the thing kiara if that makes things clearer for end-users. I care more about being inclusive at this stage, and people with strong technical knowledge and understanding will cope, and can go to the type hints or code if they need to.

I don't really have an opinon here, I just used api myself because it's short. People using pandas probably also use 'df' before they understand what a DataFrame is, so personally I wouldn't worry too much, but kiara is fine as far as I can see.

@caro401
I also prefer calling it kiara. Alternatively, kiara_client or kiara_api seem intuitive enough to me if there is a problem with the fact that kiara is the package name. I find api too vague here.

@caro401
Concerning the inputs and results variable names, I tend to use different names for each operation to enable potential re-usability of these variables (especially for the results one, I don't think that I have encountered use cases of using the inputs for two distinct operations so far). It already happened to me in the past that the value of a results variable was used as an input for two distinct operations and that these operations were not immediately following one another.

Thanks @MariellaCC, that's really helpful! I've updated the code snippet above to match what I think you've said, let me know if I've misunderstood anything.
In terms of type hints, after a bit more thinking, I think I'd prefer to leave them out of code, because I think the way code will fail if you've not imported a type will be really un-intuitive for less experienced Python users. This would be a particular problem if you are copy/pasting little bits of code around, which I expect might be how these tutorials will be used in practice.
Do you think that's reasonable? Are people more comfortable with type hints than I imagine?

I think we can use the module/operation metadata more effectively to nod at type hints. I find type hints helpful as a reminder but only when I already know what they're there for, and I think you're right to say that if people are just copying &pasting they might either end up superfluous or just completely wrong. I think if they are outlined clearly/narrative-ly enough in the metadata/operation instructions this might be able to solve both problems at once? This relies on people reading through this bit properly as a first step, but hopefully that will be done anyway!

Hmm yeah, you're probably right. @CBurge95 would you be able to edit https://github.com/DHARPA-Project/kiara-website/issues/10#issuecomment-1814317252 to put type hints where they'd be useful for you? And if you have time, suggest or make changes to my attempt at sample code https://github.com/DHARPA-Project/kiara-website/pull/11/files, to suggest how it might be helpful to introduce type hints?
or were you thinking more like a separate docs page that introduces our conventions for code in the docs, including explaining a bit about type hints?

Ahh sorry; I was thinking in terms of this
import_csv_file_inputs = {     "path": "./myfile.csv",     "quite": "often",     "there's": "lots",     "of_things": "here", }
that we can also have this nice and clear in the metadata - sorry I completely misunderstood, entirely my fault for not reading things properly!!
I think normal type hints (i.e. the hashtags bit) are actually really helpful - ideally if we're writing in markdown they'd be fleshed out in the paragraphs(?) surrounding them, but I write type hints quite a lot and appreciate when they're there, it helps me keep track of my own code, and I struggle to read others without it.

Sorry, I completely failed to explain what I meant by type hints. In Python (3.6+ IIRC), you can optionally add annotations to variables and functions to tell the code user, your text editor/IDE and optionally a python type checker (you might see MyPy or Pyre for this), what Python type that thing is. For example
# no type hint on this variable, the user has to guess what type it is, it might change later on in the code
thing = 'stuff'

# this one has a type hint (the : str bit), which tells the user this thing is a string
# so when you refer to the variable later, you know what kind of data is in it
other_thing: str = 'example'

This is more useful when you have a variable with a more complex type than string of course! We might use it to denote for example that run_job returns something, then you extract a Value out of that response. This might look like
# ... some other stuff
results = api.run_job("import.local.file", inputs=inputs)

# this file_results thing is of type Value
file_result: Value = results["file"]

This helps the person reading the code have an idea what's stored in a variable, and therefore what you can do with it later on, and can also help your text editor (VSCode etc) autocomplete functions on that value later. Here's a quick summary about type hints in case you want to learn more
@CBurge95 I think you might be referring to comments? We should absolutely put comments everywhere!
# this is a comment in python, it starts with a #

@caro401
About the code snippet:
This is exactly what I meant, thank you! And I agree with the conventions you defined in this snippet.
Type hints:
I think you're right in leaving them out of the code for Jupyter notebooks.

I think you might be referring to comments? We should absolutely put comments everywhere!
Yes I definitely was - thank you bearing with me, and for explaining things so clearly to me!! Sorry everyone for clogging this issue with my incompetence. And given my utter (self-inflicted) confusion, I would agree that type hints are good left out of Jupyter notebooks (and coders of that level) - great for developer documentation, less so for newbie users like me.


chore(release): v0.10.0 🎉

:robot: I have created a release beep boop
0.10.0 (2023-09-16)
Features

claims: enable getting authed claims with explicit jwks uri (ef422c7)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/whodisio/simple-jwt-auth/releases/tag/v0.10.0 :sunflower:


Using tab to autocomplete typeahead in watch's pattern mode

Do you want to request a feature or report a bug?
Feature
What is the current behavior?
When typing the path of a test file, Jest suggests possible matches. You can then use the up/down arrow to easily navigate between files, however, when files share a common path (when having a deep folder structure), you need to type the full path to let jest refine the matches. When pressing the tab key, Jest simply adds a tab to the path string.
What is the expected behavior?
I would expect pressing tab to partially complete the pattern, to facilitate typing. For instance, if the files structure looks like:
src
  client
    a.js
    b.js
  server
    b.js

When staring, I would type s then tab, the pattern would be src/. Then c and tab, the pattern would be src/client/, which would let me press the down arrow key only once to reach b.js.
This pattern is really common when using a CLI (ZSH does it out of the box, but I think it's something you'll find almost everywhere). Actually, Jest not supporting this pattern breaks my habit, since it's "natural" for me to do that.
If you feel that this would be a welcomed improvement, I would love to submit a PR.
Edit: One of my concerns, behaviour wise, is what should happen when the user is typing a regex, i.e. not simply a path. However, we might consider that when you're typing a regex, there's no point of hitting tab. But that might still require to be able to differentiate the different cases.

I think this would be nice(cc: @cpojer), but I wonder how the UX would work for it. As you mentioned already we would need to autocomplete the regex and maybe even show the "autocompleted" part in a different color

I'll close this one for now as there is another issue to improve the typeahead UX overall. #2595.


change taxon constraint GO:0101024

GO:0101024 mitotic nuclear membrane organization has the taxon constraint only in metazoa. It should be changed to only in Eukaryota.
There was a lot of back-and-forth in #19950, and I think there was an error in the last comment that meant the taxon constraint didn't get the correct update to match merges and other work on this bit of the ontology.

Actually in #19950 we had changed
GO:0101024 | 'nuclear membrane organization involved in mitotic nuclear division' to 'mitotic nuclear membrane organization'
Changed both taxon constraints
GO:0101024	mitotic nuclear membrane organization NCBITaxon:2759	Eukaryota
GO:0101026	nuclear membrane biogenesis involved in mitotic nuclear division	NCBITaxon:2759	Eukaryota

renamed 'GO:0101026	nuclear membrane biogenesis involved in mitotic nuclear division' -> mitotic nuclear membrane biogenesis

Thanks, Pascale


[Relay][Op] concatenate, reshape, transpose, copy

OP TODO

[x] [level 1] relay.concatenate
[x] [level 3] relay.copy
[x] [level 3] relay.transpose
[x] [level 3] relay.reshape

Misc TODO

[x] Rebase
[x] Check sanity check coverage
[x] Find right file to put these operators
[ ] Re-check docs

Issues & discussion

[x] Numpy consistency: numpy.concatenate accepts axis=None, in which case numpy flattens all input arrays before doing concat, while we do not support axis=None.
[x] Numpy consistency: numpy.reshape is a subset of our reshape. I think it is fine (or even better).
[x] Flexibility: is it okay that transpose directly convert Array<IndexExpr> axes to vector<int>?

Related issue: #1799

It is OK to directly require IndexExpr to be int when they are in array, we can do
#include <tvm/ir_operator.h>

for (size_t i = 0; i < axes.size(); ++i) {
   const int64_t* paxis = as_const_int(axes[i]);
   CHECK(paxis != nullptr);
    ...
}

concatenate: I think it is fine for now to not support axis=None and make clear error to the user
reshape: as long as the numpy part is consistent, it is fine

@tqchen @srkreddy1238 Hey folks could you help review this PR?

@tqchen hey could you help review this again at your convenience? Rebasing many times seems painful to me.

The changes LGTM, let us wait the CI and then merge it in


GenevaERS documentation discussions

This issue will cover the discussions in the GenevaERS project about documentation.

MEETING held Thursday October 15 (USA) and Friday October 16 (Australia).
Ian Cunningham reported that Docker makes install of Postgres a lot easier - just use a docker container for Postgres.
Randall Ness talked about changes to overall Help documentation for GenevaERS.  In the past we had three types of help:

Embedded help inside the workbench for SAFR (the name for GenevaERS inside IBM).
An internal IBM website for SAFR (see Info Center 4.15) that a few select customers could view.
PDF files which are included in the SAFR Website.

Randall said the new Help documentation for GenevaERS would be:

A public website for GenevaERS general documentation (a separate site from genevaers.org).
An IBM internal website(s) for the version of GenevaERS that involves paid support from IBM.  IBM customers purchasing that support can access the IBM internal websites.

Randall noted that previously, the workbench had context sensitive help - if a user pressed F`1 on a screen X then help popped up that was relevant to screen X.  However, this feature is no longer supported by software we are using to generate the workbench embedded help, and would be too costly to do manually, so the embedded help would not longer be available.  Instead, when a user pressed F1 then they would be directed to the GenevaERS General documentation website.
The meeting confirmed that the future direction for help documentation for GenevaERS is markdown files (instead of the older DITA files used by IBM).
Randall also noted that to speed up help documentation for GenevaERS there would not be screen images in the help itself, as this a large task to maintain.  Instead the help documentation would concentrate on the text content needed by users.  Eugene Morrow noted that there would still be images in the help documentation, for example to show screen icons.
Kip Twitchell suggested that the converted DITA help would be marked "Under construction" so that users would know that the help is being improved and is not yet final.
Kip recommended we create an internal folder inside IBM to collect raw materials that can be turned into help documentation.  The raw materials would remain inside IBM as they could have commercial confidential material that must be removed before becoming part of an open source system.

Meeting held Thursday October 21 (USA) and Friday October 22 (Australia)
Randall Ness noted that the meeting agreed that accuracy was more important the completeness for the help documentation.  Users needed to be able to trust what they read, and would understand if areas of help were still under construction.
Meeting agreed to create this issue under repo Github Genevaers doc.  This issue will track the meetings about Genevaers documentation and Eugene Morrow would make these entries.
Meeting agreed that specific documentation issues (for example the high level structure) would each be in a separate issue so that participants can comment and progress that specific issue.    Randall Ness is converting his Word document that has an outline of the high level structure into a markdown document using Visual Studio Code.  This will allow participants to expand and collapse areas of the structure at will.  Meeting agreed this is the way to progress the help documentation in a top-down manner.
Meeting agreed that the "V4" in Randall's current outline can be removed.  Meeting noted that there will be at least two version numbers of GenevaERS at all times - one version is free and open source, and the other version is the one used when customers have paid for IBM support.  The version of the product will distinguish which website users access for the help documentation.
Randall Ness noted how help documentation will need to be assembled from the "free" GenevaERS plus the "supported" GenevaERS, and possibly with extras parts added by customers themselves.  Ian Cunningham and Eugene Morrow both believe this can be done by reusing markdown files that are common to all of these.
Randall Ness will decide if he prefers "User Guide" or "User Manual".  Ian Cunningham suggested that "User Manual" can be the bit documentation component that contains smaller "guides" for specific tasks.
Gillian Hannington recommended a "Sample JCL" folder in the Performance Engine repo so that users can access some miscellaneous JCL that will be needed in various situations of using GenevaERS.
Eugene Morrow said that the best way to documentr the many ways that GenevaERS can be used is to have End-to-End examples.  One example might be using GenevaERS to read from DB2 databases, and the End-to-End Example for this would cover the Workbench config and the JCL required to run the Performance Engine, along with the necessary planning and analysis for this technique.  The GenevaERS documentation will need many such End-to-End Examples.
Ian Cunningham noted that the Workbench involves two major components - the metadata repository and the workbench itself.  It is possible to setup the metadata repository once, but the workbench itself may be upgraded many times while still working with the same metadata repository.


net: go1.5beta1 net tests timeout on OS X 10.10.4, apparently in getaddrinfo

The net package tests time out, apparently in getaddrinfo. This is not affected by having or not having a working internet connection, although even the "working" variant is a bit flaky for me at the moment (airport). Latest OS X (Yosemite 10.10.4), bootstrapping from official 1.4.2 package. Full log in https://gist.github.com/3a22082bc4a809627b41.
jb@syno:/usr/local/go1.5/src $ ./all.bash
...
ok  	mime/multipart	0.138s
ok  	mime/quotedprintable	0.200s
panic: test timed out after 2m0s

goroutine 268 [running]:
testing.startAlarm.func1()
	/usr/local/go1.5/src/testing/testing.go:702 +0x132
created by time.goFunc
	/usr/local/go1.5/src/time/sleep.go:129 +0x3a

goroutine 1 [chan receive]:
testing.RunTests(0x37daf8, 0x46eb60, 0x95, 0x95, 0x2ba601)
	/usr/local/go1.5/src/testing/testing.go:561 +0x8ad
testing.(*M).Run(0xc820061ef8, 0x5725e8)
	/usr/local/go1.5/src/testing/testing.go:493 +0x70
net.TestMain(0xc820061ef8)
	/usr/local/go1.5/src/net/main_test.go:50 +0x2b
main.main()
	net/_test/_testmain.go:396 +0x113

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
	/usr/local/go1.5/src/runtime/asm_amd64.s:1696 +0x1

goroutine 267 [syscall, locked to thread]:
net._C2func_getaddrinfo(0x12001b0, 0x0, 0xc8202d9d10, 0xc820268300, 0x0, 0x0, 0x0)
	??:0 +0x4d
net.cgoLookupIPCNAME(0x307fb0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x37e400)
	/usr/local/go1.5/src/net/cgo_unix.go:111 +0x1ac
net.cgoLookupIP(0x307fb0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x100000002)
	/usr/local/go1.5/src/net/cgo_unix.go:163 +0x56
net.lookupIP(0x307fb0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0)
	/usr/local/go1.5/src/net/lookup_unix.go:67 +0x94
net.glob.func15(0x37e498, 0x307fb0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0)
	/usr/local/go1.5/src/net/hook.go:10 +0x4d
net.lookupIPMerge.func1(0x0, 0x0, 0x0, 0x0)
	/usr/local/go1.5/src/net/lookup.go:68 +0x71
internal/singleflight.(*Group).doCall(0x46fdd0, 0xc8202b6d70, 0x307fb0, 0x4, 0xc820233b98)
	/usr/local/go1.5/src/internal/singleflight/singleflight.go:93 +0x2c
internal/singleflight.(*Group).Do(0x46fdd0, 0x307fb0, 0x4, 0xc820233b98, 0x0, 0x0, 0x0, 0x0, 0x10)
	/usr/local/go1.5/src/internal/singleflight/singleflight.go:63 +0x284
net.lookupIPMerge(0x307fb0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0)
	/usr/local/go1.5/src/net/lookup.go:69 +0x9b
net.LookupIP(0x307fb0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0)
	/usr/local/go1.5/src/net/lookup.go:50 +0x2d2
net.TestLookupWithIP(0xc8202e4bd0)
	/usr/local/go1.5/src/net/ip_test.go:82 +0x2fa
testing.tRunner(0xc8202e4bd0, 0x46f058)
	/usr/local/go1.5/src/testing/testing.go:455 +0x98
created by testing.RunTests
	/usr/local/go1.5/src/testing/testing.go:560 +0x86d
FAIL	net	120.024s
ok  	net/http	5.048s
...
2015/07/11 14:18:14 Failed: exit status 1
jb@syno:/usr/local/go1.5/src $ git describe
fatal: No annotated tags can describe 'b6ead9f171742cd5b519a22ecc690354b0d1ce27'.
However, there were unannotated tags: try --tags.
[128]
jb@syno:/usr/local/go1.5/src $ git describe --tags
go1.5beta1
jb@syno:/usr/local/go1.5/src $ uname -a
Darwin syno 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64
jb@syno:/usr/local/go1.5/src $

(should go1.5beta1 maybe have been an annotated tag?)

CC @bradfitz @mdempsky @mikioh

I can't reproduce. I'm using the same OS X version.
Do you have any antivirus or firewall software running? Or VPN? Somehow your DNS requests are taking a different turn inside libc/kernel.

No weird stuff (OS X firewall turned off, no VPN, no odd apps to track internet usage). However I do have a slightly unusual DNS setup; I have an /etc/resolver/<internal-company-domain> with a search path and an internal DNS server in it, that is not reachable unless I'm on the required network. This does mean unqualified names that don't actually exist in any of the earlier search paths get tried in that direction, and that takes a long time since the DNS server in question is not reachable.
I get a lot of this in tcpdump when running the test in question:
...
13:08:33.797045 IP <IP_ADDRESS>.65352 > <IP_ADDRESS>.53: 40700+ A? abc.<internal-company-domain>. (34)
13:08:33.797045 IP <IP_ADDRESS>.56815 > <IP_ADDRESS>.53: 11779+ AAAA? abc.<internal-company-domain>. (34)
13:08:50.590418 IP <IP_ADDRESS>.64323 > <IP_ADDRESS>.53: 51924+ A? 123:.<internal-company-domain>. (35)
13:08:50.590484 IP <IP_ADDRESS>.56580 > <IP_ADDRESS>.53: 8017+ AAAA? 123:.<internal-company-domain>. (35)
...

Those never get an answer. Perhaps timeout of resolving unqualified names should not really be a test failure?


Can't set assistant / supported units

Hi, When I try to set my assistant in the profile no operators / options appear. I'm assuming something is supposed to render but doesn't.

Following up on this, the console shows 1 logged error.
A 404 on https://www.krooster.com/_vercel/insights/script.js


When I try to initialize Foundation plugins in a Meteor.js app my app breaks

I am creating a Meteor app with Foundation. I am trying to initialize Foundation plugins globally on my main layout template, but whenever I add the onRendered() function block to my template helper my app disappears in the browser (i.e., the screen goes completely white). When I take the onRendered() block out, then my app reappears, but the Foundation plugins (e.g., tabs, accordions) don't work.
This is the code in my main layout template:
<template name="app-body">
  <body>
    {{> header}}
    {{> Template.dynamic template=content}}
    {{> footer}}
  </body>
</template>

This is the code in my template helper file:
import { Template } from 'meteor/templating';
import './app-body.html';

Template.app-body.onRendered(function () {
  $(document).foundation();
});

Any help you can offer would be greatly appreciated.
Thank you!

I don't know much about Meteor (in terms of pre-compiling features), but as far as I know Template.app-body is not valid JavaScript. Have you tried Template['app-body']?
Otherwise, what happens if you put a simple console.log() into the callback and don't initialize Foundation there?

Thank you Owlbertz. I was able to figure out what the problem was based on your comment. I found out that I was using the wrong naming convention for my Meteor templates. I was using a hyphen to separate the words in the template name (e.g., app-body), but I should have been using either camelCase (e.g., appBody) or underscores (e.g., app_body) to separate words within template names. When I made that name change across my app, Foundation worked again. Thank you so much for your help, Owlbertz!


Server timings reported in seconds instead of milliseconds?

I'd love to open a PR, but I have no idea if this is actually a problem or if I have some weird Chrome setup? So I can see server timings added to the headers properly:

But when I switch to the Timing tab to see the results, it looks like Chrome is interpreting the numbers as seconds:

The db line (reported as 32.9ms in the header) is transformed into 32.9 seconds in the report, same with view (230 seconds is 3.8 minutes). Maybe Chrome requires a unit after the time?
I'm running Chrome 56 and Rails 5.0.2.

hmm, the spec doesn't actually specify units... but it seems like the browser is expecting seconds

Just published v1.0.2 with a fix for this. Let me know if you're still seeing weird timings :)

I've got the opposite issue. The server returns a value in seconds, i.e. Server-Timing:view=0.322, db=0.018, total=0.350, but the browser interprets this as ms.
I'm running Chrome 59.0.3063.4 dev (64-bit) on my mac.

Yeah, apparently the spec does say it's supposed to be milliseconds, and Chrome fixed their bug in version 58. I've got a commit on master that tests the Chrome version (ugh) and returns seconds or milliseconds. I'll make a new release later today.

Released as 1.0.4 :)


Category group deletion

On deleting the parent category all the child category and its references under it should be removed.

Hello @cms-coder , Thank you for raising the issue.

We worked upon deleting the child categories linked to the parent.On deleting the parent all the linked child categories were removed.

Yeah..its working fine now


Rename field while serializing ?

Hi,
Given the following struct
#[derive(rkyv::Archive, rkyv::Serialize, rkyv::Deserialize)
struct A{
#[rename_to="my_field0"]
 field0 : u32,
#[rename_to="my_field1"]
 field1: u32
}

Is it possible to rename the field while serializing and get the original name once deserialized ?
Like Serde does
It's useful to hide some struct logic to the world, when sending the data in conjunction with Skip. You don't have to create a "networkable" separate struct by hand.
Thanks!

rkyv's wire format doesn't include the field names themselves, so this would just be a rename for the fields of the archived type. Can you provide a more complete example of how this is useful with Skip?

Ah! yes, if the names are not included in any way then it's fine as is, I can keep using Skip.
Sorry for the inconvenience!
Thank you,
Closing


Limit opencv-python version

Motivation
The latest opencv-python causes error in CI. This PR limits the version of it.
Modification
Modify requirements/runtime.txt

Lint failed

Lint failed

It passed now, but some CIs still failed. Could you help have a look?


error message on installation

I'm getting this error after using install command

/usr/bin/npm pack jupyterlab_voyager
jupyterlab_voyager-0.1.0.tgz

Errored, use --debug for full output:
TypeError: the JSON object must be str, not 'bytes'

Looks like it's some error with the JSON converting in this old version, we are wroking on a new version and will have a update soon.
Meanwhile, if you want a try, you can use the test version published on npm:
after install jupyterlab, use this command:
jupyter labextension install jupyterlab_voyager_test
if installed correctly, you can then open csv, json, tsv file ,or notebook charts in Voyager through context menu.
NOTE: you can't have both jupyterlab_voyager_test and jupyterlab_voyager installed at the same time, can only have one at a time

I tried
jupyter labextension install jupyterlab_voyager_test
but I now get this error
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

@cchorn - https://github.com/jupyterlab/jupyterlab/issues/4325#issuecomment-382173439

Thanks @zzhangjii, I have been waiting for this extension to work with the latest Jupyter Lab and I got it to work with:
jupyter labextension install jupyterlab_voyager_test
The install kept freezing but I fixed it by running the following command first:
conda install nodejs

For the memory building error:

export NODE_OPTIONS=--max-old-space-size=16000 or just add
NODE_OPTIONS=--max-old-space-size=16000 env variable when
running jupyter
lab build

Ji, can you add this to the README?
On Mon, Jun 4, 2018 at 6:06 AM, Ryan Rusha-Conto<EMAIL_ADDRESS>wrote:

Thanks @zzhangjii https://github.com/zzhangjii, I have been waiting for
this extension to work with the latest Jupyter Lab and I got it to work
with:
jupyter labextension install jupyterlab_voyager_test
The install kept freezing but I fixed it by running the following command
first:
conda install nodejs
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/altair-viz/jupyterlab_voyager/issues/47#issuecomment-394347594,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0AKUnklfpRvr73Hy46S7Nsp9S9btks5t5TDCgaJpZM4UYEMm
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

Thanks for all the help! I will update the solutions in README!

Thank you.
export NODE_OPTIONS=--max-old-space-size=16000
then
jupyter labextension install jupyterlab_voyager_test
also works inside a Docker container