Use official KZG ceremony output trusted setups

This PR changed our testing_trusted_setups.json to the official KZG ceremony output trusted setups. Two files in trusted_setups folder:

trusted_setup_4096.json is from https://github.com/CarlBeek/kzg-ceremony-verifier/blob/master/output_setups/trusted_setup_4096.json

g1_lagrange: KZG_SETUP_LAGRANGE
g2_monomial:  KZG_SETUP_G2
file sha256 checksum: 0229b43f4fac9b17374809520eb621b5ee1a7f74547e7d36918e7d4b122e178d

trusted_setup_4096_roots_of_unity.json contains the roots of unity that pyspec needs for polynomial-commitments.md. Client teams don't need it if the KZG libraries compute it.

roots_of_unity: ROOTS_OF_UNITY

This PR is currently based on the #3255 proposal.

Regarding the roots of unity, @hwwhww mentions that "Client teams don't need it if the KZG libraries compute it."
My understanding is that none of the KZG libraries are planning on loading in these points manually. (C-KZG is planning on calculating them too now.) It takes longer to parse the JSON and load in the $\mathbb{F}_q$ elements than it does to just calculate them. I think we should just specify the primary root and leave it at that.

Yes, agreed. I think it would be best to have a method in the spec for this. Something like:
PRIMITIVE_ROOT = 7

