CommClosedError: in : Stream is closed

I tried to create a minimal re-producible example for a different problem I encounter. While doing so, I was able to 're-produce' (it only happens sometimes) a different TCP-related problem.
Code:
import os
import numpy as np
from distributed import Client
from dask_jobqueue import SLURMCluster

def work(large_object):
    return large_object + 1

big_data = np.random.rand(10000, 1000)
graph = {str(i): (work, big_data) for i in range(20)}
targets = list(graph.keys())

workers = 15
kwargs = {'queue': 'cpu_low,cpu_high,gpu_low', 'resource_spec': '',
          'diagnostics_port': None,
          'cores': 8, 'memory': '15G',
          'walltime': '70:00:00', 'interface': 'em2'}

for i in range(10):
    print(i)
    with SLURMCluster(**kwargs) as cluster:
        cluster.scale(workers)
        with Client(cluster, local_directory=os.getcwd()) as client:
            big_datas = client.get(graph, targets)

Output:
0
/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/worker.py:820: UserWarning: Large object of size 80.00 MB detected in task graph:
  (array([[0.72155014, 0.38726907, 0.92209933, ...,  ... 0.9996717 ]]),)
Consider scattering large objects ahead of time
with client.scatter to reduce scheduler burden and
keep data on workers

    future = client.submit(func, big_data)    # bad

    big_future = client.scatter(big_data)     # good
    future = client.submit(func, big_future)  # good
  % (format_bytes(len(b)), s))
1
2
Future exception was never retrieved
future: <Future finished exception=CommClosedError('in <closed TCP>: Stream is closed',)>
Traceback (most recent call last):
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 177, in read
    n_frames = yield stream.read_bytes(8)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run
    value = future.result()
tornado.iostream.StreamClosedError: Stream is closed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1107, in run
    yielded = self.gen.throw(*exc_info)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 198, in read
    convert_stream_closed_error(self, e)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 126, in convert_stream_closed_error
    raise CommClosedError("in %s: %s" % (obj, exc))
distributed.comm.core.CommClosedError: in <closed TCP>: Stream is closed
3
4
5
6
7
8
9
Future exception was never retrieved
future: <Future finished exception=CommClosedError('in <closed TCP>: Stream is closed',)>
Traceback (most recent call last):
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 177, in read
    n_frames = yield stream.read_bytes(8)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run
    value = future.result()
tornado.iostream.StreamClosedError: Stream is closed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1107, in run
    yielded = self.gen.throw(*exc_info)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 198, in read
    convert_stream_closed_error(self, e)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 126, in convert_stream_closed_error
    raise CommClosedError("in %s: %s" % (obj, exc))
distributed.comm.core.CommClosedError: in <closed TCP>: Stream is closed

dask-worker.err
Traceback (most recent call last):
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/cli/dask_worker.py", line 259, in <module>
    go()
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/cli/dask_worker.py", line 255, in go
    main()
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/cli/dask_worker.py", line 206, in main
    host = get_ip_interface(interface)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/utils.py", line 160, in get_ip_interface
    for info in psutil.net_if_addrs()[ifname]:
KeyError: 'em2'
distributed.worker - INFO -       Start worker at:   tcp:distributed.worker - INFO -         Registered to:     tcp://<IP_ADDRESS>:37110
distributed.worker - INFO - -------------------------------------------------
distributed.core - INFO - Starting established connection
Traceback (most recent call last):
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/cli/dask_worker.py", line 259, in <module>
    go()
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/cli/dask_worker.py", line 255, in go
    main()
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/cli/dask_worker.py", line 206, in main
    host = get_ip_interface(interface)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/utils.py", line 160, in get_ip_interface
    for info in psutil.net_if_addrs()[ifname]:
KeyError: 'em2'
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:37966
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:35165
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:33751
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:43891
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO - -------------------------------------------------
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:40034'
slurmstepd: error: *** JOB 5561 ON compute-0-18 CANCELLED AT 2018-07-25T20:29:19 ***
slurmstepd: error: *** JOB 5559 ON compute-0-18 CANCELLED AT 2018-07-25T20:29:19 ***
slurmstepd: error: *** JOB 5560 ON compute-0-18 CANCELLED AT 2018-07-25T20:29:19 ***
slurmstepd: error: *** JOB 5558 ON compute-0-18 CANCELLED AT 2018-07-25T20:29:19 ***
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:44738'
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:46345'
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:33371'
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - End worker
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - End worker
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - End worker
distributed.dask_worker - INFO - End worker

Versions:
ipython: 6.4.0
dask: 0.18.2
dask_jobqueue: 0.3.0

My guess is that the interface you're using, em2, is not avaiable on some
of your workers
On Wed, Jul 25, 2018 at 5:44 PM, Torsten Wörtwein<EMAIL_ADDRESS>wrote:

I tried to create a minimal re-producible example for a different problem
I encounter. While doing so, I was able to 're-produce' (it only happens
sometimes) a different TCP-related problem.
Code:
import osimport numpy as npfrom distributed import Clientfrom dask_jobqueue import SLURMCluster
def work(large_object):
return large_object + 1
big_data = np.random.rand(10000, 1000)
graph = {str(i): (work, big_data) for i in range(20)}
targets = list(graph.keys())
workers = 15
kwargs = {'queue': 'cpu_low,cpu_high,gpu_low', 'resource_spec': '',
'diagnostics_port': None,
'cores': 8, 'memory': '15G',
'walltime': '70:00:00', 'interface': 'em2'}
for i in range(10):
print(i)
with SLURMCluster(**kwargs) as cluster:
cluster.scale(workers)
with Client(cluster, local_directory=os.getcwd()) as client:
big_datas = client.get(graph, targets)
Output:
0
/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/worker.py:820: UserWarning: Large object of size 80.00 MB detected in task graph:
(array([[0.72155014, 0.38726907, 0.92209933, ...,  ... 0.9996717 ]]),)
Consider scattering large objects ahead of time
with client.scatter to reduce scheduler burden and
keep data on workers
future = client.submit(func, big_data)    # bad

big_future = client.scatter(big_data)     # good
future = client.submit(func, big_future)  # good

% (format_bytes(len(b)), s))
1
2
Future exception was never retrieved
future: <Future finished exception=CommClosedError('in : Stream is closed',)>
Traceback (most recent call last):
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 177, in read
n_frames = yield stream.read_bytes(8)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run
value = future.result()
tornado.iostream.StreamClosedError: Stream is closed
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1107, in run
yielded = self.gen.throw(*exc_info)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 198, in read
convert_stream_closed_error(self, e)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 126, in convert_stream_closed_error
raise CommClosedError("in %s: %s" % (obj, exc))
distributed.comm.core.CommClosedError: in : Stream is closed
3
4
5
6
7
8
9
Future exception was never retrieved
future: <Future finished exception=CommClosedError('in : Stream is closed',)>
Traceback (most recent call last):
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 177, in read
n_frames = yield stream.read_bytes(8)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run
value = future.result()
tornado.iostream.StreamClosedError: Stream is closed
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1107, in run
yielded = self.gen.throw(*exc_info)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 198, in read
convert_stream_closed_error(self, e)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 126, in convert_stream_closed_error
raise CommClosedError("in %s: %s" % (obj, exc))
distributed.comm.core.CommClosedError: in : Stream is closed
dask-worker.err
Traceback (most recent call last):
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/cli/dask_worker.py", line 259, in
go()
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/cli/dask_worker.py", line 255, in go
main()
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 722, in call
return self.main(*args, **kwargs)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/cli/dask_worker.py", line 206, in main
host = get_ip_interface(interface)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/utils.py", line 160, in get_ip_interface
for info in psutil.net_if_addrs()[ifname]:
KeyError: 'em2'
distributed.worker - INFO -       Start worker at:   tcp:distributed.worker - INFO -         Registered to:     tcp://<IP_ADDRESS>:37110
distributed.worker - INFO - -------------------------------------------------
distributed.core - INFO - Starting established connection
Traceback (most recent call last):
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/cli/dask_worker.py", line 259, in
go()
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/cli/dask_worker.py", line 255, in go
main()
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 722, in call
return self.main(*args, **kwargs)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/cli/dask_worker.py", line 206, in main
host = get_ip_interface(interface)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/utils.py", line 160, in get_ip_interface
for info in psutil.net_if_addrs()[ifname]:
KeyError: 'em2'
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:37966
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:35165
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:33751
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:43891
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO - -------------------------------------------------
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:40034'
slurmstepd: error: *** JOB 5561 ON compute-0-18 CANCELLED AT 2018-07-25T20:29:19 ***
slurmstepd: error: *** JOB 5559 ON compute-0-18 CANCELLED AT 2018-07-25T20:29:19 ***
slurmstepd: error: *** JOB 5560 ON compute-0-18 CANCELLED AT 2018-07-25T20:29:19 ***
slurmstepd: error: *** JOB 5558 ON compute-0-18 CANCELLED AT 2018-07-25T20:29:19 ***
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:44738'
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:46345'
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:33371'
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - End worker
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - End worker
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - End worker
distributed.dask_worker - INFO - End worker
Versions:
ipython: 6.4.0
dask: 0.18.2
dask_jobqueue: 0.3.0
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-jobqueue/issues/105, or mute the thread
https://github.com/notifications/unsubscribe-auth/AASszJq8dToS5b_jGBE74HRns_idQijzks5uKREGgaJpZM4VhAUV
.

oh thanks, that might be the case. I thought 'interface' would only specify which interface to use on the cluster head (not on the workers). Is that incorrect?

I removed the 'interface' argument, the error still occurs:
Output:
0
/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/worker.py:820: UserWarning: Large object of size 80.00 MB detected in task graph:
  (array([[0.4442631 , 0.62320326, 0.05311121, ...,  ... 0.19558944]]),)
Consider scattering large objects ahead of time
with client.scatter to reduce scheduler burden and
keep data on workers

    future = client.submit(func, big_data)    # bad

    big_future = client.scatter(big_data)     # good
    future = client.submit(func, big_future)  # good
  % (format_bytes(len(b)), s))
