Config from website

Issue:
I don't really know what I can type in certain cofig options. Sometimes I would like to select super specyfic variables, e.g purpur stairs blocks, and I always make a mistake in spelling
My solution:
Make a website that writes down the code for You. With each choice the User will be getting dropdown list of blocks / iteractions / choices. Devs can add specyfic vid that shows the result of my config: enable effects -> camera in the fight gets effects.
Alternative solution:
Surfing through the web by checking lists from bukkit that developers linked in their cofig instructions.
Additional info:
User gets to download the config file, or gets to copy the code for the file.
Me rn:
d-_-b

I don't understand what these issues have to do with the website.

I don't understand what these issues have to do with the website.

pessimistic as always

I don't understand what these issues have to do with the website.

pessimistic as always

The issue should be directly related to the website. I don't understand what you mean and how these changes would contribute to the improvement/development of the website. Please elaborate on what you mean. Currently, it seems as if it is more closely related to Docs or EternalCombat.

I don't understand what these issues have to do with the website.

pessimistic as always

The issue should be directly related to the website. I don't understand what you mean and how these changes would contribute to the improvement/development of the website. Please elaborate on what you mean. Currently, it seems as if it is more closely related to Docs or EternalCombat.

I was thinking about using our website and developing skills in file extraction / animation / making guis in the way to help commuinity, because prblly most common problem in our projects is incorrect config editing.

I think it is a great idea, but there is no repository related to that. We can create a new repository for that.


NPM and GitHub versions difference

I'm currently using this module, but the NPM released version is different from the one in gibhub, it looks like the app has been rewritten in Typescrtip and a good amount of fixed for android have been done, when will this be published in NPM?

I have the same issue directly installing the GitHub version did the trick for me (for now)
yarn add teslamotors/react-native-camera-kit

I have the same issue directly installing the GitHub version did the trick for me (for now)
yarn add teslamotors/react-native-camera-kit

If you decide to go with this you must to proved the flashMode prop otherwise it will crash your app. For example:
<Camera
  type="back"
  ref={(ref) => { camera.current = ref; }}
  flashMode="auto"
  style={{ flex: 1 }}
/>

However the camera changes the type of camera (front/back) regardless of what you provide. Which is cause by this piece of code in Camera.ios.tsx
function Camera(props, ref) {
  const nativeRef = React.useRef();

  useEffect(() => {
    CKCameraManager.changeCamera(); <<<<<< Here
  }, [props.type]);

So you're either left with using patch-package and like the name suggest patching this package. Or you provide your users with a feature to change the camera type

I tested on android with your fix @onursagir and got :
A problem occurred evaluating project ':react-native-camera-kit'.
> Could not get unknown property 'kotlin_version' for object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

You are seeing the readme in master for some API changes that are in active development and haven't been released yet. If you want to see the guide for the old API you can look at the readme here.
https://github.com/teslamotors/react-native-camera-kit/tree/9518f3aef4a137a5a6f8c130782f251115dc6a16


Replace 'done' with 'done-testing'

done is now only used in Supplies; done-testing is how we now specify
that testing is over.

Thanks!


[BUG] when graphscope session is dynamically created in local mode., graphscope client can't interact with gremlin server (GIE)

Describe the bug
when  graphscope session is dynamically created in local mode., graphscope client can't interact with gremlin server (GIE) ,
To Reproduce
sess = graphscope.session()
graph = sess.g()
g = graph.add_vertices(df_person, label='person').add_edges(df_knows, label ='knows', src_label='person', dst_label ='person')
interactive = sess.gremlin(g)
print(interactive)
Expected behavior
Traceback (most recent call last):
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/client/rpc.py", line 47, in with_grpc_catch
return fn(*args, **kwargs)
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/client/rpc.py", line 169, in create_interactive_engine
response = self._stub.CreateInteractiveInstance(request)
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/grpc/_channel.py", line 946, in call
return _end_unary_response_blocking(state, call, False, None)
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking
raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNKNOWN
details = "Exception calling application: <urlopen error [Errno 111] Connection refused>"
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):

GraphScope version: [e.g., v0.1, v0.2.2, master]
OS: [e.g. MacOS, Linux]
Version [e.g. 10.15]
Kubernetes Version [e.g., 1.19]

Additional context
Add any other context about the problem here.

Thanks for your feedback, we will try to replay the bug and get back to you!

hi, can you complete the environment information, what's the GraphScope version? what's the OS you run GraphScope?

hi, can you complete the environment information, what's the GraphScope version? what's the OS you run GraphScope?