def get_roots_of_unity() -> List[int]:
    """
    Return roots of unity of order ``FIELD_ELEMENTS_PER_BLOB``.
    """
    assert (BLS_MODULUS - 1) % FIELD_ELEMENTS_PER_BLOB == 0
    root_of_unity = pow(PRIMITIVE_ROOT, (BLS_MODULUS - 1) // FIELD_ELEMENTS_PER_BLOB, BLS_MODULUS)
    return compute_powers(root_of_unity, FIELD_ELEMENTS_PER_BLOB)

@jtraglia @CarlBeek  thanks for the reviews!
1. For executable pyspec
For pyspec, ROOTS_OF_UNITY will be defined in the executable file mainnet.py. It seems the two approaches (loading json file v.s. runtime compile) have similar speeds in pyspec. Also, pyspec can add an LRU cache of it. I'm fine with either way.
2. roots_of_unity implementation:
@jtraglia thank you for the pseudo code. :)
@dankrad once implemented def roots_of_unity(order: uint64) -> List[BLSFieldElement] helper in
https://github.com/ethereum/consensus-specs/blob/dev/specs/_features/sharding/polynomial-commitments.md#roots_of_unity
The difference is that this helper is also used in low_degree_check helper with difference order argument values. I suppose it's good to make such helpers more compatible by having the parameter order: uint64?
def compute_roots_of_unity(order: uint64) -> Sequence[BLSFieldElement]:
    """
    Return roots of unity of ``order``.
    """
    PRIMITIVE_ROOT = 7
    assert (BLS_MODULUS - 1) % int(order) == 0
    root_of_unity = pow(PRIMITIVE_ROOT, (BLS_MODULUS - 1) // int(order), BLS_MODULUS)
    return compute_powers(root_of_unity, order)

/cc @asn-d6

Moreover, if clients don't need to download trusted_setup_4096.json from test vectors repo, we can move presets/[minimal, mainnet]/trusted_setups to presets/trusted_setups

@jtraglia @CarlBeek thanks for the reviews!
1. For executable pyspec
For pyspec, ROOTS_OF_UNITY will be defined in the executable file mainnet.py. It seems the two approaches (loading json file v.s. runtime compile) have similar speeds in pyspec. Also, pyspec can add an LRU cache of it. I'm fine with either way.
2. roots_of_unity implementation:
@jtraglia thank you for the pseudo code. :)
@dankrad once implemented def roots_of_unity(order: uint64) -> List[BLSFieldElement] helper in https://github.com/ethereum/consensus-specs/blob/dev/specs/_features/sharding/polynomial-commitments.md#roots_of_unity
The difference is that this helper is also used in low_degree_check helper with difference order argument values. I suppose it's good to make such helpers more compatible by having the parameter order: uint64?
def compute_roots_of_unity(order: uint64) -> Sequence[BLSFieldElement]:
    """
    Return roots of unity of ``order``.
    """
    PRIMITIVE_ROOT = 7
    assert (BLS_MODULUS - 1) % int(order) == 0
    root_of_unity = pow(PRIMITIVE_ROOT, (BLS_MODULUS - 1) // int(order), BLS_MODULUS)
    return compute_powers(root_of_unity, order)

/cc @asn-d6

Hey. That code looks good to me. No strong opinion on whether the func should be generic (to also work with sharding) or more specific (for simplicity atm), but both functions look good to me and I cross-checked that they generate the same list.

I think it might make sense to go with the flexible roots of unity implementation. Since we are now looking into implementing some form of DAS much sooner, we will need it anyway so the very minor complication won't hurt.

(Also, I noticed that the spec is currently under-defined in this respect: While the group of roots of unity with a certain order is unique, the order is not. So we do really need to include the function to compute the actual list for it to be complete)

My understanding is that none of the KZG libraries are planning on loading in these points manually. (C-KZG is planning on calculating them too now.) It takes longer to parse the JSON and load in the
elements than it does to just calculate them. I think we should just specify the primary root and leave it at that.

By the way, I did a survey a couple months ago to assess if there was interest in creating an efficient serialization format for trusted setups:

spec (unmodified with feedback): https://github.com/mratsim/constantine/blob/master/constantine/trusted_setups/README.md
feedback: https://github.com/mratsim/constantine/issues/256

The .json format will need to be changed to another format for C as parsing json from C is problematic from a security point-of-view.

The kzg-4844 test vector tarball: kzg.tar.gz

These reference tests pass with the official trusted setup (converted to c-kzg's format) 👍

not sure if it's too late to change but would it be possible to not use the "trusted setup" terminology? comes with more baggage from a time when all setup participants could be counted on two hands =)
maybe something like "kzg_setup" might be better?

Hi @tvanepps
Our team had a discussion about this topic yesterday.
The specs use trusted_setups as the folder name because they are defined in the "Trusted setup" section in polynomial-commitments.md. If we do want to sync all the names that include trusted_setup_4096.json file name, I'd say @CarlBeek's upstream https://github.com/CarlBeek/kzg-ceremony-verifier/blob/master/output_setups/trusted_setup_4096.json should be renamed since we copied it from upstream and it's better to make it clear they are identical files.
IIRC client software and KZG libraries have provided --trusted-setup-file flag. I agree with @dankrad that trusted setup is already a common technical term. Therefore, it may not be worth actively "replacing" them. For the specs, I'm fine with syncing the folder/file/presets naming, but it's better to add some more info in polynomial-commitments.md as I suggested in https://github.com/ethereum/consensus-specs/pull/3521#discussion_r1362394056.
I'm going to merge this PR for testgen now, but a post-merge (or post this release) clean-up PR is welcome. :)


missing --pre option

Sometimes we may want to upgrade with all pre-releases, so we can find out what future release may break us. At this moment this is not possible.

Hi,
What behaviour are you looking for? It would be easy to have it apply to all packages, but somewhat more difficult if you only want this for a subset.
A


python3Packages.ortools cannot be found in PYTHONPATH

Describe the bug
The Nixpkgs manual contains a section explaining how to use a virtualenv with Python packages from nixpkgs. This method doesn’t work with python3Packages.ortools.
To Reproduce
Create a shell.nix file with the following contents (this is copied directly from the manual):
let
  pkgs = import (builtins.fetchGit {
    url = "https://github.com/NixOS/nixpkgs";
    ref = "release-21.05";
    rev = "dbfaab83a8b0ed29d54fd50b187ebd551f58aa26";
  }) { };
  pythonPackages = pkgs.python37Packages;
in pkgs.mkShell {
  name = "impurePythonEnv";
  buildInputs = [
    pythonPackages.python
    pythonPackages.venvShellHook
    pythonPackages.ortools
  ];
  venvDir = "./.venv";
  postVenvCreation = ''
    unset SOURCE_DATE_EPOCH
  '';

  postShellHook = ''
    unset SOURCE_DATE_EPOCH
  '';
}

Running nix-shell --run "python -c 'import ortools'" results in ModuleNotFoundError: No module named 'ortools'.
Expected behavior
The module should be found.
Additional context
Checking the PYTHONPATH environment variable shows that the or-tools package is installed:
$ echo $PYTHONPATH
/nix/store/jbysjlvvh9cnvs8d8ls1x2y11q8pjjqh-python3-3.7.10/lib/python3.7/site-packages:/nix/store/7pslh3gg07wz495vv5cfldv9dmq0k8dq-or-tools-9.0-python/lib/python3.7/site-packages

However the directory contains an additional level that prevents Python from finding the module:
$ ls -l /nix/store/7pslh3gg07wz495vv5cfldv9dmq0k8dq-or-tools-9.0-python/lib/python3.7/site-packages
total 8
-r--r--r-- 1 root root   42 Jan  1  1970 easy-install.pth
dr-xr-xr-x 4 root root 4096 Jan  1  1970 ortools-9.0.9999-py3.7-linux-x86_64.egg

Adding the following hack to postShellHook fixes it:
postShellHook = ''
    ...
    export PYTHONPATH=$PYTHONPATH:${pythonPackages.ortools}/lib/${pythonPackages.python.libPrefix}/site-packages/ortools-9.0.9999-py3.7-linux-x86_64.egg
'';

Also the following works, but it cannot be used in conjunction with a virtualenv:
$ nix-shell -E "let pkgs = import <nixpkgs> {}; in (pkgs.python3.withPackages (ps: [ ps.ortools ])).env" --run "python -c 'import ortools'"

I have no idea how eggs work in Python so I can’t really say how this problem should be fixed. But I guess the PYTHONPATH should be fixed to expose the ortools module.
Notify maintainers
@andersk
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.10.37, NixOS, 21.05.1075.246502ae2d5 (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.12`
 - channels(sephi): `"home-manager-21.05"`
 - channels(root): `"nixos-21.05.1075.246502ae2d5, nixos-hardware, nixos-unstable-21.11pre295280.fa0326ce523, taxi"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

This was fixed. Likely by #194337


Improve API handler builder

It is quite easy to mess up the API pathing and build.
I think we should create an "API builder" this will construct the API with prams passed

agreed 👍


feat/refactor: Blueprint config structure and parsing

This PR changes how the blueprint config is stored in Studios and ShowStyles. Instead of an array of _id-value pairs, an object with string index will be used.
Additionally, optional parseConfig blueprint callbacks are added to StudioBlueprintManifest and ShowStyleBlueprintManifest. They will be called by Core only when the config changes, in order to let the blueprints process it e.g. by performing calculations and adding data. This will prevent repeating the same processing during other actions. Core will cache the processed configs and return them with context's getStudioConfig and getShowStyleConfig methods. If parseConfig is not provided, context will return unprocessed configs.

Just had a thought. Should preprocessConfig have a context so that it can log some debug/warning/errors?
I feel like it should. And later on we should look into getting the output shown to the user in the page where they will edit the config


Rename event-locations.md to event-location-equity.md and edit

Signed-off-by: Kevin Lumbard<EMAIL_ADDRESS>Event locations is being re-released as event location equity.

I'm going to close this because I think this will get resolved with the current work to update all the metrics to the new template. Thanks @klumb!


[Input] CSS: Missing right border when with action and error or focus classes

I'm not sure if that's the desired behavior, but if you check the JSFiddle you see that when you focus the input you get the right border. If you blur inputs with classes error or focus the border is gone...
I'm using Chrome 60.0.3112.90 on a macOS Sierra 10.12.6

Fixed: See https://jsfiddle.net/o0c6mk6u/2/

Will be part of Fomantic-UI 2.7.2

It's 2024 and I have the same issue, disappointing, not sure how to fix it.


[5316] Bulk recommend -  dynamic QTS or EYTS

Context
https://trello.com/c/eRBHiwlB/5316-s-dynamically-say-whether-the-user-is-recommending-trainees-for-qts-or-eyts
Changes proposed in this pull request

Add helper that takes a collection of rows and returns QTS if all QTS
EYTS if all EYTS, QTS or EYTS if mixture
Add model methods qts? and eyts to recommendations_upload_row
that returns true if the associated trainee is working towards QTS/EYTS respectively
Use helper in views (screenshots below)

Also:

Remove scope which wasn't being used anywhere

Guidance to review
Summary page bullets:

Summary page all errors:

Fix errors page:

Check page:

Confirmation page:

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?~
[ ] ~Do we need to send any updates to DQT as part of the work in this PR?~
[ ] ~Does this PR need an ADR?~

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

@johndoates the content here feels a bit weird to me. 'You need to review the errors before you can recommend for QTS', but then we talk about recommending a trainee for EYTS on the last line. Should this be changed to 'QTS or EYTS'? Feels quite complex.

Is this missing a full stop @johndoates

 Is this missing a full stop @johndoates

Yes. There should be a full stop after "their details".

@johndoates following our discussions, updated summary page:


Address fields should be dynamically generated

Address fields are gotten from the backend through global properties and we cannot know at compile time which fields are available. In https://github.com/openmrs/openmrs-esm-patient-registration/pull/33, support for address template was added and this does not count on the definition of FormValues. This is a clean up PR for instances where address fields were still hardcoded.

Btw, is this backward compatible for cases where an Address template wasn't configured or used? I didn't look much.

@samuelmale Yes. The registration form will display the default address fields if there's no address template configured. But that work was not done in this PR. You can see that here https://github.com/openmrs/openmrs-esm-patient-registration/pull/33

@FlorianRappl I've resolved the merge conflicts but after pulling from master, form validation is now broken. @samuelmale proposes a fix here https://github.com/openmrs/openmrs-esm-patient-registration/pull/44.
Right now I'm not really sure what is causing the problem. Logging the validationSchema at the point where the form is rendered shows that the validation object was created fine as I can see my configured validations but on the form it's just not working anymore.

@FlorianRappl Validation of the address fields is working fine. The only reason I thought it wasn't working was because seems someone changed the regex at the backend so I was submitting a valid value according to the regex that was configured. Had to go and check what was configured at the back. So this is unrelated to the problem Samuel is working on and this is ready for merge. Thanks for the reviews.


Add support for Telemetry feature

This enables shipping telemtry data ( chaos + OCP metadata ) and prometheus dump to a centralized location: https://github.com/redhat-chaos/krkn/pull/435.

Depends on https://github.com/redhat-chaos/krkn/pull/435.


chore: cherry pick flakiness fix

Overview

Now that this function, apparently, reduces flakiness a lot (I haven't seen any on orchestrator-relayer repo). I guess we can put it in the start node cleanup so that users won't have to worry about it.
Checklist

[ ] New and updated code has appropriate documentation
[ ] New and updated code has new and/or updated testing
[ ] Required CI checks are passing
[ ] Visual proof for any user facing features like CLI or documentation updates
[ ] Linked issues closed with keywords

Overview

Checklist

[ ] New and updated code has appropriate documentation
[ ] New and updated code has new and/or updated testing
[ ] Required CI checks are passing
[ ] Visual proof for any user facing features like CLI or documentation updates
[ ] Linked issues closed with keywords

Codecov Report

:exclamation: No coverage uploaded for pull request base (v0.12.x@2abbfd6). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             v0.12.x    #1429   +/-   ##
==========================================
  Coverage           ?   48.34%
==========================================
  Files              ?       79
  Lines              ?     4433
  Branches           ?        0
==========================================
  Hits               ?     2143
  Misses             ?     2109
  Partials           ?      181

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


NI Deviation requiring testing.TB interface reference update.

Followup changes based on - https://github.com/openconfig/featureprofiles/pull/939#discussion_r1062924708
"This code is a Contribution to the OpenConfig Feature Profiles project ("Work") made under the Google Software Grant and Corporate Contributor License Agreement ("CLA") and governed by the Apache License 2.0. No other rights or licenses in or to any of Nokia's intellectual property are granted for any other purpose. This code is provided on an "as is" basis without any warranties of any kind."

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 46.471%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
586

Relevant Lines:
1261

💛  - Coveralls

@liulk I'm not familiar with our choice of T and TB, maybe you can help offer some opinions?
BTW: the usage of the deviation is approved and Quattro team is ok with it.

To provide some rationale: *testing.T can be converted to a testing.TB but not vice versa, so helpers in a shared package should only accept testing.TB. This is to avoid having large scale changes like this PR.

Can we change fptest.AssignToNetworkInstance to just take testing.TB, not *testing.T? Also if not already, make sure it calls t.Helper() the first thing.

Updated deviation as per comment. Restored testing.TB argument in session.go and setup_test.go as before.
I understand, these changes would be applicable to fptest.SetPortSpeed deviation also. Will update it in separate PR.

@liulk Does this look fine ? Will raise a PR with similar changes for fptest.SetPortSpeed based on it.

The deviation usage is LGTMed, waiting for @liulk to LGTM the TB changes.

/gcbrun


metricRelabelings doesn't work as expected

What did you do?
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: istio-ingressgateway-remote
  namespace: istio-system
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway-remote
  endpoints:
    - port: metrics
      path: /stats/prometheus
      metricRelabelings:
      - action: drop
        regex: '^unknown(.*)'
        sourceLabels: [destination_service]

What I'm try to do is dropping those metrics from istio which have destination_service="unkonwn", but after I apply those configs and make sure they already available via prometheus console, check below prometheus configs snippets
What did you expect to see?
What I expect is after I restart istio pod, and simulate some 404 requests ,there should be no related metrics (eg istio_requests_total)scraped by promtheus .
What did you see instead? Under which circumstances?
I can still see metrics with label destination_service="unknown" scraped
System information
No response
Prometheus version
app.kubernetes.io/version=2.32.1

Prometheus configuration file
- job_name: serviceMonitor/istio-system/istio-ingressgateway-remote/0
  honor_timestamps: true
  scrape_interval: 30s
  scrape_timeout: 10s
  metrics_path: /stats/prometheus
  scheme: http
  follow_redirects: true
  relabel_configs:
  - source_labels: [job]
    separator: ;
    regex: (.*)
    target_label: __tmp_prometheus_job_name
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_service_label_app, __meta_kubernetes_service_labelpresent_app]
    separator: ;
    regex: (istio-ingressgateway-remote);true
    replacement: $1
    action: keep
  - source_labels: [__meta_kubernetes_endpoint_port_name]
    separator: ;
    regex: metrics
    replacement: $1
    action: keep
  - source_labels: [__meta_kubernetes_endpoint_address_target_kind, __meta_kubernetes_endpoint_address_target_name]
    separator: ;
    regex: Node;(.*)
    target_label: node
    replacement: ${1}
    action: replace
  - source_labels: [__meta_kubernetes_endpoint_address_target_kind, __meta_kubernetes_endpoint_address_target_name]
    separator: ;
    regex: Pod;(.*)
    target_label: pod
    replacement: ${1}
    action: replace
  - source_labels: [__meta_kubernetes_namespace]
    separator: ;
    regex: (.*)
    target_label: namespace
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_service_name]
    separator: ;
    regex: (.*)
    target_label: service
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_pod_name]
    separator: ;
    regex: (.*)
    target_label: pod
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_pod_container_name]
    separator: ;
    regex: (.*)
    target_label: container
    replacement: $1
    action: replace
  - source_labels: [__meta_kubernetes_service_name]
    separator: ;
    regex: (.*)
    target_label: job
    replacement: ${1}
    action: replace
  - separator: ;
    regex: (.*)
    target_label: endpoint
    replacement: metrics
    action: replace
  - source_labels: [__address__]
    separator: ;
    regex: (.*)
    modulus: 1
    target_label: __tmp_hash
    replacement: $1
    action: hashmod
  - source_labels: [__tmp_hash]
    separator: ;
    regex: "0"
    replacement: $1
    action: keep
  metric_relabel_configs:
  - source_labels: [destination_service]
    separator: ;
    regex: ^unknown(.*)
    replacement: $1
    action: drop
  kubernetes_sd_configs:
  - role: endpoints
    kubeconfig_file: ""
    follow_redirects: true
    namespaces:
      names:
      - istio-system