1
2
Future exception was never retrieved
future: <Future finished exception=CommClosedError('in <closed TCP>: Stream is closed',)>
Traceback (most recent call last):
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 177, in read
    n_frames = yield stream.read_bytes(8)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run
    value = future.result()
tornado.iostream.StreamClosedError: Stream is closed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1107, in run
    yielded = self.gen.throw(*exc_info)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 198, in read
    convert_stream_closed_error(self, e)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 126, in convert_stream_closed_error
    raise CommClosedError("in %s: %s" % (obj, exc))
distributed.comm.core.CommClosedError: in <closed TCP>: Stream is closed
3
4
Future exception was never retrieved
future: <Future finished exception=CommClosedError('in <closed TCP>: Stream is closed',)>
Traceback (most recent call last):
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 177, in read
    n_frames = yield stream.read_bytes(8)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run
    value = future.result()
tornado.iostream.StreamClosedError: Stream is closed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1107, in run
    yielded = self.gen.throw(*exc_info)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/core.py", line 432, in send_recv
    response = yield comm.read(deserializers=deserializers)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run
    value = future.result()
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1107, in run
    yielded = self.gen.throw(*exc_info)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 198, in read
    convert_stream_closed_error(self, e)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 126, in convert_stream_closed_error
    raise CommClosedError("in %s: %s" % (obj, exc))
distributed.comm.core.CommClosedError: in <closed TCP>: Stream is closed
5
6
Future exception was never retrieved
future: <Future finished exception=CommClosedError('in <closed TCP>: Stream is closed',)>
Traceback (most recent call last):
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 177, in read
    n_frames = yield stream.read_bytes(8)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run
    value = future.result()
tornado.iostream.StreamClosedError: Stream is closed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1107, in run
    yielded = self.gen.throw(*exc_info)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 198, in read
    convert_stream_closed_error(self, e)
  File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 126, in convert_stream_closed_error
    raise CommClosedError("in %s: %s" % (obj, exc))
distributed.comm.core.CommClosedError: in <closed TCP>: Stream is closed
7
8
9

dask-worker.err
distributed.nanny - INFO -         Start Nanny at: 'tcp://<IP_ADDRESS>:36131'
distributed.nanny - INFO -         Start Nanny at: 'tcp://<IP_ADDRESS>:37310'
distributed.nanny - INFO -         Start Nanny at: 'tcp://<IP_ADDRESS>:44237'
distributed.nanny - INFO -         Start Nanny at: 'tcp://<IP_ADDRESS>:42312'
distributed.worker - INFO -       Start worker at:   tcp://<IP_ADDRESS>:34583
distributed.worker - INFO -          Listening to:   tcp://<IP_ADDRESS>:34583
distributed.worker - INFO -              nanny at:         <IP_ADDRESS>:43423
distributed.worker - INFO -              bokeh at:          <IP_ADDRESS>:8789
distributed.worker - INFO - Waiting to connect to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -               Threads:                          8
distributed.worker - INFO -                Memory:                   15.00 GB
distributed.worker - INFO -       Local Directory: /home/twoertwe/git/python_tools/dask-worker-space/worker-kk025weh
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -         Registered to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.core - INFO - Starting established connection
 <IP_ADDRESS>:42312
distributed.worker - INFO -              bokeh at:         <IP_ADDRESS>:39719
distributed.worker - INFO - Waiting to connect to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -               Threads:                          8
distributed.worker - INFO -                Memory:                   15.00 GB
distributed.worker - INFO -       Local Directory: /home/twoertwe/git/python_tools/dask-worker-space/worker-th30p0im
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -       Start worker at:   tcp://<IP_ADDRESS>:35669
distributed.worker - INFO -          Listening to:   tcp://<IP_ADDRESS>:35669
distributed.worker - INFO -              nanny at:         <IP_ADDRESS>:37310
distributed.worker - INFO -              bokeh at:         <IP_ADDRESS>:37778
distributed.worker - INFO - Waiting to connect to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -               Threads:                          8
distributed.worker - INFO -                Memory:                   15.00 GB
distributed.worker - INFO -       Local Directory: /home/twoertwe/git/python_tools/dask-worker-space/worker-7w8_unta
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -       Start worker at:   tcp://<IP_ADDRESS>:46509
distributed.worker - INFO -          Listening to:   tcp://<IP_ADDRESS>:46509
distributed.worker - INFO -              nanny at:         <IP_ADDRESS>:44237
distributed.worker - INFO -              bokeh at:         <IP_ADDRESS>:40377
distributed.worker - INFO - Waiting to connect to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -               Threads:                          8
distributed.worker - INFO -                Memory:                   15.00 GB
distributed.worker - INFO -       Local Directory: /home/twoertwe/git/python_tools/dask-worker-space/worker-ubzhiom0
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -         Registered to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.core - INFO - Starting established connection
distributed.worker - INFO -         Registered to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.core - INFO - Starting established connection
distributed.worker - INFO -         Registered to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.core - INFO - Starting established connection
distributed.worker - INFO -         Registered to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.core - INFO - Starting established connection
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:36404
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:43098
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:35669
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:46509
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - -------------------------------------------------
slurmstepd: error: *** JOB 5711 ON compute-0-18 CANCELLED AT 2018-07-25T21:03:27 ***
distributed.worker - INFO - -------------------------------------------------
slurmstepd: error: *** JOB 5710 ON compute-0-18 CANCELLED AT 2018-07-25T21:03:27 ***
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO - -------------------------------------------------
slurmstepd: error: *** JOB 5709 ON compute-0-18 CANCELLED AT 2018-07-25T21:03:27 ***
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:42312'
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:36131'
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:37310'
slurmstepd: error: *** JOB 5708 ON compute-0-18 CANCELLED AT 2018-07-25T21:03:27 ***
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:44237'
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - End worker
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - End worker
distributed.dask_worker - INFO - End worker
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - End worker

It looks like your workers can't talk to each other or to the scheduler.
My guess is that they're listening different networks.  Unfortunately I'm
not able to help out on this much.  I recommend asking someone familiar
with your network to help.
On Wed, Jul 25, 2018 at 6:08 PM, Torsten Wörtwein<EMAIL_ADDRESS>wrote:

I removed the 'interface' argument, the error still occurs:
Output:
0
/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/worker.py:820: UserWarning: Large object of size 80.00 MB detected in task graph:
(array([[0.4442631 , 0.62320326, 0.05311121, ...,  ... 0.19558944]]),)
Consider scattering large objects ahead of time
with client.scatter to reduce scheduler burden and
keep data on workers
future = client.submit(func, big_data)    # bad

big_future = client.scatter(big_data)     # good
future = client.submit(func, big_future)  # good

