Robustness warning in Chrome?

When initiating a stream in shaka2 you get an ominous warning in the console:
It is recommended that a robustness level be specified. Not specifying the robustness level could result in unexpected behavior in the future, potentially including failure to play..
This is probably benign, but if it can be mitigated somehow, that would be great. I saw a PR merged earlier this summer in dash.js that seems to deal with this issue, (https://github.com/Dash-Industry-Forum/dash.js/pull/1446) maybe that could be of interest.

We already support robustness settings.  See "Advanced DRM Configuration" in the DRM Configuration tutorial.
We don't set robustness by default because that would require us to hard-code knowledge of valid robustness levels, which are not defined in the EME spec.  Each key system has its own set of valid robustness strings.

The message is ominous, though.  For now, the empty string is allowed by the EME spec and is meaningful:

robustness of type DOMString, defaulting to ""

The robustness level associated with the content type. The empty string indicates that any ability to decrypt and decode the content type is acceptable.

We'll keep an eye out for changes on this.  Perhaps the message references an older version of the spec in which this was not well defined.

See also this text (emphasis added) from the note following the normative text above:

... If only the empty string is specified, implementations MAY be configured to use the lowest robustness level the implementation supports.
Applications SHOULD specify the robustness level(s) they require to avoid unexpected client incompatibilities.

This warning is for the current version of the spec and related to potential changes to Chrome (or other implementations) that could break some apps that do not provide a robustness level. For example, the lowest supported level is often not appropriate for video.

Ah, I see.  Thanks for the correction, David.

All right! Thanks for the clarifications.
While reading I thought of another argument to not provide a default:
Suppose the technical details of a DRM implementation is dictated by rights acquisition terms. Setting a low default level would mask the need to make an explicit choice, leading to a potential breach of contract toward the rights holders. It makes a lot of sense to not mute the warning so that people like me need to look up the details and spec.

Just in case someone is looking for the information, to get rid of the warning, I used SW_SECURE_CRYPTO for both audioRobustness and audioRobustness, valid values for widevine are listed here : https://chromium.googlesource.com/chromium/src/+/refs/heads/lkcr/components/cdm/renderer/widevine_key_system_properties.h

Have we answered this question to everyone's satisfaction?  Can we close it?

I'm satisfied, thanks. You can close it.

I am using shaka 2.02 and set robustness level to SW_SECURE_CRYPTO for audio and video still get warning. Is it because of version? I have been used shaka(2.0.0 beta) before.
this.get('player').configure({
    drm: {
        servers: {'com.widevine.alpha': data.token},
        advanced: {
        'com.widevine.alpha': {
            'videoRobustness': 'SW_SECURE_CRYPTO',
            'audioRobustness': 'SW_SECURE_CRYPTO'
        }
        }
    }
})

@Zorig, are you using the demo app or a custom app?  If custom, are you using shaka.media.DrmEngine.probeSupport()?

@joeyparrish I am using custom app(Ember 2.10) also i used probeSupport like this. Is it wrong usage?
shaka.Player.probeSupport().then((support) => {
    if (support.drm['com.widevine.alpha']) {
    // this.set('video', document.getElementById('video'));
    // this.set('player', new shaka.Player(this.video));
    } else {
        this.set('error', 'ERROR');
    }
});

Ah, that makes sense now.  The warning is triggered by probeSupport().  Because it probes for multiple key systems and because we do not hard-code valid robustness strings per key system, the probe does not specify any robustness.

okay, @joeyparrish so how should i set robustness in this case? checking widevine is essential in my case. And some drm songs are not playing because of robustness i think

I'm not sure I understand the question.  You don't need to set robustness in any way to call probeSupport().  Is probeSupport() not working?  Or are you just trying to silence the warning?

Some of my songs are not playing. So i thought it is because of robustness level according to warning. And when i set robustness level it still gives me robustness warning

I got the same error on basic code. It's triggered by navigator.requestMediaKeySystemAccess method used to test if certain key system is supported:
var config = [{
	"initDataTypes": ["cenc"],
	"audioCapabilities": [{ "contentType": 'audio/mp4;codecs="mp4a.40.2"' }],
	"videoCapabilities": [{ "contentType": 'video/mp4;codecs="avc1.42E01E"' }]
}];
try {
	navigator.
		requestMediaKeySystemAccess("com.widevine.alpha", config).
		then(function (mediaKeySystemAccess) {
			console.log('widevine support ok');
		}).catch(function (e) {
			console.log('no widevine support');
			console.log(e);
		});
} catch (e) {
	console.log('no widevine support');
	console.log(e);
}

Add robustness level setting to config object solved the problem:
var config = [{
	"initDataTypes": ["cenc"],
	"audioCapabilities": [{ "contentType": 'audio/mp4;codecs="mp4a.40.2"', robustness: 'SW_SECURE_CRYPTO' }],
	"videoCapabilities": [{ "contentType": 'video/mp4;codecs="avc1.42E01E"', robustness: 'SW_SECURE_CRYPTO' }]
}];

Besides, this warning only triggered when key system is "com.widevine.alpha". Add robustness setting to other key system causes exception and returns false positive result:

DOMException: Unsupported keySystem or supportedConfigurations.


We want an MCMC expert to review our methods, sooner rather than later

Ideally, before we've run too many states & plan type combos through the pipeline! (in case we have to redo them)

Daryl DeFord at WSU might be an ideal candidate--I believe respected and trusted by Moon and an easy drive from me.


CrashLoopBackoff - Constant restarts

I keep getting "Liveness probe failed: HTTP probe failed with statuscode: 503 no matter which way I install as it pertains to the Helm chart or any combo with edgectl install
If I install differently:
kubectl apply --namespace ambassador
--filename https://getambassador.io/yaml/ambassador/ambassador-rbac.yaml
--filename https://getambassador.io/yaml/ambassador/ambassador-service.yaml
And proceed with the directions on Knative for Ambassador I see no issues , only exception is I cannot get to the endpoints or admin ui
If I install using the helm per:
https://www.getambassador.io/docs/latest/tutorials/getting-started/
It results in a CrashLoopBackoff with constant restarts below....
2020-07-05T16:49:19.671043674Z 2020-07-05 16:49:19 kubewatch [11 TMainThread] 1.5.5 DEBUG: looking up ID for namespace default
2020-07-05T16:49:22.579732776Z 2020-07-05 16:49:22 kubewatch [11 TMainThread] 1.5.5 DEBUG: cluster ID URL is d6e_id://cb4d673d-88a0-4d2c-ac3f-dd7d2f202257/default
2020-07-05T16:49:25.93385845Z 2020-07-05 16:49:25 kubewatch [11 TMainThread] 1.5.5 DEBUG: IngressClass check got 403
2020-07-05T16:49:26.031122015Z 2020-07-05 16:49:26 kubewatch [11 TMainThread] 1.5.5 DEBUG: Ambassador does not have permission to read IngressClass resources. To enable IngressClass support, configure RBAC to allow Ambassador to read IngressClass resources, then restart the Ambassador pod.
2020-07-05T16:49:30.820492507Z 2020-07-05 16:49:30 kubewatch [11 TMainThread] 1.5.5 DEBUG: CRD type definition not found for ambassadorinstallations.getambassador.io
2020-07-05T16:49:30.867398724Z 2020-07-05 16:49:30 kubewatch [11 TMainThread] 1.5.5 DEBUG: ambassadorinstallations.getambassador.io CRD not available
2020-07-05T16:49:30.867702861Z 2020-07-05 16:49:30 kubewatch [11 TMainThread] 1.5.5 DEBUG: cluster ID is 9e2fd712-5ea6-5938-9496-6460246a5d68 (from namespace default)
2020-07-05T16:49:31.120457185Z 2020-07-05 16:49:31 AMBASSADOR INFO starting with environment:
2020-07-05T16:49:31.122080335Z 2020-07-05 16:49:31 AMBASSADOR INFO ====
2020-07-05T16:49:31.124629797Z AMBASSADOR_ADMIN_PORT=tcp://<IP_ADDRESS>:8877
2020-07-05T16:49:31.124668577Z AMBASSADOR_ADMIN_PORT_8877_TCP=tcp://<IP_ADDRESS>:8877
2020-07-05T16:49:31.124675465Z AMBASSADOR_ADMIN_PORT_8877_TCP_ADDR=<IP_ADDRESS>
2020-07-05T16:49:31.124680105Z AMBASSADOR_ADMIN_PORT_8877_TCP_PORT=8877
2020-07-05T16:49:31.124685646Z AMBASSADOR_ADMIN_PORT_8877_TCP_PROTO=tcp
2020-07-05T16:49:31.124690164Z AMBASSADOR_ADMIN_SERVICE_HOST=<IP_ADDRESS>
2020-07-05T16:49:31.124694293Z AMBASSADOR_ADMIN_SERVICE_PORT=8877
2020-07-05T16:49:31.124699626Z AMBASSADOR_ADMIN_SERVICE_PORT_AMBASSADOR_ADMIN=8877
2020-07-05T16:49:31.124703557Z AMBASSADOR_CLUSTER_ID=9e2fd712-5ea6-5938-9496-6460246a5d68
2020-07-05T16:49:31.124708674Z AMBASSADOR_CONFIG_BASE_DIR=/ambassador
2020-07-05T16:49:31.124712551Z AMBASSADOR_NAMESPACE=ambassador
2020-07-05T16:49:31.124716802Z AMBASSADOR_PORT=tcp://<IP_ADDRESS>:80
2020-07-05T16:49:31.124720756Z AMBASSADOR_PORT_443_TCP=tcp://<IP_ADDRESS>:443
2020-07-05T16:49:31.124724517Z AMBASSADOR_PORT_443_TCP_ADDR=<IP_ADDRESS>
2020-07-05T16:49:31.124728323Z AMBASSADOR_PORT_443_TCP_PORT=443
2020-07-05T16:49:31.124733506Z AMBASSADOR_PORT_443_TCP_PROTO=tcp
2020-07-05T16:49:31.124737478Z AMBASSADOR_PORT_80_TCP=tcp://<IP_ADDRESS>:80
2020-07-05T16:49:31.124741156Z AMBASSADOR_PORT_80_TCP_ADDR=<IP_ADDRESS>
2020-07-05T16:49:31.124744796Z AMBASSADOR_PORT_80_TCP_PORT=80
2020-07-05T16:49:31.124748889Z AMBASSADOR_PORT_80_TCP_PROTO=tcp
2020-07-05T16:49:31.124752983Z AMBASSADOR_REDIS_PORT=tcp://<IP_ADDRESS>:6379
2020-07-05T16:49:31.124757084Z AMBASSADOR_REDIS_PORT_6379_TCP=tcp://<IP_ADDRESS>:6379
2020-07-05T16:49:31.124760787Z AMBASSADOR_REDIS_PORT_6379_TCP_ADDR=<IP_ADDRESS>
2020-07-05T16:49:31.12476459Z AMBASSADOR_REDIS_PORT_6379_TCP_PORT=6379
2020-07-05T16:49:31.124768329Z AMBASSADOR_REDIS_PORT_6379_TCP_PROTO=tcp
2020-07-05T16:49:31.124772142Z AMBASSADOR_REDIS_SERVICE_HOST=<IP_ADDRESS>
2020-07-05T16:49:31.124775643Z AMBASSADOR_REDIS_SERVICE_PORT=6379
2020-07-05T16:49:31.124779342Z AMBASSADOR_SERVICE_HOST=<IP_ADDRESS>
2020-07-05T16:49:31.12478293Z AMBASSADOR_SERVICE_PORT=80
2020-07-05T16:49:31.124786686Z AMBASSADOR_SERVICE_PORT_HTTP=80
2020-07-05T16:49:31.124790285Z AMBASSADOR_SERVICE_PORT_HTTPS=443
2020-07-05T16:49:31.126400772Z 2020-07-05 16:49:31 AMBASSADOR INFO ====
2020-07-05T16:49:31.132667791Z 2020-07-05 16:49:31 AMBASSADOR INFO launching worker process 'ambex': 'ambex' '--ads-listen-address=<IP_ADDRESS>:8003' '/ambassador/envoy'
2020-07-05T16:49:31.135500268Z 2020-07-05 16:49:31 AMBASSADOR INFO ambex is PID 56
2020-07-05T16:49:31.1377097Z 2020-07-05 16:49:31 AMBASSADOR INFO launching worker process 'diagd': 'diagd' '/ambassador/snapshots' '/ambassador/bootstrap-ads.json' '/ambassador/envoy/envoy.json' '--notices' '/ambassador/notices.json' '--kick' 'kill -HUP 1'
2020-07-05T16:49:31.141340156Z 2020-07-05 16:49:31 AMBASSADOR INFO diagd is PID 64
2020-07-05T16:49:32.52539851Z 2020-07-05 16:49:32 diagd 1.5.5 [P64TMainThread] INFO: WILL update Mapping status
2020-07-05T16:49:32.525848086Z 2020-07-05 16:49:32 diagd 1.5.5 [P64TMainThread] INFO: thread count 9, listening on <IP_ADDRESS>:8877
2020-07-05T16:49:33.001730991Z 2020-07-05 16:49:32 diagd 1.5.5 [P64TMainThread] INFO: Ambassador 1.5.5 booted
2020-07-05T16:49:33.019579963Z [2020-07-05 16:49:33 +0000] [64] [INFO] Starting gunicorn 19.9.0
2020-07-05T16:49:33.020833661Z [2020-07-05 16:49:33 +0000] [64] [INFO] Listening at: http://<IP_ADDRESS>:8877 (64)
2020-07-05T16:49:33.020873051Z [2020-07-05 16:49:33 +0000] [64] [INFO] Using worker: threads
2020-07-05T16:49:33.029013342Z [2020-07-05 16:49:33 +0000] [77] [INFO] Booting worker with pid: 77
2020-07-05T16:49:33.035065982Z 2020-07-05 16:49:33 diagd 1.5.5 [P77TAEW] INFO: starting Scout checker and timer logger
2020-07-05T16:49:33.038145712Z 2020-07-05 16:49:33 diagd 1.5.5 [P77TAEW] INFO: starting event watcher
2020-07-05T16:49:34.213121614Z 2020-07-05 16:49:34 AMBASSADOR INFO diagd running
2020-07-05T16:49:34.224762109Z 2020-07-05 16:49:34 AMBASSADOR INFO launching worker process 'watt': 'watt' '--listen-address=<IP_ADDRESS>:8002' '--notify' 'python /ambassador/post_update.py --watt ' '--watch' 'python /ambassador/watch_hook.py' '-s' 'service' '-s' 'ingresses' '-s' 'AuthService' '-s' 'Mapping' '-s' 'Module' '-s' 'RateLimitService' '-s' 'TCPMapping' '-s' 'TLSContext' '-s' 'TracingService' '-s' 'ConsulResolver' '-s' 'KubernetesEndpointResolver' '-s' 'KubernetesServiceResolver' '-s' 'Host' '-s' 'LogService'
2020-07-05T16:49:34.232763955Z 2020-07-05 16:49:34 AMBASSADOR INFO watt is PID 87
2020-07-05T16:49:34.238747152Z 2020-07-05 16:49:34 AMBASSADOR INFO launching worker process 'amb-sidecar': '/ambassador/sidecars/amb-sidecar'
2020-07-05T16:49:34.241482433Z 2020-07-05 16:49:34 AMBASSADOR INFO amb-sidecar is PID 98
2020-07-05T16:49:34.373744379Z time="2020-07-05 16:49:34" level=info msg="Ambassador Edge Stack configuration loaded" func=github.com/datawire/apro/cmd/amb-sidecar/runner.runE file="github.com/datawire/apro@/cmd/amb-sidecar/runner/main.go:187"
2020-07-05T16:49:38.757994896Z time="2020-07-05 16:49:38" level=error msg="Failed to create watch on /home/ambassador/.config/ambassador/: Changes might require a restart: no such file or directory" func=github.com/datawire/apro/cmd/amb-sidecar/runner.triggerOnChange file="github.com/datawire/apro@/cmd/amb-sidecar/runner/files.go:54"
2020-07-05T16:49:39.638677974Z time="2020-07-05 16:49:39" level=warning msg="statsd is not in use" func=github.com/lyft/gostats.NewDefaultStore file="github.com/lyft/gostats@v0.2.6/stats.go:193"
2020-07-05T16:49:39.653146346Z 2020-07-05 16:49:39 diagd 1.5.5 [P77TThreadPoolExecutor-0_2] ERROR: 'NoneType' object has no attribute 'overview'
2020-07-05T16:49:39.653188912Z Traceback (most recent call last):
2020-07-05T16:49:39.653196091Z   File "/usr/lib/python3.7/site-packages/ambassador-0.0.0.dev0-py3.7.egg/ambassador_diag/diagd.py", line 292, in wrapper
2020-07-05T16:49:39.653201866Z     result = f(*args, reqid=reqid, **kwds)
2020-07-05T16:49:39.653209414Z   File "/usr/lib/python3.7/site-packages/ambassador-0.0.0.dev0-py3.7.egg/ambassador_diag/diagd.py", line 578, in show_overview
2020-07-05T16:49:39.653215358Z     ov = diag.overview(request, app.estats)
2020-07-05T16:49:39.653220721Z AttributeError: 'NoneType' object has no attribute 'overview'
2020-07-05T16:49:39.653247287Z 2020-07-05 16:49:39 diagd 1.5.5 [P77TThreadPoolExecutor-0_2] ERROR: 3E9C29BC-94A7-45C9-8B84-10230A3F615E: <IP_ADDRESS> "GET /ambassador/v0/diag/" 2ms 500 server error
2020-07-05T16:49:39.653253179Z time="2020-07-05 16:49:39" level=error msg="Bad HTTP response" func=github.com/datawire/apro/cmd/amb-sidecar/devportal/server.HTTPGet.func1 file="github.com/datawire/apro@/cmd/amb-sidecar/devportal/server/fetcher.go:165" status_code=500 subsystem=fetcher url="http://<IP_ADDRESS>:8877/ambassador/v0/diag/?json=true"
2020-07-05T16:49:39.653259294Z time="2020-07-05 16:49:39" level=error msg="HTTP error 500 from http://<IP_ADDRESS>:8877/ambassador/v0/diag/?json=true" func=github.com/datawire/apro/cmd/amb-sidecar/devportal/server.HTTPGet file="github.com/datawire/apro@/cmd/amb-sidecar/devportal/server/fetcher.go:172" subsystem=fetcher url="http://<IP_ADDRESS>:8877/ambassador/v0/diag/?json=true"
2020-07-05T16:49:39.995479936Z time="2020-07-05T16:49:39Z" level=info msg="starting watt..."
2020-07-05T16:49:39.995561235Z 2020/07/05 16:49:39 api: snapshot server listening on: tcp:<IP_ADDRESS>:8002
2020-07-05T16:49:41.031586912Z time="2020-07-05 16:49:41" level=warning msg="runtime: error processing /tmp/amb/config/config: lstat /tmp/amb/config/config: no such file or directory" func="github.com/lyft/goruntime/loader.(*Loader).walkDirectoryCallback" file="github.com/lyft/goruntime@v0.1.8/loader/loader.go:87"
2020-07-05T16:49:51.160384515Z Calling Metriton
2020-07-05T16:49:54.197463235Z time="2020-07-05 16:49:54" level=error msg="0 filters configured" func="github.com/datawire/apro/cmd/amb-sidecar/filters/controller.(*Controller).Watch.func1" file="github.com/datawire/apro@/cmd/amb-sidecar/filters/controller/controller.go:151" MAIN=auth_controller
2020-07-05T16:50:15.015053789Z 2020/07/05 16:50:15 aggregator: bootstrapped!
2020-07-05T16:50:21.136778514Z 2020-07-05 16:50:21 AMBASSADOR INFO launching worker process 'envoy': 'envoy' '-c' '/ambassador/bootstrap-ads.json' '--base-id' '0' '--drain-time-s' '600' '-l' 'error'
2020-07-05T16:50:21.228965195Z 2020-07-05 16:50:21 diagd 1.5.5 [P77TAEW] INFO: configuration updated from snapshot 1 (S87 L1 G9 C4)
2020-07-05T16:50:21.229009001Z 2020-07-05 16:50:21 AMBASSADOR INFO envoy is PID 149
2020-07-05T16:50:21.336433273Z time="2020-07-05 16:50:21" level=warning msg="license_secret_watch: empty decoded license data" func=github.com/datawire/apro/cmd/amb-sidecar/runner.runE.func4 file="github.com/datawire/apro@/cmd/amb-sidecar/runner/main.go:344" MAIN=license_secret_watch
2020-07-05T16:50:21.435092066Z 2020-07-05 16:50:21 AMBASSADOR INFO KICK: started Envoy as PID 149
2020-07-05T16:50:29.752571047Z 2020-07-05 16:50:29 diagd 1.5.5 [P77TAEW] INFO: configuration updated from snapshot 2 (S87 L1 G9 C4)
2020-07-05T16:50:29.844836775Z time="2020-07-05 16:50:29" level=warning msg="license_secret_watch: empty decoded license data" func=github.com/datawire/apro/cmd/amb-sidecar/runner.runE.func4 file="github.com/datawire/apro@/cmd/amb-sidecar/runner/main.go:344" MAIN=license_secret_watch

Closing as this seems to happen with replicas and I need to troubleshoot further


Deleted commits

Hi,
some time ago we provided a pull request to provide cmake find_package files (mqtt_cppConfig.cmake, mqtt_cppTargets.cmake), see https://github.com/redboltz/mqtt_cpp/pull/149
On current master the files aren't created anymore. Within the history, i can't find the commits. It seems, the master has been reset hard. Is there a special reason or was dropping the commits an
accident?

Sure, see https://github.com/redboltz/mqtt_cpp/pull/632


Support to trigger the compaction in the flink batch mode.

现在有这个参数了吗

it will be coming soon.

https://issues.apache.org/jira/browse/HUDI-4385


Fixed(Cypress): Sphinx Nav Fiber

Problem:

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/home/runner/work/sphinx-nav-fiber/sphinx-nav-fiber/stack/.env" to rootfs at "/app/.env": mount /home/runner/work/sphinx-nav-fiber/sphinx-nav-fiber/stack/.env:/app/.env (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

Evidence:

Hi @Evanfeenstra, @Rassl, @tomsmith8, @kevkevinpal
Please merge this PR.

@Rassl:


[Bug]: npm run generate (VectoreStoreIndex) hangs on large files

Bug Description
I created a new NextJs app with npx create-llama@latest following steps here: https://github.com/run-llama/LlamaIndexTS/tree/main/packages/create-llama
No changes in code from starter template.
I added the usc tax code to the ./data folder and reran npm run generate to create embeddings. When running the script, the script hangs after saying Generating storage context....
I added basic console logging and looks like it hangs on this line:
await VectorStoreIndex.fromDocuments(documents, {
      storageContext,
      serviceContext,
    });

The pdf file I'm using is 17MB, or 7000 pages of text. No images in file.
I believe the script hangs instead of working slowly in background because I'm checking my API calls to OpenAI. Only an initial embedding call is done to generate the document metadata hash, but no subsequent API calls.
I tested by removing this large 17MB file and using a smaller PDF. Everything works fine.
Using node 18.17.0
Version
latest
Steps to Reproduce
Follow steps here to create NextJS app.
https://github.com/run-llama/LlamaIndexTS/tree/main/packages/create-llama
Add the US Tax Code to ./data. PDF download file from here http://uscode.house.gov/download/download.shtml (Title 26)
Run npm run generate.
Relevant Logs/Tracbacks
No response

That is indeed the line of code that embeds all your data.
Do you have a paid openai key? I've never really encountered this
Note that 17MB of text will take several minutes (or tens of minutes) to embed. It gets chunked into pieces of 1024 tokens.
You can try increasing the batch size on the embed model (default is 10)
from llama_index.embeddings import OpenAIEmbedding
embed_model = OpenAIEmbedding(embed_batch_size=1000)
service_context = ServiceContext.from_defaults(..., embed_model
=embed_model)

@logan-markewich I retried a few hours later and things worked. The previous failed run ran for about 15 minutes. It might just have not been long enough or I might have hit rate limits on OpenAI side, but can't be sure.
I'm going to close this out. Thanks for the response


chore(master): release 1.2.5

:robot: I have created a release beep boop
1.2.5 (2023-05-23)
Miscellaneous

deps: update dependency phpstan/phpstan-phpunit to v1.3.12 (d094c5d)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/wayofdev/php-cs-fixer-config/releases/tag/v1.2.5 :sunflower:


Auth-Layer: Dockerfile Creation

Dockerization of the project to allow it to be deployed on K8 using helm charts.

Within these 2 projects this ticket was resolved:
https://github.com/hashgraph/hedera-the-graph/pull/43
https://github.com/hashgraph/hedera-the-graph/pull/45


doc: remove experimental use-case-2, provisioninfra ref

case consistency

Do we really need to remove it? It's still usable for developers...

Do we really need to remove it? It's still usable for developers...

It is still in the documentation in the suse-ecp section. It is only removed from the general sections.


JSX but not React in scope

I'm using JSX syntax to generate virtual-dom/h code using babel plugins (this specifically).
Only problem is, now standard complains because React is not in scope.
Not quite sure how this should be addressed, however. Because that check is useful when using React.

Perhaps it'd just be best to remove that rule? Not having React in scope will blow up pretty quickly. That's  doesn't seems like something that would cause subtle bugs, it just blows up :)

Why not just disable it for your use case?
Put this at the top of your file:
/* eslint-disable react-in-jsx-scope */

@jprichardson Wouldn't disabling the rule be friendlier for people using React competitors like Riot and Deku? I don't really want to be opinionated and push people to React without a good reason.

@feross yep.

I don't really want to be opinionated and push people to React without a good reason.

Alright, fair enough. While it's nice to have the live feedback in my IDE (linter-js-standard) when I forget to add React with JSX, I definitely understand this perspective and don't have a strong feeling either way.

This error is almost impossible to miss, as the code simply will fail at require time in almost all cases.
I'm OK with it being disabled.

@HenrikJoreteg want to send a PR?

Sure, will do
On Wed, Dec 2, 2015 at 19:00 Feross Aboukhadijeh<EMAIL_ADDRESS>wrote:

@HenrikJoreteg https://github.com/HenrikJoreteg want to send a PR?
—
Reply to this email directly or view it on GitHub
https://github.com/feross/standard/issues/351#issuecomment-161501825.

Didn't know if you need anything else in terms or tests or whatnot. Just tweaked the config in the other module? Just lemme know if i missed something.

it does raise an interesting question, however. Now what happens to the h that's an unused variable?

@HenrikJoreteg So, now you get an unused variable warning?

right

I merged that change, but, we can roll it back if necesssary.
If h is undefined, then, you should global it out IMHO.

@dcousens doing /*global h*/ doesn't solve it because h is an unused variable. Have to do: /*eslint no-unused-vars: [2, {"varsIgnorePattern": "h"}]*/

We currently have a way to define globals via package.json, perhaps we need a way to define unused vars too?

not sure if this is relevant, but setting h as a global in package.json will not throw a no-unused-vars error if it's not used.

Roger that, @rstacruz! That should be a way to get around the error for sure!

I agree that'd be a nice way to do it. I could see this kind of thing
happening more and more now that people are doing more things with babel
plugins.
On Wed, Dec 9, 2015 at 9:38 PM Dan Flettre<EMAIL_ADDRESS>wrote:

We currently have a way to define globals via package.json, perhaps we
need a way to define unused vars too?
—
Reply to this email directly or view it on GitHub
https://github.com/feross/standard/issues/351#issuecomment-163492627.

Running into this myself. When using something else for JSX other than React, a whole slew of errors actually happen. Here's a simple example using deku
/** @jsx element */
import 'element' from 'magic-virtual-element'
import { render, tree } from 'deku'

render(tree(

), document.body)

'React' must be in scope when using JSX (react/react-in-jsx-scope)
Unknown property 'class' found, use 'className' instead (react/no-unknown-property)
"element" is defined but never used (no-unused-vars)

I really wanna use standard on this new project but all of these things make it a pain.

Same problem with snabbdom-jsx. We are trying to port cerebral to standard, but hit this blocking issue.
The only way to use standard is to wrap all jsx related imports with
/*eslint-disable no-unused-vars*/

and every jsx file with
/*eslint-disable react/react-in-jsx-scope*/

disabling react-in-jsx-scope is just an inconvenience, but disabling no-unsed-vars is bad.
In order to use jsx with something other than react it is necessary to declare the plugin in your .babelrc
  "plugins": [
    [ "transform-react-jsx", { "pragma": "Component.DOM" } ]
  ]

Maybe standard could check this, then instead of checking for React it  could now check for Component and auto fix both of the above rules?

@feross perhaps we ditch react in the next major?   Is it possible for us to do things like eslint-env react?

As a lateral thought, it'd be nice for standard-engine to pick up your local .eslintrc.
You can set your eslintrc to this:
{
  "extends": ["standard", "standard-react"]
}

...and customize it as you see fit.

@rstacruz that would be neat.

I ended up adding React as a global in package.json which isn't a terrible solution, though a bit hacky.
I almost wonder if standard should just ignore react-related settings beyond tolerating JSX.

@HenrikJoreteg it really does feel like it should just be an extension,  so I'm not impartial to that either.

Yeah, I'd like to eliminate built-in React rules (i.e. eslint-config-standard-react) from standard. We can create a standard-react package for those who want the old behavior, with built-in react support.

I'm trying to wrap my head around the unused variable thing. Can someone help me understand?
@rstacruz In your example:
/** @jsx element */
import 'element' from 'magic-virtual-element'
import { render, tree } from 'deku'

render(tree(

), document.body)

It does appear that 'element' is an unused variable. I'm guessing that the @jsx pragma thing is actually making use of it, though?
What can standard do to accommodate this better?

React-specific rules are removed in master now, in preparation of standard v6. :+1:
@HenrikJoreteg @jprichardson @dcousens @Flet @rstacruz @garth Let me know if you think of a way to fix the JSX unused variable issue, or at least make it easier to deal with.

Alright, I've gotten it so that @rstacruz's example doesn't have any issues in standard v6 and will just pass. The /* @jsx element */ pragma is used when it exists, and the other react-specific rules are gone.
But I'm still going to keep the basic sanity-check JSX rules. Here's the list:
    "react/jsx-boolean-value": 2,
    "react/jsx-closing-bracket-location": 2,
    "react/jsx-indent": [2, 2],
    "react/jsx-indent-props": [2, 2],
    "react/jsx-no-duplicate-props": 2,
    "react/jsx-no-undef": 2, //
    "react/jsx-uses-react": 2, // doesn't actually require react -- uses @jsx pragma
    "react/jsx-uses-vars": 2, // marks variables in jsx as used
    "react/self-closing-comp": 2

And the no-unknown-property is removed.

Looks like I'm a little late to the party, but I'd like to propose adding "jsxPragma" to the standard config.
note: If this should be in a different issue, let me know and I'll continue this in a new one.
Right now, I've got a component using preact (which uses virtual-dom) that requires h instead of React as a global.
import { h, render } from 'preact'
import { IndexRoute, Route, Router } from 'react-router'
import { createHistory } from 'history'
import { App } from './app'
import { Home } from './home'
import { About } from './about'

export const routes = (
  <Route path='/' component={App}>
    <IndexRoute component={Home} />
    <Route path='/about' component={About} />
  </Route>
)

render(<Router history={createHistory}>{routes}</Router>, document.querySelector('[data-hook="app"]'))

Babel allows a config in .babelrc like so:
{
  "jsxPragma": "h"
}

Thus, is might work if standard could have it's jsxPragma set (vs. including the pragma statement on each page) like so in package.json which could be used to ignore the "defined but never used" errors. Should work for any jsx library I would think.
"standard": {
  "jsxPragma": "h"
}

@mike-engel standard's philosophy is to avoid configuration and opt for in-line documentation. You can set which JSX pragma you're using by adding a comment to the top of your file:
/** @jsx h */
import { h, render } from 'preact'
// etc ...

That should work :+1:

Yeah, I understand @feross. I was coming at it from the angle where instead of having to add the pragma to every file (I don't currently add them, they're inferred as react jsx by default), it would be nice to have one place to add them. It would be the same idea as defining globals in one place vs. adding /* global describe*/ to every test file.
I understand the reasoning for keeping it out, however, and it's just a thought.

@mike-engel Thanks for clarifying what you meant. I still think we'll keep this out of the package.json for now.

@feross just want to add my point of view for maybe additional perspective.
I totally agree that there should be zero configuration using standard. But, as I see it, the pragma isn't a configuration. jsx already baked into standard (this is the configuration) and because there are different virtual dom libraries, jsx users must specify the pragma. So the question is not if to specify but where to specify and to me it seems similar to the parser option because its consistent along the project.
The need of adding additional and same line to all jsx files so a tool (standard) that already supports jsx will understand the input, just doesn't feel 100% to me so IMHO I think @mike-engel suggestion is better than the current state and setting jsxPragma should be part of standard somehow.

It would be the same idea as defining globals in one place vs. adding /* global describe */ to every test file.

Except that is exactly what we think should happen,  because anything else means implied context which causes programmer errors and should be avoided.
I like to code by the phrase:

if it is ugly,  make it as ugly as possible,  unless its beautiful,  in which case let it be beautiful

@dcousens I 100% agree with you.
Maybe I'm wrong but I just don't see the pragma falls into the globals category. As I see it, globals are implicitly defined and explicitly used and in the jsx case it something that explicitly required (not global) but used implicitly.
I thought that jsx support should include the configuration (rules) + pragma definition (setting by the user) because its not complete without the pragma but now I have better understanding about your point of view. Not sure about my opinion.
Is this the only use case for this scenario (explicit require and implicit use) ?

@mike-engel What's the workaround you're using for Preact (if you found one)? As of right now, standardjs seems unusable for a preact app since it catches every instance of h as unused. And I'm not adding /** @jsx h */ to every component file, that seems unreasonable.

@jsonmaur preact didn't end up working back then for what we needed, so we never had to support standard + preact together

I am using Preact in a new app I'm building. Right now, I'm just adding /** @jsx h */ to the top of every component file. It's not that bad.

@mattdesl Re-opening to consider how to improve this in future versions.

I would like to address this in a future version of standard. Does anyone have interest in sending a PR to standard-engine to add a jsxPragma option that can get picked up from the package.json configuration key?

React is moving away from requiring that React is in scope, and instead the jsx transpiler adds the appropriate import. Maybe the way forward is to simply disable this rule? 🤔

@LinusU Happy to do that! But if we do that will we get another error related to using an undefined variable?

I guess JSX needs React to be in scope.
So, if you were to simply import react at the very top, you can get past this problem.

I am developing a React component as an npm package. I need this rule enabled, otherwise my code cannot be used in other projects. How can I enable react-in-jsx-scope?


Incorrect casing on cosmos LCD query response types

I'm pretty ignorant of the mechanics of proto generation, and am not positive this is a telescope issue. I'm also working with the upcoming .46 cosmos release, which might be relevant
Basically, I have a repo (https://github.com/haveanicedavid/groups-ui) which is using a package (https://github.com/haveanicedavid/cosmos-groups-ts) generated through telescope, where I

pulled down the latest tagged SDK .46 release (v0.46.1)
copied the proto tags over from /proto in SDK to /proto in the telescope proj
pulled in missing proto files from the buf registry (buf export buf.build/cosmos/cosmos-sdk:$(curl -sS https://api.github.com/repos/cosmos/cosmos-sdk/commits/v0.46.1 | jq -r .sha) --output ./proto in the telescope proj)
ran the codegen script yarn codegen (fixing proto errors til it runs correctly) and published to NPM

With that, i've been able to generate an LCD client through the factory and successfully run queries, and the shape of response data on those queries is correct, but the casing is off because LCD / REST sends properties in snake_case. For example the GroupInfo interface:

compared to the response (totalWeight vs total_weight, created_at vs createdAt):

Again, I’m not sure this is an issue with telescope or on my end (there are a lot of moving parts), but it seems like the response data for LCD / REST is structured as snake_case: https://docs.cosmos.network/master/modules/group/#rest so presumably this could impact all LCD query clients generated with cosmos protos

thank you @haveanicedavid — this is super detailed.
I'll dig into this. It could be we may want to visit the keepCasing option in the parser and then make sure that all works well with the existing protos.

https://github.com/cosmos/cosmos-sdk/issues/8055 <- possibly relevant. If cosmos-SDK switches to camelCase for V2 of grpc gateway, this should be a non-issue I think
@pyramation in the immediate, if there’s an easy way to implement something like keepCasing and produce snake_case types, that would be helpful for me and presumably anyone else using LCD clients — but again, only seems worth your time if it’s easy given the above

Thanks again btw! I pulled your repo down, the LCD endpoints seem to be in snake_case, not camelCase. Please read my findings below and let me know if I've misunderstood the problem.

Perhaps we just have some confusion? One idea I had... were you trying to type responses with GroupInfo instead of using the result directly from the typed response? Keep in mind, the LCD automatically types the responses with QueryGroupInfoResponse which is
export interface QueryGroupInfoResponse {
  /** info is the GroupInfo for the group. */
  info: GroupInfoRes;
}

export interface GroupInfoRes {
  /** id is the unique ID of the group. */
  id: Long;

  /** admin is the account address of the group's admin. */
  admin: string;

  /** metadata is any arbitrary metadata to attached to the group. */
  metadata: string;

  /**
   * version is used to track changes to a group's membership structure that
   * would break existing proposals. Whenever any members weight is changed,
   * or any member is added or removed this version is incremented and will
   * cause proposals based on older versions of this group to fail
   */
  version: Long;

  /** total_weight is the sum of the group members' weights. */
  total_weight: string;

  /** created_at is a timestamp specifying when a group was created. */
  created_at: string;
}

ok so, maybe I did miss this manual commit: https://github.com/haveanicedavid/cosmos-groups-ts/commit/913823e97b4338a4e7bc6fd4728edfc4a01300b2
so I take it this is why things are snake_case.

@pyramation Sorry, I should have clarified - yes, I recently updated those types manually for response values just to get back to the UI work - anywhere you see Res appended to the end of a definition (mostly within response.lcd.ts), that was manual
If you pull down https://github.com/haveanicedavid/cosmos-groups-ts and run a yarn codegen, I believe it will overwrite the manual definitions. Or you could dowgrade the comsos-groups-ts package to a prior version (like 0.0.12)

@pyramation Sorry, I should have clarified - yes, I recently updated those types manually for response values just to get back to the UI work - anywhere you see Res appended to the end of a definition (mostly within response.lcd.ts), that was manual

thanks appreciate it! glad you can focus on the UI!
I'll see if I can explore the keepCasing w/o breaking other parts of the app.

@pyramation 🙏
Please don’t spend too much time on it - it’s not too hard to manually modify some of the types. FWIW, telescope has still been a huge timesaver, and the convenience methods are great!

Please don’t spend too much time on it - it’s not too hard to manually modify some of the types. FWIW, telescope has still been a huge timesaver, and the convenience methods are great!

Wow thank you so much! That means a lot.
Well, I've got a PR I'll start working on, we can track it here: https://github.com/osmosis-labs/telescope/pull/195
It's possible that it works, so I could probably publish it with defaulting to the current casing, but it would allow us to test the original casing. If it breaks, at least other projects won't break since we can keep it under a flag/option, and then fix whatever needs to be in order to properly encode protos w the new casing.

Successfully published:
 -<EMAIL_ADDRESS>
this has the prototypes.parser.keepCase option

maybe we can give it a whirl. I would guess there are likely issues, but if we can successfully make TXs, then this should work! Otherwise I'll keep chipping away at it ;) We should probably default to keepCase — it was inherited from ts-proto and we should use the original developer go protobuf casing anyhow.

oh awesome! I’ll try it out either later tonight or tomorrow morning. Thank you!

actually seems like TX creation through the MessageComposer works fine! But there is an issue making queries with snake_case params.
IE this (excerpt.. pseudo-codey to show snake keys`) works:
  return cosmosgroups.MessageComposer.withTypeUrl.createGroupWithPolicy({
    admin,
    decision_policy,
    group_policy_metadata: '',
    group_policy_as_admin: policyAsAdmin === 'true',
    group_metadata: JSON.stringify({
      name,
      description,
      forumLink,
      updatedAt: new Date().toString(),
      other: otherMetadata,
    }),
    members: groupMembers,
  })

but this does not:
    const lcdClient = await cosmos.ClientFactory.createLCDClient({
      restEndpoint: Chain.active.rest,
    })
    lcdClient.cosmos.group.v1.groupMembers({ group_id })

— it expects a camelCase property. Bypassing TS, it returns data as expected:
    // @ts-ignore
    lcdClient.cosmos.group.v1.groupMembers({ groupId })

oh interesting! so maybe we just need to fix the LCD. I'll dig in.
Very happy to hear that TXs work :)

ok so looks like inside of the LCD, we're doing this:
  async groupInfo(params: QueryGroupInfoRequest): Promise<QueryGroupInfoResponse> {
    const endpoint = `cosmos/group/v1/group_info/${params.groupId}`;
    return await this.request<QueryGroupInfoResponse>(endpoint);
  }

so technically, if we fix cosmos/group/v1/group_info/${params.groupId} to be cosmos/group/v1/group_info/${params.group_id} it should work!

@pyramation I noticed that poking around last night, and was trying to figure out how that’s set within telescope but am still pretty new to the codebase. I should have time later tonight to poke around and see if I can hack together a potential fix, but pointers are welcome 😄
It does seem that if the value inside the LCD client is modified (ie to group_id) it should work!

I'm working on a fix!

https://github.com/osmosis-labs/telescope/pull/196
Successfully published:
 -<EMAIL_ADDRESS>
some new updates

I think it may do what we need?

Awesome! Not only fixes the original issue, but also optional types aroudn pagination. Pulled in the new changes, and was able to run all the LCD queries and messages I have implemented without modifying the generated types at all 🥳 🎉
Closing the issue - thanks so much!

amazing! great to hear!
I guess the question I have for telescope now is, how to manage when keepCase:false — I'll make a new issue ;)

Oh hope I didn't close prematurely! Feel free to re-open. Happy to help testing moving forward as well if you make a new issue - just tag me

totally cool! I made an issue here we can track: #197


The problem is the second line in this sequence:
        record_ids = [
            record_id
            for record in at_only.values()
            if record.custom_fields.get(field_name) != field_val
        ]

which should have been:
        record_ids = [
            record.record_id
            for record in at_only.values()
            if record.custom_fields.get(field_name) != field_val
        ]


All Engine roll LUCI presubmit jobs queuing for 19+ hours

https://github.com/flutter/flutter/pull/76956

Looks to me like these never got scheduled https://ci.chromium.org/p/flutter/builders/try/Linux analyze

Starting on 02/27 at 08:16 PST the handler to update the build status started failing with:

2021-02-27 08:16:48.526 PST
Available tags: [build_address:luci.flutter.try/Linux Arm Host Engine/1943, builder:Linux Arm Host Engine, buildset:pr/git/24683, buildset:sha/git/97446127fb8a36b49597945839863e215ed533a7, github_link:https://github.com/flutter/engine/pull/24683, swarming_hostname:chromium-swarm.appspot.com, swarming_tag:log_location:logdog://logs.chromium.org/flutter/buildbucket/cr-buildbucket.appspot.com/8854127956672830000/+/annotations, swarming_tag:luci_project:flutter, swarming_tag:os:Debian, swarming_tag:recipe_name:engine/engine_arm, swarming_tag:recipe_package:flutter/recipe_bundles/flutter.googlesource.com/recipes, swarming_task_id:51fd18996cd33410, user_agent:flutter-cocoon]
2021-02-27 08:16:48.526 PST
Setting status: {build: Instance of 'Build', hostname: cr-buildbucket.appspot.com, user_data: {"repo_owner":"flutter","repo_name":"engine","user_agent":"flutter-cocoon","check_run_id":1994602313}} for Linux Arm Host Engine
2021-02-27 08:16:48.781 PST
GitHub Error: Requested Resource was Not Found
#0      GitHub.handleStatusCode (package:github/src/common/github.dart:400:9)
#1      GitHub.request (package:github/src/common/github.dart:372:7)
<asynchronous suspension>
#2      GitHub.requestJson (package:github/src/common/github.dart:268:22)
<asynchronous suspension>
#3      GithubChecksService.updateCheckStatus (package:cocoon_service/src/service/github_checks_service.dart:116:38)
<asynchronous suspension>
#4      LuciStatusHandler.post (package:cocoon_service/src/request_handlers/luci_status.dart:99:7)
<asynchronous suspension>
#5      RequestHandler.service.<anonymous closure> (package:cocoon_service/src/request_handling/request_handler.dart:49:22)
<asynchronous suspension>
#6      main.<anonymous closure>.<anonymous closure> (file:///app/bin/server.dart:134:9)
<asynchronous suspension>

It seems to have been resolved at 02/28 at 19:53 PST. This was a problem with the github APIs.
Do we have rolls started today with the same issue?

I have not checked. Should we close the current roll and kick off a new one?

I closed the current roll, and will keep an eye on the new one.

Perfect, I'll take a look too.

New roll is here https://github.com/flutter/flutter/pull/76995

Leaving this issue open to track possible solutions to handling github api outages, which would produce these symptoms. Possible solution is to have us retry with backoff.

Duplicating this against https://github.com/flutter/flutter/issues/86383. We've enabled the ci.yaml check to ensure builds are scheduled.


Missing icon

 Issue by 00alis
Wednesday Oct 22, 2014 at 16:22 GMT
Originally opened as https://github.com/arduino/forum2/issues/66

sent items

Closing as obsoleted by the switch to a Discourse based forum this week.


Add not between operator

Use case: You have the between operator and it would be extremely beneficial for it to allow NOT in front of it
Feature description: If I wanted to run a query that gave me results that didn't appear within a certain timerange, I could use NOT BETWEEN
WHERE date NOT BETWEEN ? AND ?

closing due to user error


Fix lifetime annotation of some Path operations.

Consider this line: let path2 = path1.sub("test")
Currently, because of a lifetime annotation, compiler consider path2 be borrowing path1. This prevents path1 being dropped while path2 is in use. However, this is unnecessary as path2 isn't actually borrowing anything in path1. This change removes the annotation.

Looks good, thanks for the PR!


fix: add overflow-auto for homepage code block

Why not white-space: pre-wrap.

Fixup from twitter.

Because:

Why not white-space: pre-line.

Fixup from other pr

Because:

Why this?
Because I'm don't want to fix the bug for mobiles and create a new bug for desktops. I know this issue, I'm the creator of this issue. It's global file what uses not only on the homepage when I'm found the best option to fix this I fix this globally, but this fixes this strange global message.
Life is Strange 2

This closes #2629

This closes #2629 I think?

Updated with closes


use CLIEngine & jest to test

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- tests/configs.test.js  1

Clones added
============
- tests/configs.test.js  2

See the complete overview on Codacy


[Draft] Add the function to update user's language setting

Close: #268
I added two APIs(functions) in this work. One is a function that takes username as a parameter and returns the language of the corresponding account(L422~L425 in account.rs), and the other is a function that takes username as a parameter and modifies the language of the corresponding account.
However, while writing the test code, I found that if we ask for account query, we can get the value of the language field. I wasn't sure if we really need the first function.
I thought maybe I was misunderstanding the work I was assigned. So I opened work on #268 issue with draft PR. I would sincerely appreciate it if you could comment on my work, and if there is anything I misunderstood, I will immediately correct it and continue the work. @sophie-cluml  @sehkone

I am afraid I didn't understand what you meant by this:

However, while writing the test code, I found that if we ask for account query, we can get the value of the language field. I wasn't sure if we really need the first function.

Is this question relevant to the previous discussion https://github.com/aicers/review-web/pull/258#pullrequestreview-2241846640 ? If not, could you help me understand please?

I am afraid I didn't understand what you meant by this:

However, while writing the test code, I found that if we ask for account query, we can get the value of the language field. I wasn't sure if we really need the first function.

Is this question relevant to the previous discussion #258 (review) ? If not, could you help me understand please?

I didn't understand it while I was working on it, but I found what I misunderstood. You can forget about it. I will change the PR to ready to merge as it is.

The commit message currently only mentions functions, but I think it should specify that they are GraphQL APIs.

The commit message currently only mentions functions, but I think it should specify that they are GraphQL APIs.

I modified the commit message and I have just force-pushed the commit.

@div-seungha
The commit message should be corrected. update_language is not the GraphQL API but its corresponding Rust method

@div-seungha
The commit message should be corrected. update_language is not the GraphQL API but its corresponding Rust method

I have replaced update_language with updateLanguage in the commit message.


Add two new pipelines for performing comet

I added two pipelines for performing comet. These two pipelines are an integration of the following four steps existing in the current comet: (1) run comet to get collections of exclusive gene sets (run_comet.py), (2) perform comet on permuted matrices (run_comet_permutation.py), (3a) compute significance, (3b) create visualization (compute_significance.py).

The first pipeline (run_comet_simple.py) provide the function to get collections of exclusive gene sets  and have the visualization of these collections, i.e. combines steps (1) and (3b).
The second pipeline (run_comet_full.py) provide the function to get collections of exclusive gene sets, permute matrices, perform significant test, and have the visualization of significant collections, i.e. go through (1), (2), (3a) and (3b).

I am going to summarize my thoughts here, and then add line comments as necessary about the code.
Can you go through the suggestions below that you agree with and do the easiest ones? Then we should merge and tackle any remaining items over the coming weeks.
Correctness
The new pipeline looks like a big improvement over the current version of the code to me. I successfully ran two examples testing out the new pipeline with only one minor change required (dealing with the Multi-Dendrix dependency correctly):
$ python run_comet_full.py -np 1 -o tmp -m example_datasets/gbm/GBM.m2 -mf 10 -gf example_datasets/gbm/GBM.glst -ks 3 3 -N 10000 -r 1
$ python run_comet_simple.py -o tmp -m example_datasets/gbm/GBM.m2 -mf 10 -gf example_datasets/gbm/GBM.glst -ks 3 3 -N 10000 -r 1

Design
Command line interface

Can we merge the run_comet_full.py, run_comet_simple.py, and run_exhaustive.py scripts? I think ideally we could use the argparse subparsers (like we do for HotNet2) to get functionality like this:
  $ python run_comet.py simple [...]
  $ python run_comet.py full [...]
  $ python run_comet.py

To do this, maybe just move the bulk of the code for each into comet/simple.py, comet/full.py, and comet/exhaustive.py?

Didn't we discuss adding a P-value threshold parameter for adding edges to the marginal probability graph? I think this is vital, since we used such a threshold in the simulations.

Datasets
Can you add the LAML, BRCA, and STAD datafiles to the example_datasets? BRCA/STAD is particularly important so we can easily test the subtype runs, which I did not test yet.
Output

We discussed a new format for the output TSV files? Do you remember what this was? I remember clearly that "Target Weight" was removed, but otherwise am not sure.
We need to output the "consensus" modules in text format.
We should change the JSON file to always be named params .json. Further, it should always be in the topmost directory of the output directory (rather than in the results/ subdirectory).
We should also update the output to standard out.

Visualization
We should update the mutation matrix code to the latest version of GD3, which is much more functional. Alternately, we could add GD3 as a requirement to bower.json.
Code
There are a number of sections of code that need to be rewritten, but I vote to push this until after we finish the "redesign".


HAWQ-1061. Add check_sizes_valid for all mode of hawq register.

cc @ictmalili @linwen

also cc @stanlyxiang

+1

+1

Merged into master.


history.listen doesn't fire when route changes via history.push

Version
5.0.0
Test Case

Steps to reproduce

import { withRouter, Link } from 'react-router-dom';
componentDidMount() {this.unlisten = this.props.history.listen(() => console.log('route changed')); }
componentWillUnmount() {this.unlisten();}
this.props.history.push('url'); in my case this line executed after ajax req
export default connect(mapStateToProps, mapDispatchToProps)(withRouter(MyCom));

Expected Behavior
console.log('route changed') should run after step 4. but it doesn't.
Actual Behavior
history.listen doesn't fire.
BTW when if route changes via <Link>, everything is fine.

Please don't recreate issues.

@timdorr please don't close the issue without any explanation then! if this is not a bug, what is this?

@dehghani-mehdi This is an issue related to ReactTraining/history not to React Router.

Just for reference, for more info about this issue, see: https://github.com/ReactTraining/history/issues/710


Text correction

For line "For our application we require 3 tables" should this be "For our application we require 3 databases" ?

Absolutely! Nice catch. Fixed in 78ddfb30ef6d6fada6e7a39176d0628fbc0f733f


Uberon import redundantly brings in a chunk of NCBI taxonomy

/extensions/uberon_import.owl includes a chunk of NCBI taxonomy - this is redundant with the taxonomy directly imported. Would be better if it just included dangling references to the terms used.
CC @hdietze

General issue, for CL etc. Some notes here: https://github.com/ontodev/robot/issues/38

Is this fixed ? @balhoff perhaps you know?

Is this still valid @balhoff?
I'm not trying to close tickets tright now, I just spotted it while looking for something else....

This looks to be still the case. We can fix this by extracting the GO uberon_import from the new uberon-base.owl published by Uberon, but I would like to first discuss with @cmungall some issues about checking transitive ontology dependencies.

This should be fixed by the next Uberon release.


Consider: requiring --cfg allow_crate_unstable

I believe that by requiring a --cfg opt in (i.e. in RUSTFLAGS) it is possible to support "layered unstablility" while preventing "unstability hiding".
Specifically: if semver-exempt features are available under (just) a normal cargo feature flag, it is possible that you use some crate awsm-sauce under its default features and assume everything is stable, but in actuality awsm-sauce enables some unstable-risky-feature in the crate upstream, exposing you to semver breakage if upstream takes advantage of the fact the functionality is marked unstable to change it in an API breaking way. Even though your application did not acknowledge the use of unstable features at all.
This is the reason that proc-macro2 requires setting --cfg procmacro2_semver_exempt to get access to unstable features.

Note that this must not only be done for your crate, but for any crate that depends on your crate. This infectious nature is intentional, as it serves as a reminder that you are outside of the normal semver guarantees.

However, extending this pattern to more than one crate is problematic, because while the lack of being able to encapsulate this is desired, it makes writing libraries utilizing upstream unstable features impractical. Say I'm the author awsm-sauce: now upstream is requiring --cfg upstream_semver_exempt, and I've realized the error of my ways, so gate the use of unstable parts of upstream behind an unstable-* flag. But now, even though my consumers are reasonably hidden from my use of upstream, and they're explicitly opting into my unstable API surface, they have to also opt into upstream's unstable surface.
My proposed solution: form a consensus that every crate should use the same --cfg flag, e.g. allow_crate_unstable (that's a literal crate, not a placeholder for the crate name) or allow_3rd_party_unstable or crates_are_semver_exempt; something illustrative. The point is to have a singular opt-in for builds which unlocks the ability to enable any crate's unstable APIs, just like using the nightly Rust toolchain gives all crates being compiled the ability to enable #![feature]s.
Suggested implementation
Normally annotated functions:
/// This function does something really risky!
///
/// Don't use it yet!
#[stability::unstable(feature = "risky-function")]
pub fn risky_function() {
    impl_body!()
}

// becomes

/// This function does something really risky!
///
/// Don't use it yet!
///
/// # Availability
///
/// **This API is marked as unstable** and is only available when the
/// `unstable-risky-function` crate feature is enabled. This comes with no
/// stability guarantees, and could be changed or removed at any time.
#[cfg(all(allow_crate_unstable, feature = "unstable-risky-function"))]
pub fn risky_function() {
    impl_body!()
}

/// This function does something really risky!
///
/// Don't use it yet!
#[cfg(not(all(allow_crate_unstable, feature = "unstable-risky-function")))]
pub(crate) fn risky_function() {
    impl_body!()
}

However, for the usage of upstream unstable, we need additional annotation, because the function cannot even be compiled if the upstream does not expose the used unstable item(s).
/// This function does something really risky!
///
/// Don't use it yet!
#[stability::unstable(feature = "risky-function")]
#[stability::upstream(crate = "proc-macro2", feature = "proc_macro_diagnostic")]
pub fn risky_function() {
    impl_body!()
}

// becomes

/// This function does something really risky!
///
/// Don't use it yet!
///
/// # Availability
///
/// **This API is marked as unstable** and is only available when the
/// `unstable-risky-function` crate feature is enabled. This comes with no
/// stability guarantees, and could be changed or removed at any time.
///
/// **This API uses upstream unstable features** from the following crates:
///
/// - `proc-macro2`: `unstable-proc_macro_diagnostic`
///
/// Using this API exposes you to the unstability of these crates as well.
#[cfg(all(allow_crate_unstable, feature = "unstable-risky-function"))]
pub fn risky_function() {
    impl_body!()
}

#[stability::upstream] is a pseudo-attribute recognized, parsed, and stripped by #[stability::unstable].
If always requiring RUSTFLAGS=--cfg allow_crate_unstable is deemed excessive, we could allow the use of some e.g. this-software-is-provided-as-is-with-no-warranty-of-any-kind feature alternative to --cfg allow_crate_unstable, with an attached disclaimer that this disables the protection against hiding instability.

This is an interesting proposal, thanks for writing it up. I'll have to think on this.

A small revision to the suggested expansion:

#[cfg(feature = "unstable-risky-function")]
pub fn risky_function() {
    impl_body!()
}

#[cfg(not(feature = "unstable-risky-function"))]
pub(crate) fn risky_function() {
    impl_body!()
}

#[cfg(all(feature = "unstable-risky-function", not(allow_crate_unstable))]
compile_error!("use of feature(unstable-risky-function) requires --cfg allow_crate_unstable");

This has the advantage of providing a targeted error explaining that use of the feature requires a --cfg opt-in (instead of just saying the function is private).
It has the downside of duplicating this message for every API gated on the same feature flag. This could be mitigated by the proc macro maintaining a global memo of what feature flags have already had a guard emitted... though I worry both that this mitigation breaks build determinism (e.g. if the macros are handled in a different unspecified order) and might sometimes maintain state between crates (e.g. making whether a feature is gated depend on whether state from a previous compilation is still in cache).


[22.0.x] Fix publication of wasmtime-wasi-threads for the future

Semi-backport of #8986 to remove invalid categories of the wasmtime-wasi-threads crate that aren't present on crates.io.

See also https://github.com/bytecodealliance/wasmtime/pull/9424 for the 21.0.x branch


upgraded package keep showing in the upgrade list

Brief description of your issue
There are two packages in my system:
Name                        Id                   Version       Available  Source
--------------------------------------------------------------------------------
Logitech G HUB              Logitech.GHUB        2022.6.271036 2022.7.502 winget
Everything <IP_ADDRESS>9 (x64) voidtools.Everything < <IP_ADDRESS>4  <IP_ADDRESS>7 winget

That winget cannot recognize the upgraded version.
Steps to reproduce

winget upgrade --all to upgrade packages.

Run the command again.

Expected behavior
After upgrading, winget should recognize the upgraded ones.
Actual behavior
winget does not recognize the upgraded ones.
The img below shows the software has actually been upgraded:

Environment
Windows Package Manager v1.3.2091
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22000.795
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.18.2091.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Duplicate of #2425


Would you add GammaM0, GammaM1 and GammaM3 into class ConnectionSetup?

Hi,
I want new parameters in  ConnectionSetup class. I need GammaM0, GammaM1 and GammaM3. It is possible to get value from this parameters?
Best regards
Witek

Hi Nathan,
Sorry γM3 exists inside class ConnectionSetup, but we need to set γM0, γM1 and γM2.
Assembly IdeaRS.OpenModel, Version=<IP_ADDRESS>

Best regards
Witek

Hi Witek,
This is actually already possible. SteelSetup is an abstract class you can you to set these values. Create a new SteelSetupECEN() class and assign it to the SteelSetup property. There is an example below:
public static void SetECENSetupValues(ConnectionSetup setup)
{
    setup.SteelSetup = new SteelSetupECEN()
    {
        GammaM0 = 0,
        GammaM1 = 1,
        GammaM2 = 2,
        GammaMfi = 3,
        GammaMu = 4
    };
}

Please let me know if you have problems with this.
Thanks
Nathan


Show capabilities summary for LSP in :LspInfo

Language server
No response
Requested feature
A common pattern of users' on_attach functions is to gate keymaps and functionality based on the server's capabilities, e.g.:
if client.server_capabilities.documentHighlightProvider then
  -- ...
end

As such, it'd be nice to have an overview of what the currently attached LSP server is capable of.
Other clients which have this feature
No response

Given the resolution of #2932, should we just close this?


Way to use a proxy (code inside)

I tried to make a pull request but I have no permission. All I did was add a way to use a proxy, it doesn't affect anything else. To use it just pass this object to the constructors:
proxies = {
  'http': 'http://<IP_ADDRESS>:3128', # Examples
  'https': 'http://<IP_ADDRESS>:1080',
}
ts = TimeSeries(key=key, proxies=proxies)

http://docs.python-requests.org/en/latest/user/advanced/#proxies
git diff:
diff --git a/alpha_vantage/alphavantage.py b/alpha_vantage/alphavantage.py
index 925156f..7ff006a 100644
--- a/alpha_vantage/alphavantage.py
+++ b/alpha_vantage/alphavantage.py
@@ -28,7 +28,7 @@ class AlphaVantage(object):
         "https://www.alphavantage.co/digital_currency_list/"

     def __init__(self, key=None, retries=5, output_format='json',
-                 treat_info_as_error=True, indexing_type='date'):
+                 treat_info_as_error=True, indexing_type='date', proxies={}):
         """ Initialize the class

         Keyword Arguments:
@@ -58,6 +58,7 @@ class AlphaVantage(object):
         # variable will be overriden by those functions not needing it.
         self._append_type = True
         self.indexing_type = indexing_type
+        self.proxies = proxies

     def _retry(func):
         """ Decorator for retrying api calls (in case of errors from the api
@@ -254,7 +255,7 @@ class AlphaVantage(object):
             meta_data_key:  The key for getting the meta data information out
             of the json object
         """
-        response = requests.get(url)
+        response = requests.get(url, proxies=self.proxies)
         if 'json' in self.output_format.lower() or 'pandas' in \
                 self.output_format.lower():
             json_response = response.json()

If you add this, can you also add a function setProxy(proxy), please? I'm finding it useful.

Hi @jmcneves, thanks for your issue. How come you don't have permissions? It would be awesome if you could do the PR it is your feature and it would be cool if it showed in the library that way (I've got some pull request already and they worked well). Give it another try and if not I'll update the library and generate another release.
Saludos,
Romel

You're right, I forgot about forks and I was trying to make a branch.
https://github.com/RomelTorres/alpha_vantage/pull/59

merged


[PERF] Better tracing for storage access

Description of changes
Summarize the changes made by this PR.

Improvements & Bug fixes

Cleaner tracing for reading blocks
Cleaner tracing for reading hnsw

New functionality

None

Test plan
How are these changes tested?

[x] Tests pass locally with pytest for python, yarn test for js, cargo test for rust

Documentation Changes
None

Merging despite test failure - which I fix in #2501 but that is waiting for review. This change 100% is unrelated to that.


feat: SDK for using filter/lightpush

Filter relies in many ways on the same building blocks as relay for its reliability, but in a modular, "pick your own tradeoffs" way:

redundancy (for relay in full message connections, for filter in subscriptions)
randomness (selecting random peers for connection/subscription, preferably with some peer cycling)
periodically checking that you received all messages against a cache (this doesn't really exist yet for filter, but you could imagine using occasional store queries to achieve something similar)

As such it will be helpful to provide a configurable "reliability" SDK on top of filter for projects without the capacity to build these features from the ground up with filter.
Priority: not critical for launch

Where does this come from? Seems like a dupe of #1463

@fryorcraken  Looks like its a task under 2.1 here https://github.com/waku-org/research/issues/3 under the task breakdown comment.

@fryorcraken let me know if #1463 should replace this issue

superseded by  #1463


bug(zero-bin): regression with native tracer

We're observing a regression since the merge of #393 with the native tracer.
It seems any Cancun block on latest develop when fetched with a native tracer is failing during proof generation with error of the following kind on the prover side:
assertion `left == right` failed: In TrieInputs, an account's storage_root didn't match the associated storage trie hash
  left: 0x13a9d067b4c956eac54aecf8510ab9966746e412975d630b720f6ce2c68eb80c
 right: 0xb6ee1b643986085199b2bf7a2d669665b901fd370ac35ddbd823dddff8ae74eb

Steps to reproduce

check out develop at commit f531584baff69e5afcbf122b30dbc697db3fadc3

build leader (test_only features enabled, as it is enough to highlight the bug and limits runtime)

run RUST_LOG=info ./target/release/leader --runtime in-memory --load-strategy on-demand rpc --rpc-type native --rpc-url native_rpc_endpoint --block-interval 19807080..19807081 --backoff 1000 --max-retries 1000 (any block works, but this one is small so convenient for testing) -> ❌

Skip last PR changes: develop commit a5b92b2b2bcc7bbf8725190aaa0fba7007e51a6a

repeat build and run step -> ✅

@0xaatif would you mind looking at it as it relates to your refactoring PR?

The StorageTrie is wrong, it shouldn't use TypedMpt, it should only be a thin wrapper over hashedpartialtrie. I'll open a PR this evening


Provide a sendfile implementation for Netty based on io_uring.

Motivation:
Provide a sendfile implementation for Netty based on io_uring.
https://github.com/netty/netty-incubator-transport-io_uring/issues/210
Modification:
Provide a sendfile implementation for Netty based on io_uring.
Result:
https://github.com/netty/netty-incubator-transport-io_uring/issues/210

Will have a look soon

@dreamlike-ocean did you sign our ICLA? https://netty.io/s/icla

Yes. I have signed the ICLA.

@dreamlike-ocean ok ... I will take it from here. This needs a bit of work


problem about results

Dear author,
When the keyword in my input.out is:

...
...
ML-relevant keywords
ml_model = 'nn'
...
...

That is, when I select  neural network, the fitted output file is different from Gaussian regression.
The output files of Gaussian regression are: compute_energy.py  hyperparameters  model.json  performance and so on
but  output files of   neural network are ; hyperparameters  model.pt  PES.dat  test_set  train_set
Are these correct? Do not have "performance"
if correct
How should I use the NN model?
like using  the GP model,  have an instance on this webpage:
https://github.com/CCQC/PES-Learn/blob/master/1_Tutorials/0_water_pes_command_line_interface/cli_tutorial.md
"The compute_energy.py file can be imported and used. Here's an example python script use_model.py which imports the pes function and evaluates some energies at some cartesian geometries."
Thanks for your help!!!

The compute_energy.py file for neural networks is not quite finished. I will add it in the next few days. Once the change is applied, you will have to git pull to update PES-Learn. To generate the convenience function, you will likely have to train a new model. Sorry about that!

Should be fixed now. Trained NN's now produce compute_energy.py, and performance files.


[core] Introduce index metadata

Purpose

The index file is partition + bucket granularity.
This is the pre work of dynamic buckets, which allows for saving which keys are contained in a bucket in dynamic bucket mode, in order to locate the bucket of the key.
Tests

API and Format

Documentation

+1


Styling issues on firefox 50.1.0 on linux

The default browser for linux mint is currently firefox 50.1.0. The text and graphics extend all the way from one side of the screen to the other with no border. There are also large vertical gaps between some sections.

@jrkirby thanks for letting us know!
While I can't promise a quick fix, we will include better fallback styles for browsers that we can't polyfill. That being said, I don't immediately see why Firefox 50 wouldn't be polyfilled correctly, so this warrants a deeper look.


support proxy for provider side. #67

What is the purpose of the change
Support use custom proxy to generate invoker on provider side.
Brief changelog

dubbo-config/dubbo-config-api/src/main/java/com/alibaba/dubbo/config/ServiceConfig.java
Unit tests

Verifying this change
Add related test case.
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[ ] Run mvn clean install -DskipTests & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #1873 into master will increase coverage by 0.02%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master    #1873      +/-   ##
============================================
+ Coverage     42.49%   42.51%   +0.02%
- Complexity     4707     4713       +6
============================================
  Files           646      646
  Lines         30680    30683       +3
  Branches       5390     5391       +1
============================================
+ Hits          13037    13046       +9
+ Misses        15620    15617       -3
+ Partials       2023     2020       -3

Impacted Files
Coverage Δ
Complexity Δ

...n/java/com/alibaba/dubbo/config/ServiceConfig.java
47.44% <100%> (+0.83%)
62 <0> (+3)
:arrow_up:

.../dubbo/monitor/support/AbstractMonitorFactory.java
84.09% <0%> (+2.27%)
6% <0%> (+1%)
:arrow_up:

...rpc/protocol/dubbo/telnet/InvokeTelnetHandler.java
55.69% <0%> (+3.79%)
13% <0%> (+2%)
:arrow_up:

Continue to review full report at Codecov.

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


Feature/upse 311

Checklist

[x ] the individual contributor license agreement is signed
[x ] commit message follows commit guidelines
[ ] tests are included
[ ] documentation is changed or added
[ ] message properties have been updated with new phrases
[ ] view conforms with WCAG 2.0 AA

Description of change

Thanks for adding related docs in https://github.com/uPortal-Project/uportal-project.github.io/pull/44 !


New new proposal

This proposal is open for discussion and voting. If you are an eligible voter on this project (and not the proposer), you may cast your vote on whether or not it is accepted.
How to vote
Vote by entering one of the following symbols in a comment on this pull request. Only your last vote will be counted, and you may change your vote at any time until the change is accepted or closed.

vote
symbol
type this
points

Yes
:white_check_mark:
:white_check_mark:
1

No
:negative_squared_cross_mark:
:negative_squared_cross_mark:
-1

Abstain
:zipper_mouth_face:
:zipper_mouth_face:
0

Block
:no_entry_sign:
:no_entry_sign:
-1000

Proposals will be accepted and merged once they have a total of 2 points when all votes are counted. Votes will be open for a minimum of 7 days, but will be closed if the proposal is not accepted after 90.
Votes are counted automatically here, and results are set in the merge status checks below.
Changes
@jt-nti, if you want to make further changes to this proposal, you can do so by clicking on the pencil icons here. If a change is made to the proposal, no votes cast before that change will be counted, and votes must be recast.


Panic on bulk update requests

Please use the following questions as a guideline to help me answer
your issue/question without further inquiry. Thank you.
Which version of Elastic are you using?
[ ] elastic.v2 (for Elasticsearch 1.x)
[x] elastic.v3 (for Elasticsearch 2.x)
[ ] elastic.v5 (for Elasticsearch 5.x)
Go Version: 1.7.4
Please describe the expected behavior
suppressing error
Please describe the actual behavior
error message:
panic: value method elastic.BulkUpdateRequest.Source called using nil *BulkUpdateRequest pointer

goroutine 362 [running]:
panic(0xb428c0, 0xc420b65290)
        /usr/local/go/src/runtime/panic.go:500 +0x1a1
gopkg.in/olivere/elastic%2ev3.(*BulkUpdateRequest).Source(0x0, 0xc42085fa0a, 0x0, 0x0, 0x0, 0x0)
        <autogenerated>:1606 +0x124
gopkg.in/olivere/elastic%2ev3.(*BulkService).bodyAsString(0xc423bec380, 0x7fd112e68000, 0x0, 0x417055, 0x413f6a)
        /mnt2/dpkg-build/ads-build/src/gopkg.in/olivere/elastic.v3/bulk.go:139 +0x8f
gopkg.in/olivere/elastic%2ev3.(*BulkService).DoC(0xc423bec380, 0x0, 0x0, 0xc42498bc70, 0xc4203bb6a0, 0x59c0f8)
        /mnt2/dpkg-build/ads-build/src/gopkg.in/olivere/elastic.v3/bulk.go:169 +0xee
gopkg.in/olivere/elastic%2ev3.(*BulkService).Do(0xc423bec380, 0xca7ae8, 0xc42498bc70, 0x0)
        /mnt2/dpkg-build/ads-build/src/gopkg.in/olivere/elastic.v3/bulk.go:156 +0x3d
...

using the latest commit
Any steps to reproduce the behavior?
Sorry, I have no clue about it.
I've add validation req != nil. still got the same error though it's occasionally happen (about one in every million call)

Bulk only uses the requests that you pass into it via Add? Are you sure you do not pass a nil request to Add somehow?

Maybe you have some sort of concurrency issue here, where you re-use a *BulkUpdateRequest in your code? Testing with the race detector enabled could help you find such issues.

I add validation right before calling req.Source() on bulk.go file seems not help. About race condition, I use mutex, define variable locally, avoid go-routine (inside & caller function itself) and also testing Copy() of s.requests into a local slice before bodyAsString iteration.
Okay, I'll take a look on it.
Thank You.

I don't think req.Source() is not the problem. I think you add a nil request via Add(...). Please try to figure out if you add a nil there in your code.
var batch []elastic.BulkableRequest
for <some-condition> {
  req := <create-some-bulk-request>
  if req == nil {
    // I think the request might be nil here in your code, so check for this!
    panic("request is nil")
  }
  batch = append(batch ,req)
}
bulk = bulk.Add(batch...)


HDFS-16503. Should verify whether the path name is valid in the WebHDFS

JIRA: HDFS-16503.
When creating a file using WebHDFS, there are two main steps:

Obtain the location of the Datanode to be written.
Put the file to this location.

Currently NameNodeRpcServer verifies that pathName is valid, but NamenodeWebHdfsMethods and RouterWebHdfsMethods do not.
So if we use an invalid path(such as duplicated slash), the first step returns success, but the second step throws an InvalidPathException.
IMO, we should also do the validation in WebHdfs, which is consistent with the NameNodeRpcServer.

The same WebHDFS operations are: CREATE, APPEND, OPEN, GETFILECHECKSUM. So we can add DFSUtil.isValidName to redirectURI for NamenodeWebHdfsMethods and RouterWebHdfsMethods.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 35s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
12m 41s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
23m 11s

trunk passed

+1 :green_heart:
compile
5m 54s

trunk passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
compile
5m 36s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
1m 15s

trunk passed

+1 :green_heart:
mvnsite
3m 13s

trunk passed

+1 :green_heart:
javadoc
2m 29s

trunk passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
3m 11s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
6m 58s

trunk passed

+1 :green_heart:
shadedclient
20m 23s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 26s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 43s

the patch passed

+1 :green_heart:
compile
5m 44s

the patch passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javac
5m 44s

the patch passed

+1 :green_heart:
compile
5m 22s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
5m 22s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  5s

the patch passed

+1 :green_heart:
mvnsite
2m 49s

the patch passed

+1 :green_heart:
javadoc
2m  2s

the patch passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
2m 47s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
7m  9s

the patch passed

+1 :green_heart:
shadedclient
20m 41s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m 22s

hadoop-hdfs-client in the patch passed.

+1 :green_heart:
unit
229m 18s

hadoop-hdfs in the patch passed.

+1 :green_heart:
unit
22m 18s

hadoop-hdfs-rbf in the patch passed.

+1 :green_heart:
asflicense
0m 44s

The patch does not generate ASF License warnings.

393m  1s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4067/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4067

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 119c40a380b8 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / c4587e795a439ed563a824084bf5312765fc0ea3

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4067/1/testReport/

Max. process+thread count
3109 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-client hadoop-hdfs-project/hadoop-hdfs hadoop-hdfs-project/hadoop-hdfs-rbf U: hadoop-hdfs-project

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4067/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

Hi @tasanuma @ayushtkn @Hexiaoqiao , could you please take a look? Thanks.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 43s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
13m 10s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
23m  5s

trunk passed

+1 :green_heart:
compile
5m 50s

trunk passed with JDK Ubuntu-11.0.14+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
5m 29s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
1m 14s

trunk passed

+1 :green_heart:
mvnsite
3m 12s

trunk passed

+1 :green_heart:
javadoc
2m 31s

trunk passed with JDK Ubuntu-11.0.14+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
3m 11s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
6m 58s

trunk passed

+1 :green_heart:
shadedclient
20m 49s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 28s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 42s

the patch passed

+1 :green_heart:
compile
5m 43s

the patch passed with JDK Ubuntu-11.0.14+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
5m 43s

the patch passed

+1 :green_heart:
compile
5m 27s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
5m 27s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  4s

the patch passed

+1 :green_heart:
mvnsite
2m 48s

the patch passed

+1 :green_heart:
javadoc
2m  4s

the patch passed with JDK Ubuntu-11.0.14+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
2m 51s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
7m  6s

the patch passed

+1 :green_heart:
shadedclient
20m 17s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m 24s

hadoop-hdfs-client in the patch passed.

+1 :green_heart:
unit
226m 12s

hadoop-hdfs in the patch passed.

+1 :green_heart:
unit
21m  8s

hadoop-hdfs-rbf in the patch passed.

+1 :green_heart:
asflicense
0m 48s

The patch does not generate ASF License warnings.

389m 19s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4067/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4067

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 7ef8acc83b1c 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 931c6e244a4a84f1369198e4ef16a839019a4a6f

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.14+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4067/2/testReport/

Max. process+thread count
3442 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-client hadoop-hdfs-project/hadoop-hdfs hadoop-hdfs-project/hadoop-hdfs-rbf U: hadoop-hdfs-project

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4067/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 35s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
13m 32s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
24m  0s

trunk passed

+1 :green_heart:
compile
6m 17s

trunk passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
compile
5m 46s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
1m 13s

trunk passed

+1 :green_heart:
mvnsite
3m 10s

trunk passed

+1 :green_heart:
javadoc
2m 30s

trunk passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
3m  8s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
7m 22s

trunk passed

+1 :green_heart:
shadedclient
21m 54s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 27s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 49s

the patch passed

+1 :green_heart:
compile
6m 18s

the patch passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javac
6m 18s

the patch passed

+1 :green_heart:
compile
5m 35s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
5m 35s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  4s

the patch passed

+1 :green_heart:
mvnsite
2m 47s

the patch passed

+1 :green_heart:
javadoc
2m  7s

the patch passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
2m 46s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
7m 37s

the patch passed

+1 :green_heart:
shadedclient
21m 12s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m 27s

hadoop-hdfs-client in the patch passed.

+1 :green_heart:
unit
232m 49s

hadoop-hdfs in the patch passed.

+1 :green_heart:
unit
23m 21s

hadoop-hdfs-rbf in the patch passed.

+1 :green_heart:
asflicense
0m 46s

The patch does not generate ASF License warnings.

403m 22s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4067/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4067

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux f2c49ec998df 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / bcf6935f39c4524eb8b60f0f6a06495c7e795f01

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4067/3/testReport/

Max. process+thread count
3564 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-client hadoop-hdfs-project/hadoop-hdfs hadoop-hdfs-project/hadoop-hdfs-rbf U: hadoop-hdfs-project

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4067/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

Thanks @ayushtkn .


WIP: Revamp Screens

Work In Progress:
Credentials Details / Relationship Detail popup content
Settings Screen
Gifted Chat Buttons
https://user-images.githubusercontent.com/19255438/208125975-b5851da9-c803-4cff-a75c-bd7b2cb00bf9.mov

@AlexAndrei98 @2byrds  this is the progress so far. I am still working on some screens.

Thank you so much for posting @HunnySajid this was very helpful for the meeting.
Here are the notes from watching the video with Ilona and Alex:
Highest priority:
Remove the pink background using the same background as the screen.
Divide the rows by a line at the bottom of each row
Make the key/label bold to distingquish it from value

Medium Priority:
Please put the RootsID logo in the top left corner of the Contacts and Credentials screen so that brand is part of our demo coming up.
Lower priority:
We love the 'card look' of the layers of screens (as the slide up), perhaps even the qrcode modal could slide from the bottom and the user can slide it back down when they are done with it?  In general we want to move consistently towards cards on top of cards and dismissing them the same way throughout the app
We'll work on the Settings Screen issues in 2023.

I've merged these changes into my separate repo by hand (roots-react-native-experimental) which has no expo, newer versions of libs, etc.  I'm going to rebase and merge these changes now, so that your future changes are easier for me to add in the future

@HunnySajid after merging your work, i'm continuing to update things in my repo, for instance

What would really be helpful for me this weekend is if you can you focus on updating the quick replies to use yellow instead of blue and to possibly not have to click confirm after selecting a button?  And possibly if the buttons could be single selection (radio) instead of being able to multi-select them.... and if you could make the button unselect after touching it, meaning you touch it, it does the action and then unselects.
That would be awesome!

@2byrds  Good work with the integration and credentials detail modal. I am going to work on the quick replies thing you mentioned. I will let you know as soon as I am done and then I can help you with the pending tasks if any.

@HunnySajid perfect thank you!


Doesn't skip file if previously encoded

Files my-movie.avi (x264) and my-movie-2.avi (x264) are in : ToBeConverted folder
I run the following command :
node ./h265ize -d D:\h265ize\output -g D:\h265ize\temp F:\ToBeConverted
After my-movie.avi is done, I interrupt the process ( ctrl + c ).
I run the command again :
node ./h265ize -d D:\h265ize\output -g D:\h265ize\temp F:\ToBeConverted
Current behavior : It launches the conversion of my-movie.avi instead of skipping it by detecting the presence of my-movie.mkv in output folder.
Expected behavior : Detect that my-movie.avi has already been encoded in x265 and is still present in output folder, skip it and encode my-movie-2.avi instead.
I'm pretty sure this was the behavior when using the version provided by npm install h265ize, so this would be a regression

I assume this is a regression from me trying to implement #77. Will look into and fix.

Please pull again and let me know if the issue persists.

Issue is still present

h265ize --version?

master#46e0123

Okay so, I found out why there was an issue.
I was encoding an entire folder :
node h265ize -d D:\h265ize\output\ -g D:\h265ize\temp "F:\TvShows\MyTVShow\"
In this folder I have subfolders:

Season 1
-- S01E01.mkv
-- S01E02.mkv
-- S01E03.mkv
Season 2
-- S02E01.mkv
-- S02E02.mkv
-- S02E03.mkv
Season 3
-- S03E01.mkv
-- S03E02.mkv
-- S03E03.mkv

So I was expecting my files to be in:
D:\h265ize\output\MyTVShow\Season 1
D:\h265ize\output\MyTVShow\Season 2
D:\h265ize\output\MyTVShow\Season 3
However, all my files are converted in the root of my destination folder, and folder structure isn't preserved.
D:\h265ize\output\S01E01.mkv
D:\h265ize\output\S01E02.mkv
D:\h265ize\output\S01E03.mkv
D:\h265ize\output\S02E01.mkv
D:\h265ize\output\S02E02.mkv
D:\h265ize\output\S02E03.mkv
D:\h265ize\output\S03E01.mkv
D:\h265ize\output\S03E02.mkv
D:\h265ize\output\S03E03.mkv

This is not the regular behavior, right ?

Correct again, this is not the correct behavior. Although it depends where you run the command from, I cannot think of a senerio where this occuring would be correct. Time to do some more digging.
I think I will make it an issue to add a more integrate testing system.

Hm, if my tv show folder has space in its name, it doesn't work for batch processing anymore.
node h265ize -d D:\h265ize\output -g D:\h265ize\temp "F:\TvShows\Dr. House\" --debug
Output:
[h265ize]: Input F:\TvShows\Dr. House" --debug does not exist.
[h265ize]: Could not retrieve input paths.

Of course, the folder exists.

Almost there, the "root" folder is still missing.
Command : node h265ize -d D:\h265ize\output\ -g D:\h265ize\temp "F:\TvShows\MyTVShow\"
Expected output architecture:
D:\h265ize\output\MyTVShow\Season 1
D:\h265ize\output\MyTVShow\Season 2
D:\h265ize\output\MyTVShow\Season 3

Actual output architecture:
D:\h265ize\output\Season 1
D:\h265ize\output\Season 2
D:\h265ize\output\Season 3

This is expected functionality. Your expected output could be produced by moving the target directory up one: node h265ize -d D:\h265ize\output\ -g D:\h265ize\temp "F:\TvShows\"


RebuildHistory

Major rewrite to use TimeSeries TimeArrays in all streams, so there is no longer any _History types, just Stream, UnitOp etc.

The one that breaks everything?


Safe-guard installer with log and message prompt

Coverage decreased (-0.5%) to 80.315% when pulling c31c6202d15f5f49da6a487bf3f1d7f3935bdecd on feature/add-installer-log into 19503bf9c19b5e3272d32a916f6f03ea036c9927 on main.


[conn] number of failures should be reset after every connection attempt

This PR addresses #41 and resets the number of failures after each connection attempt. I also added a check in the logic so that if the error we receive when attempting to write the bytes is temporary we don't immediately reset the connection. In addition, I also rewrote the tests for when there is no active connection as property tests as I felt this better expressed the contract of the connection.
cc @xichen2020 and @prateek since he's familiar with gopter

Coverage decreased (-0.1%) to 92.103% when pulling ec963e29436c9751b3fccf0809bd1638979b48ef on jeromefroe/conn/reset-failures-each-time-we-try-to-connect into 2c23411f8259fbadf1f384bff65ec58f7e76471a on master.

Coverage increased (+0.2%) to 92.433% when pulling 3e8193c49550636251b4e172eb217d99d630e05f on jeromefroe/conn/reset-failures-each-time-we-try-to-connect into 2c23411f8259fbadf1f384bff65ec58f7e76471a on master.

Coverage increased (+0.2%) to 92.433% when pulling 9e660262a7b9615d8066441a3601e17c6506695f on jeromefroe/conn/reset-failures-each-time-we-try-to-connect into 2c23411f8259fbadf1f384bff65ec58f7e76471a on master.

Coverage increased (+0.3%) to 92.483% when pulling 2a3652565017f4796667abbf8aeb136b652d5574 on jeromefroe/conn/reset-failures-each-time-we-try-to-connect into 2c23411f8259fbadf1f384bff65ec58f7e76471a on master.