### Alertmanager version

_No response_

### Alertmanager configuration file

_No response_

### Logs

_No response_

Thanks for your report. It looks as if this is actually a question about usage and not development.
It makes more sense to ask questions like this on the prometheus-users mailing list or our forums rather than in a GitHub issue. In our community channels, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.


failure to install v8-debug

First of all,i install node-inspector by command "npm install -g node-inpsector --unsafe-perm" on Ubuntu 14.04LTS 32bit,and then it is successful.
Then i access http://<IP_ADDRESS>:8080/?port=5858,show "Can not find module $NPM_HOME/lib/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.7.3/node-v47-linux-ia32/debug.node"on the console.
Below is error info on the period of installation
@3y3 can you help me? thanks so much.
npm install -g v8-debug
npm ERR! Linux 3.19.0-25-generic
npm ERR! argv "/usr/node-v5.6.0-linux-x86/bin/node" "/usr/node-v5.6.0-linux-x86/bin/npm" "install" "v8-debug"
npm ERR! node v5.6.0
npm ERR! npm  v3.6.0
npm ERR! Cannot read property 'target' of null
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     https://github.com/npm/npm/issues
npm ERR! Please include the following file with any support request:
npm ERR!     /usr/npm-global/lib/node_modules/node-inspector/npm-debug.log
root@ubuntu:/usr/npm-global/lib/node_modules/node-inspector# npm install v8-debug -g
npm WARN lifecycle<EMAIL_ADDRESS>cannot run in wd %s %s (wd=%s<EMAIL_ADDRESS>node -e 'process.exit(0)' /usr/npm-global/lib/node_modules/.staging/v8-debug-858816f5

<EMAIL_ADDRESS>install /usr/npm-global/lib/node_modules/v8-debug
node-pre-gyp install --fallback-to-build

gyp WARN EACCES user "root" does not have permission to access the dev dir "/root/.node-gyp/5.6.0"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/npm-global/lib/node_modules/v8-debug/.node-gyp"
make: Entering directory /usr/npm-global/lib/node_modules/v8-debug/build' make: *** No rule to make target../.node-gyp/5.6.0/include/node/common.gypi', needed by Makefile'.  Stop. make: Leaving directory/usr/npm-global/lib/node_modules/v8-debug/build'
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/node-v5.6.0-linux-x86/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:100:13)
gyp ERR! stack     at ChildProcess.emit (events.js:185:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)
gyp ERR! System Linux 3.19.0-25-generic
gyp ERR! command "/usr/node-v5.6.0-linux-x86/bin/node" "/usr/node-v5.6.0-linux-x86/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "build" "--fallback-to-build" "--module=/usr/npm-global/lib/node_modules/v8-debug/build/debug/v0.7.3/node-v47-linux-ia32/debug.node" "--module_name=debug" "--module_path=/usr/npm-global/lib/node_modules/v8-debug/build/debug/v0.7.3/node-v47-linux-ia32"
gyp ERR! cwd /usr/npm-global/lib/node_modules/v8-debug
gyp ERR! node -v v5.6.0
gyp ERR! node-gyp -v v3.2.1
gyp ERR! not ok
node-pre-gyp ERR! build error
node-pre-gyp ERR! stack Error: Failed to execute '/usr/node-v5.6.0-linux-x86/bin/node /usr/node-v5.6.0-linux-x86/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js build --fallback-to-build --module=/usr/npm-global/lib/node_modules/v8-debug/build/debug/v0.7.3/node-v47-linux-ia32/debug.node --module_name=debug --module_path=/usr/npm-global/lib/node_modules/v8-debug/build/debug/v0.7.3/node-v47-linux-ia32' (1)
node-pre-gyp ERR! stack     at ChildProcess. (/usr/npm-global/lib/node_modules/v8-debug/node_modules/node-pre-gyp/lib/util/compile.js:83:29)
node-pre-gyp ERR! stack     at emitTwo (events.js:100:13)
node-pre-gyp ERR! stack     at ChildProcess.emit (events.js:185:7)
node-pre-gyp ERR! stack     at maybeClose (internal/child_process.js:827:16)
node-pre-gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
node-pre-gyp ERR! System Linux 3.19.0-25-generic
node-pre-gyp ERR! command "/usr/node-v5.6.0-linux-x86/bin/node" "/usr/npm-global/lib/node_modules/v8-debug/node_modules/.bin/node-pre-gyp" "install" "--fallback-to-build"
node-pre-gyp ERR! cwd /usr/npm-global/lib/node_modules/v8-debug
node-pre-gyp ERR! node -v v5.6.0
node-pre-gyp ERR! node-pre-gyp -v v0.6.27
node-pre-gyp ERR! not ok
Failed to execute '/usr/node-v5.6.0-linux-x86/bin/node /usr/node-v5.6.0-linux-x86/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js build --fallback-to-build --module=/usr/npm-global/lib/node_modules/v8-debug/build/debug/v0.7.3/node-v47-linux-ia32/debug.node --module_name=debug --module_path=/usr/npm-global/lib/node_modules/v8-debug/build/debug/v0.7.3/node-v47-linux-ia32' (1)
npm ERR! Linux 3.19.0-25-generic
npm ERR! argv "/usr/node-v5.6.0-linux-x86/bin/node" "/usr/node-v5.6.0-linux-x86/bin/npm" "install" "v8-debug" "-g"
npm ERR! node v5.6.0
npm ERR! npm  v3.6.0
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: node-pre-gyp install --fallback-to-build
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-pre-gyp install --fallback-to-build'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the v8-debug package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs v8-debug
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls v8-debug
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /usr/npm-global/lib/node_modules/node-inspector/npm-debug.log
root@ubuntu:/usr/npm-global/lib/node_modules/node-inspector# node-inspector
Node Inspector v0.12.8
Visit http://<IP_ADDRESS>:8080/?port=5858 to start debugging.