% (format_bytes(len(b)), s))
1
2
Future exception was never retrieved
future: <Future finished exception=CommClosedError('in : Stream is closed',)>
Traceback (most recent call last):
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 177, in read
n_frames = yield stream.read_bytes(8)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run
value = future.result()
tornado.iostream.StreamClosedError: Stream is closed
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1107, in run
yielded = self.gen.throw(*exc_info)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 198, in read
convert_stream_closed_error(self, e)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 126, in convert_stream_closed_error
raise CommClosedError("in %s: %s" % (obj, exc))
distributed.comm.core.CommClosedError: in : Stream is closed
3
4
Future exception was never retrieved
future: <Future finished exception=CommClosedError('in : Stream is closed',)>
Traceback (most recent call last):
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 177, in read
n_frames = yield stream.read_bytes(8)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run
value = future.result()
tornado.iostream.StreamClosedError: Stream is closed
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1107, in run
yielded = self.gen.throw(*exc_info)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/core.py", line 432, in send_recv
response = yield comm.read(deserializers=deserializers)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run
value = future.result()
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1107, in run
yielded = self.gen.throw(*exc_info)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 198, in read
convert_stream_closed_error(self, e)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 126, in convert_stream_closed_error
raise CommClosedError("in %s: %s" % (obj, exc))
distributed.comm.core.CommClosedError: in : Stream is closed
5
6
Future exception was never retrieved
future: <Future finished exception=CommClosedError('in : Stream is closed',)>
Traceback (most recent call last):
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 177, in read
n_frames = yield stream.read_bytes(8)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1099, in run
value = future.result()
tornado.iostream.StreamClosedError: Stream is closed
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/tornado/gen.py", line 1107, in run
yielded = self.gen.throw(*exc_info)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 198, in read
convert_stream_closed_error(self, e)
File "/home/twoertwe/miniconda3/envs/panama/lib/python3.6/site-packages/distributed/comm/tcp.py", line 126, in convert_stream_closed_error
raise CommClosedError("in %s: %s" % (obj, exc))
distributed.comm.core.CommClosedError: in : Stream is closed
7
8
9
dask-worker.err
distributed.nanny - INFO -         Start Nanny at: 'tcp://<IP_ADDRESS>:36131'
distributed.nanny - INFO -         Start Nanny at: 'tcp://<IP_ADDRESS>:37310'
distributed.nanny - INFO -         Start Nanny at: 'tcp://<IP_ADDRESS>:44237'
distributed.nanny - INFO -         Start Nanny at: 'tcp://<IP_ADDRESS>:42312'
distributed.worker - INFO -       Start worker at:   tcp://<IP_ADDRESS>:34583
distributed.worker - INFO -          Listening to:   tcp://<IP_ADDRESS>:34583
distributed.worker - INFO -              nanny at:         <IP_ADDRESS>:43423
distributed.worker - INFO -              bokeh at:          <IP_ADDRESS>:8789
distributed.worker - INFO - Waiting to connect to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -               Threads:                          8
distributed.worker - INFO -                Memory:                   15.00 GB
distributed.worker - INFO -       Local Directory: /home/twoertwe/git/python_tools/dask-worker-space/worker-kk025weh
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -         Registered to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.core - INFO - Starting established connection
<IP_ADDRESS>:42312
distributed.worker - INFO -              bokeh at:         <IP_ADDRESS>:39719
distributed.worker - INFO - Waiting to connect to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -               Threads:                          8
distributed.worker - INFO -                Memory:                   15.00 GB
distributed.worker - INFO -       Local Directory: /home/twoertwe/git/python_tools/dask-worker-space/worker-th30p0im
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -       Start worker at:   tcp://<IP_ADDRESS>:35669
distributed.worker - INFO -          Listening to:   tcp://<IP_ADDRESS>:35669
distributed.worker - INFO -              nanny at:         <IP_ADDRESS>:37310
distributed.worker - INFO -              bokeh at:         <IP_ADDRESS>:37778
distributed.worker - INFO - Waiting to connect to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -               Threads:                          8
distributed.worker - INFO -                Memory:                   15.00 GB
distributed.worker - INFO -       Local Directory: /home/twoertwe/git/python_tools/dask-worker-space/worker-7w8_unta
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -       Start worker at:   tcp://<IP_ADDRESS>:46509
distributed.worker - INFO -          Listening to:   tcp://<IP_ADDRESS>:46509
distributed.worker - INFO -              nanny at:         <IP_ADDRESS>:44237
distributed.worker - INFO -              bokeh at:         <IP_ADDRESS>:40377
distributed.worker - INFO - Waiting to connect to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -               Threads:                          8
distributed.worker - INFO -                Memory:                   15.00 GB
distributed.worker - INFO -       Local Directory: /home/twoertwe/git/python_tools/dask-worker-space/worker-ubzhiom0
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO -         Registered to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.core - INFO - Starting established connection
distributed.worker - INFO -         Registered to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.core - INFO - Starting established connection
distributed.worker - INFO -         Registered to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.core - INFO - Starting established connection
distributed.worker - INFO -         Registered to:  tcp://<IP_ADDRESS>:39860
distributed.worker - INFO - -------------------------------------------------
distributed.core - INFO - Starting established connection
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:36404
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:43098
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:35669
distributed.worker - INFO - Stopping worker at tcp://<IP_ADDRESS>:46509
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - -------------------------------------------------
slurmstepd: error: *** JOB 5711 ON compute-0-18 CANCELLED AT 2018-07-25T21:03:27 ***
distributed.worker - INFO - -------------------------------------------------
slurmstepd: error: *** JOB 5710 ON compute-0-18 CANCELLED AT 2018-07-25T21:03:27 ***
distributed.worker - INFO - Connection to scheduler broken.  Reconnecting...
distributed.worker - INFO - -------------------------------------------------
distributed.worker - INFO - -------------------------------------------------
slurmstepd: error: *** JOB 5709 ON compute-0-18 CANCELLED AT 2018-07-25T21:03:27 ***
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:42312'
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:36131'
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:37310'
slurmstepd: error: *** JOB 5708 ON compute-0-18 CANCELLED AT 2018-07-25T21:03:27 ***
distributed.nanny - INFO - Closing Nanny at 'tcp://<IP_ADDRESS>:44237'
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - End worker
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - End worker
distributed.dask_worker - INFO - End worker
distributed.dask_worker - INFO - Exiting on signal 15
distributed.dask_worker - INFO - End worker
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-jobqueue/issues/105#issuecomment-407943857,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASszI1co-7Gy5upANBFcAUKTien_0zNks5uKRaCgaJpZM4VhAUV
.

If that is the case, shouldn't it always fail? I'm quite sure they are able to talk to each other - they are all in the same subnet (the cluster head has a second interface, which is why I originally specified 'em2' for it).

ok, thanks. I hope I find what is going wrong

Good luck!
On Thu, Jul 26, 2018 at 8:37 AM, Torsten Wörtwein<EMAIL_ADDRESS>wrote:

Closed #105 https://github.com/dask/dask-jobqueue/issues/105.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-jobqueue/issues/105#event-1755354842, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AASszKmTemjh2jrCXbX7vF_a4bOflocMks5uKeJNgaJpZM4VhAUV
.


Fix markdown linking to ssl.md

It was discovered in slack by community member trying to locate cql ssl settings:
http://docs.nosqlbench.io/#/docs/drivers/cql.md
404: http://docs.nosqlbench.io/services/docs/drivers/ssl.mdundefined
I dug into code and verify that ssl.md is correctly located in driver-cql-shaded/src/main/resources but the path is not complete:
[Additional parameters may need to be provided](ssl.md).
In other places, for example tcpclient, the link is:
[Additional parameters may need to be provided](../../../../driver-cql/src/main/resources/ssl.md).
There are 6 other instances.

Ran into this again today.... i think the current link is:
https://docs.nosqlbench.io/docs/drivers/ssl/
404'ing old doc pages, no bueno...

The docs structure is changed.


Concurrent access fails.

I am using Xlsxir from a phoenix application which means there will be the potential for multiple users to try and process their spreadsheets simultaneously.
But due to the global unzip dir (I think) and ets tables, concurrent access fails. This is evident when I run my tests. If they run async, I get failures. If I serialise them - they all pass.
The solution I came up with was to put a GenServer facade in front of Xlsxir. Calls to the facade are serialised via the GenServer's mailbox so xlsx processing only happens on one file at a time.
This is not ideal but it solves the initial problem. It may lead to a performance bottleneck in the (for me, far) future.
I was wondering whether it would be useful for this technique to be added to the documentation?
Here's an example of the GenServer:
defmodule Excel do
  use GenServer

  def start_link do
    GenServer.start_link(__MODULE__, :ok, name: :excel)
  end

  ## Public interface

  def from_xlsx(path) do
    GenServer.call(:excel, {:from_xlsx, path})
  end

  ## Server callbacks
  def handle_call({:from_xlsx, path}, _from, state) do
    {:reply, do_work(Xlsxir.multi_extract(path)), state}
  end

  defp do_work({:error, _} = err), do: err
  defp do_work(tables) do
    res = process_tables(tables)
    tables |> Enum.each(fn {:ok, id} -> Xlsxir.close(id) end)

    res
  end

  ...

# Usage:
  # start the GenServer
  Excel.start_link

  # and in your app, use it:
  res = Excel.from_xlsx("path/to/file.xlsx")

That's my first GenServer - and I know it's a little odd because it doesn't actually care about state at all. I'm more than happy to hear feedback on whether the above is useful, not, or whether it is a "start" for something that may be useful.
Note: with the change to use the above pattern, my tests run successfully when running async.

I see that PR #52 may address these issues in a much better way. If that PR gets merged then I expect the above is of little use going forward.

Hey @brushbox, we are working to get #52 merged. If you can, please test it out once we do to verify it solves your problem. Thanks for detailing out the issues you're having.

#52 was merged, so please give it a shot to see if it fixes your issue. Closing for now, please re-open if you continue to have issues.

Thanks, Jason. Sorry for taking so long to reply…been crazy busy.
I think everything is working well with the changes … I do have a new bug that I’ve found.
I’m working to isolate it and will raise a PR when I’ve got a fix in place … but I haven’t had a lot of time for this lately, unfortunately.

On 17 Jun 2017, at 1:55 pm, Jason Kennell<EMAIL_ADDRESS>wrote:
Closed #58 https://github.com/jsonkennell/xlsxir/issues/58.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/jsonkennell/xlsxir/issues/58#event-1127750407, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAxfivMi_G4Sh5O-PCtRXbsNgK-Jj27ks5sE04ygaJpZM4N2Dml.


[feature] Add MIP arguments to render target getters

Describe the solution you'd like
Add a mip argument (defaulting to 0) to GetWidth etc to save the user having to compute the value themselves

Added in 25b037f132a2be3af5e30991c0ca2e35baae0d00


Compilation error with nightly

My code was building last week, but after an update of the nightly compiler, I started getting these messages (one instance shown):
$ cargo +nightly build

(...)

   Compiling futures-util-preview v0.3.0-alpha.5