running on k8s cluster,   graph session that has been successfully created， pods with  GIE, GAE has been launched as well,  but it failed at interactive = sess.gremlin(g) statement.  below is the detailed log
2021-07-28 03:32:17,540 [INFO][session:583]: Initializing graphscope session with parameters: {'addr': None, 'mode': 'eager', 'cluster_type': 'k8s', 'num_workers': 2, 'preemptive': True, 'k8s_namespace': None, 'k8s_service_type': 'NodePort', 'k8s_gs_image': 'registry.cn-hongkong.aliyuncs.com/graphscope/graphscope:0.5.0', 'k8s_etcd_image': 'quay.io/coreos/etcd:v3.4.13', 'k8s_image_pull_policy': 'IfNotPresent', 'k8s_image_pull_secrets': [], 'k8s_gie_graph_manager_image': 'registry.cn-hongkong.aliyuncs.com/graphscope/maxgraph_standalone_manager:0.5.0', 'k8s_zookeeper_image': 'zookeeper:3.4.14', 'k8s_coordinator_cpu': 0.5, 'k8s_coordinator_mem': '512Mi', 'k8s_etcd_num_pods': 1, 'k8s_etcd_cpu': 2, 'k8s_etcd_mem': '4Gi', 'k8s_zookeeper_cpu': 2, 'k8s_zookeeper_mem': '4Gi', 'k8s_gie_graph_manager_cpu': 2, 'k8s_gie_graph_manager_mem': '4Gi', 'k8s_vineyard_daemonset': 'none', 'k8s_vineyard_cpu': 4, 'k8s_vineyard_mem': '4Gi', 'vineyard_shared_mem': '4Gi', 'k8s_engine_cpu': 4, 'k8s_engine_mem': '4Gi', 'k8s_mars_worker_cpu': 0.2, 'k8s_mars_worker_mem': '512Mi', 'k8s_mars_scheduler_cpu': 0.2, 'k8s_mars_scheduler_mem': '512Mi', 'with_mars': False, 'k8s_volumes': {}, 'k8s_waiting_for_delete': False, 'timeout_seconds': 600, 'dangling_timeout_seconds': 600, 'k8s_client_config': {}}
2021-07-28 03:32:18,455 [INFO][cluster:308]: Launching coordinator...
2021-07-28 03:32:21,891 [INFO][utils:167]: coordinator-pwkpkx-5cd75cc784-nmk2d: Successfully assigned gs-kukjzb/coordinator-pwkpkx-5cd75cc784-nmk2d to rancher-node3
2021-07-28 03:32:21,891 [INFO][utils:167]: coordinator-pwkpkx-5cd75cc784-nmk2d: Container image "registry.cn-hongkong.aliyuncs.com/graphscope/graphscope:0.5.0" already present on machine
2021-07-28 03:32:23,071 [INFO][utils:167]: coordinator-pwkpkx-5cd75cc784-nmk2d: Created container coordinator
2021-07-28 03:32:23,072 [INFO][utils:167]: coordinator-pwkpkx-5cd75cc784-nmk2d: Started container coordinator
2021-07-28 11:32:29,404 [INFO][cluster:684]: Launching GIE graph manager ...
2021-07-28 11:32:30,569 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Successfully assigned gs-kukjzb/gs-graphmanager-pwkpkx-5c8b456646-p96g2 to rancher-node2
2021-07-28 11:32:33,564 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Container image "registry.cn-hongkong.aliyuncs.com/graphscope/maxgraph_standalone_manager:0.5.0" already present on machine
2021-07-28 11:32:33,566 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Created container manager
2021-07-28 11:32:33,568 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Started container manager
2021-07-28 11:32:33,571 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Container image "zookeeper:3.4.14" already present on machine
2021-07-28 11:32:33,573 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Created container zookeeper
2021-07-28 11:32:33,575 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Started container zookeeper
2021-07-28 03:32:36,152 [INFO][utils:167]: coordinator-pwkpkx-5cd75cc784-nmk2d: Readiness probe failed: dial tcp <IP_ADDRESS>:59184: connect: connection refused
2021-07-28 11:32:36,582 [INFO][cluster:797]: GIE graph manager service is ready.
2021-07-28 11:32:36,583 [INFO][cluster:541]: Launching etcd ...
2021-07-28 11:32:37,683 [INFO][cluster:807]: Etcd is ready, endpoint is xx.xx.xx.xx:58375
2021-07-28 11:32:37,683 [INFO][cluster:431]: Launching GraphScope engines pod ...
2021-07-28 11:32:38,294 [INFO][cluster:864]: [gs-engine-pwkpkx-7r6wl]: Successfully assigned gs-kukjzb/gs-engine-pwkpkx-7r6wl to rancher-node3
2021-07-28 11:32:39,301 [INFO][cluster:864]: [gs-engine-pwkpkx-hf5fq]: Successfully assigned gs-kukjzb/gs-engine-pwkpkx-hf5fq to rancher-node3
2021-07-28 11:32:42,984 [INFO][cluster:864]: [gs-engine-pwkpkx-7r6wl]: Container image "registry.cn-hongkong.aliyuncs.com/graphscope/graphscope:0.5.0" already present on machine
2021-07-28 11:32:42,986 [INFO][cluster:864]: [gs-engine-pwkpkx-7r6wl]: Created container engine
2021-07-28 11:32:42,988 [INFO][cluster:864]: [gs-engine-pwkpkx-7r6wl]: Started container engine
2021-07-28 11:32:42,993 [INFO][cluster:864]: [gs-engine-pwkpkx-7r6wl]: Created container vineyard
2021-07-28 11:32:42,996 [INFO][cluster:864]: [gs-engine-pwkpkx-7r6wl]: Started container vineyard
2021-07-28 11:32:43,992 [INFO][cluster:864]: [gs-engine-pwkpkx-hf5fq]: Container image "registry.cn-hongkong.aliyuncs.com/graphscope/graphscope:0.5.0" already present on machine
2021-07-28 11:32:43,994 [INFO][cluster:864]: [gs-engine-pwkpkx-hf5fq]: Created container engine
2021-07-28 11:32:43,997 [INFO][cluster:864]: [gs-engine-pwkpkx-hf5fq]: Started container engine
2021-07-28 11:32:44,001 [INFO][cluster:864]: [gs-engine-pwkpkx-hf5fq]: Created container vineyard
2021-07-28 11:32:44,004 [INFO][cluster:864]: [gs-engine-pwkpkx-hf5fq]: Started container vineyard
2021-07-28 11:32:56,674 [DEBUG][cluster:896]: vineyard rpc runs on xx.xx.xx.xx:30441
2021-07-28 11:32:56,675 [INFO][cluster:900]: GraphScope engines pod is ready.
2021-07-28 11:32:56,684 [INFO][cluster:1043]: Engines pod name list: ['gs-engine-pwkpkx-7r6wl', 'gs-engine-pwkpkx-hf5fq']
2021-07-28 11:32:56,684 [INFO][cluster:1044]: Engines pod ip list: ['xx.xx.xx.xx', 'xx.xx.xx.xx']
2021-07-28 11:32:56,684 [INFO][cluster:1045]: Engines pod host ip list: ['xx.xx.xx.xx', 'xx.xx.xx.xx']
2021-07-28 11:32:56,684 [INFO][cluster:1047]: Vineyard service endpoint: xx.xx.xx.xx:30441
2021-07-28 11:32:56,684 [INFO][cluster:936]: Starting GAE rpc service on xx.xx.xx.xx:56507 ...
2021-07-28 11:32:59,202 [DEBUG][utils:991]: Resolve mpi cmd prefix: ['mpirun', '--allow-run-as-root', '-n', '2', '-host', 'gs-engine-pwkpkx-7r6wl:1,gs-engine-pwkpkx-hf5fq:1']
2021-07-28 11:32:59,202 [DEBUG][utils:992]: Resolve mpi env: {'OMPI_MCA_btl_vader_single_copy_mechanism': 'none', 'OMPI_MCA_orte_allowed_exit_without_sync': '1', 'OMPI_MCA_odls_base_sigkill_timeout': '0', 'OMPI_MCA_plm_rsh_agent': '/usr/local/bin/kube_ssh'}
2021-07-28 11:32:59,375 [DEBUG][cluster:973]: Analytical engine launching command: mpirun --allow-run-as-root -n 2 -host gs-engine-pwkpkx-7r6wl:1,gs-engine-pwkpkx-hf5fq:1 grape_engine --host <IP_ADDRESS> --port 56507 -v 10 --vineyard_socket /tmp/vineyard_workspace/vineyard.sock
2021-07-28 11:32:59,566 [INFO][coordinator:1131]: Coordinator server listen at <IP_ADDRESS>:59184
2021-07-28 03:33:07,926 [INFO][cluster:567]: Coordinator pod start successful with address xx.xx.xx.xx:32138, connecting to service ...
2021-07-28 03:33:13,068 [INFO][rpc:111]: GraphScope coordinator service connected.
I0728 11:33:16.370306    96 grape_instance.cc:864] Registering Graph, graph type: 4, Type sig: e33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521, lib path: /tmp/gs/builtin/e33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521/libe33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521.so
I0728 11:33:16.379833    88 grape_instance.cc:864] Registering Graph, graph type: 4, Type sig: e33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521, lib path: /tmp/gs/builtin/e33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521/libe33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521.so
I0728 11:33:16.416115    96 grape_instance.cc:110] Loading graph, graph name: graph_a37JncCH, graph type: ArrowFragment, type sig: e33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521
I0728 11:33:16.427814    88 grape_instance.cc:110] Loading graph, graph name: graph_a37JncCH, graph type: ArrowFragment, type sig: e33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521
I0728 11:33:17.047847    88 property_graph_frame.cc:107] [worker-1] loaded graph to vineyard ...
I0728 11:33:17.055609    96 property_graph_frame.cc:107] [worker-0] loaded graph to vineyard ...
Connecting to the PostgreSQL database...
I0728 11:33:18.075819    88 property_graph_frame.cc:274] [worker-1] Add labels to graph and loaded to vineyard ...
I0728 11:33:18.076035    96 property_graph_frame.cc:274] [worker-0] Add labels to graph and loaded to vineyard ...
I0728 11:33:19.383785    88 property_graph_frame.cc:274] [worker-1] Add labels to graph and loaded to vineyard ...
I0728 11:33:19.395239    96 property_graph_frame.cc:274] [worker-0] Add labels to graph and loaded to vineyard ...
I0728 11:33:19.528188    88 gs_object.h:65] Object graph_yDsbzayy[LABELED_FRAGMENT_WRAPPER] is destructed.
I0728 11:33:19.556005    96 gs_object.h:65] Object graph_yDsbzayy[LABELED_FRAGMENT_WRAPPER] is destructed.
Traceback (most recent call last):
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/client/session.py", line 1135, in gremlin
2021-07-28 11:43:28,676 [ERROR][coordinator:606]: create interactive instance for object id<PHONE_NUMBER>7559523 failed with error code -1 message Check instance ready timeout
engine_params=engine_params,
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/client/rpc.py", line 47, in with_grpc_catch
2021-07-28 11:43:28,676 [ERROR][coordinator:606]: create interactive instance for object id<PHONE_NUMBER>7559523 failed with error code -1 message Check instance ready timeout
return fn(*args, **kwargs)
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/client/rpc.py", line 170, in create_interactive_engine
return check_grpc_response(response)
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/framework/errors.py", line 181, in check_grpc_response
raise error_type(status.error_msg, detail)
graphscope.framework.errors.InteractiveEngineInternalError: 'create interactive instance for object id<PHONE_NUMBER>7559523 failed with error code -1 message Check instance ready timeout'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "app.py", line 34, in
interactive = sess.gremlin(g)
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/client/utils.py", line 156, in wrapper
return_value = func(*args, **kwargs)
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/client/session.py", line 1140, in gremlin
raise InteractiveEngineInternalError(str(e)) from e
graphscope.framework.errors.InteractiveEngineInternalError: "'create interactive instance for object id<PHONE_NUMBER>7559523 failed with error code -1 message Check instance ready timeout'"
2021-07-28 11:43:29,418 [INFO][coordinator:635]: Coordinator close interactive instance with url[http://<IP_ADDRESS>:8080/instance/close?graphName=11144263247559523&podNameList=gs-engine-pwkpkx-7r6wl,gs-engine-pwkpkx-hf5fq&containerName=engine&waitingForDelete=False]

hi, can you complete the environment information, what's the GraphScope version? what's the OS you run GraphScope?
environment
GraphScope version: 0.5.0
OS: Ubuntu 20.04.2
Kubernetes Version v1.20.5
python3: version3.6.8
build mode: local build

running on k8s cluster, graph session that has been successfully created， pods with GIE, GAE has been launched as well, but it failed at interactive = sess.gremlin(g) statement. below is the detailed log
2021-07-28 03:32:17,540 [INFO][session:583]: Initializing graphscope session with parameters: {'addr': None, 'mode': 'eager', 'cluster_type': 'k8s', 'num_workers': 2, 'preemptive': True, 'k8s_namespace': None, 'k8s_service_type': 'NodePort', 'k8s_gs_image': 'registry.cn-hongkong.aliyuncs.com/graphscope/graphscope:0.5.0', 'k8s_etcd_image': 'quay.io/coreos/etcd:v3.4.13', 'k8s_image_pull_policy': 'IfNotPresent', 'k8s_image_pull_secrets': [], 'k8s_gie_graph_manager_image': 'registry.cn-hongkong.aliyuncs.com/graphscope/maxgraph_standalone_manager:0.5.0', 'k8s_zookeeper_image': 'zookeeper:3.4.14', 'k8s_coordinator_cpu': 0.5, 'k8s_coordinator_mem': '512Mi', 'k8s_etcd_num_pods': 1, 'k8s_etcd_cpu': 2, 'k8s_etcd_mem': '4Gi', 'k8s_zookeeper_cpu': 2, 'k8s_zookeeper_mem': '4Gi', 'k8s_gie_graph_manager_cpu': 2, 'k8s_gie_graph_manager_mem': '4Gi', 'k8s_vineyard_daemonset': 'none', 'k8s_vineyard_cpu': 4, 'k8s_vineyard_mem': '4Gi', 'vineyard_shared_mem': '4Gi', 'k8s_engine_cpu': 4, 'k8s_engine_mem': '4Gi', 'k8s_mars_worker_cpu': 0.2, 'k8s_mars_worker_mem': '512Mi', 'k8s_mars_scheduler_cpu': 0.2, 'k8s_mars_scheduler_mem': '512Mi', 'with_mars': False, 'k8s_volumes': {}, 'k8s_waiting_for_delete': False, 'timeout_seconds': 600, 'dangling_timeout_seconds': 600, 'k8s_client_config': {}}
2021-07-28 03:32:18,455 [INFO][cluster:308]: Launching coordinator...
2021-07-28 03:32:21,891 [INFO][utils:167]: coordinator-pwkpkx-5cd75cc784-nmk2d: Successfully assigned gs-kukjzb/coordinator-pwkpkx-5cd75cc784-nmk2d to rancher-node3
2021-07-28 03:32:21,891 [INFO][utils:167]: coordinator-pwkpkx-5cd75cc784-nmk2d: Container image "registry.cn-hongkong.aliyuncs.com/graphscope/graphscope:0.5.0" already present on machine
2021-07-28 03:32:23,071 [INFO][utils:167]: coordinator-pwkpkx-5cd75cc784-nmk2d: Created container coordinator
2021-07-28 03:32:23,072 [INFO][utils:167]: coordinator-pwkpkx-5cd75cc784-nmk2d: Started container coordinator
2021-07-28 11:32:29,404 [INFO][cluster:684]: Launching GIE graph manager ...
2021-07-28 11:32:30,569 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Successfully assigned gs-kukjzb/gs-graphmanager-pwkpkx-5c8b456646-p96g2 to rancher-node2
2021-07-28 11:32:33,564 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Container image "registry.cn-hongkong.aliyuncs.com/graphscope/maxgraph_standalone_manager:0.5.0" already present on machine
2021-07-28 11:32:33,566 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Created container manager
2021-07-28 11:32:33,568 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Started container manager
2021-07-28 11:32:33,571 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Container image "zookeeper:3.4.14" already present on machine
2021-07-28 11:32:33,573 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Created container zookeeper
2021-07-28 11:32:33,575 [INFO][cluster:785]: [gs-graphmanager-pwkpkx-5c8b456646-p96g2]: Started container zookeeper
2021-07-28 03:32:36,152 [INFO][utils:167]: coordinator-pwkpkx-5cd75cc784-nmk2d: Readiness probe failed: dial tcp <IP_ADDRESS>:59184: connect: connection refused
2021-07-28 11:32:36,582 [INFO][cluster:797]: GIE graph manager service is ready.
2021-07-28 11:32:36,583 [INFO][cluster:541]: Launching etcd ...
2021-07-28 11:32:37,683 [INFO][cluster:807]: Etcd is ready, endpoint is xx.xx.xx.xx:58375
2021-07-28 11:32:37,683 [INFO][cluster:431]: Launching GraphScope engines pod ...
2021-07-28 11:32:38,294 [INFO][cluster:864]: [gs-engine-pwkpkx-7r6wl]: Successfully assigned gs-kukjzb/gs-engine-pwkpkx-7r6wl to rancher-node3
2021-07-28 11:32:39,301 [INFO][cluster:864]: [gs-engine-pwkpkx-hf5fq]: Successfully assigned gs-kukjzb/gs-engine-pwkpkx-hf5fq to rancher-node3
2021-07-28 11:32:42,984 [INFO][cluster:864]: [gs-engine-pwkpkx-7r6wl]: Container image "registry.cn-hongkong.aliyuncs.com/graphscope/graphscope:0.5.0" already present on machine
2021-07-28 11:32:42,986 [INFO][cluster:864]: [gs-engine-pwkpkx-7r6wl]: Created container engine
2021-07-28 11:32:42,988 [INFO][cluster:864]: [gs-engine-pwkpkx-7r6wl]: Started container engine
2021-07-28 11:32:42,993 [INFO][cluster:864]: [gs-engine-pwkpkx-7r6wl]: Created container vineyard
2021-07-28 11:32:42,996 [INFO][cluster:864]: [gs-engine-pwkpkx-7r6wl]: Started container vineyard
2021-07-28 11:32:43,992 [INFO][cluster:864]: [gs-engine-pwkpkx-hf5fq]: Container image "registry.cn-hongkong.aliyuncs.com/graphscope/graphscope:0.5.0" already present on machine
2021-07-28 11:32:43,994 [INFO][cluster:864]: [gs-engine-pwkpkx-hf5fq]: Created container engine
2021-07-28 11:32:43,997 [INFO][cluster:864]: [gs-engine-pwkpkx-hf5fq]: Started container engine
2021-07-28 11:32:44,001 [INFO][cluster:864]: [gs-engine-pwkpkx-hf5fq]: Created container vineyard
2021-07-28 11:32:44,004 [INFO][cluster:864]: [gs-engine-pwkpkx-hf5fq]: Started container vineyard
2021-07-28 11:32:56,674 [DEBUG][cluster:896]: vineyard rpc runs on xx.xx.xx.xx:30441
2021-07-28 11:32:56,675 [INFO][cluster:900]: GraphScope engines pod is ready.
2021-07-28 11:32:56,684 [INFO][cluster:1043]: Engines pod name list: ['gs-engine-pwkpkx-7r6wl', 'gs-engine-pwkpkx-hf5fq']
2021-07-28 11:32:56,684 [INFO][cluster:1044]: Engines pod ip list: ['xx.xx.xx.xx', 'xx.xx.xx.xx']
2021-07-28 11:32:56,684 [INFO][cluster:1045]: Engines pod host ip list: ['xx.xx.xx.xx', 'xx.xx.xx.xx']
2021-07-28 11:32:56,684 [INFO][cluster:1047]: Vineyard service endpoint: xx.xx.xx.xx:30441
2021-07-28 11:32:56,684 [INFO][cluster:936]: Starting GAE rpc service on xx.xx.xx.xx:56507 ...
2021-07-28 11:32:59,202 [DEBUG][utils:991]: Resolve mpi cmd prefix: ['mpirun', '--allow-run-as-root', '-n', '2', '-host', 'gs-engine-pwkpkx-7r6wl:1,gs-engine-pwkpkx-hf5fq:1']
2021-07-28 11:32:59,202 [DEBUG][utils:992]: Resolve mpi env: {'OMPI_MCA_btl_vader_single_copy_mechanism': 'none', 'OMPI_MCA_orte_allowed_exit_without_sync': '1', 'OMPI_MCA_odls_base_sigkill_timeout': '0', 'OMPI_MCA_plm_rsh_agent': '/usr/local/bin/kube_ssh'}
2021-07-28 11:32:59,375 [DEBUG][cluster:973]: Analytical engine launching command: mpirun --allow-run-as-root -n 2 -host gs-engine-pwkpkx-7r6wl:1,gs-engine-pwkpkx-hf5fq:1 grape_engine --host <IP_ADDRESS> --port 56507 -v 10 --vineyard_socket /tmp/vineyard_workspace/vineyard.sock
2021-07-28 11:32:59,566 [INFO][coordinator:1131]: Coordinator server listen at <IP_ADDRESS>:59184
2021-07-28 03:33:07,926 [INFO][cluster:567]: Coordinator pod start successful with address xx.xx.xx.xx:32138, connecting to service ...
2021-07-28 03:33:13,068 [INFO][rpc:111]: GraphScope coordinator service connected.
I0728 11:33:16.370306 96 grape_instance.cc:864] Registering Graph, graph type: 4, Type sig: e33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521, lib path: /tmp/gs/builtin/e33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521/libe33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521.so
I0728 11:33:16.379833 88 grape_instance.cc:864] Registering Graph, graph type: 4, Type sig: e33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521, lib path: /tmp/gs/builtin/e33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521/libe33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521.so
I0728 11:33:16.416115 96 grape_instance.cc:110] Loading graph, graph name: graph_a37JncCH, graph type: ArrowFragment, type sig: e33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521
I0728 11:33:16.427814 88 grape_instance.cc:110] Loading graph, graph name: graph_a37JncCH, graph type: ArrowFragment, type sig: e33529e80839a2064a804ce453c761a9483aa7ab775bcfddc1a1f9da63dcb521
I0728 11:33:17.047847 88 property_graph_frame.cc:107] [worker-1] loaded graph to vineyard ...
I0728 11:33:17.055609 96 property_graph_frame.cc:107] [worker-0] loaded graph to vineyard ...
Connecting to the PostgreSQL database...
I0728 11:33:18.075819 88 property_graph_frame.cc:274] [worker-1] Add labels to graph and loaded to vineyard ...
I0728 11:33:18.076035 96 property_graph_frame.cc:274] [worker-0] Add labels to graph and loaded to vineyard ...
I0728 11:33:19.383785 88 property_graph_frame.cc:274] [worker-1] Add labels to graph and loaded to vineyard ...
I0728 11:33:19.395239 96 property_graph_frame.cc:274] [worker-0] Add labels to graph and loaded to vineyard ...
I0728 11:33:19.528188 88 gs_object.h:65] Object graph_yDsbzayy[LABELED_FRAGMENT_WRAPPER] is destructed.
I0728 11:33:19.556005 96 gs_object.h:65] Object graph_yDsbzayy[LABELED_FRAGMENT_WRAPPER] is destructed.
Traceback (most recent call last):
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/client/session.py", line 1135, in gremlin
2021-07-28 11:43:28,676 [ERROR][coordinator:606]: create interactive instance for object id<PHONE_NUMBER>7559523 failed with error code -1 message Check instance ready timeout
engine_params=engine_params,
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/client/rpc.py", line 47, in with_grpc_catch
2021-07-28 11:43:28,676 [ERROR][coordinator:606]: create interactive instance for object id<PHONE_NUMBER>7559523 failed with error code -1 message Check instance ready timeout
return fn(*args, **kwargs)
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/client/rpc.py", line 170, in create_interactive_engine
return check_grpc_response(response)
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/framework/errors.py", line 181, in check_grpc_response
raise error_type(status.error_msg, detail)
graphscope.framework.errors.InteractiveEngineInternalError: 'create interactive instance for object id<PHONE_NUMBER>7559523 failed with error code -1 message Check instance ready timeout'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "app.py", line 34, in
interactive = sess.gremlin(g)
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/client/utils.py", line 156, in wrapper
return_value = func(*args, **kwargs)
File "/root/.pyenv/versions/3.6.8/lib/python3.6/site-packages/graphscope/client/session.py", line 1140, in gremlin
raise InteractiveEngineInternalError(str(e)) from e
graphscope.framework.errors.InteractiveEngineInternalError: "'create interactive instance for object id<PHONE_NUMBER>7559523 failed with error code -1 message Check instance ready timeout'"
2021-07-28 11:43:29,418 [INFO][coordinator:635]: Coordinator close interactive instance with url[http://<IP_ADDRESS>:8080/instance/close?graphName=11144263247559523&podNameList=gs-engine-pwkpkx-7r6wl,gs-engine-pwkpkx-hf5fq&containerName=engine&waitingForDelete=False]

hi @346057177 seems the log this time the error is not , it connect to manager service successfully  but check query failed.

is there a discussion group ,eg. weixin group?   can we join in to identify the problem？

is there a discussion group ,eg. weixin group? can we join in to identify the problem？

you can join the ding ding group 31533139

duplicate with #619


[Compatibility] Added CLIENT GETNAME, SETNAME, SETINFO commands

Adding the CLIENT GETNAME, SETNAME, SETINFO commands to garnet

[x] Add CLIENT GETNAME, SETNAME, SETINFO commands
[x] Add Integration Test cases, ACL Test
[x] Add documentation

@Vijay-Nirmal please resolve the conflicts because we cannot merge it as is

@vazois Done

Wow! Awesome!
Thank you for your works, this working improve compatibility,
ex in java) Spring data redis , lettuce