i have the same issue. Any ideas to fix?

Hm. I see that you use ia32 linux architecture. Unfortunately we don't have prebuilt binaries for ia32 on linux. In this situation node-gyp tries to compile binary for you.
Maybe you don't have required dependencies for build. For linux I use gcc v4.7.2

Getting this on Mac OSX 10.8
v0.12.6-8
Node 5.10.1

Having install issue on Mac OSX 10.9.5
npm ERR<EMAIL_ADDRESS>preinstall: node -e 'process.exit(0)'
npm ERR! spawn sh ENOENT
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>preinstall script 'node -e 'process.exit(0)''.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the v8-debug package,
npm ERR! not with npm itself.
node -v
v6.1.0
npm --ve
3.8.6

Install issues on OSX 10.11.4
npm ERR<EMAIL_ADDRESS>preinstall: node -e 'process.exit(0)'
npm ERR! spawn sh ENOENT
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>preinstall script 'node -e 'process.exit(0)''.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the v8-debug package,
npm ERR! not with npm itself.
node -v
6.0.0
npm -v
3.8.6

Same on Ubuntu 16.04 using node v6.1.0 installed via nvm if it isn't obvious from the below (it is).
$ npm install -g node-inspector

><EMAIL_ADDRESS>preinstall /home/alan/.nvm/versions/node/v6.1.0/lib/node_modules/.staging/v8-profiler-7890d715
> npm install node-pre-gyp