error[E0658]: `crate` visibility modifier is experimental (see issue #45388)
 --> /home/pedro/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-preview-0.3.0-alpha.5/src/future/chain.rs:7:1
  |
7 | crate enum Chain<Fut1, Fut2, Data> {
  | ^^^^^
  |
  = help: add #![feature(crate_visibility_modifier)] to the crate attributes to enable

My Cargo.toml:
[dependencies]
(...)
futures-preview = "0.3.0-alpha.5"
(...)

My specs:
$ rustup show
Default host: x86_64-unknown-linux-gnu

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)

active toolchain
----------------

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.30.0-nightly (2d4e34ca8 2018-09-09)

Fixed by #1254.


Add support for TASKCORE_DB_PATH env var

https://github.com/tarikguney/taskcore/projects/1#card-42528199

Looks good! Thanks.


How does this work?

bump, Mustache language occupies 69.9% of the repo and 100% of headache now occupies me.


key influencers visualizations

very useful

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 4200dd45-15ab-ee4a-9818-10cc81475f64
Version Independent ID: 0b96ac28-e2a2-41c9-eff0-efd864fc0529
Content: Key influencers visualizations tutorial - Power BI
Content Source: powerbi-docs/visuals/power-bi-visualization-influencers.md
Service: powerbi
Sub-service: powerbi-ai
GitHub Login: @aphilip94
Microsoft Alias: anphil

Thanks for your comment, @Gaibusha. This issue has been assigned to the doc author for review.

Thanks you @Gaibusha!


List ASR rules

Hi,
It would interesting if PrivescCheck was able to detect whether ASR is configured or not, and if there is a misconfiguration among the ASR rules (cf. win10-asr-get.ps1).
Below an example of the script's output:

Good idea! Thanks for the suggestion.

Added with commit f106e7b


1 Pity Navia

The website shows me as having obtained Navia at 1 pity when that clearly isn’t the case.
(I mentioned this on the Discord, but thought this would be the better place to put it long-term.)

Moved this to backend

Thanks maalni
On Mon, Jun 3, 2024, 16:16 maalni @.***> wrote:

Moved this to backend
—
Reply to this email directly, view it on GitHub
https://github.com/dval-in/dvalin-backend/issues/109#issuecomment-2144697046,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVGOQTDMNF3SBWVBNQCQAZTZFQX6PAVCNFSM6AAAAABIWCZPXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBUGY4TOMBUGY
.
You are receiving this because you commented.Message ID:
@.***>

This issue should be already resolved for new data. Older data needs to be migrated manually. Will leave this open until older data was migrated.
@maalni So has it been migrated?  Navia still displays as 1 pity for me.

This issue should be already resolved for new data. Older data needs to be migrated manually. Will leave this open until older data was migrated.
@maalni So has it been migrated?  Navia still displays as 1 pity for me.

a new version will come, currently in testing. Importing from paimon should resolve the issue.
if u can't/ dont want to import, we'll do it manually for u


Output the zone object-graph as a zone string

The TODO contains this entry.
Does anyone have thoughts on what it'd take to do this? I've not really put any energy into it yet, but just wanted to check if anyone had thoughts/notes?

Don't think anyone has had a think about this, and there's been no update for ~2 years, so I'm going to close the issue.


Deployment Loop and "workaround".

I received this error before the recent mod to use yt-dlp as well as after.  Previously you could make the error go away by pointing the app to a new directory where no music was present.   In this case the only thing in lidarr's wanted list is Kelly Clarkson's Breakway album and although a "Breakaway (2018) folder exists lyd creates a "Breakaway" folder so not sure why it's occuring.
The workaround is to point lyd to a subdir of the music folder then import those tracks.
2023-05-10 14:46:17.400667+00:00Starting Lidarr Youtube Downloader
2023-05-10 14:46:17.500630+00:00Album: 1/1   Track: 1/19
2023-05-10 14:46:17.500695+00:00================================================================================
2023-05-10 14:46:17.500703+00:002023-05-10T14:46:17.500703917Z
2023-05-10 14:46:17.500708+00:00Path           : /mnt/tank/shared/media/music/Kelly Clarkson
2023-05-10 14:46:17.500722+00:00Artist         : Kelly Clarkson
2023-05-10 14:46:17.500727+00:00Album          : Breakaway
2023-05-10 14:46:17.500731+00:00Track          : Breakaway
2023-05-10 14:46:17.500736+00:00Genre          : Alternative Rock
2023-05-10 14:46:17.500740+00:00Date           : 2004
2023-05-10 14:46:17.500748+00:00CD Count       : 1
2023-05-10 14:46:17.500753+00:00CD No          : 1
2023-05-10 14:46:17.500757+00:00Track No       : 1/15
2023-05-10 14:46:17.500761+00:002023-05-10T14:46:17.500761919Z
2023-05-10 14:46:17.511525+00:00Traceback (most recent call last):
2023-05-10 14:46:17.511561+00:002023-05-10T14:46:17.511561964Z
2023-05-10 14:46:17.511578+00:00File "/lyd.py", line 605, in
2023-05-10 14:46:17.511585+00:00app()
2023-05-10 14:46:17.511589+00:002023-05-10T14:46:17.511589954Z
2023-05-10 14:46:17.511594+00:00File "/lyd.py", line 601, in run
2023-05-10 14:46:17.511598+00:00iterate_missing(artist, iterative)
2023-05-10 14:46:17.511607+00:002023-05-10T14:46:17.511607973Z
2023-05-10 14:46:17.511612+00:00File "/lyd.py", line 572, in iterate_missing
2023-05-10 14:46:17.511617+00:00iterate_records(json["records"], totalRecords, record_counter, artist_filter)
2023-05-10 14:46:17.511622+00:002023-05-10T14:46:17.511622688Z
2023-05-10 14:46:17.511627+00:00File "/lyd.py", line 526, in iterate_records
2023-05-10 14:46:17.511635+00:00iterate_tracks(
2023-05-10 14:46:17.511640+00:002023-05-10T14:46:17.511640188Z
2023-05-10 14:46:17.511644+00:00File "/lyd.py", line 498, in iterate_tracks
2023-05-10 14:46:17.511648+00:00get_song(
2023-05-10 14:46:17.511653+00:002023-05-10T14:46:17.511653099Z
2023-05-10 14:46:17.511657+00:00File "/lyd.py", line 371, in get_song
2023-05-10 14:46:17.511664+00:00update_lidarr_db(artistName, albumName, title, trackNumber, year)
2023-05-10 14:46:17.511669+00:002023-05-10T14:46:17.511669592Z
2023-05-10 14:46:17.511674+00:00File "/lyd.py", line 293, in update_lidarr_db
2023-05-10 14:46:17.511678+00:00album_id = get_lidarr_album_id(cur, albumName, year)
2023-05-10 14:46:17.511686+00:002023-05-10T14:46:17.511686155Z
2023-05-10 14:46:17.511690+00:00File "/lyd.py", line 236, in get_lidarr_album_id
2023-05-10 14:46:17.511694+00:00cur.execute(
2023-05-10 14:46:17.511699+00:002023-05-10T14:46:17.511699545Z
2023-05-10 14:46:17.511703+00:00sqlite3.OperationalError: no such table: Albums
2023-05-10 14:46:17.511708+00:002023-05-10T14:46:17.511708083Z

Workaround is NOT working this time..even when pointed to empty subdir after creating the Kelly Clarkson folder and Breakaway  folder it gives same error.

2023-05-10 15:08:54.798791+00:00Starting Lidarr Youtube Downloader
2023-05-10 15:08:54.925174+00:00Album: 1/1   Track: 1/19
2023-05-10 15:08:54.925201+00:00================================================================================
2023-05-10 15:08:54.925208+00:002023-05-10T15:08:54.925208408Z
2023-05-10 15:08:54.925213+00:00Path           : /mnt/tank/shared/media/music/Kelly Clarkson
2023-05-10 15:08:54.925226+00:00Artist         : Kelly Clarkson
2023-05-10 15:08:54.925231+00:00Album          : Breakaway
2023-05-10 15:08:54.925237+00:00Track          : Breakaway
2023-05-10 15:08:54.925246+00:00Genre          : Alternative Rock
2023-05-10 15:08:54.925252+00:00Date           : 2004
2023-05-10 15:08:54.925260+00:00CD Count       : 1
2023-05-10 15:08:54.925265+00:00CD No          : 1
2023-05-10 15:08:54.925270+00:00Track No       : 1/15
2023-05-10 15:08:54.925274+00:002023-05-10T15:08:54.925274786Z
2023-05-10 15:08:55.960312+00:00Youtube search
2023-05-10 15:08:55.960391+00:00========================================
2023-05-10 15:08:55.960431+00:002023-05-10T15:08:55.960431833Z
2023-05-10 15:08:55.960447+00:00Best title: Kelly Clarkson - Breakaway (VIDEO)
2023-05-10 15:08:55.960460+00:00Best match: 0.8666666666666667
2023-05-10 15:08:55.960474+00:002023-05-10T15:08:55.960474090Z
2023-05-10 15:08:55.960487+00:00Selected https://www.youtube.com/watch?v=c-3vPxKdj6o
2023-05-10 15:08:55.960511+00:002023-05-10T15:08:55.960511155Z
2023-05-10 15:08:55.960532+00:00Youtube-dl
2023-05-10 15:08:55.960546+00:00========================================
2023-05-10 15:08:55.960561+00:002023-05-10T15:08:55.960561120Z
2023-05-10 15:08:55.960574+00:00youtube-dl
2023-05-10 15:08:55.960611+00:00--no-progress
2023-05-10 15:08:55.960624+00:00-x
2023-05-10 15:08:55.960637+00:00--audio-format mp3 "https://www.youtube.com/watch?v=c-3vPxKdj6o"
2023-05-10 15:08:55.960685+00:00-o
2023-05-10 15:08:55.960693+00:00"/music/Kelly Clarkson/Breakaway/Kelly Clarkson - Breakaway - Breakaway.mp3"
2023-05-10 15:08:55.960703+00:002023-05-10T15:08:55.960703997Z
2023-05-10 15:09:02.794978+00:002023-05-10T15:09:02.794978746Z
2023-05-10 15:09:02.795028+00:00Downloaded successfully
2023-05-10 15:09:02.795042+00:002023-05-10T15:09:02.795042079Z
2023-05-10 15:09:02.795050+00:00[youtube] Extracting URL: https://www.youtube.com/watch?v=c-3vPxKdj6o
2023-05-10 15:09:02.795074+00:00[youtube] c-3vPxKdj6o: Downloading webpage
2023-05-10 15:09:02.795093+00:00[youtube] c-3vPxKdj6o: Downloading android player API JSON
2023-05-10 15:09:02.795102+00:00[info] c-3vPxKdj6o: Downloading 1 format(s): 251
2023-05-10 15:09:02.795109+00:00[dashsegments] Total fragments: 1
2023-05-10 15:09:02.795123+00:00[download] Destination: /music/Kelly Clarkson/Breakaway/Kelly Clarkson - Breakaway - Breakaway.webm
2023-05-10 15:09:02.795130+00:00[download] Download completed
2023-05-10 15:09:02.795137+00:00[ExtractAudio] Destination: /music/Kelly Clarkson/Breakaway/Kelly Clarkson - Breakaway - Breakaway.mp3
2023-05-10 15:09:02.795144+00:00Deleting original file /music/Kelly Clarkson/Breakaway/Kelly Clarkson - Breakaway - Breakaway.webm (pass -k to keep)
2023-05-10 15:09:02.795156+00:002023-05-10T15:09:02.795156719Z
2023-05-10 15:09:02.808708+00:00Traceback (most recent call last):
2023-05-10 15:09:02.808738+00:002023-05-10T15:09:02.808738382Z
2023-05-10 15:09:02.808758+00:00File "/lyd.py", line 605, in
2023-05-10 15:09:02.808775+00:00app()
2023-05-10 15:09:02.808781+00:002023-05-10T15:09:02.808781301Z
2023-05-10 15:09:02.808787+00:00File "/lyd.py", line 601, in run
2023-05-10 15:09:02.808796+00:00iterate_missing(artist, iterative)
2023-05-10 15:09:02.808808+00:002023-05-10T15:09:02.808808269Z
2023-05-10 15:09:02.808814+00:00File "/lyd.py", line 572, in iterate_missing
2023-05-10 15:09:02.808823+00:00iterate_records(json["records"], totalRecords, record_counter, artist_filter)
2023-05-10 15:09:02.808829+00:002023-05-10T15:09:02.808829180Z
2023-05-10 15:09:02.808834+00:00File "/lyd.py", line 526, in iterate_records
2023-05-10 15:09:02.808839+00:00iterate_tracks(
2023-05-10 15:09:02.808843+00:002023-05-10T15:09:02.808843688Z
2023-05-10 15:09:02.808857+00:00File "/lyd.py", line 498, in iterate_tracks
2023-05-10 15:09:02.808863+00:00get_song(
2023-05-10 15:09:02.808868+00:002023-05-10T15:09:02.808868053Z
2023-05-10 15:09:02.808872+00:00File "/lyd.py", line 441, in get_song
2023-05-10 15:09:02.808877+00:00append_to_skip_file(bestLink)
2023-05-10 15:09:02.808886+00:002023-05-10T15:09:02.808886165Z
2023-05-10 15:09:02.808891+00:00File "/lyd.py", line 333, in append_to_skip_file
2023-05-10 15:09:02.808896+00:00with open(".skip", "a+") as file_object:
2023-05-10 15:09:02.808901+00:002023-05-10T15:09:02.808901409Z
2023-05-10 15:09:02.808906+00:00PermissionError: [Errno 13] Permission denied: '.skip'
2023-05-10 15:09:02.808914+00:002023-05-10T15:09:02.808914313Z

Ok I caused the last one because I changed the container to run as a specific user and it didn't like it so error still occurs but workaround DOES still work.


Load onto 'non GUI' server

I'm pretty much "following the bouncing ball" here, (So i'm not digging too far into the code with my limited skills) but my incremental approach to getting a web server implementation has stalled.
Prior to trying to get a cloud based solution - I've tried to install onto just a local Ubuntu Server within a VirtualBox VM.
Mainly to prove it works there, before getting sidetracked on other server issues.
The install procedure work fine (as per the install guide) until I try and run "invoke superuser" - where it fails over installation of Cairo, which seems to be graphical user display  module - not relevant for the Server install ?? I think I managed to get Cairo sorted (maybe not completely) but now have an issue with 'Pango' which seems a bit more intractable!!
Server also fails to run over same issue.
Is there something I'm missing, or do I actually need a full GUI server instance ??

Hey @watarat welcome :)
It looks like what is happening here is you're getting stuck at the install requirements for weasyprint. This is a python package used for PDF generation, which is why it requires graphics packages to be installed.
"Normally" those packages would be installed on a ubuntu-ish setup (I think?)
Follow the Linux Setup Instructions for weasyprint to ensure those other packages are installed.
I'll have to add this into the install script to check for these packages

Ahh - fantastic - worked well 😀
Ran through all of the packages listed in your link
sudo apt-get install build-essential python3-dev python3-pip python3-setuptools python3-wheel python3-cffi libcairo2 libpango-1.0-0 libpangocairo-1.0-0 libgdk-pixbuf2.0-0 libffi-dev shared-mime-info
Several installed..
Re running invoke install, then invoke superuser succeeded, and is now running server.
Many thanks!!
(I had read of Cairo being used in weasyprint - but hadnt made the connection that all of weasyprint was needed for the pdf, just assumed that Cairo was part of some GUI output :) )

Thanks for the feedback - glad it is working for you now!
I'll make a note to update the install documentation to include these requirements


Make Rust code executable via F* extraction

One of the goals here is to test the engine via extraction.
Related to #526, being able to exact all the tests executed by cargo test to F* and to run via OCaml compilation would be great.

This is in progress with the new annotated core library, thus still relevant.


solarc-gtk-theme: init at 1.0.2

Motivation for this change
Add SolArc theme.
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

@GrahamcOfBorg build solarc-gtk-theme


tf-binding  Registering two gradient with name 'WarpRNNT' !

Hello! first thanks for your code, it helps a lot!
But I was encountered some problems when I install the tensorflow-binding. I build the libwarprnnt.so successfully and passes the test cases " test_cpu test_gpu test_time test_time_gpu".
And then "cd tensorflow_binding; sudo -E CUDA=/usr/local/cuda python3 setup.py install", it seems   performing well, but when I ran "sudo -E CUDA=/usr/local/cuda python3 setup.py test", it failed.
Here is the output log:
#####################################log start
_setup.py:63: UserWarning: Assuming tensorflow was compiled without C++11 ABI. It is generally true if you are using binary pip package. If you compiled tensorflow from source with gcc >= 5 and didn't set -D_GLIBCXX_USE_CXX11_ABI=0 during compilation, you need to set environment variable TF_CXX11_ABI=1 when compiling this bindings. Also be sure to touch some files in src to trigger recompilation. Also, you need to set (or unsed) this environment variable if getting undefined symbol: _ZN10tensorflow... errors
warnings.warn("Assuming tensorflow was compiled without C++11 ABI. "
running test
running egg_info
writing dependency_links to warprnnt_tensorflow.egg-info/dependency_links.txt
writing warprnnt_tensorflow.egg-info/PKG-INFO
writing top-level names to warprnnt_tensorflow.egg-info/top_level.txt
reading manifest file 'warprnnt_tensorflow.egg-info/SOURCES.txt'
writing manifest file 'warprnnt_tensorflow.egg-info/SOURCES.txt'
running build_ext
copying build/lib.linux-x86_64-3.5/warprnnt_tensorflow/kernels.cpython-35m-x86_64-linux-gnu.so -> warprnnt_tensorflow
/disk2/syd/warp-transducer/tensorflow_binding/setup.py:63: UserWarning: Assuming tensorflow was compiled without C++11 ABI. It is generally true if you are using binary pip package. If you compiled tensorflow from source with gcc >= 5 and didn't set -D_GLIBCXX_USE_CXX11_ABI=0 during compilation, you need to set environment variable TF_CXX11_ABI=1 when compiling this bindings. Also be sure to touch some files in src to trigger recompilation.  ERROR
test_warprnnt_op (unittest.loader._FailedTest) ... ERROR
======================================================================
ERROR: test_basic (unittest.loader._FailedTest)
ImportError: Failed to import test module: test_basic
Traceback (most recent call last):
File "/usr/lib/python3.5/unittest/loader.py", line 428, in _find_test_path
module = self._get_module_from_name(name)
File "/usr/lib/python3.5/unittest/loader.py", line 369, in _get_module_from_name
import(name)
File "/disk2/syd/warp-transducer/tensorflow_binding/tests/test_basic.py", line 3, in
from warprnnt_tensorflow import rnnt_loss
File "/disk2/syd/warp-transducer/tensorflow_binding/warprnnt_tensorflow/init.py", line 37, in
@ops.RegisterGradient("WarpRNNT")
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/framework/ops.py", line 2285, in call
_gradient_registry.register(f, self._op_type)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/framework/registry.py", line 62, in register
(self._name, name, function_name, filename, line_number))
KeyError: "Registering two gradient with name 'WarpRNNT' !(Previous registration was in setup /usr/lib/python3.5/distutils/core.py:148)"
======================================================================
ERROR: test_warprnnt_op (unittest.loader._FailedTest)
ImportError: Failed to import test module: test_warprnnt_op
Traceback (most recent call last):
File "/usr/lib/python3.5/unittest/loader.py", line 428, in _find_test_path
module = self._get_module_from_name(name)
File "/usr/lib/python3.5/unittest/loader.py", line 369, in _get_module_from_name
import(name)
File "/disk2/syd/warp-transducer/tensorflow_binding/tests/test_warprnnt_op.py", line 3, in
from warprnnt_tensorflow import rnnt_loss
File "/disk2/syd/warp-transducer/tensorflow_binding/warprnnt_tensorflow/init.py", line 37, in
@ops.RegisterGradient("WarpRNNT")
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/framework/ops.py", line 2285, in call
_gradient_registry.register(f, self._op_type)
File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/framework/registry.py", line 62, in register
(self._name, name, function_name, filename, line_number))
KeyError: "Registering two gradient with name 'WarpRNNT' !(Previous registration was in setup /usr/lib/python3.5/distutils/core.py:148)"

Ran 2 tests in 0.000s
FAILED (errors=2)
Test failed: <unittest.runner.TextTestResult run=2 errors=2 failures=0>
error: Test failed: <unittest.runner.TextTestResult run=2 errors=2 failures=0>_
####################################log end
BTW，when I ran "python3 tests/test_basic.py" and "python3 tests/test_warprnnt_op.py" it passed. I'm confused about the differences and it seems "python setup.py test" runs the test cases twice and it repo the issues the second time.
Do you have any idea about what happened here ?
When i use this interface(warprnnt_tensorflow.rnnt_loss) in my own tensorflow train program(timit as the train dataset),  I encountered "CUDA_ERROR_ILLEGAL_ADDRESS" error randomly, sometimes it occurs after 1 step, sometimes several steps. The log details is:
###start###
2019-05-21 15:05:25.985187: E tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:649] failed to record completion event; therefore, failed to create inter-stream dependency
2019-05-21 15:05:25.985270: I tensorflow/stream_executor/stream.cc:4793] stream 0x7fdeba0adbb0 did not memcpy host-to-device; source: 0x104e2486900
2019-05-21 15:05:25.985289: E tensorflow/stream_executor/stream.cc:318] Error recording event in stream: error recording CUDA event on stream 0x7fdeba0adc80: CUDA_ERROR_ILLEGAL_ADDRESS; not marking stream as bad, as the Event object may be at fault. Monitor for further errors.
2019-05-21 15:05:25.985312: E tensorflow/stream_executor/cuda/cuda_event.cc:48] Error polling for event status: failed to query event: CUDA_ERROR_ILLEGAL_ADDRESS
2019-05-21 15:05:25.985329: F tensorflow/core/common_runtime/gpu/gpu_event_mgr.cc:206] Unexpected Event status: 1
Aborted
###end###
thanks for your time. I'm really appreciate if you could reply.
tf.version: 1.10.1
cuda: 9.0
GPU: TITAN Xp 12G
platfom: Linux Ubuntu 16.04.3 LTS
corpus: timit(123dim fbank to 61phns)