PayPal authentication window freezes

This issue occurs using the old Vault flow and js v2.27.0.
After adding the credentials and clicking on "Agree", the loading animation appears, but the window never closes. The PayPal account is added to the dropdown though.
I "fixed" it by downgrading the js file to 2.24.1.

Hi @Tyrdall -
This bug should be fixed in version 2.28.0. For details, see https://groups.google.com/forum/#!topic/braintree-sdk-announce/yIY1teacxlc
Please let us know if the issue persists.
Thank you!


Change default theme

Description
This issue changes the default theme from Next to v7
Issues Resolved
#173
Check List

[ ] All tests pass

[ ] yarn test:jest
[ ] yarn test:jest_integration

[ ] New functionality includes testing.
[ ] New functionality has been documented.
[ ] Update CHANGELOG.md
[ ] Commits are signed per the DCO using --signoff

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 55.39%. Comparing base (f066302) to head (b8b3df2).
Report is 84 commits behind head on 4.9.0.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##            4.9.0     #174       +/-   ##
===========================================
- Coverage   66.96%   55.39%   -11.58%
===========================================
  Files        3300     1194     -2106
  Lines       63585    24048    -39537
  Branches    10141     4013     -6128
===========================================
- Hits        42582    13321    -29261
+ Misses      18538    10100     -8438
+ Partials     2465      627     -1838

Flag
Coverage Δ

Linux_1
?

Linux_2
55.39% <ø> (+0.22%)
:arrow_up:

Linux_3
?

Windows_1
?

Windows_2
?

Windows_3
?

Windows_4
?

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

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


resizeTabs based on view width

Resizes tabs based on the view width rather than the screen width. Tabs resize properly if you want the bottom bar on oneside side of a split view

Coverage increased (+0.2%) to 56.298% when pulling 92bda34ed96be9e64944dabc7a0d0dd949e553ab on celanajaya:tabs-from-viewWidth into ef0dffd8efed848d31f473ed7ccb6b0683797624 on roughike:development.

I see now that most pull requests are into master. I'll close and resubmit.


consider wheels

Many pypi packages only uploaded wheels, which poet doesn't consider.
This PR makes a small change to also accept wheels as artifact.
fixes #29

Can you give an example of a package that doesn't distribute an sdist? I don't think there are "many".

This isn't sufficient to resolve #29; some packages have  entries on pypi but no uploaded distributions.

I'm one of the @mitmproxy maintainers, and we only shop wheels, because otherwise we run into problems with Python2 installations.
So I know of mitmproxy and one of our dependencies: construct.

Python wheels should be the first choice and sdist should be the fallback.
Why not consider macOS binary wheels? People regularly install Homebrew and pip binaries.

Why not consider macOS binary wheels?