/home/alan/.nvm/versions/node/v6.1.0/bin/node-pre-gyp -> /home/alan/.nvm/versions/node/v6.1.0/lib/node_modules/node-pre-gyp/bin/node-pre-gyp
/home/alan/.nvm/versions/node/v6.1.0/lib
└──<EMAIL_ADDRESS>

><EMAIL_ADDRESS>preinstall /home/alan/.nvm/versions/node/v6.1.0/lib/node_modules/.staging/v8-debug-b0ae679d
> node -e 'process.exit(0)'

/home/alan/.nvm/versions/node/v6.1.0/lib
└── (empty)

npm ERR! Linux 4.4.0-22-generic
npm ERR! argv "/home/alan/.nvm/versions/node/v6.1.0/bin/node" "/home/alan/.nvm/versions/node/v6.1.0/bin/npm" "install" "-g" "node-inspector"
npm ERR! node v6.1.0
npm ERR! npm  v3.8.6
npm ERR! file sh
npm ERR! path sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn sh

npm ERR<EMAIL_ADDRESS>preinstall: `node -e 'process.exit(0)'`
npm ERR! spawn sh ENOENT
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>preinstall script 'node -e 'process.exit(0)''.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the v8-debug package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node -e 'process.exit(0)'
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs v8-debug
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls v8-debug
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/alan/longhorn/npm-debug.log
npm ERR! code 1

Install issues on OSX 10.11.3
node -v 6.1.0
npm -v  3.8.6
npm ERR<EMAIL_ADDRESS>preinstall: `node -e 'process.exit(0)'`
npm ERR! spawn sh ENOENT
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>preinstall script 'node -e 'process.exit(0)''.

Getting the same issue since 0.7.7. Error occurs installing node-inspector which uses
"v8-debug": "~0.7.1",
Environment is centos:6.6 (docker image):
><EMAIL_ADDRESS>preinstall /usr/local/lib/node_modules/node-inspector/node_modules/v8-profiler
> npm install node-pre-gyp
npm ERR! Linux 3.19.0-30-generic
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "node-pre-gyp"
npm ERR! node v0.12.13
npm ERR! npm  v2.15.0
npm ERR! path /root/.npm/node-pre-gyp
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! Error: EACCES, mkdir '/root/.npm/node-pre-gyp'
npm ERR!     at Error (native)
npm ERR!  { [Error: EACCES, mkdir '/root/.npm/node-pre-gyp'] errno: -13, code: 'EACCES', path: '/root/.npm/node-pre-gyp' }
npm ERR!
npm ERR! Please try running this command again as root/Administrator.
npm ERR! Please include the following file with any support request:
npm ERR!     /usr/local/lib/node_modules/node-inspector/node_modules/v8-profiler/npm-debug.log
><EMAIL_ADDRESS>preinstall /usr/local/lib/node_modules/node-inspector/node_modules/v8-debug
> node -e 'process.exit(0)'
><EMAIL_ADDRESS>install /usr/local/lib/node_modules/node-inspector/node_modules/v8-debug
> node-pre-gyp install --fallback-to-build
[v8-debug] Success: "/usr/local/lib/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.7.7/node-v14-linux-x64/debug.node" is installed via remote
npm ERR! Linux 3.19.0-30-generic
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-g" "node-inspector" "rtail"
npm ERR! node v0.12.13
npm ERR! npm  v2.15.0
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>preinstall: `npm install node-pre-gyp`
npm ERR! Exit status 243
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>preinstall script 'npm install node-pre-gyp'.
npm ERR! This is most likely a problem with the v8-profiler package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     npm install node-pre-gyp
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs v8-profiler
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR!     npm owner ls v8-profiler
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /tmp/npm-debug.log

Getting it too on:
npm ERR! node v4.4.4
npm ERR! npm  v2.15.1
npm ERR<EMAIL_ADDRESS>install: node-pre-gyp install --fallback-to-build

`
><EMAIL_ADDRESS>preinstall /usr/local/lib/node_modules/node-inspector/node_modules/v8-debug
> node -e 'process.exit(0)'

shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied

><EMAIL_ADDRESS>preinstall /usr/local/lib/node_modules/node-inspector/node_modules/v8-profiler
> node -e 'process.exit(0)'

shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
-
><EMAIL_ADDRESS>install /usr/local/lib/node_modules/node-inspector/node_modules/v8-debug
> node-pre-gyp install --fallback-to-build

shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
sh: node-pre-gyp: command not found

><EMAIL_ADDRESS>install /usr/local/lib/node_modules/node-inspector/node_modules/v8-profiler
> node-pre-gyp install --fallback-to-build

shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
sh: node-pre-gyp: command not found
npm ERR! Darwin 15.5.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-g" "node-inspector"
npm ERR! node v4.4.4
npm ERR! npm  v2.15.1
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn

npm ERR<EMAIL_ADDRESS>install: `node-pre-gyp install --fallback-to-build`
npm ERR! spawn ENOENT
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-pre-gyp install --fallback-to-build'.
npm ERR! This is most likely a problem with the v8-debug package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs v8-debug
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR!     npm owner ls v8-debug
npm ERR! There is likely additional logging output above.

Got the same issue here.
npm ERR! node v4.4.7
npm ERR! npm  v3.10.2
npm ERR! code ELIFECYCLE

npm ERR<EMAIL_ADDRESS>install: `node-pre-gyp install --fallback-to-build`
npm ERR! Exit status 126
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-pre-gyp install --fallback-to-build'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the v8-debug package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs v8-debug
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls v8-debug
npm ERR! There is likely additional logging output `above.