There were some bugs in the gpu kernel, its fixed now, you could have a try.
BTW, the test suite is not used.

There were some bugs in the gpu kernel, its fixed now, you could have a try.
BTW, the test suite is not used.

I'm afraid the bugs are sill there, maybe other bugs. I cloned your new repository warp-rnnt just now, and install the tf-binding after remake the .so file, but the train process went crush again with the same exception as above. when i ran tf_debug, it came to segmentation fault at the end.

Did you use the CPU version ? If true, the log_softmax op should be manually called before rnnt_loss.

Did you use the CPU version ? If true, the log_softmax op should be manually called before rnnt_loss.

No, I use the GPU version.

I find it may due to the previous test.
Directly run python tests/test_basic.py or tests/test_warprnnt_op.py  seems no problem.

Hi, same problem here.
tf.version: 2.0.0-beta1
cuda: 10.0
GPU: Tesla V100
platfom: Linux Ubuntu 16.04.3 LTS
In addition to the "registering two warprnnt" and "CUDA_ERROR_ILLEGAL_ADDRESS" problem,
I print out the loss and it doesn't seem right.
tf.Tensor(0.5390258, shape=(), dtype=float32)
tf.Tensor(-0.9253367, shape=(), dtype=float32)
tf.Tensor(-0.16041934, shape=(), dtype=float32)
2019-07-28 14:53:57.698202: E tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:750] failed to record completion event; therefore, failed to create inter-stream dependency
2019-07-28 14:53:57.698235: I tensorflow/stream_executor/stream.cc:4813] [stream=0x558c9580d870,impl=0x558c957ffe00] did not memcpy host-to-device; source: 0x558cff547f80
2019-07-28 14:53:57.698248: E tensorflow/stream_executor/stream.cc:331] Error recording event in stream: error recording CUDA event on stream 0x558c9580c110: CUDA_ERROR_ILLEGAL_ADDRESS: an illegal memory access was encountered; not marking stream as bad, as the Event object may be at fault. Monitor for further errors.
2019-07-28 14:53:57.698261: E tensorflow/stream_executor/cuda/cuda_event.cc:29] Error polling for event status: failed to query event: CUDA_ERROR_ILLEGAL_ADDRESS: an illegal memory access was encountered
2019-07-28 14:53:57.698278: F tensorflow/core/common_runtime/gpu/gpu_event_mgr.cc:273] Unexpected Event status: 1
Aborted (core dumped)