Homebrew policy (and therefore poet's policy) is to build from source.
Pure-python wheels are technically a distribution format and not a source format but the distinction feels less important and it might simplify things at some future point where setuptools is less dominant so I feel less strongly about it.


Consider a slimmer base image (e.g. distroless)

Describe the problem/challenge you have
We'd like to ship kapp-controller with the minimum necessary bits. We're currently using photon as our base image. Is there a better (i.e. slimmer) option?
Describe the solution you'd like
Investigate alternative options (such as distroless) and determine if we should consider making a switch. If the changes appear to be simple, feel free to make the necessary changes.
Anything else you would like to add:

similar issue in secretgen-controller: vmware-tanzu/carvel-secretgen-controller#40

Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.

After some discussion, we're deciding to hold off on investigating further into this issue until we learn more about other build processes that we may be able to leverage. If anyone from the community is interested in this work, please let us know.

Another thing to consider if we don't want to change the base image, could we remove tools that we don't need that could create security vulnerabilities?

Looks like we can't remove the shell from photon:4.0
❯ docker run -ti --rm photon:4.0 bash
root [ / ]# tdnf remove bash
Refreshing metadata for: 'VMware Photon Linux 4.0 (x86_64) Updates'
Refreshing metadata for: 'VMware Photon Extras 4.0 (x86_64)'
Refreshing metadata for: 'VMware Photon Linux 4.0 (x86_64)'
Error(1030) : The operation would result in removing the protected package : tdnf

I don't think we can get away with a smaller image right now because we need git. HOWEVER we now have a sidecar where most of the work happens, so perhaps the main kc base os can in fact be minimal. Will leave this issue open to investigate!


Store events

to enable history replay
to build analytics

"analytics" is really just "more views"

Oh yeah!

Marking as a refactoring since there is no proposal for an actual feature here, but rather the enabling of potential future features.
This is probably not worth doing in isolation. It should probably be rolled into being part of the first feature it will enable.


Don't send players module options while reloading them

Closes #96 by only sending the module options to players after all the modules have been reloaded.

Thank you for your PR, however the problem with this solution is that it prevents updating options that have actually been changed for players currently on the server when reloading. I've gone ahead and made the changes to address that in this PR https://github.com/LunarClient/Apollo/pull/101.


Add support for ESC[3J is simple terminal

when running curl parrot.live, we get in the log:
erresc: unknown csi ESC[3J

check out https://apple.stackexchange.com/a/113168 for more info

no longer using simple terminal

no longer using simple terminal


&mdash broken in several locations (content)

code "&mdash" broken in:
Zoning TOOLTIP
Neighborhood Studies and Plans TOOLTIP
Community-Based Plans TOOLTIP

@andycochran  I can make changes and close out issue if required.

It should be — (with the closing semicolon).

Closed with PR


build: Install setuptools explicitly

Codecov Report

Merging #1363 (c85172a) into master (18da638) will decrease coverage by 0.15%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1363      +/-   ##
==========================================
- Coverage   99.16%   99.00%   -0.16%
==========================================
  Files          83       83
  Lines        6347     6359      +12
  Branches     1126     1123       -3
==========================================
+ Hits         6294     6296       +2
- Misses         27       33       +6
- Partials       26       30       +4

Flag
Coverage Δ

unittests
99.00% <100.00%> (-0.13%)
:arrow_down:

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

Impacted Files
Coverage Δ

src/schemathesis/runner/impl/core.py
97.75% <ø> (ø)

src/schemathesis/specs/openapi/references.py
96.92% <100.00%> (+0.09%)
:arrow_up:

src/schemathesis/specs/openapi/schemas.py
99.56% <100.00%> (+<0.01%)
:arrow_up:

src/schemathesis/_compat.py
77.77% <0.00%> (-11.12%)
:arrow_down:

src/schemathesis/runner/impl/threadpool.py
98.23% <0.00%> (-1.77%)
:arrow_down:

src/schemathesis/extra/pytest_plugin.py
98.24% <0.00%> (-1.76%)
:arrow_down:

src/schemathesis/cli/callbacks.py
98.33% <0.00%> (-1.67%)
:arrow_down:

src/schemathesis/specs/openapi/loaders.py
98.31% <0.00%> (-0.85%)
:arrow_down:

src/schemathesis/cli/output/default.py
99.68% <0.00%> (-0.32%)
:arrow_down:

Continue to review full report at Codecov.

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


a hv.Dataset.to(hv.Bars, ...) not displaying all the data, inconsistent with static plots

I am plotting a bunch of bar plots, counts versus time. When I use holoviews to do this, I am using the groupby option to group by "User" and so get a drop down menu that renders the plots. The problem is, when I select a user that has a lower limit of the time axis that is greater than the others, the plot renders fine. But returning to a user with earlier data, the new plot only captures the data from the starting time of the earlier plot! using Bokeh to zoom / scrolll to the left shows no data!   See cell 146 of the attached notebook, and try selecting user "Amaya, Naomi", and then select "Hoefert, Susannah". and Compare the resulting plot with the static plot rendered in matplotlib below; they do not match. Then refresh and just select "HOefert, Susannah" without selecting anyone prevoiusly, and all the data is there. I want to use holoviews but cannot trust it is capturing all the data!
ISSUE.zip

I am facing a very similar problem. Is there a workaround?


allow setting initial index

In #20, the code was changed to start Option IDs at 0. This broke existing workflows, as it changed the returned ID to no longer align with indexes on source lists.
This PR attempts to reconcile both worlds. It sets display index as an option of the menu, and resets backend accounting to use zero-indexing. So, for example, if I take a slice of entries and turn them into options, and the user selects the first entry, it will always have ID 0, to align w/ the index I started with. But if I want the display to start at 0 or 1 or any other integer, I can control that. I set it to default to 1, to align with the current display behavior.

Looks awesome thanks!!!

Woot, thanks!
Would it be possible to cut an updated tag (I guess 5.0.1 or 5.1.0) with this, so I can pin to the tag in my downstream go.mod?

v5.1.0 tagged


Filter job end-points

Summary
Part of #1270 , this PR pretends to clean-up some end-points from Jobs to only those ones that we are currently using.
Details
End-Points removed:

POST /jobs/: it's not possible to create jobs directly from the end-point
PUT /jobs/{id}: I think we are not updating jobs from PUT call
PATCH /jobs/{id}: I think we are not updating jobs from PATCH call
DELETE /jobs/{id}: we are not removing jobs using DELETE call

@akihikokuroda @IceKhan13 let me know if we are using any of the end-points that I removed in this PR. All tests are passing, I was trying to look through the code and running some tests that I have locally just in case too but I could forget something perfectly.


[cluster] Errors from the application are not re-tried now

Hi guys!
I've tweak how the {{ $method.Name }}WithOpts is working.
Mainly because it would trigger the opts.RetryAction on any error.
If the error was a future: timeout or a legitimate application error, it would retry it opts.RetryCount times.
I don't think that was intended. The retry pattern for requesting data from the actor is solid, it retries if the actor is busy or some networking issue - but if the actor returns an legit error I don't see the point of retrying.
Main change was here:
for i := 0; i < opts.RetryCount; i++ {
		res, err = fun()
		if err == nil || err.Error() != "future: timeout" {
			return res, nil
		} else if opts.RetryAction != nil {
				opts.RetryAction(i)
		}

It's only retrying it the error is a future: timeout - I'm happy to extend to other cluster errors if you guys see fit. Or take some other approach that allows for application errors to go throught the cluster without being retried.
Thanks!

Merged! = )


The Ignore setting don't seem to be working

Please run the SmellsSpec in the specs2 project. You should get failed examples for long lines whilst they should be ignored.

I changed the sniff path to "src/main/scala/org/specs2/matcher" and it successfully ignored the 'NoLongLines smell:
...
[info]   /Users/arosien/asr/specs2/src/main/scala/org/specs2/matcher/DataTable.scala should smell ok
[info]   + NoDefaultSuperCtors ('Java, 'Scala)
[info]   o NoLongLines ('*)
[info] ignored: failed snippet NoLongLines at /Users/arosien/asr/specs2/src/main/scala/org/specs2/matcher/DataTable.scala:1 (Your line is too long, make it shorter) 'package org.specs2' doesn't match '.*.{200,}.*'
...
[info]   /Users/arosien/asr/specs2/src/main/scala/org/specs2/matcher/ScalaCheckMatchers.scala should smell ok
[info]   + NoDefaultSuperCtors ('Java, 'Scala)
[info]   o NoLongLines ('*)
[info] ignored: failed snippet NoLongLines at /Users/arosien/asr/specs2/src/main/scala/org/specs2/matcher/ScalaCheckMatchers.scala:1 (Your line is too long, make it shorter) 'package org.specs2' doesn't match '.*.{200,}.*'
...
[info] Total for specification SmellsSpec
[info] Finished in 35 seconds, 190 ms
[info] 190 examples, 0 failure, 0 error, 2 skipped

So we agree that it's a bug? I'm not supposed to define every path I want to sniff under src/main/scala, right?

 I'll just let it run and verify I see that those Ignores are NOT ignored (the bug).

Can't reproduce, or I'm not quite understanding.

I'm wondering if this could come from the fact that I'm on windows and you're on Linux or Mac. Maybe path searching or path comparison could work differently. That'd be nice to get hold of another windows user to confirm that.


Unable to deploy - Error - No open port found. Make sure 'npm start' creates an HTTP server on a port (any).

URGENT - No open port found. Make sure 'npm start' creates an HTTP server on a port (any).
This string is repeated over and over, is there anyway to stop and remove the deploy ?

now rm <deployment> 😊

The deployment is stuck at "BUILDING" and won't let me remove that way :(
It's been like this for an hour, no timeout
[image: LearnUpon]
David Bryant
Account Manager
Email:
<EMAIL_ADDRESS>Phone:
+61 283 111 209 <+61283111209>
Web:
www.learnupon.com
Twitter:
@learnupon https://twitter.com/learnupon
Discover why customers love LearnUpon https://www.learnupon.com/customers/
.
On Mon, Sep 18, 2017 at 6:50 PM, Leo Lamprecht<EMAIL_ADDRESS>wrote:

now rm  😊
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/zeit/now-cli/issues/873#issuecomment-330161214, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AcJhDrdMSGZtQ8et-2aWg4qhJb-f81Glks5sji7ogaJpZM4PalTu
.

NVM Got it :) Thank you for your help!
[image: LearnUpon]
David Bryant
Account Manager
Email:
<EMAIL_ADDRESS>Phone:
+61 283 111 209 <+61283111209>
Web:
www.learnupon.com
Twitter:
@learnupon https://twitter.com/learnupon
Discover why customers love LearnUpon https://www.learnupon.com/customers/
.
On Mon, Sep 18, 2017 at 6:55 PM, David Bryant<EMAIL_ADDRESS>wrote:

The deployment is stuck at "BUILDING" and won't let me remove that way :(
It's been like this for an hour, no timeout
[image: LearnUpon]
David Bryant
Account Manager
Email:
<EMAIL_ADDRESS>Phone:
+61 283 111 209 <+61283111209>
Web:
www.learnupon.com
Twitter:
@learnupon https://twitter.com/learnupon
Discover why customers love LearnUpon
https://www.learnupon.com/customers/.
On Mon, Sep 18, 2017 at 6:50 PM, Leo Lamprecht<EMAIL_ADDRESS>wrote:

now rm  😊
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/zeit/now-cli/issues/873#issuecomment-330161214, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AcJhDrdMSGZtQ8et-2aWg4qhJb-f81Glks5sji7ogaJpZM4PalTu
.


fix: use the proper url to walk through modules during dev style coll…

Is
We get flashes of unstyled content for any included css in dev.
Should
There should be no foucs.
Background
The happenings actually are much more complicated than the fix might suggest 🥴. We had a series of unfortunate events with the changes from the last release:

The changes from https://github.com/nksaraf/vinxi/pull/310 applied a flawed logic to detect dynamically imported modules (as far as I can tell).
A later merge conflict resolution introduced two "bugs":

2a: https://github.com/nksaraf/vinxi/commit/00cb3d38fbc19ea3d49c656028a648da99c1450e#diff-59f5f323d1f5e2fd6f3b8f4f8275e8d7ceb138027e7faaec96719fdbd9eebc64R119 - it changed the already flawed logic to check staticImportedUrls on the parent node, instead of the current node of the for-loop
2b: https://github.com/nksaraf/vinxi/commit/00cb3d38fbc19ea3d49c656028a648da99c1450e#diff-59f5f323d1f5e2fd6f3b8f4f8275e8d7ceb138027e7faaec96719fdbd9eebc64R120 - it used the wrong node url to walk through the modules

Since the logic for detecting dynamically imported modules was flawed from the beginning, I removed it which fixed 2a. Secondly I fixed the line that resulted in 2b.
Follow ups
Since this undoes the changes from https://github.com/nksaraf/vinxi/pull/310 we need to discuss a better way to identify and exclude dynamically imported modules in the style collection - (..personally I am not a fan of excluding them and the resulting foucs, but if thats really the goal, then we should atleast do it properly 😅🙈)
Videos
Before fix
https://github.com/nksaraf/vinxi/assets/4012401/ba066aa7-989a-48a2-8ed6-5791bb07bc51
After fix
https://github.com/nksaraf/vinxi/assets/4012401/0158d3e8-e56d-4fa1-a475-7a09eb322d44

Why do you see the logic I wrote before was flawed? From my understanding that is a valid way to detect whether modules are statically imported (since module nodes will have node.staticImportedUrls?.size > 0 if statically imported) and the bug just originates from those two merge conflict resolutions you mentioned.

I just found that the issue was also excluding .css modules from adding. I'll make a follow-up PR for this.


Change types scalable nodes

In the current state there are modules with which there are autoscaling policies associated. However such modules do not belong to scalable types.
This PR addresses it, by changing the type of the modules that have associated autoscaling policies to seaclouds.nodes.ControlledDynamicWebAppCluster.
This PR also creates seaclouds.nodes.Compute type in node_types.
Tests have been created to check that changes in the types have been produced in the correct nodes.
You can see that I've not squashed the commits. I've done it on purpose. I would like @rosogon looking at the two firsts because they are related to his PR that is currently failing. I thought it would be clearer for him if I do not squash all the changes into one already from the beginning.

Current coverage is 32.29%

Merging #195 into master will increase coverage by +0.10% as of ddc6191

@@            master    #195   diff @@
======================================
  Files          320     322     +2
  Stmts        11692   11756    +64
  Branches      1471    1479     +8
  Methods          0       0
======================================
+ Hit           3764    3797    +33
- Partial        386     392     +6
- Missed        7542    7567    +25

Review entire Coverage Diff as of ddc6191

Powered by Codecov. Updated on successful CI builds.

Thx @perezp. Good job.
I have added some minor comments. could yo take a look?

+1

Thanks for the review @kiuby88


Inconsistent Scanning Rates

Hey all,
I've run into some interesting behavior with how often the app reports scans (points?) to the server:
In tracking mode, after hitting Start Scan, it may take up to a minute for the app to begin reporting to the server ("X seconds ago: added X bluetooth and X wifi points"). Once it starts reporting, the following behavior follows:

Keep screen alive, and app open, for about 30 seconds. Typically every 10 seconds, the app will report to the server. However, this sometimes varies up to 15 or 20 seconds on occasion.
For exactly four reports, everything works fine.
After the fourth report to the server, the app does not report to the server for at least another 30 seconds, up to a minute.
After 30-60 seconds, the app will report.
After another four total reports, the process repeats.

I've disabled WiFi Scan Throttling in dev options, disabled battery optimizations for the app, and have set the Location permission to Allow all the time.
This happens with the app in both foreground and background.
I'll be able to test further in the morning, but so far, it's been a head-scratcher.
My setup:

Self-hosted server using Docker inside a Debian VM, on LAN
Debian VM has 4GB RAM and 64GB storage (resource usage doesn't seem to be a problem, 52GB free storage space, always at least 3GB free RAM, and CPU never reaches above 20% with 2 cores allocated).
Samsung Galaxy S10 Plus, Android 10

The limit of four scans is awfully coincidental with the WiFi throttling limits:

Each foreground app can scan four times in a 2-minute period

But WiFi throttling is disabled in dev options (I triple checked), and it's limited to a one-minute period, not two-minute. Maybe Android has a hard-set, 1-minute limit?
Thanks!

Studying the app code, and if I understand correctly, this line:
https://github.com/schollz/find3-android-scanner/blob/4f0100eccf41ec097416bcea55f17375376898df/app/src/main/java/com/internalpositioning/find3/find3app/MainActivity.java#L351 https://github.com/schollz/find3-android-scanner/blob/4f0100eccf41ec097416bcea55f17375376898df/app/src/main/java/com/internalpositioning/find3/find3app/MainActivity.java#L352
Limits scanning to four times, before stopping. Then it waits for another message from server before resuming scanning (as this if statement is inside an onMessage, which is Android's handling of a websocket receive?)
However, Go is totally foreign to me, so understanding https://github.com/schollz/find3 will be a project on its own for me that I'm very eager to tackle :)
I'm in the process of setting Android Studio up again and will experiment with a copy of this repo.

Alright, after playing with it in Android Studio, my above theory isn't correct. Setting line 351 to >5 does not result in more scans running before the break period.
However, following the log as the app scans, "proper" behavior (i.e., during the four scans) is:

D/BluetoothAdapter: startDiscovery
D/ScanService: started wifi scan
started discovery

In logs. Then, after 10 seconds:

D/ScanService: timer off, trying to send data

After the fourth scan, timer off doesn't occur after 10 seconds.

After more investigation, it seems that the issue stems from WifiManager not broadcasting. Further:
As per https://developer.android.com/reference/android/net/wifi/WifiManager#startScan()

This method was deprecated in API level 28.
The ability for apps to trigger scan requests will be removed in a future release.

As per https://issuetracker.google.com/issues/79906367

"WifiManager startScan throttled"
Status: Won't Fix (Intended behavior)

Despite scan throttling being turned off, I suspect WifiManager has something hard-coded, or is otherwise buggy (at least in Android 10), as it was deprecated in Android 9 (API level 28).
As per https://android-developers.googleblog.com/2018/03/previewing-android-p.html

Android P adds platform support for the IEEE 802.11mc WiFi protocol -- also known as WiFi Round-Trip-Time (RTT) -- to let you take advantage of indoor positioning in your apps.

 If I understand Android Studio correctly, FIND3 is targeted towards API Level 24, and as such, RTT is not available. I wonder if the large API Level gap be causing quirks as well?
Anyway, thank you schollz for your amazing work. If you're thinking of continuing development on FIND, I'd be happy to help any way I can, though I'm still learning. :)

I just noticed ScanService has an interesting "chunk" of code with multiple delays (started at line112). I feel very silly for missing this.


cupy website problem

https://docs-cupy.chainer.org/en/stable/
The page isn’t redirecting properly

Looks like the website is down?

Yes, but it worked yesterday.
On Tue, Apr 28, 2020, 7:49 PM Leo Fang<EMAIL_ADDRESS>wrote:

Looks like the website is down?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/cupy/cupy/issues/3313*issuecomment-620962432__;Iw!!Mih3wA!XQHx9ElWmgI9lL9G2qL50sqc4Y8jdNd7HwcWM0ki5RrEDD95Z_YHR-HdkUzPQE6jyw$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AM5FCP65LHFMWWX4I6DU23DRO6IU5ANCNFSM4MTH73RA__;!!Mih3wA!XQHx9ElWmgI9lL9G2qL50sqc4Y8jdNd7HwcWM0ki5RrEDD95Z_YHR-HdkUw2mTzJgA$
.

We are looking into it, thanks :)

The website works now!
Thanks,
Qin
On Wed, Apr 29, 2020 at 8:04 PM emcastillo<EMAIL_ADDRESS>wrote:

We are looking into it, thanks :)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/cupy/cupy/issues/3313*issuecomment-621584850__;Iw!!Mih3wA!U45wCPQiitz1Jti1Nyx7fg-a14KN5f4YtfO8eadhtyA36JbZiQILmvnCmaqJyphQBw$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AM5FCPZLSHLGYP2VQYKH3QLRPDTDXANCNFSM4MTH73RA__;!!Mih3wA!U45wCPQiitz1Jti1Nyx7fg-a14KN5f4YtfO8eadhtyA36JbZiQILmvnCmapwNI5hTw$
.


Add development support for SSL

Revise the dev_loadbalancer role so that HAProxy does SSL
Update the omeka and site_proxy roles to allow the API to use SSL.

This PR is bound to the frontend changes currently under review as https://github.com/dpla/frontend/pull/83

Hold on before reviewing; need to change one thing.

OK, ready for review.

Here's some information I'm going to add to the next automation version's release notes, which should help with testing.

You need to have api_default_protocol to your group_vars/all file
If you're switching to https by modifying api_default_protocol, you need to re-run the frontend, exhibitions, and site_proxy playbooks.
You need to have the latest version of frontend.
Read this re configuring your browser to use the local.dp.la self-signed certificate:
http://blog.getpostman.com/2014/01/28/using-self-signed-certificates-with-postman/  I have found that you get by without restarting Chrome, if you use it. If you recreate the loadbal VM or you regenerate the SSL certificate, you'll have to redo the steps in that blog post to replace the trusted local.dp.la certificate in your chain.

Upgrade instructions:
ssh <you>@loadbal
sudo aptitude purge hatop
sudo aptitude purge haproxy
exit
$ ansible-playbook -u <you> -i development playbooks/dev_loadbalancer.yml

I'm working on adding some of that the the README, to go along with this pull request...

👍

This should be ready for review again.
Please do not merge yet. I'll want to squash the last commit before it's merged.

Will do

An update on this PR's scope. The changes are now:

Add development support for SSL
Add port to es_cluster_loadbal
Fix Exhibitions frontend URL variable
Clean up redundancy in dev_ingestion_all.yml

I am debating how to squash these. All but the last are in some way related to enabling SSL in development. I think the last one should remain a separate commit.

@markbreedlove I think it makes sense to squash those four SSL commits together
979bc18
3bd830f
419b130
2b28564

@markbreedlove squashed and good to merge into develop.

@moltude Yes, I think it's good to merge.


Fix badges attribute for the User class

Summary

The flag property in the API is no longer used to determine the user's badges, resulting in the library thinking the user has no badges. Instead, it uses the badges property. This PR will make it use the badges property instead of flags
Heres an example for a user with badges (i used pprint to pretty print it):
{'_id': '01F1WKM5TK2V6KCZWR6DGBJDTZ',
 'avatar': {'_id': '1XpKpyqGvJ5BBl6uNfg5DBd0Nliyf4KVbtRH4pmLnZ',
            'content_type': 'image/png',
            'filename': 'sJ0lsZxzlYTyxC3HVzogea9LKlCVwtpvYMNZIFVA_k.png',
            'metadata': {'height': 410, 'type': 'Image', 'width': 411},
            'size': 343493,
            'tag': 'avatars'},
 'badges': 1807,
 'discriminator': '6328',
 'display_name': 'Jennifer',
 'online': False,
 'relationship': 'None',
 'status': {'presence': 'Focus', 'text': 'dandori issue'},
 'username': 'Infi'}

This also adds the relevant joke 2 badge (amorbus) in the UserFlags class, which was previously missing.
Checklist

[x] If code changes were made then they have been tested.

[x] I have updated the documentation to reflect the changes.

[ ] This PR fixes an issue.
[x] This PR adds something new (e.g. new method or parameters).
[x] This PR is a breaking change (e.g. methods or parameters removed/renamed)
[ ] This PR is not a code change (e.g. documentation, README, …)

Thanks!


Omron 2jcie bu01 usb

Initial implementation of Omron's USB type Environment Sensor using USB to UART interface

Merged, thank you! Please consider consolidating this further by implementing interfaces, adding additional examples and perhaps refactoring under a single library.


[BUG] Connection reset by peer errors on the Sandbox environment

Bug Description
We are intermittently encountering Connection reset by peer errors for a few connector calls
Expected Behavior
Ideally, we shouldn't have any of these errors in our system
Have you spent some time checking if this bug has been raised before?

[X] I checked and didn't find a similar issue

Have you read the Contributing Guidelines?

[X] I have read the Contributing Guidelines

Are you willing to submit a PR?
None

Is there any fix for this? It really slows down development productivity.


If Configured, Wait for a Publisher Confirm When republishing to the DLQ

republishToDlq is sending messages to a dlx using a fire-forget style and right away it acks the rejected message. However, specially in clustered environments, it is too risky to send messages without publisher-confirmation. We are at risk of loosing the rejected message.
Today, RabbitMQ does not use publisher-confirmation to send a rejected message to a dlx. This means, there is a risk (in clustered environments) whereby we could lose messages because RabbitMQ removes the message from the queue right after sending the message.
Here is where republishToDlq  comes very handy if it used publisher-confirm under the covers and only acked the rejected message after we receive an publisher-confirm acknowledgement.
There are corner cases that we need to handle such as:

what to do if we receive a negative publisher-confirm? Maybe reject+requeue so that we do not lose the message? or retry it again?
do we want to ensure the message also gets to a queue? i.e. use mandatory flag.
how long do we wait for the publisher-confirmation? I guess a configurable timeout should be enough.

Already implemented by https://github.com/spring-cloud/spring-cloud-stream-binder-rabbit/pull/314


Please put a license on this code ...

... so that we know, under which condition it can be used.
Thanks
Uwe

I'll post a license, but until I do all this is MIT


LiveKit Server Startup Error: Secret Key Length and Redis Connection Issues

Hello LiveKit team,
I'm encountering a couple of issues when trying to start the LiveKit server on my environment. Below are the error logs and details regarding the issues:

Secret Key Length Error

During the startup, the LiveKit server logs an error related to the secret key length being too short. The exact log message is as follows:2024-03-17T04:59:09.818Z ERROR livekit config/config.go:668 secret is too short, should be at least 32 characters for security {"apiKey": "apioenimkey"}

It seems that the validation step for the secret/API key requires it to be at least 32 characters long. However, I'm unsure if this requirement has changed recently or if there's a specific format the key needs to follow.

Redis Connection Refused

Following the secret key length error, there's also an issue with connecting to Redis. The log indicates that the connection is refused:2024-03-17T04:59:09.820Z INFO livekit redis/redis.go:133 connecting to redis {"simple": true, "addr": "<IP_ADDRESS>:6379"}
unable to connect to redis: dial tcp <IP_ADDRESS>:6379: connect: connection refused

This issue occurs despite the Redis server being up and running, and accessible from other services within the same network.

I would appreciate any guidance or recommendations on resolving these issues. Specifically, I'm looking for:

Confirmation on the secret/API key length requirement and any format it needs to comply with.
Suggestions on troubleshooting the Redis connection issue, considering the server is operational and there haven't been recent changes to its configuration or network access rules.

@cubxxw Did you figure out what went wrong in your setup for Redis connection?

same problem with you, got " connection refused" error even if my redis is accessible in the same network.

what is the network setup for Redis? which OS? and are you running livekit via Docker?

i setup my redis standalone server in my own os x and running livekit via docker.

that is the problem, Redis by default only alllows localhost connections. Any application running within a docker container will not appear as localhost to Redis. You'll need to edit Redis configs to allow it to connect. This is not a livekit-specific issue.


Sometimes folders are not shown

Hi,
Sometimes we have a strage issue. I try to explain this issue:
We create five folders using droppy (all shown), after a few hours only two of five folders are present inside droppy, but if i take a look at the filesystem all five folders are present.
Filesystem:
├── stadtbezirksstatistik
├── wahlstatistik
├── wahlstatistik_(1.wg)
├── wahlstatistik2017_bt
└── wahlstatistik2018_ob_wg1

Droppy:
├── stadtbezirksstatistik
└── wahlstatistik

Missing:

wahlstatistik_(1.wg)
wahlstatistik2017_bt
wahlstatistik2018_ob_wg1

Maybe a problem with underscores?
Droppy-Version: "droppy 8.0.4"

Sorry for the late response. I tested with your filenames but couldn't reproduce. Generally, all filenames including Unicode are supported, so that shouldn't be it.
What kind of file system is the files directory on? If it is a network drive, you might need to set pollingInterval to something like 10000 (to scan new files every 10s) because change detection mechanisms can be unreliable on those.

Hi, no problem ;)
The files are stored on an NFS-Share but since Droppy 9.0.x the problem seems to be fixed.

Okay, I'd definately recommend setting a pollingInterval with NFS.


🔖 Release version 4.5.2

🔗 Dependencies
Issues of the milestone corresponding to this version should be done before resolving this issue.
✅ Checklist

[x] 🔖 Set Gradle project's version to this new one.
[x] 📝 Update versioning annotations of unreleased declarations.
[x] 📝 Check the copyright notice in the license documentation.
[ ] 🚀 Deliver packages to the Maven central by running the delivery workflow.
[ ] 🚀 Close valid packages and drop invalid ones on the Maven central.
[ ] 🚀 Release packages on the Maven central.
[ ] 🚀 Run the ./gradlew :publishApiReference command for publishing the new API reference.
[ ] 📝 Move the unreleased changelog to a GitHub release draft.
[ ] 🔖 Run the ./gradlew :tag command for creating a Git annotated tag for this version.
[ ] 🔖 Publish the GitHub release on the annotated tag.
[ ] 🔖 Set Gradle project's version to the next snapshot.
[ ] 📝 Announce this release on Reddit.
[ ] 📝 Announce this release on Slack.
[ ] 📝 Announce this release on Twitter.

Due to a migration of Maven Central, it is now impossible to deliver packages without further actions (see documentation for migrating from legacy OSSRH to Central Portal).

I've contacted the Sonatype Support for migrating the org.kotools namespace to the new Central Portal.
To be continued...


EKF height sensor selection and fallback in two places

The logic that handles height sensor fallback is implemented in more than one place, eg Ekf::controlHeightFusion() and Ekf::controlHeightSensorTimeouts()
This should be centralised.

I don't think this is solved


Refactoring and Upgrading to .net 5.0

Hello there Can I Contribute on this project I'm gonna Upgrade it to .net 6.0 and Refactor Some Issues, I made a very little Refactoring, Just take a look please.

Excuse me, Are you gonna merge them?

Hello sir, can I contribute this API with you? And if everything is OK ...
Merge them with master branch?
On Thu, Nov 25, 2021, 10:56 AM Ahsan Raza @.***> wrote:

@.**** approved this pull request.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/evgomes/supermarket-api/pull/11#pullrequestreview-815711340,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANV3QGCACFKMYBSZHPKTWGTUNX25LANCNFSM5IXBHT4A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Yes, still in progress

Hi @mahmmoudkinawy,
Everything looks good, I will merge this pull request. Thank you for your contribution.
Thank you @AhsanRazaUK for reviewing it too.
I will update the Readme with the changes list later.

@all-contributors please add @mahmmoudkinawy for code

@all-contributors please add @AhsanRazaUK for review


Add an ALL option to the runs column

So the current filtering structure allows us to build queries like "Gecko has STATUS = PASS or OK or SKIP". If we want to get all results which show ERROR for all runs (Servo and Gecko let's say), then we will need to add two constraints, the first saying "Gecko is ERROR" and the second saying "Servo is ERROR". It would be convinient if we could add an "ALL" option (implying both Gecko and Servo are ERROR).
One nuance that is important here is that we need to disable the "Results from " option if ALL is selected. ("ALL" is not "Results from Gecko" makes no sense). One must disable this option when only one run is present (you have imported only one log file)

Could you elaborate? I would like to fix this.

@Sumith1896 , I've updated the issue description. If you would like to work on it, I'll go about describing a brief procedure to solve it along with some code hints.

@jgraham , @Sumith1896 I'll start working on this bug :smile:


Add Ruby Github Workflow

Since only admins can setup CircleCi I've instead opted for setting up Ruby Github Workflow

Instructions misunderstood, need to actually implement CirlceCi


RuuviTag support

Hi. Is there any plan to directly support RuuviTags in this library?
Many thanks.
M.

That's not in the plan right now. There have been a few posts on the Community about Ruuvi and other options, like this one: https://community.particle.io/t/ble-beacon-thermometers/60444/4


[Feature]: get all wallets data when you connect them via metamask

Is your request related to a problem?
I need to collect all wallets addresses when user connects metamask wallets. I get only data for current active wallet in metamask.

Feature Description
Add connected wallets data to onboard.state.select() subscription.
https://github.com/blocknative/web3-onboard/blob/v2-web3-onboard/packages/core/README.md#auto-selecting-a-wallet
Alternative Solutions
Maybe I am missing something in the API. Please point me on where I can get this info if it is available somewhere.
Anything else?
Thank you for the work you've done on this project!

@Badbreaddead the discussion that has been taking place has been directly from our BixDev lead with the MM team's
Here you can see the MM Docs where only the active wallet is returned/emitted - https://docs.metamask.io/guide/ethereum-provider.html#connect


Consider including Tekton release w/ dashboard fix for init container failure displays in Kabanero 0.9.0

The Tekton community has put in a fix for the Tekton issue https://github.com/tektoncd/dashboard/issues/1155 with the following comment:
"Ensure we display details of init container failures in the
TaskRun and PipelineRun details pages, to aid users in
debugging failures (often related to missing / misconfigured
secrets, etc.)"
So this update should be included when a new release of the "Tekton Dashboard and WebHooks Extensions" is available. This is the associated release page https://github.com/tektoncd/dashboard/releases
Could Kabanero pick up the new release of the "Tekton Dashboard and WebHooks Extensions" with this fix for the 0.9.0 release?

Tekton will contain the fix and become available after Kabanero 0.8.0.

@anneqm - Any update of this fix and what Tecton release will contain it would be appreciated.

@marikaj123 This fix, https://github.com/tektoncd/dashboard/issues/1155, was included in the Tekton Dashboard v 0.6.0 so it is ready for when kabanero moves up to Dashboard v0.6.1.

@bconey - FYI: the fix was provided in Tekton release 0.6.0 and above https://github.com/tektoncd/dashboard/releases.

I am closing this, as we've picked up dashboard release 0.6.1 in Kabanero 0.9.0.


Error: could not detect network when tapping join group in frontend

Describe the bug
Error: could not detect network when tapping join group in frontend
To Reproduce
Steps to reproduce the behavior:
following steps in readme

yarn start:contracts

yarn start:web-app

yarn start:relay

tap join group in frontend

Expected behavior
❯ yarn start:relay
Started HTTP relay API at http://localhost:3000/
Error: could not detect network (event="noNetwork", code=NETWORK_ERROR, version=providers/5.6.8)
    at Logger.makeError (/Users/paulyu/paul_playground/boilerplate/node_modules/@ethersproject/logger/src.ts/index.ts:261:28)
    at Logger.throwError (/Users/paulyu/paul_playground/boilerplate/node_modules/@ethersproject/logger/src.ts/index.ts:273:20)
    at JsonRpcProvider.<anonymous> (/Users/paulyu/paul_playground/boilerplate/node_modules/@ethersproject/providers/src.ts/json-rpc-provider.ts:444:23)
    at step (/Users/paulyu/paul_playground/boilerplate/node_modules/@ethersproject/providers/lib/json-rpc-provider.js:48:23)
    at Object.throw (/Users/paulyu/paul_playground/boilerplate/node_modules/@ethersproject/providers/lib/json-rpc-provider.js:29:53)
    at rejected (/Users/paulyu/paul_playground/boilerplate/node_modules/@ethersproject/providers/lib/json-rpc-provider.js:21:65)
    at processTicksAndRejections (node:internal/process/task_queues:95:5) {
  reason: 'could not detect network',
  code: 'NETWORK_ERROR',
  event: 'noNetwork'
}

Technologies (please complete the following information):

Node.js version: v18.10.0
NPM version: 8.19.2
Solidity version: 0.8.4

Additional context
when I was running the contract, I got following warnging:
You are using a version of Node.js that is not supported by Hardhat, and it may work incorrectly, or not work at all.

Please, make sure you are using a supported version of Node.js.

To learn more about which versions of Node.js are supported go to https://hardhat.org/nodejs-versions

My Trial
https://github.com/ethers-io/ethers.js/issues/1316 here's a similar error message, but it doesn't seems to helps

Hi @NOOMA-42!
Which version of NodeJS are you using?
Have you created the .env file? You can run the following command:
cp .env.example .env

I'm using v18.10.0 for NodeJS.
I've also created .env file as default
ETHEREUM_URL=http://localhost:8545
ETHEREUM_CHAIN_ID=1337
ETHEREUM_PRIVATE_KEY=ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
CONTRACT_ADDRESS=0xDc64a140Aa3E981100a9becA4E685f962f0cF6C9
RELAY_URL=http://localhost:3000
REPORT_GAS=false
INFURA_API_KEY=
COINMARKETCAP_API_KEY=

Hi @NOOMA-42!
Which version of NodeJS are you using?
Have you created the .env file? You can run the following command:
cp .env.example .env

Can you check if the Hardhat Ethereum URL is correct when you run yarn start:contracts? Is it generating the right contract address (0xDc64a140Aa3E981100a9becA4E685f962f0cF6C9)?

Verifier20 contract has been deployed to: 0x5FbDB2315678afecb367f032d93F642f64180aa3
Poseidon library has been deployed to: 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512
IncrementalBinaryTree library has been deployed to: 0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0
Semaphore contract has been deployed to: 0xCf7Ed3AccA5a467e9e704C703E8D87F634fB0Fc9
Greeter contract has been deployed to: 0xDc64a140Aa3E981100a9becA4E685f962f0cF6C9

Can you check if the Hardhat Ethereum URL is correct when you run yarn start:contracts? Is it generating the right contract address (0xDc64a140Aa3E981100a9becA4E685f962f0cF6C9)?

I can't reproduce this error :/ The only difference should be the Node.js version, but it looks like it is using the wrong Network URL.

It's the Node.js version causes the error. The hardhat only supports Node.js 16 Gallium LTS release for now and haven't support 18 Hydrogen LTS release. After downgrading Node.js, the error were gone.

It's the Node.js version causes the error. The hardhat only supports Node.js 16 Gallium LTS release for now and haven't support 18 Hydrogen LTS release. After downgrading Node.js, the error were gone.

Ahn, good to know! Thank you very much!


Remove Calendar from the top main menu

This reverts https://github.com/xHain-hackspace/xhain-website/pull/36

Deploying preview to https://xHain-hackspace-xhain-website-pr-40.surge.sh


database/sql: reuses expired connections with strategy= alwaysNewConn

What version of Go are you using (go version)?

$ go version
go version go1.11.5 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/georgeleslie-waksman/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/georgeleslie-waksman/co/backend/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/georgeleslie-waksman/co/backend/opt/go1.11.5"
GOTMPDIR=""
GOTOOLDIR="/Users/georgeleslie-waksman/co/backend/opt/go1.11.5/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/41/19kt662x72n9nfj8hzb8t1q00000gq/T/go-build118274996=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

When connections are released, they may bypass the pool and be used to fulfill requests made with strategy=alwaysNewConn even if they are "expired" according to SetConnMaxLifetime, which allows the connections to fail on BeginTx with ErrBadConn despite passing through putConn with err == nil
The following testcase (for database/sql_test.go) exhibits the failure case:
func TestPutConnExpiredOrBadReset(t *testing.T) {
	execCases := []struct{
		expired bool
		badReset bool
	}{
		{false, false},
		{true, false},
		{false, true},
	}

	t0 := time.Unix(1000000, 0)
	offset := time.Duration(0)

	nowFunc = func() time.Time { return t0.Add(offset) }
	defer func() { nowFunc = time.Now}()

	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	db := newTestDB(t, "magicquery")
	defer closeDB(t, db)

	db.SetMaxOpenConns(1)

	for _, ec := range execCases {
		ec := ec
		name := fmt.Sprintf("expired=%t,badReset=%t", ec.expired, ec.badReset)
		t.Run(name, func(t *testing.T) {
			db.clearAllConns(t)

			db.SetMaxIdleConns(1)
			db.SetConnMaxLifetime(10 * time.Second)

			conn, err := db.conn(ctx, alwaysNewConn)
			if err != nil {
				t.Fatal(err)
			}

			var wg sync.WaitGroup
			wg.Add(1)
			go func() {
				defer wg.Done()
				conn, err := db.conn(ctx, alwaysNewConn)
				if err != nil {
					t.Fatal(err)
				}
				db.putConn(conn, err, false)
			}()

			// Wait for pending request
			for len(db.connRequests) < 1 {}

			if ec.expired {
				offset = 11 * time.Second
			} else {
				offset = time.Duration(0)
			}

			if ec.badReset {
				conn.ci.(*fakeConn).stickyBad = true
			}
			db.putConn(conn, err, true)

			wg.Wait()
		})
	}
}

with output:
--- FAIL: TestPutConnExpiredOrBadReset (0.00s)
    --- FAIL: TestPutConnExpiredOrBadReset/expired=true,badReset=false (0.00s)
        sql_test.go:2226: driver: bad connection
    --- FAIL: TestPutConnExpiredOrBadReset/expired=false,badReset=true (0.00s)
        sql_test.go:2226: driver: bad connection
FAIL
FAIL	_/Users/georgeleslie-waksman/co/go/src/database/sql	1.337s

What did you expect to see?
BeginTx's third attempt with strategy=alwaysNewConn should not reuse an existing connection and should definitely not reuse an expired connection.
What did you see instead?
BeginTx's third attempt fails with ErrBadConn due to connection expiration.

To the best of my understanding, we can resolve the issue by modifying putConnDbLocked so that only new connections may only be directly used to fulfill requests and reused connections must pass through the idle pool.

This issue also occurs and is seriously exacerbated if the session resetter channel db.resetterCh becomes blocked, in which case connections will be released back with err = driver.ErrBadConn and sent for reuse.

CC @kardianos

I have updated the issue with a more minimal failure case that can be dropped directly into database/sql_test.go

I have put together a fix and submitted a PR: https://github.com/golang/go/pull/32656

@gwax Let's ignore the session resetter issue for now, I will resolve that in the next release.
Can you explain when you encounter this issue, and what it looks like for your application when you do? Thanks.

In our application, with SetConnMaxLifetime, we experience a small but steady rate of driver.ErrBadConn being returned by DB.BeginTx.
In debugging and tracing the issue, we found the code path is as follows:

DB.BeginTx tries twice with strategy == cachedOrNewConn, getting driver.ErrBadConn both times: https://github.com/golang/go/blob/master/src/database/sql/sql.go#L1676
DB.BeginTx calls DB.begin with strategy == alwaysNewConn: https://github.com/golang/go/blob/master/src/database/sql/sql.go#L1682
DB.begin calls DB.conn with strategy == alwaysNewConn: https://github.com/golang/go/blob/master/src/database/sql/sql.go#L1694
We have the maximum number of connections open so we push a request to db.connRequests: https://github.com/golang/go/blob/master/src/database/sql/sql.go#L1176
(thread2) Concurrently to this, another thread finishes execution with a connection that has gone (or is just about to go over its lifetime) and attempts to put the connection back: https://github.com/golang/go/blob/master/src/database/sql/sql.go#L1322
(thread2) The released connection is then used to satisfy the pending request (reused connection for a new alwaysNewConn request): https://github.com/golang/go/blob/master/src/database/sql/sql.go#L1371
DB.conn checks if the connection has expired (it has) and we return driver.ErrBadConn: https://github.com/golang/go/blob/master/src/database/sql/sql.go#L1207

Adding an expiry check to the putConn codepath decreased the rate of errors (smaller concurrency race window) but did not eliminate them.
Enabling session resetter hits the same race condition but spikes our error rate. In this case, the resetter was overloaded and we were having dc.lastErr set concurrently to the connection release (step 6): https://github.com/golang/go/blob/master/src/database/sql/sql.go#L1339

The PR that I have submitted is fairly large and is, perhaps, clearer to understand as two separate changes (I can resubmit as two PRs, if that makes it easier).
The first change is quite large, and refactors db.freeConn from []*driverConn to chan *driverConn. This change is necessary so that while we are at max connections and waiting for a request to be filled, we can use a case statement to unblock on either a direct request or on a connection going to the pool: https://github.com/golang/go/pull/32656/commits/6baa77b79f1c5d208e340f3111b3a234f913cc41
The second change is quite small and makes sure that reused sessions always go to the connection pool, not connRequests: https://github.com/golang/go/pull/32656/commits/9816712de941689afbae2f5e80d4c8079ae1a18d

@gwax Thank you for the bullet point description of events that lead up to this.
Don't resend the PR yet. There is actually a deeper issue I would like to address here I think. The propensity for this connection pool implementation to retain expired connections is a fundamental design issue.
Any change we do won't make it into the Go1.13 release (this is on me, I'm sorry). So we are targeting Go1.14 here.
Fundamentally, if a driver connection is expired then it should be closed and a new one should be returned, "atomically" within conn. If we factor out the code that opens a new connection at the end of db.conn, then allow it to be called from either expired or normal case, that seems more optimal then worrying about how the connections are represented in a queue (and would touch less code).
What do you think of that approach?

I am happy to live with a Go1.14 target and patch our deployed version of the code. I far prefer a patch that will eventually be in mainline so that we can timebox deploying a fork on our end.
Ultimately, I am in favor of any approach that fixes this bug, with a preference for solutions that minimize race conditions and complexity, while maximizing readability. If a small fix is possible, I will always prefer changing fewer lines of code over any other preferences.
Ultimately, I don't think fully avoiding expired/broken connections in the pool is possible. A connection could expire at the very moment it is pulled from the pool no matter how aggressively we clean it. That, and, aggressive cleaning comes at a cost.
I do, in principle, like the idea, which I think you're proposing, that we could close an expired connection and open a new one all within the same conn() request (presumably with the relevant locks held to ensure connection limits and concurrent safety).
That said, I think we're still likely to run into race conditions and queuing fairness issues if we continue to use a slice for the connection pool and channels for new requests. Every other, smaller, attempt I made to fix this issue ran afoul of something.
From a readability and maintainability standpoint, I would really prefer if strategy = alwaysNewConn always meant that a connection was not being reused.
My PR was written with the goal of having the slice -> buffered chan connection pool change be the only architectural change. I could take another pass and see if my changes could be simplified or made to touch fewer places.
In the end, I think we want a conn() method of the form:
db.connRequests <- something
select {
case <-ctx.Done():
  // bail
case conn, ok := <-db.connectionPool:
  // if not ok return db closed
  // if good connection and newOrCached: return
  // else close, open and return a new one
case conn, ok := <-db.filledRequests:
  // if not ok return db closed
  // return conn
}

If we take a broader approach, I would love to see db.connRequests become FIFO instead of depending on whatever is the first value to come when iterating through the map via range. I am also happy to leave that as outside the scope of this issue and either file another, or disregard.
If there's a plan, or architecture, that you're ok with, I have some time and energy available for implementation.

@kardianos this issue still exists and is still causing errors for us. Could you provide some attention or direction to this?
In the hopes of trying to get a fix into the standard library, I have reorganized and curated the commits in my earlier PR: https://github.com/golang/go/pull/32656
The commits now reflect three separate steps in the fixing process:

https://github.com/golang/go/pull/32656/commits/13d516d6d235ee0850110d9f35f4bc203dfbb318 - a refactor of the code to convert the free connection pool from a slice to a buffered channel (this is necessary to properly handle concurrent pool access).
https://github.com/golang/go/pull/32656/commits/08f679ed25113dfc31c3f2e32dcad40b148f80eb - a failing test
https://github.com/golang/go/pull/32656/commits/93f9037048a359ce6b0728ab285c17b1b0eb9d74 - a fix to prevent old sessions being used to fill new requests

If there is more that I can do or another approach that you think is better, please provide me with some direction. I am happy to devote time and energy to creating a fix, as long as my fix has a chance of landing.

have same problem
go version go1.13.3 linux/amd64

mysql connection closed by server side, then transaction throw an error.

CL Ready. Waiting for a reviewer.

Thanks for this, been chasing this in our apps for a while, thought it was a driver error but after adding logging to the driver it was never returning this, so this could be the cause of our issues too.

Thank for @gwax and @kardianos 's effort to address it out, it helps a lot on trouble shooting my application.
I can expect this issue will be resolved on go v1.15 , right?

nb


Publish to OpenVSX

To use ProjectIDX and Theia, distribution of OpenVSX is required.

OpenVSX namespace registration completed
Claiming namespace comnori

This may also have the same issue, should check it along with that issue.

https://github.com/comnori/vscode-java-pack/issues/2#issuecomment-1863976655


Add MusicXML compatibility

Hi, It's great to see you contribute this package, it's exactly what this organization needs. I originally wanted to implement the features in this package in MIDI.jl, but now it seems too good to be true, so MIDI.jl can focus on MIDI parsing.
I think there is still a lot of work to be done on MusicXML support at this point.

MusicXML.jl is not actively maintained and has not been updated for a long time.
MusicXML.jl uses AcuteML.jl as a mapper to convert XML files and Julia types. But we have to define the structure of MusicXML julia types manually, rather than automatically generated from the official MusicXML 4.0 schema, which may cause some unexpected behavior in MusicXML file parsing.
Unfortunately, Julia still does not have a ready-made tool for converting XSD to julia types, so maybe we need to implement it ourselves.

Unfortunately I personally don't know anything about XML or MusicXML, but it if you are able to implement that it would be fantastic!

Unfortunately I personally don't know anything about XML or MusicXML, but it if you are able to implement that it would be fantastic! I'm happy to help where I can of course.

Thank you very much!
I don't think this will happen anytime soon, the continued maintenance of MusicXML.jl requires a lot of work. At least I think that MusicXML.jl is not performing very well right now, and there are many scores that cannot be parsed correctly.
I think we can keep this issue open until we have a mature MusicXML.jl.

Another thing I want to emphasize is whether we have to implement MusicXML export in MusicTheory.jl？
In my opinion we should separate concerns and make this package contain only music theory stuff.
Other packages in this organization have made similar mistakes. One package implements a feature that should be implemented by another package
My suggestion is to let MusicManipulation.jl do the corresponding MusicXML/Lilypond export function. Make this package contain music theory content only. This achieves orthogonality in the functionality of each software package within the organization.

All in all, I think this package should focus on "The computable part of music theory”, like pitch, notes, chords, duration, intervals, modes.
Other features should be added with caution or contributed to other packages within the organization.

I totally agree about orthogonality. Ideally this package could effectively be a MusicBase.jl package that other packages depend on for basic types representing notes etc.

Ideally this package could effectively be a MusicBase.jl package that other packages depend on for basic types representing notes etc.

In fact, in my own practice, trying to design universal symbolic musical structures would lead to enormous complexity.
The basic types in MusicTheory.jl should focus only on music theory calculations. In practice, to map the data in symbolic music files, different packages use different types to represent notes. For example, the Note in MIDI.jl is actually an abstraction of the Note On and Note Off events, while the Note in MusicXML.jl contains the necessary musical notation information.
Therefore, I personally think that the types in MusicTheory.jl should not exist as base types for other packages, but only provide basic data conversion compatible with other symbolic music types.
In short, focusing on the implementation of music theory and providing minimal support for other symbolic music will improve the cohesion of this package.
Thank you again for your work and for filling the gap in this organization. I just want to share some of my personal experience and reach some consensus before further development. I think this will be of some benefit to the subsequent development of this package.

OK thanks, that makes sense. I'm interested to see what you come up with.


Support custom ocamlfind predicates

If we have a library with such a META file, there is no way to trigger the thisone predicate using jbuilder:
archive(byte,-thisone) = "default.cma"
archive(byte,thisone) = "good.cma"

Could you add a way to support custom ocamlfind predicates ?

Supporting the full power of findlib predicates in jbuilder would be complicated. There is a discussion in #136 about supporting libraries with multiple implementations. I assume it would cover this case.

Supporting the full power of findlib predicates in jbuilder would be complicated.

Can you elaborate ? Is there a reason not to use the Fl_metascanner from findlib for instance ? I understand that using ocamlfind (the binary) can be rather slow but is it also the case with its library ?

The implementation is not the issue, jbuilder already has an implementation of a subset of findlib.
Jbuilder ensures that things work the same way whether the dependencies are installed or present in the workspace. This allows you to work on several related projects simultaneously and can cut down compilation times as well.
To keep this property and handle custom findlib predicates we'd need to teach jbuilder about these predicates, both when defining a library for which you'd write such a meta file if you were writing it by hand and at use sites. This seems complicated.
The idea in #136 or in the namespace proposal is to capture the most important use case of findlib predicates, which is to define several implementations for a given interface.

Full support for OCaml predicates was also ruled in the dev meeting at the ICFP. So the odds of this being implemented are microscopic, therefore I will close this.
However, @jpdeplaix please continue to bring up other use cases of predicates that jbuilder fails to meet.


3.3  Hardware/Software Mapping

OOSE: 7.4.1 Mapping Subsystems to Processors and Components.
"Describe how subsystems are assigned to hardware and off-the-shelf components. Also list and explain issues introduced by multiple nodes and software re-use."

This server needs to run 24/7 in order for the PlanningPoker system to be available to the users.
I would recommend removing "24/7"


Module has no object Tracer

Attempting to triage, I find that I get this error when I run Crash:
In [10]: crash = rex.Crash("./a.out",s.posix.dumps(0))
ROP: 100% ||||||||||||||||||||||||||||||||||||||||||| Time: 0:00:00 309.83  B/s
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-10-d5738d6de2e8> in <module>()
----> 1 crash = rex.Crash("./a.out",s.posix.dumps(0))

/home/user/.virtualenvs/angr/local/lib/python2.7/site-packages/rex/crash.pyc in __init__(self, binary, crash, pov_file, aslr, constrained_addrs, crash_state, prev_path, hooks, format_infos, rop_cache_tuple, use_rop, explore_steps, angrop_object)
    106                         raise NonCrashingInput
    107
--> 108             self._tracer = tracer.Tracer(binary, input=self.crash, pov_file=self.pov_file, resiliency=False,
    109                                          hooks=self.hooks, add_options=add_options, remove_options=remove_options)
    110             ChallRespInfo.prep_tracer(self._tracer, format_infos)

AttributeError: 'module' object has no attribute 'Tracer'

Checking out "tracer" in ipython, I cannot find a "Tracer" method either. The tracer being used appears to be:
~/.virtualenvs/angr/local/lib/python2.7/site-packages/tracer.py

This is an unfortunate naming collision that we'll resolve at some point (hopefully soon). Basically, there is a standard python package named "tracer", but that's not what we're referring to. We're referring to a component that assists with concolic execution in angr: https://github.com/angr/tracer.
If the problem persists after installing that, please reopen the issue!


ISPN-15109 Exclude byteman dependency from JGroups dependency

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

I am surprised that this is a compile time dep in JGroups.. I thought @belaban wanted zero deps.

@wburns - there is a suggestion to make this dependency optional, see https://github.com/belaban/JGroups/pull/733


Warn on second new Pretender

Not everyone is diligent about shutting down their Pretenders. This will prevent a second instance from starting up.

Coverage decreased (-23.3%) to 75.13% when pulling c6d088c366362a6a03629d57ecf57b3e3209e25c on warn-on-second-pretender into 1d451d849be2c06f78af4ca07c0d163dc81cb402 on master.

Coverage increased (+0.02%) to 98.446% when pulling 4c0e93aecea47b95395d3f4af8947c9be68626cc on warn-on-second-pretender into 1d451d849be2c06f78af4ca07c0d163dc81cb402 on master.

❤  LGTM!

I'm not 100% familiar with what happens today if you do this.  If things continue to work in this scenario we should change this to a warning (or bump majors).

@rwjblue If you start new instances while a previous one is running, all new xhr requests go to the most recently created instance, which leads to unexpected routing. If you lose track of the first one you started, you can never restore the native XMLHttpRequest object.
Happy to bump majors though to avoid breaking.

👍  to the major bump, makes sense.

Closing to do a small fixup.


Incorrect addition to phishing list

Please remove https://tickets.newfutures.network from phishing list.
The site was built by decentration, a W3F funded entity, trusted also by multiple blockchain communities.
Do you know what caused this going on the list? This would help me not make same mistake. Because talisman and metamask also have the same phishing flag.
I think it is because the domain does not have a home page, and is only subdomain.

Looking at the site itself, no idea why it was listed in https://github.com/polkadot-js/phishing/pull/2717 (it doesn't ask for a see, simple connect)


Allow self-signed certificates

@homeyjd thanks for sending this and submitting the Contribution Agreement. I'm curious, which version of PHP did you run into the issue with?

5.6.
Was working fine on 5.4. Recently updated to 5.6.15 and it broke.

We'd be open to an option of "allow_selfsigned" in the config hash passed to new Splunk_Service($conf).
As it stands it appears the only way to use the stream_context HTTP transport class AND allow self-signed certs is code change.
I saw CURLOPT_SSL_VERIFYPEER => false in Http::requestWithCurl(), but I can't trigger that functionality directly.  The only alternative was to re-implement the HTTP transport class, and that seemed silly considering the fix was so small.

Yep - it looks like the default changed in 5.6: http://php.net/manual/en/migration56.openssl.php
An option would be nice, but I think the change is OK as is, given that it was basically defaulted to false anyway. Let me know if you want to change this to add an option.

An option would be cool, but the quick fix works for us now.
fwiw, I saw you had pulled a PR for adding Composer integration.  Would love to get the autoloading pushed upstream.  You're instructions for contributing only allow submitting a PR against a single branch.  Can I add this commit to this PR?
https://github.com/dmvorg/splunk-sdk-php/commit/b893736f0882c96559ef3986e21cefe6e122093b
Composer uses master-branch for parsing the package name, so the integration won't be complete until merged to master.  But our fork is working well with Composer:
{
  "repositories": [
        { "type": "vcs", "url": "https://github.com/dmvorg/splunk-sdk-php" }
  ],
  "require": {
    "splunk/splunk-sdk-php": "dev-master"
  }
}

https://github.com/splunk/splunk-sdk-php/pull/40/commits

We've merged #41 instead, thanks everyone.


Write API documentation

In progress. I've decided to update the documentation as I build to make it less daunting. As I build each module/component, I should be documenting it.