did anyone find any solution to this?

Possible related to https://github.com/node-inspector/v8-debug/issues/31
I've created a repo to make it easier for the maintainers to reproduce the issue I'm seeing: https://github.com/sqren/v8-debug-debug

Same problem on Fedora 24.

see russfrisch solution at https://github.com/node-inspector/v8-debug/issues/7

Reproducible on Windows 7 Enterprise

Same problem on MAC OS 10.11.4
node v7.0.0
npm 3.10.8

Same problem on MAC OS 10.11.6
`npm ERR! Darwin 15.6.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-g" "node-inspector"
npm ERR! node v7.0.0
npm ERR! npm  v4.0.2
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: node-pre-gyp install --fallback-to-build
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-pre-gyp install --fallback-to-build'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the v8-debug package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs v8-debug
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls v8-debug
npm ERR! There is likely additional logging output above.`

Same on macOS 10.12.1.
node v7.2.0 & v6.9.1.
npm v4.0.3 & the one bundled with node v6.9.1.

working correctly with Node 6.x version

npm ERR! node v7.3.0
npm ERR! npm  v3.10.10
npm ERR<EMAIL_ADDRESS>install: node-pre-gyp install --fallback-to-build
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-pre-gyp install --fallback-to-build'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the v8-debug package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs v8-debug
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls v8-debug
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /app/be/npm-debug.log
The command '/bin/sh -c npm install /app/be/' returned a non-zero code: 1
error with docker

Any solution yet ?

Looks like node-inspector doesnt work with latest node versions, per https://github.com/node-inspector/node-inspector/issues/907
However you might not need it, similar functionality is now built into node. Just use node --inspect yourApp.js and follow similar workflow.

Works with Node v6.9.4. If you've never installed another version of Node alongside your existing one, I recommend using nvm.  Here's a good quick intro.

@matthewepler Thank you very much, 6.3.1 works like a charm. Was using 7.4.0.

@matthewepler Thanks, I was able to use node v6.5.0 with our heroku build process.
/ package.json
...
  "engines": {
    "node": "~6.5.0",
    "npm": "3.10.7"
  },
...

Delete "grunt-node-inspector" from package.json
Heroku does not like grunt-node-inspector with node v7.1.0

try npm rebuild node-sass

I solved it by using node 6.11

Guys is there a workaround to not downgrade to node <= 10?

I just updated node inspector to the last version to dix my issue

I got this error message while running grunt serve, after upgrading nodev6 to nodev8
then, I replace the string debug with inspect in my gruntfile.js, then it worked like charm.
NodeV8 simply says to use -inspect instead of debug