Hi,
I finally found why the loss is abnormal..
In the tensorflow binding document(20190731) here:
costs = warprnnt_tensorflow.rnnt_loss(acts, labels, label_lengths, input_lengths)
However,
the cost in the test cases, which are the right one should be:
costs = rnnt_loss(logits, labels, input_length, label_length, blank)
the order of the two parameters are reversed.
Hope no more people meet the same issue...
@HawkAaron

@Slyne Thank you very much! The problem is fixed now.

There were some bugs in the gpu kernel, its fixed now, you could have a try.
BTW, the test suite is not used.

I'm afraid the bugs are sill there, maybe other bugs. I cloned your new repository warp-rnnt just now, and install the tf-binding after remake the .so file, but the train process went crush again with the same exception as above. when i ran tf_debug, it came to segmentation fault at the end.

So, did you solve this problem? I guess it might be caused by the tensorflow. The first time, I install tensorflow automatically, everything is ok. But resently, I build tensorflow source code and install it manually, then I install this binding it gives this errors. And I still can not solve it.

@Slyne Thank you very much! The problem is fixed now.

KeyError: "Registering two gradient with name 'WarpRNNT' ! Problem is still not solved, should I feel free to ignore this test error?


fixing github actions build

The tests don't actually run because it doesn't find assemblies. Leaving it in this state for now and opening a ticket to fix that issue.


Reactive easy full control

This PR updates #158 to be compatible with https://github.com/open-rmf/rmf_ros2/pull/286

I noticed a quite reproducible (most times, but not 100% of the times) jump in the schedule after a negotiation. I'm not sure what implications it might have but it seems a bit odd.
I can reproduce it best at startup in the battle royale scenario:
ros2 launch rmf_demos_gz_classic battle_royale.launch.xml
ros2 launch rmf_demos battle_go.launch.xml

An example video is below, robot with the schedule jump is in the top left. In all my tests it's either TinyRobotA or TinyRobotB in the top left of the map.
Screencast from 2023-07-13 10-59-19.webm

After some brief testing, I noticed that when a cleanerbot's cleaning path gets in the way of a patrol robot's route, the robots get stuck in a deadlock without negotiation. Not 100% sure but it might be because trajectory scheduling is not implemented for the cleaning perform action (example) .
https://github.com/open-rmf/rmf_demos/assets/30265743/d2c436b4-9b0c-4d19-9a03-6faef0aa4f8d

it might be because trajectory scheduling is not implemented for the cleaning perform action

Strange, it is implemented. I might suggest trying a clean build with the reactive_easy_full_control branches for both rmf_ros2 and rmf_demos. Here's a video of what it should look like when the robot is cleaning:
https://github.com/open-rmf/rmf_demos/assets/1307217/ec25c006-1831-4f03-9066-395d5d93cbc1
Maybe try a test where you just send the cleaning bot with nothing else running and see if the cleaning trajectory shows up on the schedule.

 I can still reproduce the same situation though. Haven't figured out a potential cause, leaving a screen recording with terminal logs here first.
https://github.com/open-rmf/rmf_demos/assets/30265743/14296e3e-0a1c-4353-9536-8cfc62427d24

@luca-della-vedova Good catch, I've found a subtle bug in the schedule update code that wasn't correctly accounting for planned waits. If you run the latest version the problem should be completely gone now.
@xiyuoh I've added traffic checkpoints for the activity (in this case cleaning) traffic schedule, so now the traffic negotiations should work better.


spec: in array and slice literals, the index/key can be non-integer type

What version of Go are you using (go version)?
Go playground
What operating system and processor architecture are you using (go env)?
package main

const k float64 = 3.0

var _ = []int{k: 3}
var _ = [...]int{k: 3}

func main() {}

See https://play.golang.org/p/x3keRiD0fVT. This compiles without an error.
What did you expect to see?
From the spec:

For array and slice literals the following rules apply:

Each element has an associated integer index marking its position in the array.
An element with a key uses the key as its index. The key must be a non-negative constant representable by a value of type int; and if it is typed it must be of integer type.
An element without a key uses the previous element's index plus one. If the first element has no key, its index is zero.

It mentions that if the index is typed, it must be of integer type. However, the above code compiles even if the index has type float64. Probably the spec should be saying "can be converted to int" or something, or the compiler should report an error?

@griesemer @rsc  go/types misses the case where the index to an array/slice is a typed constant with an underlying type int - same with composite array/slice literals. This should not work according to the spec:
https://play.golang.org/p/5vrtDMqGt9t

@ak2196 I'm sure I'm missing something but why do you say that your example should not work?  A type defined to int is still an integer type.

@ianlancetaylor maybe I am confused or reading the spec wrong
bar's type is foo, foo's underlying type is int but the spec says for array literals:
"An element with a key uses the key as its index. The key must be a non-negative constant representable by a value of type int; and if it is typed it must be of integer type."
In this case the key is typed - the type is not 'int' it's foo but foo's underlying type is int. I guess it depends on what "integer type" means. Does it mean just int or anything that has int as the underlying type?

@ak2196 "integer type" does not mean just int.  The spec does not seem to define it clearly (though I may be missing something) but certainly wherever the spec says "integer type" it accepts int, int8, int16, uint, etc., as well as any other type defined to one of those types.

@ianlancetaylor That definitely makes sense. Thanks for clearing it up.

Revisit to see if there's anything to do here.

It looks the behavior has been changed since 1.17.

Both the 1.17 and 1.18 compiler correctly report an error here and follow the spec. This is now working as expected. Closing.


Why do strange slashes often appear in masks?

I don't really know, it just sometimes doesn't seem to return enough data to draw the full mask


Feature Request: Version that works with User Stories and Bugs

Love the ability to quickly assign tasks.  It would be fantastic to be able to do this at a User Story and Bug (or PBI) level to help with more program/project management at a higher level.

Great idea,
I will try implement that in the future.

I love this, this is what my management wants to see but I need it to work with User Stories and Bugs


Adding GPU-accelerated MSM implementation

This PR adds a GPU-accelerated implementation for MSM: https://github.com/supranational/pasta-msm/blob/main/Cargo.toml
Mina side: https://github.com/MinaProtocol/mina/pull/12602)

Warning: I believe I might not have a compatible GPU and I am only using their CPU implementation

I did run into some weird mutex bug that I can't reproduce anymore (https://github.com/supranational/pasta-msm/issues/2) so I'm putting this behind a gpu feature.
The bench can be ran with:
cargo criterion -p o1-utils --bench msm --features gpu

here's a small MSM of size 20:
arkworks msm of length 20
                        time:   [209.97 µs 219.27 µs 230.18 µs]
                        change: [+0.6269% +6.4962% +12.549%] (p = 0.03 < 0.05)
                        Change within noise threshold.

supra msm of length 20  time:   [520.79 µs 533.57 µs 547.85 µs]
                        change: [-2.6103% -0.5490% +1.5491%] (p = 0.61 > 0.05)
                        No change in performance detected.

it only starts getting efficient around ~100. I'm falling back to arkworks if the length of the MSM is under 128 (this is what the nova implementation does as well)
arkworks msm of length 128
                        time:   [603.32 µs 669.73 µs 755.80 µs]
                        change: [+19.461% +30.086% +40.933%] (p = 0.00 < 0.05)
                        Performance has regressed.

supra msm of length 128 time:   [405.97 µs 418.83 µs 436.57 µs]
                        change: [-9.9518% -3.9928% +1.7631%] (p = 0.23 > 0.05)
                        No change in performance detected.

size 200:
arkworks msm of length 200
                        time:   [907.47 µs 961.33 µs 1.0261 ms]
                        change: [+0.0386% +27.408% +62.869%] (p = 0.05 < 0.05)
                        Change within noise threshold.

supra msm of length 200 time:   [697.13 µs 739.53 µs 793.43 µs]
                        change: [+23.911% +36.714% +51.081%] (p = 0.00 < 0.05)
                        Performance has regressed.

size 400:
arkworks msm of length 400
                        time:   [2.7526 ms 2.9586 ms 3.1813 ms]
                        change: [+101.31% +116.71% +135.88%] (p = 0.00 < 0.05)
                        Performance has regressed.

supra msm of length 400 time:   [1.1369 ms 1.1549 ms 1.1755 ms]
                        change: [-18.471% -8.8812% +0.8302%] (p = 0.11 > 0.05)
                        No change in performance detected.

the gap seems to increase with size, so these are not going to be really useful for the MSM for composition polynomial, but are probably going to be really useful for the MSM used in commitments (as the URS gets super large) and the MSM used to check the folded Gs coming from the proofs in pickles.verify
A test for a single very large size (2^18) that could mirror the size of our URS shows a 10ms difference:
$ cargo test --release --package o1-utils --features gpu -- --ignored large_msm --nocapture
running MSM of size 262144
cpu msm took: 281.071544ms
gpu msm took: 271.999473ms

Doesn't look that great to me :| if I do 100 of them the gap increases, so perhaps this is good
running MSM of size 262144
100 cpu msm took: 43.320211253s
100 gpu msm took: 35.781777069s

Here's a flamegraph, from my reading our usage is not spending much time doing non-useful things (like converting types).