[#236]Add the input organization name box to the login page

Signed-off-by: fengyang_sy<EMAIL_ADDRESS>

This PR breaks the dashboard


Please add the 'method' option

I compared all existing request options with the options in the interface definition. All looks good except method is missing.

Done, will push shortly :+1:


Unresponsiveness on iOS after dismissing Review modal

Unresponsiveness on iOS after dismissing Review modal
Hi James,
I work on a relatively large-scale enterprise application and we've observed unresponsiveness that occurs after dismissing the review modal quickly after it appears. We think this issue may have appeared somewhere around the release of iOS 17 and could be due to the way that the SKStoreReviewController appears on top of our MAUI application.  It's possible that the ConnectedScenes are not being filtered properly. In our app we've found that backgrounding and re-foregrounding the application seems to fix the unresponsiveness.
Version Number of Plugin: 6.2.0
Device Tested On: iPhone 13 Pro Max (iOS 16.6)
Please find here a sample app (https://github.com/tatesakai/storeReviewPluginSampleAppBug) (sorry I forgot .gitignore) and while the unresponsiveness is nowhere near ours (we've noticed up to 10-30 seconds of unresponsiveness post-modal dismissal in production), hopefully it's enough for you to reproduce the issue.
If you quickly tap the store review button and dismiss the modal, you'll notice a second or two of unresponsiveness.

This is the logic I run: you can add it directly into your source code:

var windowScene = UIApplication.SharedApplication?.ConnectedScenes?.ToArray<UIScene>()?.FirstOrDefault(x => x.ActivationState == UISceneActivationState.ForegroundActive) as UIWindowScene;
					if (windowScene != null)
					{
						SKStoreReviewController.RequestReview(windowScene);
					}

Hi James.
I'm on version 7.0.0-beta of the plugin, and I'm facing the same issue. I believe this version includes the code snippet you added above.
One thing I've noticed, whenever I deploy a new instance of the app to my physical iOS device when debugging, the review modal appears normally and is dismissed normally with a very minor unresponsiveness (< 1 second). Any future requests to view the modal and dismiss it after that will cause the unresponsiveness to happen, and like @tatesakai mentioned, it can be upward of 30 seconds. Even restarting the app will still cause the unresponsiveness to happen. This keeps happening until I deploy a new instance again, where only the first request will work normally, and then further requests will cause unresponsiveness.

Hello @jamesmontemagno,
I'm experiencing the exact same issue described in detail by @tahahalwanii. Looking forward to any insights or potential fixes. Thanks!


README updates

Add a lifecycle badge to the readme: https://github.com/bcgov/repomountie/blob/master/doc/lifecycle-badges.md
Include the requirements needed to run the code. Just R? stats-can specific tools?

Fixed in #9


Separate downloaded copybooks / includes according to Workspace

Description of the enhancement requested
IBM Z Open Editor relies on Zowe Explorer for downloading and storing copybooks / includes retrieved from the z/OS mainframe.
This storage is unique and common to all active Workspaces.
This does not allow working on different versions of copybooks / includes depending on the Workspace, or even on the Git branch if the Workspace is associated with a Git Repository.
It would therefore be necessary:

either an evolution of Zowe Explorer to be able to declare a storage folder relating to the Workspace,
or that Z Open Editor adds information specific to the Workspace, or even specific to the Git branch in the Workspace, to the storage path.

See Need zowe.files.temporaryDownloadsFolder.path setting to be relative to current Workspace on zowe / vscode-extension-for-zowe Github site.

@FALLAI-Denis could you provide specific scenarios where problem could happen?

If you have your copybooks on MVS then changing branches or workspaces would not impact what you pull from MVS. How do you switch versions on MVS? Wouldn't they be in different data sets? Do you have examples where this could be a problem? You can use different Zowe profiles for different workspaces as the "zopeneditor.zowe" settings can be scoped to a workspace and each profile will get its own temp sub-folder.
If you have you copybooks local then it will open the local files directly and not place them in a temp directory; so switching branches means accessing the files from that branch. Are you saying that you have copybooks in a different git repo in one workspace and two other workspaces access them? Then why not clone the copybook repo twice and adjust you property-groups temporarily?

Hi @phaumer,
In fact, being able to manage a storage path for downloaded copybooks based on workspace context is a necessary condition for versioning, but it is not a sufficient condition.
You also need a way to define the search for copybooks / includes according to the workspace context, or even the Git branch if this workspace is a Git repository. To date, we must manually modify the declarations in the zapp.yaml file.
In discussion Interactions between the Git workflow and Builds actions, I put a diagram which describes the promotion of elements including copybooks / includes and which shows the use of a  copybooks PDS concatenation mechanism at build time. Note on this diagram the existence of two promotion circuits: one for the evolutions, one for the corrections.
Since then we have evolved our solution and the application copybooks / includes are managed by cloned Git repositories in a dedicated folder in the workspace, with a mechanism that allows switching branches depending on the context of the workspace. . On the other hand, technical copybooks / includes continue to be managed by means of a PDS concatenation, a concatenation which depends on the context of the Git branch used in the workspace.
We also have another need concerning the search for copybooks / includes which is linked to the fact that our applications can be multi-partitions: part of the application is intended for a mainframe partition, and another part of the same application can be intended for a another mainframe partition, but both parts must be managed globally and cohesively. For historical reasons, each part of the application is built on a related partition, which requires having a management of downloaded copybooks / includes per mainframe partition for the same workspace, with potentially the same copybook / include names on each of the partition.
I also refer you to another request made in connection with this subject: Need to have contextual property groups (relative to Git branches)

Hi,
About location of copybooks, see also requirements for "SonarLint for COBOL":

By default, SonarLint takes the analysis configuration from the SonarQube or SonarCloud server therefore it is required that your project has already been analyzed by SonarQube or SonarCloud. The following COBOL analyzer properties are synced by default unless previously overridden locally. Note that all properties found on the server will be synced locally, not just this selection:

sonar.cobol.dialect
sonar.cobol.file.suffixes
sonar.cobol.sourceFormat
sonar.cobol.copy.suffixes
sonar.cobol.copy.directories

In case copybooks are in different location locally, the analyzer property sonar.cobol.copy.directories should be defined in the /project/.vscode/settings.json file.
If working with COBOL files via Zowe explorer, it is recommended to update your Zowe workspace settings in VS Code by modifying the temporary file location; temporary files should be saved to your project folder which is bound to SonarQube or SonarCloud. With the correct configuration, the analysis will be executed normally and you should see detected problems.

Clearly, sonar.cobol.copy.directories setting must correspond to the location used by Z Open Editor for storing copybooks downloaded from mvs, (which is not the same folder that Zowe Explorer uses to open a PDS file/member from mvs), but also to the various locations declared in the zapp.yaml file(s).

Hi,
I suggest that the copybooks/includes download location be specified in the zapp.yaml file.
In principle each Workspace, for us Git Repository, has its own zapp.yaml file.
This zapp.yaml file could be different from one Workspace version to another (from one Git branch to another if the zapp.yaml file is declared in the .gitignore file).
This would allow each Workspace to use its own versions of copybooks, without interference between the different Workspaces (but increasing the volume of data since there would then be duplication of copybooks/includes in each Workspace).
This would perfectly meet our different needs.
Indeed, we use a .imports folder declared in .gitignore to import the different necessary copybooks by cloning Git repositories (Git repositories dedicated to the management of copybooks, separated from the Git repositories of the programs).
It would then be enough for Z Open Editor to download the mvs copybooks into a subfolder of this .imports folder.

works consistent with the active git branch, (part after feature/) :

Example of implementation via the zapp.yaml file:

For us should be a subfolder of .imports, like ".imports/downloaded".
Thanks.

Hi,
I read changelog for Zowe Explorer V3: it will manage mainframe files in memory (resource URI), instead of on local temp directory on disk (resource path).
ZOE use ZE services to download MVS Copybooks / Includes.
Does this address our need to have a "per workspace" management of downloaded Copybooks / Include?


🚧 API: ReadableStream

Context
Specification: Streams
Specification interface: Interface ReadableStream
Additional documentation:

mdn docs
deno docs
Cloudflare workers docs
Boa documentation

dependencies:

#141

Expected TypeScript interface
/** This Streams API interface represents a readable stream of byte data. The
 * Fetch API offers a concrete instance of a ReadableStream through the body
 * property of a Response object.
 *
 * @category Streams API
 */
declare interface ReadableStream<R = any> {
  readonly locked: boolean;
  cancel(reason?: any): Promise<void>;
  getReader(options: { mode: "byob" }): ReadableStreamBYOBReader;
  getReader(options?: { mode?: undefined }): ReadableStreamDefaultReader<R>;
  pipeThrough<T>(transform: {
    writable: WritableStream<R>;
    readable: ReadableStream<T>;
  }, options?: PipeOptions): ReadableStream<T>;
  pipeTo(dest: WritableStream<R>, options?: PipeOptions): Promise<void>;
  tee(): [ReadableStream<R>, ReadableStream<R>];
  values(options?: {
    preventCancel?: boolean;
  }): AsyncIterableIterator<R>;
  [Symbol.asyncIterator](options?: {
    preventCancel?: boolean;
  }): AsyncIterableIterator<R>;
}

/** @category Streams API */
declare var ReadableStream: {
  readonly prototype: ReadableStream;
  new (
    underlyingSource: UnderlyingByteSource,
    strategy?: { highWaterMark?: number; size?: undefined },
  ): ReadableStream<Uint8Array>;
  new <R = any>(
    underlyingSource?: UnderlyingSource<R>,
    strategy?: QueuingStrategy<R>,
  ): ReadableStream<R>;
  from<R>(
    asyncIterable: AsyncIterable<R> | Iterable<R | PromiseLike<R>>,
  ): ReadableStream<R>;
};

@johnyob UnderlyingSource looks to be necessary for ReadableStream, but looks priority like doesn't match

@johnyob  same thing for QueuingStrategy

See https://www.notion.so/trilitech/Streams-bf95305c1fa9480aa37e8f19d83de2a5#41d13a17b79d4a6495308bb2fd6090b9


Question about the output of the coarse registration

Hi,
Thanks for your work,
I have two Gaussian clouds that are already aligned and I'm testing the coarse registration method with them.
However the result is quite disappointing and giving me a transform result that is far from being an identity matrix :
[[-0.07166722 -0.5279686   0.00634995  4.515895  ]
 [ 0.52784467 -0.07148125  0.01406345 -1.9595625 ]
 [-0.01308281  0.00818184  0.53262484 -0.06575554]
 [ 0.          0.          0.          1.        ]]

On top of this the scales are also off : ref_adjust_scale = 0.09 and src_adjust_scale = 0.09 .
I produced those gaussian clouds with spherical harmonics of degree 0, is it the cause of my poor results ?
Also, are the colored points in the saved demo_outputs clouds the points used by the superPoint matcher ?
Thanks in advance,
Best regards,
Hugo

Hi Hugo,
Could you please provide your original file?
The colored points in the saved demo_outputs clouds are the sampling points for coarse registration.
Best,
Jiahao

Maybe the problem lies in the overlap area of the two scenes? How much overlap area between the two scenes in your data?

Maybe the problem lies in the overlap area of the two scenes? How much overlap area between the two scenes in your data?

The area of overlap is quite large between the two clouds, half of the first and a good 1/4th  of the second ...
Is your method already supposed to be working on large-scale scenarios ?
Does the fact I'm not using any spherical harmonics could cause a problem as well ?
Have a good day,
Best,

Maybe that is the problem of the domain gap between your dataset and ScanNet-GSReg. I dont think the reason is not using any spherical harmonics. It would be even better if you could provide me with your data so that I can help you find the reason.

Hi,
Is there a way to be sure the version of the code I have is properly functioning with a ground truth benchmark, like estimating a know translation for instance ?
I successfully downloaded the ScanNet-GSReg first batch of sequences, is there an associated GT transform I can use to ensure that my code has the proper behavior ?
Thanks in advance,
Best,
Hugo

You can evaluate this model on the sample data (https://1drv.ms/f/c/31078419ab45666e/EiUYfzkosRpPv2zhu38kLbwBIR-GA2IvvCyMYc3VGWdFhA?e=o2MSW2)
The Identity matrix is the GT transform of the ScanNet-GSReg train dataset and we performed data augmentation at each iteration while training.
The ScanNet-GSReg first batch of sequences might be part of the ScanNet-GSReg training dataset.

Thanks for your quick answer !
I'm gonna test this, I suspect having an issue with SuperPoint and my GPU which would lead to a bad estimation ...
It could also explain my previous issues with the coarse estimation.
Do you know by any chance if there's a way to use your pipeline on cpu ?
Have a great day,
Best regards,

You should modify the code in L142 of demo.py
model = create_model(cfg).cuda()

and the code in L148-L151 of demo.py
data_dict = to_cuda(data_dict)
output_dict = model(data_dict)
data_dict = release_cuda(data_dict)
output_dict = release_cuda(output_dict)

You can put the model and data on the cpu instead of gpu.
I hope this is helpful to you.

Hi,
Thanks for your answer.
It doesn't seem to directly work like this for me.
Down the line things are expected to be on the GPU in geotransformer modules even if the model and data are placed on cpu.
Is there something else I need to modify for this to work ?
Thanks in advance,
Hugo

In addition, you should revise the code in the function point_to_node_partition: https://github.com/GAP-LAB-CUHK-SZ/GaussReg/blob/aed5e66130b7b890f3fc6ad84a27759b6090fc63/experiments/geotransformer.gaussian_splatting.indoor/model.py#L99, which includes the operation of transferring data to the GPU: https://github.com/GAP-LAB-CUHK-SZ/GaussReg/blob/aed5e66130b7b890f3fc6ad84a27759b6090fc63/geotransformer/modules/ops/pointcloud_partition.py#L87.
My apologies for overlooking this. I will update this part as well.
I'm also confused by your results. Has anyone else encountered this issue?


Remove default tink user

Description of changes:
The default template currently creates a default user tink on ubuntu. This is not needed for anything so this PR removes this default user.
Testing (if applicable):
Ran a create and verified the cluster creation still works with this default user removed
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm


ximeraPreamble.tex

Have a special file:
ximeraPreamble.tex
ximeraPrintstyle.sty
These will live at the top of the repo, and be loaded by all ximera/xourse files by default, if present, and silently ignored if they are not there.
In the documentation, we will explain that you could use absolute paths.
This doesn't solve the "graphics path" issue.
but this is easily solved with multiple graphics paths.
Wim suggested this.

Solved in  #9eae3479bda9ac0969f403186f5c90fb0197778a (ximeraPreamble) and #91df29bcc75d57e50252cddaf08694a55a8cc5ef (graphicspath: use /pictures !)


update readme

the old readme still has references to aspectj
instructions can be short

also add build instructions -- custom build needs package before tests

remove aspectj dependency !

remove aspectj dependency !

Note to self: The code itself doesn't seem to have any dependency on AspectJ -- just the README.

The README also mentions InvocationTrackerManagerFilter and InvocationTracker, but nothing by those names exists in either main or datastoreapi (which has been merged into main).

InvocationTrackerManagerFilter was removed in 2925f41b48d, seems to now be ProvenanceTrackerFilter (based on the fact that it implements Filter)
InvocationTracker is now part of ThreadLocalProvenanceTracker (5e31fc1f0b1aa3)

Also ProvenancePickupServlet -> JsonProvenanceInfoPickupServlet.


Sherpa-Romeo Integration

From release plan spreadsheet
Estimate from release plan: 40 hours
Expressing interest: none
No additional notes

Basic SHERPA/RoMEO integration already exists in 7.0. Needs discussion as to what additional features are needed. May be overestimated.

See comment in https://github.com/DSpace/DSpace/issues/2840 the Sherpa/RoMEO submission panel is mostly readonly, we can eventually think about a "force refresh" button. I would reduce the estimation to 3 days


False/hard annotations with occluded objects

I am currently looking at the YCB-video dataset and noticed that there might be occlusions that are "too hard":
e.g.  the sugar box in the image below

Is there a flag for hard occlusions in the dataset?
Were these annotations used to train poseCNN?

Thank you.

hello, can you tell me how to make my own dataset for train? I can't access the google drive.


Check for invalid uses of .form-control

Fixes #262.
CC: @hnrch02 for review

Otherwise LGTM.

Coverage remained the same at 100.0% when pulling e0783e5de6575ea20086c30fc3202aa5f73431d0 on fix-262 into 91fd0fa3471facff810173c8561cfd311fd786ac on master.