@mimoo
I found the request on the twitter.(https://twitter.com/cryptodavidw/status/1621948382683213824).
Here is one result I could provide.

Gnuplot not found, using plotters backend
arkworks msm of length 20
                        time:   [194.16 µs 209.35 µs 226.38 µs]

Benchmarking supra msm of length 20: Warming up for 3.0000 s
Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 5.0s, enable flat sampling, or reduce sample count to 70.
supra msm of length 20  time:   [994.78 µs 994.90 µs 995.04 µs]

arkworks msm of length 128
                        time:   [292.83 µs 298.58 µs 304.91 µs]

supra msm of length 128 time:   [327.28 µs 350.70 µs 374.59 µs]

arkworks msm of length 200
                        time:   [394.92 µs 401.60 µs 409.36 µs]

supra msm of length 200 time:   [531.23 µs 574.51 µs 620.00 µs]

arkworks msm of length 400
                        time:   [658.72 µs 686.92 µs 719.91 µs]

Benchmarking supra msm of length 400: Warming up for 3.0000 s
Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 5.7s, enable flat sampling, or reduce sample count to 60.
supra msm of length 400 time:   [1.0556 ms 1.0877 ms 1.1170 ms]

Here is the GPU info.
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 510.108.03   Driver Version: 510.108.03   CUDA Version: 11.6     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0  On |                  N/A |
| N/A   51C    P8    16W /  N/A |     54MiB /  8192MiB |     19%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A      2415      G   /usr/lib/xorg/Xorg                 53MiB |
+-----------------------------------------------------------------------------+

thanks @duguorong009 , looks like your GPU was truncated but I see cuda so most likely cuda compatible :o indeed these don't seem like great benchmarks as well. I'm wondering what's going on there...

Note to myself: the implementation actually falls back to ADX (non-GPU) for MSM of size < 2^16


feat: add support for dotnet repos

Work in progress, adding support for dotnet style release process.

based on  conversation with @jskeet, we're going to abandon this for now and start with something that specifically targets CHANGELOG generation.


--message-format=json panic on broken pipe

rustc version: 1.80.0-nightly (7c52d2db6 2024-06-03)
platform: x86_64-unknown-linux-gnu
On a clean project run:
cargo +nightly fmt --message-format=json | echo ice

If the program which is being piped to (echo in this case) doesn't consume the input, the write will cause a panic in rustfmt.
rustc-ice-2024-06-04T16_38_03-53230.txt
My expected behavior is the command would fail, but it would not generate a rustc-ice-2024-06-04T16_38_03-53230.txt file or suggesting filing an issue.

Thanks for the report. This is likely a duplicate of #6089 and other reported piping issues like #2926


Test github actions deployment

This is a test PR to check if the github actions integration is working properly from firebase

Wow! This is pretty interesting stuff, it sets up a temp site within the PR on netlify - awesome!


Title windows appropriately

Existing behaviour: when launching Podium, two windows appear:

Slides - "Toga"
Notes - "Toga"

This PR titles the two windows more appropriately:

Slides - "Podium - Slides"
Notes - "Podium - Notes"

Alternative: If "Podium" and "Podium - Notes" seems more clean, let me know and I'll correct the PR accordingly.

Note: change functionally works, but requires toga-cocoa=0.3.0-dev10, which is currently showing behaviour issues (upstream issue in toga)


add credentials to all requests

I don't think it's necessary to send credentials for requests except for metadata (which contains login state).
However, @arandomb reports interestingly ( #482 ) that the metadata endpoint appears to work, while the match one does not (and match does not send credentials).  Maybe sending the credentials makes it work, in which case we may as well send them.

This PR is now inverted (adding credentials to all missing requests, since that appears to resolve #482


TinyGo support

First off, wanted to say thanks for such a great project. While the issue title may sound like a feature request, the code generated by vtprotobuf already works with TinyGo. You can see an example of that here: https://github.com/kyleconroy/go-wasm-plugins
What I'd like to ask about is making TinyGo support explicit via a CI job. Is this something you'd be interested in supporting? If so I can take a first pass.

Yeah for sure, I wouldn't mind running a TinyGo CI build (it it doesn't take a prohibitively long amount of time to run -- which it shouldn't!). Please feel free to send a Pull Request. Thanks!


Emotes

What do I have to do to get my emotes into Better Discord?

you could upload them to BetterTwitchTV or FrankerFaceZ


A tag consisting of spaces can not be deleted or changed

Steps to reproduce

Go to VM / Images / Firewall
Click on any entity
Go to tab "Tags"
Create new tag with key = " " and value = " " (space)

Actual result
The created tag can not be deleted or changed
Expected result
The created tag can be deleted or changed
Environment

Browser:
- [ ] Chrome version XX
- [ ] Firefox version XX
- [ ] Safari version XX
- [ ] Opera version XX
- [ ] IE version XX
- [ ] Edge version XX
Others:

Connected feature ID
vm_tag_display
vm_tag_edit
vm_tag_delete
Screenshots

@ershovaelena should we allow this tags?
I think this tags should be invalid. What do you think?

Test:
vm_tag_create
vm_tag_edit
vm_tag_display
image_tag_display
image_tag_create
image_tag_edit
firewall_tag_display
firewall_tag_create
firewall_tag_edit

Need to clarify requirements

Discussed with PO:
The only restriction is no spaces as the first symbol in keys and values.
So user can enter numbers, spaces inside of keys and values, special symbols.

Error entering a space character in the "Value" field is not localized
Steps:

Go to VM/Image/Firewall tags of any entity
Go to create or edit tag
Enter space character in "value" field

Actual result: Error appears with a text "TAGS.TAG_INVALID"
Expected result: Error appears with a text "Field value must start with 'non-space' character"

Tested on 1215


Removed Multiprocessing Cell

Fixes #30

Ahh okay I'll have a look at it!

I had a look and it looks fine to me. Can you point out the cell?


Implement Cursor Trail Effect on CHAT PAGE

This PR implements a cursor trail effect on the CHAT Page, enhancing the user interface by adding colorful circles that follow the mouse cursor.
Changes Made:

HTML: Added multiple

 elements to create the trail effect.
CSS: Defined styles for the circles, including size, color, and transition effects.
JavaScript:

Captured mouse movements to update the position of the circles.
Implemented a color array for dynamic visuals.
Used requestAnimationFrame for smooth animations.

This change aims to create a more engaging and interactive user experience.
fixes: #4980
@sailaja-adapa @abhi03ruchi

ohh , there are conflicts

resolve them fast ...

resolve them fast ...

done

@abhi03ruchi


sudo apt-simphony is misleading

using sudo make apt-simphony hints that one is installing simphony, though we are only installing some dependencies. Should could be renamed to something like:
sudo make apt-simphony-deps
to avoid confusion.
same is true for sudo make-lammps and make-mayavi

Fixed in the current release. Closing.


Fix password reset form

I was trying out the password reset and found the password reset form pointed to sign up instead of password reset. this PR fixes that.

Thanks! Can we get a test added for this and then I can merge?

I realized we don't have any system tests yet, so we can do this later if/when we decide to add those.


BUG Remove index page body overflow

BUG Remove index page body overflow
Current

New

Assign me under JWOC

@AftabMankapure this bug has been resolved.


Dark mode flicker in Chrome

I've noticed that in Chrome (macOS 109.0.5414.87) there is a flickering when navigating between pages only for the production build. In dev mode this doesn't seem to occur nor does it occur in Safari for the production build.
Here's a video showing the issue:
https://user-images.githubusercontent.com/47544496/214039411-00eb8ea9-d7c3-494c-9433-68b346def6ac.mov

oh man Chrome is doing its own resource prioritization again. It's happening in my blog too https://dineshpandiyan.com. I will see what's going on this week. We probably might have to preload the critical stylesheet or use js and set the css vars in :root.

Just fixed this theme flash issue in this commit https://github.com/flexdinesh/blogster/commit/4f275e8550b683241afae2d80af9531fdb06a8cf
The root cause was the background-color transition style we had transition: background-color 0.3s ease;. Chrome was adding a transition to the color even on first paint while firefox did not. Either way, lesson learnt - do not use bg color transition on page load for non-white backgrounds or Chrome will flash white once.


Improve error handling

Need to have an option to choose what to do when an error occurs (now scraper process fails on first error and directory is removed).
Need to provide opportunity to ignore error and continue scraping (Maybe something like stopOnError) and maintain a list of errorred resources

Implemented in #106


⚠ PrivateHD has degraded performance

In 53b3fac, PrivateHD ($PHD) experienced degraded performance:

HTTP code: 200
Response time: 18722 ms

Resolved: PrivateHD performance has improved in 8b63cca.


Bugfix: correctly overwrite the range in registry if specified

Small bug, overwrite=True argument in update_variable_registry_ranges() was not working properly.

 Should we wait for other potential bugfixes/changes?

@cyrraz should we create a small release? Should we wait for other potential bugfixes/changes?

A small release does not hurt.


'date' is undefined

https://jsfiddle.net/97fzrdv4/13/
Your Environment

flatpickr version used:  v4.4.3
Browser name and version: IE 11
OS and version: WIN 10

I am using a hook that was posted here: https://github.com/flatpickr/flatpickr/issues/698
new Flatpickr(yourElement, {
onChange: [function(selectedDates){
const dateArr = selectedDates.map(date => this.formatDate(date, "Y-m-d"));
}]
}
It seems to work in most browsers, but IE is throwing an error ('date' is undefined).
*edit: It appears that there is more to this issue that I first thought. I believe the issue is actually that the arrow function in this hook is not supported in IE (edge yes).

I believe the issue is actually that the arrow function in this hook is not supported in IE

Yes, IE11 doesn't support arrow functions. You need to use a plain function(){} or transpile your code with babel before deploying to production.


Variable is inferred incorrectly if modified in function within the scope

🔎 Search Terms
type inferring error
🕗 Version & Regression Information
I get the same error in 3.3.3 to 5.3.2
⏯ Playground Link
https://www.typescriptlang.org/play?ts=5.3.3#code/ATDGHsDsGcBdgLYE8BiBXSpgF5gAoBKHAPmAG8AoEEAGwFN4BDALmDgCcBLSAc2AB9gkNDRo4hImgG4KVahBjxoEAA50AJikjjCJcnOrBG4gEQAjGoxMzDAXxkG2qjVsIPDsJGuABBcZ7VwADMjG2B7IA
💻 Code
  const myFunc = () => {
    let a: string | null = null;

    const scopedFn = () => {
      a = "bla";
    };

    scopedFn();

    type A = typeof a;
  };

🙁 Actual behavior
type A is inferred as null
🙂 Expected behavior
type A is inferred as string | null
Additional information about the issue
No response

Another duplicate of #9998.


v1.3.0

New Features
More Settings

Recognition Map

New Function

Runnable Threads

Instead using AsyncTasks directly inside the plugin's UCLASSES, I've created separated Runnables to manage the recognition/synthesis work in NonBlocking threads and send the informations to the UCLASSES to call the delegates broadcasts.

Changes

Fix Viseme data broadcast delay
Fix cancellation log crash
Fix .wav file loading (In .wav File to Text)
Rename some functions & adjust some comments (Added core redirects)
Fix delegates and add a check to ensure that the plugin will broadcast only in game thread to avoid crashes in widgets calls
Added more logs & Debugging prints
Removed boolean bIsContinuous from recognizers, now they're using only continuous: Continuous tasks are better to manage in the runnables, allow task cancellation/stop and work similar to the single recognition (if you stop talking, the recognition will stop too)
Fix thread blocking/game freezing when a task is activated/deactivated
Added new delegates: Synthesis Started and Recognition Started
Set the plugin settings to accept 10 candidate languages

Note: More information about recognition map is coming.

Pre-Release 1: https://github.com/lucoiso/UEAzSpeech/releases/tag/v1.3.0-pre-1

New features
Recognition Map Check adjustments

The function is now a Async Task and run in a background thread
Now this function will try to check the exact word instead only checking if the input string contains a substring by using String Delimiters to validate the word range

Phrase Lists Map
The plugin now supports inserting data into phrase list grammar at runtime!

Changes

Set some functions from UAzSpeechHelper as BlueprintCallable instead BlueprintPure
Fix broadcast in thread exit
Adjust logs & prints
Add new properties to Recognition Map
Optimize includes

Pre-release 2: https://github.com/lucoiso/UEAzSpeech/releases/tag/v1.3.0-pre-2


Error: spawn ..\llama.cpp\main ENOENT at ChildProcess._handle.onexit

Really good project to adopt local GPT, thanks all for the effort!
I tried different models on w11, there are two models work fine with command line like ”main -m  -p “, they are ggml-vic13b-uncensored-q4_0.bin  and ggml-vic13b-q4_0.bin, still got errors "libc++abi: terminating due to uncaught exception of type std::runtime_error: unexpectedly reached end of file." for other models.  Continue to run test-application.sh with server together, got errors below:
Message from test-application.sh (client terminal):
--GPT-LLAMA.CPP TEST INSTALLATION SCRIPT LAUNCHED--
PLEASE MAKE SURE THAT A LOCAL GPT-LLAMA.CPP SERVER IS STARTED. OPEN A SEPARATE TERMINAL WINDOW START IT.\n
What port is your server running on? (press enter for default 443 port): 8000
Please drag and drop the location of your Llama-based Model (.bin) here and press enter:
../llama.cpp/models/ggml-vic13b-uncensored-q4_0.bin
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100   266    0     0  100   266      0   4977 --:--:-- --:--:-- --:--:--  5018
curl: (56) Recv failure: Connection was reset
Error: Curl command failed!
Is the gpt-llama.cpp server running? Try starting the server and running this script again.
Make sure you are testing on the right port. The Curl commmand server error port should match your port in the gpt-llama.cpp window.
Please check for any errors in the terminal window running the gpt-llama.cpp server.
Message from server terminal:

REQUEST RECEIVED
PROCESSING NEXT REQUEST FOR /v1/chat/completions
LLAMA.CPP DETECTED

=====  CHAT COMPLETION REQUEST  =====

AUTO MODEL DETECTION FAILED. LOADING DEFAULT CHATENGINE...
{}

=====  LLAMA.CPP SPAWNED  =====
..\llama.cpp\main -m ..\llama.cpp\models\ggml-vic13b-uncensored-q4_0.bin --temp 0.7 --n_predict 1000 --top_p 0.1 --top_k 40 -c 2048 --seed -1 --repeat_penalty 1.1764705882352942 --reverse-prompt user: --reverse-prompt
user --reverse-prompt system: --reverse-prompt
system --reverse-prompt
-i -p Complete the following chat conversation between the user and the assistant. system messages should be strictly followed as additional instructions.
system: You are a helpful assistant.
user: How are you?
assistant: Hi, how may I help you today?
system: You are ChatGPT, a helpful assistant developed by OpenAI.
user: How are you doing today?
assistant:
=====  REQUEST  =====
user: How are you doing today?
node:events:491
throw er; // Unhandled 'error' event
^
Error: spawn ..\llama.cpp\main ENOENT
at ChildProcess._handle.onexit (node:internal/child_process:283:19)
at onErrorNT (node:internal/child_process:476:16)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
Emitted 'error' event on ChildProcess instance at:
at ChildProcess._handle.onexit (node:internal/child_process:289:12)
at onErrorNT (node:internal/child_process:476:16)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
errno: -4058,
code: 'ENOENT',
syscall: 'spawn ..\llama.cpp\main',
path: '..\llama.cpp\main',
spawnargs: [
'-m',
'..\llama.cpp\models\ggml-vic13b-uncensored-q4_0.bin',
'--temp',
'0.7',
'--n_predict',
'1000',
'--top_p',
'0.1',
'--top_k',
'40',
'-c',
'2048',
'--seed',
'-1',
'--repeat_penalty',
'1.1764705882352942',
'--reverse-prompt',
'user:',
'--reverse-prompt',
'\nuser',
'--reverse-prompt',
'system:',
'--reverse-prompt',
'\nsystem',
'--reverse-prompt',
'\n\n\n',
'-i',
'-p',
'Complete the following chat conversation between the user and the assistant. system messages should be strictly followed as additional instructions.\n' +
'\n' +
'system: You are a helpful assistant.\n' +
'user: How are you?\n' +
'assistant: Hi, how may I help you today?\n' +
'system: You are ChatGPT, a helpful assistant developed by OpenAI.\n' +
'user: How are you doing today?\n' +
'assistant:'
]
}
Node.js v18.16.0

The problem is fixed, the reason is the path of main.exe under llama.cpp/build/bin ,  should move it to llama.cpp.


Update bastion-faq.md

Corrected Line 218### My privatelinke.azure.com cannot resolve to management.privatelink.azure.com to :### My privatelink.azure.com cannot resolve to management.privatelink.azure.com

@asukumar22 Thanks for the typo fix!


How I can to use the calendar only on an annual basis ( Yearly ) ?

How I can to use the calendar only on an annual basis ( Yearly ) ?  I don’t want to use the other formats on calender.

With two options:
view: for select the initial view (year)
and "views", an array that you can enable / disable views
views: {
			year: {
				slide_events: 1,
				enable: 1
			},
			month: {
				slide_events: 1,
				enable: 0
			},
			week: {
				enable: 0
			},
			day: {
				enable: 0
			}
		},

thank you :)