refac/ batchAssert

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

7 of 7 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.0009%) to 98.953%

Totals

Change from base Build<PHONE_NUMBER>:
0.0009%

Covered Lines:
2613

Relevant Lines:
2620

💛  - Coveralls

Codecov Report

Merging #220 (b0d93dc) into main (5a77815) will increase coverage by 0.00%.
The diff coverage is 100.00%.

:exclamation: Current head b0d93dc differs from pull request most recent head 76da450. Consider uploading reports for the commit 76da450 to get more accurate results

@@           Coverage Diff           @@
##             main     #220   +/-   ##
=======================================
  Coverage   99.74%   99.74%
=======================================
  Files          68       68
  Lines        3121     3124    +3
  Branches      528      528
=======================================
+ Hits         3113     3116    +3
  Misses          8        8

Impacted Files
Coverage Δ

data-structures/graph/utils/graph.js
100.00% <100.00%> (ø)

utils/arrays/arrays.js
100.00% <100.00%> (ø)

utils/testing/assertions.js
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

7 of 7 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.0009%) to 98.953%

Totals

Change from base Build<PHONE_NUMBER>:
0.0009%

Covered Lines:
2613

Relevant Lines:
2620

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

74 of 74 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.001%) to 98.953%

Totals

Change from base Build<PHONE_NUMBER>:
0.001%

Covered Lines:
2614

Relevant Lines:
2621

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

79 of 79 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.003%) to 98.955%

Totals

Change from base Build<PHONE_NUMBER>:
0.003%

Covered Lines:
2619

Relevant Lines:
2626

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

105 of 110 (95.45%)  changed or added relevant lines in 8 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.002%) to 98.95%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

data-structures/graph/Graph.js
9
14
64.29%

Totals

Change from base Build<PHONE_NUMBER>:
-0.002%

Covered Lines:
2604

Relevant Lines:
2611

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

105 of 110 (95.45%)  changed or added relevant lines in 8 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.002%) to 98.95%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

data-structures/graph/Graph.js
9
14
64.29%

Totals

Change from base Build<PHONE_NUMBER>:
-0.002%

Covered Lines:
2604

Relevant Lines:
2611

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

138 of 143 (96.5%)  changed or added relevant lines in 8 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.003%) to 98.955%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

data-structures/graph/Graph.js
9
14
64.29%

Totals

Change from base Build<PHONE_NUMBER>:
0.003%

Covered Lines:
2621

Relevant Lines:
2628

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

138 of 143 (96.5%)  changed or added relevant lines in 8 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.003%) to 98.955%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

data-structures/graph/Graph.js
9
14
64.29%

Totals

Change from base Build<PHONE_NUMBER>:
0.003%

Covered Lines:
2621

Relevant Lines:
2628

💛  - Coveralls


"Received RST_STREAM with error code 2" from any call

Environment details

OS type and version: OS X 12.3.1
Python version: python --version: Python 3.9.13
pip version: pip --version: pip 22.2.2
google-cloud-datastream version: pip show google-cloud-datastream: 1.1.0

Steps to reproduce

Fresh virtualenv, installing nothing but pip install google-cloud-datastream
Use the sample code at https://github.com/googleapis/python-datastream/blob/main/samples/generated_samples/datastream_v1_generated_datastream_get_connection_profile_sync.py (or any code that actually makes a datastream API call)
Receive error

google.api_core.exceptions.InternalServerError: 500 Received RST_STREAM with error code 2

I'm using the example here of DatastreamClient().get_connection_profile(), but I've received the same error from multiple other methods like list_connection_profiles(), list_routes(), anything that calls the API basically.
Code example
Simplest:
from google.cloud import datastream_v1
client = datastream_v1.DatastreamClient()
response = client.get_connection_profile(name="mysql-bq-dev")

Following the sample code:
from google.cloud import datastream_v1
client = datastream_v1.DatastreamClient()
request = datastream_v1.GetConnectionProfileRequest(name="mysql-bq-dev")
response = client.get_connection_profile(request=request)

Both yield the same error. Going line by line, declaring the client is fine, declaring the request is fine, but once client.get_connection_profile() is called the error is thrown.
Stack trace
From 2nd example above
Traceback (most recent call last):
  File "/Users/nick.bellamy/test/datastream/lib/python3.9/site-packages/google/api_core/grpc_helpers.py", line 50, in error_remapped_callable
    return callable_(*args, **kwargs)
  File "/Users/nick.bellamy/test/datastream/lib/python3.9/site-packages/grpc/_channel.py", line 946, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/Users/nick.bellamy/test/datastream/lib/python3.9/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking
    raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.INTERNAL
	details = "Received RST_STREAM with error code 2"
	debug_error_string = "{"created":"@1660664399.127751000","description":"Error received from peer ipv4:<IP_ADDRESS>:443","file":"src/core/lib/surface/call.cc","file_line":967,"grpc_message":"Received RST_STREAM with error code 2","grpc_status":13}"
>

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/nick.bellamy/test/testing.py", line 4, in <module>
    response = client.get_connection_profile(request=request)
  File "/Users/nick.bellamy/test/datastream/lib/python3.9/site-packages/google/cloud/datastream_v1/services/datastream/client.py", line 742, in get_connection_profile
    response = rpc(
  File "/Users/nick.bellamy/test/datastream/lib/python3.9/site-packages/google/api_core/gapic_v1/method.py", line 154, in __call__
    return wrapped_func(*args, **kwargs)
  File "/Users/nick.bellamy/test/datastream/lib/python3.9/site-packages/google/api_core/grpc_helpers.py", line 52, in error_remapped_callable
    raise exceptions.from_grpc_error(exc) from exc
google.api_core.exceptions.InternalServerError: 500 Received RST_STREAM with error code 2

Hi @nbellamy-paper,
Are you using any proxies? The grpc error code you are getting is 13 which is reserved for internal/serious problems. Basically something is not workign for you on fundamental level.
This stackwoverflow stackwoverflow response response may help (unless you haven't seen it already).
In general, the issue seems to be on server/networking level which is beyond what client side library can control in a reasonable way. Also it is very suspicious that it fails on a basic example (which suggest that the isue is in environment or server side setup, not in how you use the library itself).

Thanks for the response @vam-google
No proxies in use, no. No VPN - just a direct internet connection.
One of my colleagues (on a different laptop, in a different city & ISP) has the same problems with this library.
I can use other google python libs just fine.
nick.bellamy ~  $ python3
Python 3.10.6 (main, Aug 11 2022, 13:36:31) [Clang 13.1.6 (clang-13<IP_ADDRESS>.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from google.cloud import bigquery
>>> for dataset in bigquery.Client().list_datasets():
...   print(dataset.dataset_id)
...
# redacted list of datasets - no error, output as expected
>>> from google.cloud import storage
>>> for bucket in storage.Client().list_buckets():
...   print(bucket.name)
...
# redacted list of buckets - no error, output as expected
>>> from google.cloud import datastream
>>> datastream.DatastreamClient().list_connection_profiles()
Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 50, in error_remapped_callable
    return callable_(*args, **kwargs)
  File "/opt/homebrew/lib/python3.10/site-packages/grpc/_channel.py", line 946, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/opt/homebrew/lib/python3.10/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking
    raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.INTERNAL
	details = "Received RST_STREAM with error code 2"
	debug_error_string = "{"created":"@1661956364.181316000","description":"Error received from peer ipv4:<IP_ADDRESS>:443","file":"src/core/lib/surface/call.cc","file_line":967,"grpc_message":"Received RST_STREAM with error code 2","grpc_status":13}"
>

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/homebrew/lib/python3.10/site-packages/google/cloud/datastream_v1/services/datastream/client.py", line 640, in list_connection_profiles
    response = rpc(
  File "/opt/homebrew/lib/python3.10/site-packages/google/api_core/gapic_v1/method.py", line 154, in __call__
    return wrapped_func(*args, **kwargs)
  File "/opt/homebrew/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 52, in error_remapped_callable
    raise exceptions.from_grpc_error(exc) from exc
google.api_core.exceptions.InternalServerError: 500 Received RST_STREAM with error code 2
>>>

What is the address <IP_ADDRESS> in Error received from peer ipv4:<IP_ADDRESS>:443?  I had assumed it was the GCP datastream API, and that I have no control over that endpoint. Is that something that I can control?
I am happy to troubleshoot client/environment problems if you have further guidance, but everything else seems to be working fine. I don't have a web proxy on my laptop config, and I'm not aware of any reverse proxies that we control as described in the stackoverflow article.

Hi @nbellamy-paper, I recently came across the same issue. The value for name should be in the form projects/<projectname>/locations/<location>/connectionProfiles/<profilename> instead of <profilename>
As an example,
import google.cloud.datastream_v1 as datastream_v1
client = datastream_v1.DatastreamClient()
request = datastream_v1.GetConnectionProfileRequest(name="projects/someproject/locations/us-central1/connectionProfiles/mysql-bq-dev")
response = client.get_connection_profile(request=request)

I'll keep this issue open so we can track improving the sample code.

I still receive the same error using that name format.  Still the same error on list_connection_profiles() as well.
$ python
Python 3.10.6 (main, Aug 11 2022, 13:36:31) [Clang 13.1.6 (clang-13<IP_ADDRESS>.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import google.cloud.datastream_v1 as datastream_v1
>>> client = datastream_v1.DatastreamClient()
>>> client.list_connection_profiles()
Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 50, in error_remapped_callable
    return callable_(*args, **kwargs)
  File "/opt/homebrew/lib/python3.10/site-packages/grpc/_channel.py", line 946, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/opt/homebrew/lib/python3.10/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking
    raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.INTERNAL
	details = "Received RST_STREAM with error code 2"
	debug_error_string = "{"created":"@1664832422.162304000","description":"Error received from peer ipv4:<IP_ADDRESS>:443","file":"src/core/lib/surface/call.cc","file_line":967,"grpc_message":"Received RST_STREAM with error code 2","grpc_status":13}"
>

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/homebrew/lib/python3.10/site-packages/google/cloud/datastream_v1/services/datastream/client.py", line 640, in list_connection_profiles
    response = rpc(
  File "/opt/homebrew/lib/python3.10/site-packages/google/api_core/gapic_v1/method.py", line 154, in __call__
    return wrapped_func(*args, **kwargs)
  File "/opt/homebrew/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 52, in error_remapped_callable
    raise exceptions.from_grpc_error(exc) from exc
google.api_core.exceptions.InternalServerError: 500 Received RST_STREAM with error code 2
>>> request = datastream_v1.GetConnectionProfileRequest(name="projects/redacted/locations/redacted/connectionProfiles/mysql-bq-dev")
>>> response = client.get_connection_profile(request=request)
Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 50, in error_remapped_callable
    return callable_(*args, **kwargs)
  File "/opt/homebrew/lib/python3.10/site-packages/grpc/_channel.py", line 946, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/opt/homebrew/lib/python3.10/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking
    raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.INTERNAL
	details = "Received RST_STREAM with error code 2"
	debug_error_string = "{"created":"@1664832504.684270000","description":"Error received from peer ipv4:<IP_ADDRESS>:443","file":"src/core/lib/surface/call.cc","file_line":967,"grpc_message":"Received RST_STREAM with error code 2","grpc_status":13}"
>

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/homebrew/lib/python3.10/site-packages/google/cloud/datastream_v1/services/datastream/client.py", line 746, in get_connection_profile
    response = rpc(
  File "/opt/homebrew/lib/python3.10/site-packages/google/api_core/gapic_v1/method.py", line 154, in __call__
    return wrapped_func(*args, **kwargs)
  File "/opt/homebrew/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 52, in error_remapped_callable
    raise exceptions.from_grpc_error(exc) from exc
google.api_core.exceptions.InternalServerError: 500 Received RST_STREAM with error code 2
>>>

Even I am getting the same error : https://github.com/googleapis/python-datastream/issues/137
Even the REST API is not working for me. @nbellamy-paper did rest api work for you ?

Hi @nbellamy-paper,
I was able to re-create the error using the code provided.
>>> import google.cloud.datastream_v1 as datastream_v1
>>> client = datastream_v1.DatastreamClient()
>>> client.list_connection_profiles()

I modified the code to include the request parameter and I no longer receive the error. Please can you try the sample code below?

import google.cloud.datastream_v1 as datastream_v1
project_id = "your-project"
location = "us-central1"
client = datastream_v1.DatastreamClient()
request = datastream_v1.ListConnectionProfilesRequest(parent=f"projects/{project_id}/locations/{location}/connectionProfiles")
response = client.list_connection_profiles(request=request)
print(response)

Hi @Rstar1998,
It appears that this specific API provides a generic error code which is not helpful. Usually Received RST_STREAM with error code 2 indicates that something is wrong with the request.
I've used the gcloud tool to troubleshoot the correct format required.
For example, the following command may give a hint about the format needed for parent.
 gcloud datastream connection-profiles list --location=us-central1 --verbosity=debug

Please feel free to open a new issue if you're still experiencing an issue.

I'm going to close this issue but please feel free to open a new issue if you're still experiencing a problem.

I still receive the same error using the code you provided @parthea .
>>> import google.cloud.datastream_v1 as datastream_v1
>>> project_id = "redacted"
>>> location = "redacted"
>>> client = datastream_v1.DatastreamClient()
>>> request = datastream_v1.ListConnectionProfilesRequest(parent=f"projects/{project_id}/locations/{location}/connectionProfiles")
>>> response = client.list_connection_profiles(request=request)
Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 50, in error_remapped_callable
    return callable_(*args, **kwargs)
  File "/opt/homebrew/lib/python3.10/site-packages/grpc/_channel.py", line 946, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/opt/homebrew/lib/python3.10/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking
    raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.INTERNAL
	details = "Received RST_STREAM with error code 2"
	debug_error_string = "{"created":"@1665586914.027808000","description":"Error received from peer ipv4:<IP_ADDRESS>:443","file":"src/core/lib/surface/call.cc","file_line":967,"grpc_message":"Received RST_STREAM with error code 2","grpc_status":13}"
>

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/homebrew/lib/python3.10/site-packages/google/cloud/datastream_v1/services/datastream/client.py", line 640, in list_connection_profiles
    response = rpc(
  File "/opt/homebrew/lib/python3.10/site-packages/google/api_core/gapic_v1/method.py", line 154, in __call__
    return wrapped_func(*args, **kwargs)
  File "/opt/homebrew/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 52, in error_remapped_callable
    raise exceptions.from_grpc_error(exc) from exc
google.api_core.exceptions.InternalServerError: 500 Received RST_STREAM with error code 2
>>>

Hi @nbellamy-paper,
As I mentioned in https://github.com/googleapis/python-datastream/issues/123#issuecomment-1274830550, there is a known issue where the backend provides a generic error code 500 which is not helpful. Usually Received RST_STREAM with error code 2 indicates that something is wrong with the request.
See the below example using curl, I get a valid response when I use location us-central1 and I receive a 404 when I use location us-east4.
This succeeds
curl -X GET -H "Authorization: Bearer "$(gcloud auth application-default print-access-token) "https://datastream.googleapis.com/v1/projects/project-xxxx/locations/us-central1/streams/my-stream/objects"

This fails with 404 error
curl -X GET -H "Authorization: Bearer "$(gcloud auth application-default print-access-token) "https://datastream.googleapis.com/v1/projects/project-xxxx/locations/us-central1/streams/my-stream/objects"

With the python client, if I repeat the same steps I get a valid response with location us-central1 but I receive 500 Received RST_STREAM with error code 2 when I use location us-east4 which indicates that the server responds with 500 when it should respond with 404.
import google.cloud.datastream_v1 as datastream_v1
project_id ="partheniou-303520"
#location = "us-east4" This results in 500 Received RST_STREAM with error code 2
location="us-central1"
stream_name="my-stream"
client = datastream_v1.DatastreamClient()
request = datastream_v1.ListStreamObjectsRequest(parent=f"projects/{project_id}/locations/{location}/streams/{stream_name}")
response = client.list_stream_objects(request=request)
print(response)

This issue only happens when using the gRPC transport. We are actively developing a python client with REST transport, which could be used as a workaround however the work is still in progress. In the meantime, I've reported the issue to the API team. Googlers see b/246509350.

Closing this bug as obsolete. The issue was fixed b/246509350. Please open a new issue if the problem re-appears.


Validate functions before parsing them.

Currently get an error with this:
tackle foo

tackle.yaml
foo<-:
  help: bar

Ie. Nothing in the foo hook. Should be caught earlier when creating the hook, not when trying to parse it. Or just putting a empty dict when params are missing.

https://github.com/sudoblockio/tackle/pull/126


We need to change target generate speed dynamically

Done by https://github.com/intel-go/nff-go/commit/5ea25c59f16dddebe9fedfaeb45d7071bc4dfc04


User Comment & Review System

Hello, I noticed you assigned comment and review system but I am and have
been working on is on data scraping and APIs. I do not know if this is a
mix-up.
On Sat, 30 Jul 2022, 18:47 Amafaye Wallace Jr, @.***>
wrote:

Assigned #45
https://github.com/zuri-training/Team-29_PriceCompare/issues/45 to
@OjewaleKehinde https://github.com/OjewaleKehinde.
—
Reply to this email directly, view it on GitHub
https://github.com/zuri-training/Team-29_PriceCompare/issues/45#event-7095067813,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMNKYMBJAOGTYMF4OLFZIW3VWVTBJANCNFSM546EJXYA
.
You are receiving this because you were assigned.Message ID:
@.***
.com>

Na me be de do the work before o🌚😢

I and Etinosa are the ones working on this. Contact Wallace to reassign you


Inference with CV2 Images

Hello in the test.py or demo.py you use LMDB dataset to run inference , how wan i di the same thing but with Cv2 images or PIL images .
and also how can i serve the model for exemple making a Flask app thath take a single image(word) and return the prediction .

@hmiche Hi. Did you figure this out?


dict_generic has minimum length 1

First of all thank you for creating this library!
While using this library I noticed that dict_generic generates dictionaries with a minimum length of 1. This is in contrast to set_generic which generates sets at a minimum size of zero.
I ran into this in a use-case where the maximum dictionary size I want to generate depends on another generator and can go down to zero, which triggers a failure due to this assertion.
Was there any particular reason to choose a minimum size of 1 for dictionary generation? If not it may be better to allow a minimum size of zero.

Thanks for opening this issue.
I believe that it is likely a mistake on my part that the minimum size of generated dictionaries is 1 as compared to min size of sets, which is 0.  The stdlib's set is even implemented in terms of the dict, so I can't think of any reason that I would have done that intentionally.  I also went back to some of the libraries that this one is based on and don't see any special restrictions that generated dicts (or maps, hash tables, etc.) should be >= 1.
Anyway, I think you're right in that it would be more correct to allow generation of empty dicts.


mvnw clean package -DskipTests error

Question
RC2-release  run  mvn clean package -DskipTests
[ERROR] Failed to execute goal org.xolstice.maven.plugins:protobuf-maven-plugin:0.5.0:compile-custom (default) on project collector-remote-grpc-provider: Unable to copy the file to D:\skywalking\apm-collector\apm-collector-remote\collector-remote-grpc-provider\target\protoc-plugins: D:\skywalking\apm-collector\apm-collector-remote\collector-remote-grpc-provider\target\protoc-plugins\protoc-3.3.0-windows-x86_64.exe (请求的操作无法在使用用户映射区域打开的文件上执行。) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :collector-remote-grpc-provider

I am sorry to say, this is common error for protoc running in Windows. Try to reboot your IDE or machine to fix this.
I haven't better solution. You could google for this. :)


Investigate failed Elixir test in CI

https://github.com/ockam-network/ockam/runs/6104986594?check_suite_focus=true#step:6:214

Should be fixed in #2671


Vector rendering is not working. | 1.20.4

I have block rendering working, but vector rendering (lines between blocks) is not working.
I tried:

to use the config of my friend who has everything working.
deleting all mods except fabric, malilib, watson. (different versions).
a different java - termurin and oracle (v17 both)
compiling the mod on my java

I'm using an amd 6750xt video card, maybe the problem is in the drivers, but as I understand it, it seems the method of rendering vectors and outlines for blocks is the same.

My watson config
watson.json

@papersaccul under Edits, you haven't set linkedcreation or linkeddestruction to true

@vacla sry, i attached the wrong config.
linkedcreation, linkeddestruction and vectoprShown are enabled, but they don't work. Otherwise the config is the same.

Not really sure what is happening, seems like same issue perhabs as https://github.com/vacla/Watson/issues/41


Error installing: salesforce-lavis 1.0.2 depends on decord

I'm trying to pip install lavis, but keeps getting this:
ERROR: Cannot install salesforce-lavis==1.0.0 and salesforce-lavis==1.0.2 because these package versions have conflicting dependencies.

The conflict is caused by:
    salesforce-lavis 1.0.2 depends on decord
    salesforce-lavis 1.0.0 depends on decord

When trying to run pip install decord I get:
ERROR: Could not find a version that satisfies the requirement decord (from versions: none)
ERROR: No matching distribution found for decord

I tried this on new virtual-envs using Python 3.11, 3.10 and 3.8 on an M1 mac.

Hi, @shakedzy  I met the same error onM1 Macbook with Python 3.18.16.
I did some search and found that it's because the decord does not support M1 chip. See here: https://github.com/dmlc/decord/issues/225
I am afraid it just does not work to install lavis on M1 chip Macbook

same here. it depends on decord and not possible to install

Seems like the open issue on decord is from 08/2022, so I guess this isn't getting fixed any time soon..

I'm on Intel, not M1, but it's possible you could try to install from source?
brew install ffmpeg cmake
git clone --recursive https://github.com/dmlc/decord
cd decord
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make
cd ../python
python setup.py install

You may need to change some source code as shown here: https://github.com/dmlc/decord/issues/186#issuecomment-1171882325

Hello, for anyone landing here, this is how i temporarily fixed this annoying issue.
I am using python 3.10 on Intel macOS, but it looks like there are no wheels for decord for my python version (up to 3.8).
So, I downloaded the wheel manually (Wheels), I used decord-0.6.0-cp38-cp38-macosx_10_15_x86_64.whl
Then, I tried to pip install decord-0.6.0-cp38-cp38-macosx_10_15_x86_64.whl, but it yielded errors because cp38 means I should have python3.8.
I changed the filename to decord-0.6.0-cp310-cp310-macosx_10_15_x86_64.whl and ran pip install decord-0.6.0-cp310-cp310-macosx_10_15_x86_64.whl, package installed successfully.
Afterwards I ran python3 -m pip install salesforce-lavis and finally I managed to install it.
Note: I tried to install decord from source: no success.

If you install from source, you need to change the source code itself because you likely have an incompatible ffmpeg (v5 instead of v4).

For Apple Silicon try:
diff --git a/lavis/datasets/data_utils.py b/lavis/datasets/data_utils.py
index 0ea4f44..0765665 100644
--- a/lavis/datasets/data_utils.py
+++ b/lavis/datasets/data_utils.py
@@ -12,7 +12,7 @@ import random as rnd
 import tarfile
 import zipfile

-import decord
+import eva-decord as decord
 import webdataset as wds
 import numpy as np
 import torch
diff --git a/requirements.txt b/requirements.txt
index 247190d..05a3e7d 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,5 +1,5 @@
 contexttimer
-decord
+eva-decord
 einops>=0.4.1
 fairscale==0.4.4
 ftfy

and build with pip install -e .

I was able to run the Zoo on ARM 64 Ubuntu Linux / Python 3.9 after doing the following steps. I have not tried anything else yet.

Use @devfacet's suggestion with a few modifications of the eva-decord instructions.

Make sure to clone the repository recursively -- not zip download. There are dependencies on other Git projects.
Follow the instructions build.
Copy the libdecord.so into the decord/python directory.
Modify python/setup.py replacing 'libdecord.dylib' with 'libdecord.so'
python3.9 setup.py install --user

Example code:
apt-get update
apt-get install -y build-essential python3-dev python3-setuptools make cmake
apt-get install -y ffmpeg libavcodec-dev libavfilter-dev libavformat-dev libavutil-dev
git clone --recursive https://github.com/georgia-tech-db/eva-decord.git
mkdir eva-decord/build & cd eva-decord/build
cmake .. -DUSE_CUDA=0 -DCMAKE_BUILD_TYPE=Release
make
cp libdecord.so ../python
cd ../python & sed -i 's/dylib/so/g' setup.py
python3.9 setup.py install --user

Extract the requirements.txt from the Lavis repository tagged 1.0.2 adding the following lines and removing decord.

langcodes
pathy
smart-open
spacy-legacy
spacy-loggers
typer==0.7.*
thinc
huggingface_hub
braceexpand
portalocker
antlr4-python3-runtime==4.9.*
eva-decord

Install Lavis using modified requirements
python3.9 -m pip install salesforce-lavis==1.0.2 --no-deps -r lavisRequirements.txt

lavisRequirements.txt

For Apple Silicon try (https://github.com/georgia-tech-db/eva-decord):
diff --git a/requirements.txt b/requirements.txt
index 247190d..05a3e7d 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,5 +1,5 @@
 contexttimer
-decord
+eva-decord
 einops>=0.4.1
 fairscale==0.4.4
 ftfy

and build with pip install -e .

I had to make a small change above because it was still breaking on my M1 with Python3.10 because of the version specified for open3d in requirements (open3d==0.13.0). I simply removed the version from it
diff --git a/requirements.txt b/requirements.txt
index 247190d..05a3e7d 100644
--- a/requirements.txt
+++ b/requirements.txt
-open3d==0.13.0
+open3d

and build with pip install -e .


Add predictive calls for statistics/get

Constructs and asynchronously precaches the expected statistics/get calls.
I haven't tested on any other account yet, so I can't guarantee its portability. The code's a bit of a mess, sorry I don't have much experience with Go.
Cuts the 88 calls down from ~19s to ~7s :
2021/08/08 19:44:49 "POST http://<IP_ADDRESS>:21611/api/sys/get_env HTTP/1.1" from <IP_ADDRESS>:56205 - 200 88B in 750.5014ms
2021/08/08 19:44:49 "POST http://<IP_ADDRESS>:21611/api/user/login HTTP/1.1" from <IP_ADDRESS>:56207 - 200 122B in 204.6694ms
2021/08/08 19:44:50 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 4390B in 783.4534ms
2021/08/08 19:44:50 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 724B in 0s
2021/08/08 19:44:50 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 824.6µs
2021/08/08 19:44:50 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 896.1µs
2021/08/08 19:44:50 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:50 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:50 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:50 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:50 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:50 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:51 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:51 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:51 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:51 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:51 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 930.9µs
2021/08/08 19:44:51 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:51 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:51 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:51 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 2282B in 0s
2021/08/08 19:44:51 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26953B in 0s
2021/08/08 19:44:51 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26817B in 425.7µs
2021/08/08 19:44:51 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26794B in 825.5µs
2021/08/08 19:44:52 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26794B in 1.0008ms
2021/08/08 19:44:52 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26797B in 351.9µs
2021/08/08 19:44:52 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26794B in 214.3µs
2021/08/08 19:44:52 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26794B in 515.5µs
2021/08/08 19:44:52 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26794B in 0s
2021/08/08 19:44:52 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26794B in 1.0005ms
2021/08/08 19:44:52 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26794B in 0s
2021/08/08 19:44:52 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26794B in 801.4µs
2021/08/08 19:44:52 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26794B in 859.4µs
2021/08/08 19:44:52 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26794B in 0s
2021/08/08 19:44:52 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26794B in 98.2µs
2021/08/08 19:44:52 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26794B in 0s
2021/08/08 19:44:53 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:53 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 26979B in 0s
2021/08/08 19:44:53 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 7913B in 0s
2021/08/08 19:44:53 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 356B in 0s
2021/08/08 19:44:53 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:53 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:53 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:53 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:53 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:53 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:53 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 227.8µs
2021/08/08 19:44:53 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 850.7µs
2021/08/08 19:44:54 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:54 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 374.4µs
2021/08/08 19:44:54 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 281.3µs
2021/08/08 19:44:54 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:54 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:54 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 821.8µs
2021/08/08 19:44:54 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:54 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 356B in 132.5µs
2021/08/08 19:44:54 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 11209B in 813.3µs
2021/08/08 19:44:54 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 3794B in 0s
2021/08/08 19:44:54 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:54 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:55 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:55 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 1ms
2021/08/08 19:44:55 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:55 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:55 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 374.9µs
2021/08/08 19:44:55 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:55 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:55 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:55 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:55 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:55 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:55 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:56 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:56 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:56 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:56 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:56 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:56 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 615.2µs
2021/08/08 19:44:56 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:56 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 186.6µs
2021/08/08 19:44:56 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 264.5µs
2021/08/08 19:44:56 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
2021/08/08 19:44:56 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 363.3µs
2021/08/08 19:44:56 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 820.7µs
2021/08/08 19:44:57 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
Empty queue, shutting down
2021/08/08 19:44:57 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 81.6µs
Empty queue, shutting down
2021/08/08 19:44:57 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 807.7µs
Empty queue, shutting down
2021/08/08 19:44:57 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 62B in 0s
Empty queue, shutting down
2021/08/08 19:44:57 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 11209B in 634.5µs
Empty queue, shutting down
2021/08/08 19:44:57 "POST http://<IP_ADDRESS>:21611/api/statistics/get HTTP/1.1" from <IP_ADDRESS>:56207 - 200 3794B in 307.7µs
Done looking up stats
2021/08/08 19:44:58 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 214.5103ms
2021/08/08 19:44:58 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 626.0845ms
2021/08/08 19:44:59 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 357.2075ms
2021/08/08 19:44:59 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 462.8115ms
2021/08/08 19:45:00 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 433.6656ms
2021/08/08 19:45:00 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 442.131ms
2021/08/08 19:45:01 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 493.572ms
2021/08/08 19:45:01 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 447.8864ms
2021/08/08 19:45:02 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 396.5558ms
2021/08/08 19:45:02 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 405.9449ms
2021/08/08 19:45:02 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 380.7232ms
2021/08/08 19:45:03 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 370.216ms
2021/08/08 19:45:03 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 419.268ms
2021/08/08 19:45:04 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 352.4136ms
2021/08/08 19:45:04 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 442.2107ms
2021/08/08 19:45:05 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 370.9468ms
2021/08/08 19:45:06 "POST http://<IP_ADDRESS>:21611/api/tus/write HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 924.0961ms
2021/08/08 19:45:06 "POST http://<IP_ADDRESS>:21611/api/catalog/get_follow HTTP/1.1" from <IP_ADDRESS>:56207 - 200 63B in 188.0536ms
2021/08/08 19:45:06 "POST http://<IP_ADDRESS>:21611/api/catalog/get_block HTTP/1.1" from <IP_ADDRESS>:56207 - 200 63B in 180.5847ms
2021/08/08 19:45:06 "POST http://<IP_ADDRESS>:21611/api/catalog/get_replay HTTP/1.1" from <IP_ADDRESS>:56207 - 200 898B in 232.0526ms
2021/08/08 19:45:06 "POST http://<IP_ADDRESS>:21611/api/catalog/get_replay HTTP/1.1" from <IP_ADDRESS>:56207 - 200 898B in 235.0867ms
2021/08/08 19:45:07 "POST http://<IP_ADDRESS>:21611/api/catalog/get_replay HTTP/1.1" from <IP_ADDRESS>:56207 - 200 932B in 187.2807ms
2021/08/08 19:45:07 "POST http://<IP_ADDRESS>:21611/api/lobby/get_vip_status HTTP/1.1" from <IP_ADDRESS>:56207 - 200 61B in 223.561ms
2021/08/08 19:45:08 "POST http://<IP_ADDRESS>:21611/api/item/get_item HTTP/1.1" from <IP_ADDRESS>:56207 - 200 61B in 228.0793ms
2021/08/08 19:45:08 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 233.6574ms
2021/08/08 19:45:08 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 200.1365ms
2021/08/08 19:45:08 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 209.0975ms
2021/08/08 19:45:09 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 231.5874ms
2021/08/08 19:45:09 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 237.855ms
2021/08/08 19:45:09 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 184.1354ms
2021/08/08 19:45:09 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 233.2095ms
2021/08/08 19:45:10 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 228.1558ms
2021/08/08 19:45:10 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 203.5506ms
2021/08/08 19:45:10 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 273.6371ms
2021/08/08 19:45:10 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 202.4744ms
2021/08/08 19:45:11 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 206.0463ms
2021/08/08 19:45:11 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 230.4112ms
2021/08/08 19:45:11 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 196.7701ms
2021/08/08 19:45:11 "POST http://<IP_ADDRESS>:21611/api/statistics/set HTTP/1.1" from <IP_ADDRESS>:56207 - 200 59B in 241.7007ms
2021/08/08 19:45:14 "POST http://<IP_ADDRESS>:21611/api/sys/get_news HTTP/1.1" from <IP_ADDRESS>:56207 - 200 741900B in 1.3231453s

I really like this idea, but never spent enough time to dissect the /statistics/get calls.
Will take a look later today or tomorrow.

Not sure if this helps, but here is a list of /statistics/get calls my account does:
a006ff0fffff
a005ffffffff
a0020100ffff
a0020101ffff
a0020102ffff
a0020103ffff
a0020104ffff
a0020105ffff
a0020106ffff
a0020107ffff
a0020108ffff
a0020109ffff
a002010affff
a002010cffff
a002010dffff
a002010effff
a002010fffff
a0010100feff
a0010100ffff
a0010101feff
a0010101ffff
a0010102feff
a0010102ffff
a0010103feff
a0010103ffff
a0010104feff
a0010104ffff
a0010105feff
a0010105ffff
a0010106feff
a0010106ffff
a0010107feff
a0010107ffff
a0010108feff
a0010108ffff
a0010109feff
a0010109ffff
a001010afeff
a001010affff
a001010cfeff
a001010cffff
a001010dfeff
a001010dffff
a001010efeff
a001010effff
a001010ffeff
a001010fffff

Also need some documentation for https://github.com/optix2000/totsugeki/blob/master/UNSAFE_FEATURES.md


Add c++ runtime support for substring-before and substring-after

[X ] Changes comply with the maintainer guide.
[X ] SHA512s are updated for each updated download.
[ ] The "supports" clause reflects platforms that may be fixed by this new version.
[ ] Any fixed CI baseline entries are removed from that file.
[ ] Any patches that are no longer applied are deleted from the port's directory.
[X ] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[ X] Only one version is added to each modified port's versions file.

Upstream PR link?

"Upstream PR link?"
I don't understand what you mean...

Since it doesn't look like a build fix, these changes should be approved by library authors before being added as a patch to vcpkg.

OK - xqilla is an abandonned or almost abandonned project that I myself added into vcpkg for convenience - my patch improves the performance of the xpath methods substring-before and substring-after

I'm not sure if the vcpkg repo is the right place to host this kind of improvement.

The package is appropriately marked as vcpkg_cmake_config_fixup(PACKAGE_NAME unofficial-xqilla)

This is just labelling the cmake config package. IMO this is part of the porting effort (vcpkg), not of the develpoment effort (extermal).

Add reviewed tag for further review by the vcpkg team.

This kind of change needs to be made by upstream. Please open a PR against upstream.

The problem is that there is no active upstream of this project - I was the one who packaged it for vcpkg - so others might use it - and I try to improve it by submitting patches


Add a Reaction time tester Extension

Is your feature request related to a problem? Please describe.
this feature includes an Reaction time tester Extension.
Describe the solution you'd like
A Reaction Time Tester extension for browsers allows users to measure their reaction speed by clicking a button as soon as the screen turns green. It features a simple popup interface with instructions and displays the reaction time in milliseconds.
What problem is this feature trying to solve?
The Reaction Time Tester extension is designed to solve the problem of individuals wanting to measure and improve their reflexes and response speed in a convenient and engaging way. It provides a simple tool for users to test their reaction times, track their performance, and potentially improve their cognitive and motor skills through repeated practice.
How do we know when the feature is complete?
the user will be able to test their reaction Time

@Sulagna-Dutta-Roy please assign the issue


fix sort on glob

add missing .each on Glob.sort

This also helped with a build issue I was having in a project based on
https://github.com/amirrajan/rubymotion-templates/blob/1e487367e2ab89828fc404b52eabb3a34eff006f/motion/project/template/osx/builder.rb#L60-L67
Thanks @davetrollope and @amirrajan


Updated runtime #51 to 'localhost'

Updated console.log to work on all platforms  from... <IP_ADDRESS>:port  to... localhost:port

Why does deno.listen() default to <IP_ADDRESS>  and deno deno.listenTls()
defaults to <IP_ADDRESS> ?
Are you saying that the addr param is (string | null) ?
Since this is a js file, there is no typing, and no type guarding?
would a default addr param be more appropriate?...
export async function serve(addr = 'localhost:8080') {
On Fri, Jul 9, 2021 at 9:51 AM William Perron @.***>
wrote:

@.**** requested changes on this pull request.
In src/runtime.js
https://github.com/denoland/deployctl/pull/64#discussion_r666965214:

@@ -48,7 +48,7 @@ export async function serve(addr) {
addr = { hostname, port: Number(port) };
}
const listener = Deno.listen(addr);

const host = ${listener.addr.hostname}:${listener.addr.port};

const host = localhost:${listener.addr.port};

The hostname can be set using --addr <IP_ADDRESS>:8080 so instead of
replacing this string here with a hardcoded localhost it would be a good
idea to set a default value for hostname on line 47
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/denoland/deployctl/pull/64#pullrequestreview-703071920,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZAPQYOES2JUD6VZ65TKQLTW35G5ANCNFSM5ACYDPDA
.

I don't know that there's a difference between the defaults of Deno.listen and Deno.listenTls, at least not that I know of. Regardless, <IP_ADDRESS> and <IP_ADDRESS> are functionally both "localhost" anyway, it's just windows that handles them differently. Looking closer at Deno.listen it seems like localhost gets parsed as <IP_ADDRESS> or <IP_ADDRESS> so my proposed solution won't work.
Instead we could probably just assign a new variable specifically for console output that's based off the input directly rather than the listener object.

Trying to work with deployctl in my windows10 vscode is an absolute PITA!
red squigles everwhere,  Anything to do with new URL() is broken in Deno on
Win.
the <IP_ADDRESS> not running in the browser, types issues all over the place...
deno run errors with no module 'deno' in one of the deps?
Too frustrating for me.  I'd love to contribute, but this is a futile
exercise.
Thanks guys ...
On Fri, Jul 9, 2021 at 12:50 PM William Perron @.***>
wrote:

@.**** commented on this pull request.
In src/runtime.js
https://github.com/denoland/deployctl/pull/64#discussion_r667086161:

@@ -42,13 +42,13 @@ class FetchEvent extends Event {

window.FetchEvent = FetchEvent;
-export async function serve(addr) {
+export async function serve(addr = 'localhost:8080') {
unfortunately no, because the output of Deno.listen returns the IP
address behind "localhost" so we need to have this hostname || "localhost"
logic before Deno.listen and keep it in a variable that we can
interpolate for the output on the console.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/denoland/deployctl/pull/64#discussion_r667086161, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZAPQZAXX4K2GOTMUGBWQDTW4SG3ANCNFSM5ACYDPDA
.

Some other time perhaps.

By the way, because of the deno URL issues, Fresh won't run on win10. I
posted an issue there.
On Fri, Jul 9, 2021, 1:15 PM NickD Hrones @.***> wrote:

Trying to work with deployctl in my windows10 vscode is an absolute PITA!
red squigles everwhere,  Anything to do with new URL() is broken in Deno
on Win.
the <IP_ADDRESS> not running in the browser, types issues all over the place...
deno run errors with no module 'deno' in one of the deps?
Too frustrating for me.  I'd love to contribute, but this is a futile
exercise.
Thanks guys ...
On Fri, Jul 9, 2021 at 12:50 PM William Perron @.***>
wrote:

@.**** commented on this pull request.
In src/runtime.js
https://github.com/denoland/deployctl/pull/64#discussion_r667086161:

@@ -42,13 +42,13 @@ class FetchEvent extends Event {

window.FetchEvent = FetchEvent;
-export async function serve(addr) {
+export async function serve(addr = 'localhost:8080') {
unfortunately no, because the output of Deno.listen returns the IP
address behind "localhost" so we need to have this hostname ||
"localhost" logic before Deno.listen and keep it in a variable that we
can interpolate for the output on the console.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/denoland/deployctl/pull/64#discussion_r667086161,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZAPQZAXX4K2GOTMUGBWQDTW4SG3ANCNFSM5ACYDPDA
.


On first connect to newly started ParagonTT, BIND does not get through

start ParagonTT with a suitable configuration (e.g. SLETT)
start the raf_client binary to connect to it
The TML context message is correctly received on ParagonTT side, but the BIND message does not appear

This is a bit strange and it only happens, if ParagonTT is freshly started. It does not happen with the SLETT tool, even though ParagonTT was freshly started.

It is better now, but still happens sometimes. It is not clear, if this problem is on the rs-space side, or on the ParagonTT side. It does not happen, when SLETT is used against ParagonTT. It seems that ParagonTT does not get the TML message, which is really strange as it is sent (verifiable).


Research MQTT for communication between server and resources

We want to have mutual tls authentication between the devices.  Can we do that and also take advantage of something like MQTT?
https://mqtt.org/

MQTT seems like it may be more than what we need.
The original thinking on our architecture is probably less feature rich and less flexible, but I think MQTT would add more unneeded complexity.
We can revisit if anyone objects.

MQTT seems like it may be more than what we need.
The original thinking on our architecture is probably less feature rich and less flexible, but I think MQTT would add more unneeded complexity.
We can revisit if anyone objects.


Helper method store.compareToReport()

I wrote this code:
// pickup the materials that belongs to the 2 "profiles"
List<Material> left = store.select(jobName, jobTimestamp,
			new MetadataPattern.Builder([ "profile": profile1 ]).build()
			)

List<Material> right = store.select(jobName, jobTimestamp,
			new MetadataPattern.Builder([ "profile": profile2 ]).build()
			)

// difference greater than the criteria should be warned
double criteria = 0.0d

// make DiffArtifacts
DiffArtifacts stuffedDiffArtifacts =
	store.makeDiff(left, right,
		new MetadataIgnoredKeys.Builder()
			.ignoreKey("profile")
			.ignoreKey("URL.host")
			.build())
int warnings = stuffedDiffArtifacts.countWarnings(criteria)

// compile HTML report
Path reportFile = store.reportDiffs(jobName, stuffedDiffArtifacts, criteria, jobName.toString() + "-index.html")

This worked, but not very good. This requires programmers to be aware of the internal of materialstore API. Those internals should be hidden to them.
It would be nice if I can write in a more compact syntax as follows, which does the same work as above:
CompletedReport report = store.compareToReport({
    jobName = jobName
    jobTimestamp= jobTimestamp
    metadataPatternLeft = new MetadataPattern.Builder([ "profile": profile1 ]).build()
    metadataPatternRight = new MetadataPattern.Builder([ "profile": profile2 ]).build()
    criteria = 0.0d
    metadataIgnoredKeys = new MetadataIgnoredKeys.Builder()
			.ignoreKey("profile")
			.ignoreKey("URL.host")
			.build()
    reportName: jobName.toString() + "-index.html"
})

This is equivalent to
... store.compareToReport({
    delegate.jobName = jobName
    delegate.jobTimestamp = jobTimestamp
    delegate.metadataPatternLeft ...
})

not worth


Use case for easy-scpi (or not?)

Dear Brian,
I spent a few hours trying to figure out how to use easy-scpi for my use case and I thought you might be interested in my conclusions:

My SCPI instrument has parametrized queries (see this previous issue) so I have to call the SCPI_Instrument.query() method which is not much different than using PyVISA directly.
My instrument has several "channels" (let's say they are channels) of which I use only a subset. Making that subset user-defined at my instrument class instantiation (inheriting from SCPI_Instrument) does not mixes well with easy-scpi parsing of nested method calls of my instrument. This could be done using eval() although this generalization negates the ease-of-use of easy-scpi:

eval(f"my_instrument.{channel_label_as_a_string}.whatever()")

It hides away PyVISA objects and makes manual control of my instrument MUCH MORE USER-FRIENDLY for testing and debugging.
It is one more library in the final requirement file and I have to consider the licensing if I intend to redistribute my work.

Overall, I believe it's still worth interacting with my instrument as a subclass of SCPI_Instrument, mostly for the third point. The class methods are identical to an ab initio class based on PyVISA (assuming some aliases for the query() and write() methods of the PyVISA resource).
The fourth point will have to be considered of course.

Thanks so much for the feedback :)
Indeed, I developed the package for fairly basic use cases and manual control, so tried to keep things as simple as possible.
I'm not actively using the library at the moment, so won't make any changes. However, if you see a way to improve it or incorporate these functionalities, I always welcome a PR.

The license has been updated to MIT or Apache in 0.1.6.


CEO-232 Add unsaved changes warning

Purpose

Show a unsaved changes warning when a user tries to hit "Back" and has unsaved answers.
Related Issues
Closes CEO-232
Submission Checklist

[x] Commits include the JIRA issue and the #review hashtag (e.g. CEO-### #review <comment>)
[x] Code passes linter rules (npm run eslint/clj-kondo --lint src)

Testing

Given I am a user, When I am collecting, And I have unsaved answers, And I try to navigate away, Then I am shown a unsaved changes warning.

Screenshots

Unsaved changes alert

Unsaved confirm alert when using the plot nav

src/js/collection.js
56, instead of maintaining a separate state just check if any questions have been answered.
324, 325, can the events just be called once in didMount and didUnmount?
Check on quit click, change plot click, and beforeunload.

Update with:

Removed isUnsaved and now use _.isEqual to compare the original/new sample values
Added check for hasChanged to the plot navigation functions (see screenshots above)
Moved the add/remove listener fn to componentDidMount/WillUnmount

src/js/collection.js
323, 445, Move your functions to the same place in the code. Above confirmUnsaved looks good.
367, If you are creating a helper function for repeatability, include the check for !this.hasChanged()
385, confirmUnsaved does not take any input.
620, 655, this.setState is async so in this form, you cant guarantee that the value is reset.  Do this synchronously by passing "ignoreCheck" into navToNextPlot.  This is more clear what you are trying to do anyway.

src/js/collection.js
375, ignoreCheck === true is redundant if (ignoreCheck || this.confirmUnsaved())


Why there is no ReLU in FPN output

Hi @roytseng-tw ,
Thanks for the nice work.
I have a question about the FPN code: why there is no ReLU activation in the Post-hoc scale-specific 3x3 convolutions as well as the lateral connection?

First of all, there is no ReLU there in Detectron's FPN implementation either.
Here's my opinion on why:

post-hoc scale-specific 3x3 convs: the outputs are used to extract roi features, so it's better to be dense.
lateral convs: the outputs are fused with the features one-level above, so you want them to have same kind of distribution.

This exact question is answered in the paper already:

There are no non-linearities in these extra layers,
which we have empirically found to have minor impacts

Thanks!


🐛: Footer is not responsive

Title
Footer Responsiveness Issues
Bug
When the viewport width decreases, the footer may be cut off.
Changes
I'll fix this bug by adding a few lines of CSS code to the footer-container to make the footer responsive.
Screenshots 📷

Full Name
Mohd Ahsan Raza Khan
Participant Role
GSSOC, GSOC, Hacktoberfest

Title
Footer Responsiveness Issues
Bug
When the viewport width decreases, the footer may be cut off.
Changes
I'll fix this bug by adding a few lines of CSS code to the footer-container to make the footer responsive.
Screenshots 📷

Full Name
Mohd Ahsan Raza Khan
Participant Role
GSSOC, GSOC, Hacktoberfest

I will assign you do it your best


Add Customizable MetricsReporters to the Measure-Builds Gradle Plugin

Thank you for the great plugin! I find this plugin to be well-designed and modern, making appropriate use of the latest Gradle features. It's a great example of a plugin that leverages Gradle's capabilities effectively.
Overview
This pull request introduces a new feature that allows users to customize the MetricsReporters in the Measure-Builds Gradle plugin. With this change, users can now provide their own implementation of the MetricsReporter interface to handle the reporting of build metrics according to their specific requirements.
Note
Please note that with the removal of the built-in reporting functionality, users will now need to provide their own implementation of MetricsReporter to handle the reporting of build metrics. This change gives users complete control over how and where the metrics are reported.
I understand that I can fork this plugin and maintain my own version with the changes I need. However, I believe that making the plugin customizable and extensible is beneficial for the open-source community. By working together, we can create a better tool that caters to a wider range of use cases and requirements.

@wzieba @malinajirka
Could you take the time to review this PR?

hi @takahirom ! Thank you for the contribution. I agree with your arguments about making this plugin customizable. Initially, we thought it'll be for internal usage only, but that's true it could be nicely extended by introducing custom reporters.
In the following days, I'll review proposed changes 👍

Hi @wzieba
Thank you for considering the introduction of custom reporters!
I have worked on the refactoring and discovered a bug where the users' reports were not properly handled through configuration changes.
I believe the issue is resolved now. I'm referring to the buildScan's buildScanPublished{} extension. However, we're unable to view the buildScan's implementation. It seems that the Action interface is utilized within this extension, which is why I opted for Property.

Hi @wzieba, I've utilized the detekt autocollect task and added a typealias. If you have any feedback or suggestions, please let me know. Feel free to modify my implementation by making changes directly in this PR.

hi @takahirom , thank you for applying the suggestions. I really like this new API and the flexibility that it brings 🙌 .
While experimenting with the new API introduced in this PR though, I've noticed a problem when using it with Groovy. I've prepared an explanation and fix in #43. Please have no hesitation to leave comments and/or suggestions there.
And just a heads-up - I need to perform a few more tests before merging this PR, but I'll be able to do this only early next week. I hope that's ok for you. In any case, if you'd like, you can check a snapshot of the plugin built from the mirror branch (#39) using coordinates like:
plugins {
    id 'com.automattic.android.measure-builds' version '39-1accd072d3d243f9fab57033780d2ab0d53d3692'
}

In the future, I plan to make this plugin available from Gradle Plugin Portal (#42) so it'll be easier.

Thanks again! Looks good with #43 and #44 fixes.


[feature request] views coverage

istanbul is most popular code coverage tool for JavaScript. It cannot test coverage of views, but it is possible and I think not so much hard to implement code coverage for views. It will allow to check if some code branches or entire views (dead views) are not used in project. I have checked code generated by jade. For integration with istanbul this part will need to be changed (to make lines in .jade and .js matching) or additional code will need to be written if (options.instrumentForIstanbul) { ... }, then we save instrumented code in .jade -> .js files, then we load all instrumented js-views to jade's views cache, then run tests with generating coverage, then in lcov report replace .js -> .jade (cheat).

Without doubt, this is very difficult. The nature of Jade/Pug demands two levels of code mapping: jade to js, and jade to html. So far we have mostly focused on the latter.
To achieve the former which is necessary for this ticket, pugjs/jade-code-gen#21 will surely help.


Incorrect reference to log() - should be workspace()?

The note at the top of this page states "... Use the log() expression to write ...", shouldn't that be workspace()?

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

ID: 308fb374-f4c6-74c4-806a-59f863e4040c
Version Independent ID: 9aded2b4-524e-5ece-da83-c8d6eebd0731
Content: app() expression in Azure Monitor log queries - Azure Monitor
Content Source: articles/azure-monitor/logs/app-expression.md
Service: azure-monitor
Sub-service: logs
GitHub Login: @bwren
Microsoft Alias: bwren

@jeanmarc Thanks for your feedback and PR! We will review and provide an update as appropriate.

@jeanmarc Verified and updated the document as required. Thanks again!


Refactor/renable recently visited side tab

Was TW-252.  Known issues:

Limit recent list to current project
Restrict recent list to opt-in routes/actions per controller
Display helper for differences b/w RESTful endpoints and task endpoints.

@LocoDelAssembly if you want to take a stab, I want the functionality/invocation to be something like:
class foo_controller < ApplicationController
   # inherits recent from concern included at DataController
   add_to_recent only: [:show]
end

Closing this it doesn't seem pertinent vs. pinboard and build in recent lists where more applicable.


qsharp.azure.execute waits for 30 seconds, if results are not done, fails

Describe the bug
currently, when submitting a job to Azure Quantum using qsharp.azure, the client waits for 30 seconds and then throws an error if results are not returned.
since most jobs are going to take longer than 30 seconds, would it be an idea to not throw an error but just return immediately with a handle to the job ID? this gives the impression that something went wrong
To Reproduce
Steps to reproduce the behavior:
result = qsharp.azure.execute(RandomNumber, n=3, shots=1000, jobName="Generate 3-bit random number")
Waiting up to 30 seconds for Azure Quantum job to complete...
[10:03:28] Current job status: Waiting
[10:03:34] Current job status: Waiting
[10:03:39] Current job status: Waiting
[10:03:44] Current job status: Waiting
[10:03:49] Current job status: Waiting
Job ID fb4c07fb-d10e-497d-8eed-0f4de47909eb has not completed. To check the status, call %azure.status with the job ID.
---------------------------------------------------------------------------
AzureError                                Traceback (most recent call last)
<ipython-input-33-2bd34ae1e50b> in <module>
      1 qsharp.azure.target("honeywell.hqs-lt-1.0")
----> 2 result = qsharp.azure.execute(AllocateQubitsandApplyDriver, n=3, shots=1000, jobName="Generate 3-bit random number")
~/anaconda3/envs/releasetest/lib/python3.7/site-packages/qsharp/azure.py in execute(op, **params)
    135     """
    136     result = qsharp.client._execute_callable_magic("azure.execute", op, raise_on_stderr=False, **params)
--> 137     if "error_code" in result: raise AzureError(result)
    138     return result
    139
AzureError: {'error_code': 1005, 'error_name': 'JobNotCompleted', 'error_description': 'The specified Azure Quantum job has not yet completed.'}

Expected behavior
Just wait until there is a result

Closing because this is the intended behavior. You can immediately get back the jobId by using azure.submit, or can pass a longer timeout value to azure.execute.
If you have more comments or input feel free to re-open the issue!


New softmax forward kernel in dev/cuda

Did tiny modifications to made codes cleaner and performance better.
OS: Ubuntu 22.04
Device: NVIDIA GeForce RTX 3070 Laptop GPU
Performance
softmax_forward6 (online softmax with cooperative groups)
block_size   32 | time 14.3109 ms | per token 1.75 µs
block_size   64 | time 13.4489 ms | per token 1.64 µs
block_size  128 | time 16.3121 ms | per token 1.99 µs
block_size  256 | time 17.4961 ms | per token 2.14 µs
block_size  512 | time 22.0295 ms | per token 2.69 µs
block_size 1024 | time 22.6308 ms | per token 2.76 µs

softmax_forward8 (online softmax without cgs)
block_size   32 | time 14.2730 ms | per token 1.74 µs
block_size   64 | time 13.2274 ms | per token 1.61 µs
block_size  128 | time 14.4429 ms | per token 1.76 µs
block_size  256 | time 17.3742 ms | per token 2.12 µs
block_size  512 | time 18.2752 ms | per token 2.23 µs
block_size 1024 | time 20.2799 ms | per token 2.48 µs

I agree that __shfl_xor_sync() is way complicated than  __shfl_down_sync().
In my view, if just for reduction, __shfl_down_sync() and __shfl_xor_sync() can properly do the job, and I found that using __shfl_donw_sync() for reduction needs val = __shfl_sync(0xFFFFFFFF, val, 0) for synchronization that __shfl_xor_sync() doesn't. I'm still finding the specific reason behind this.
Here is the comparison. These changes don't improve the kernel that much, but they are not harmful, as least I think that.
Comparison Before and After Changes
Using __shfl_down_sync() with __shfl_sync()
block_size   32 | time 15.2935 ms | per token 1.87 µs
block_size   64 | time 15.2867 ms | per token 1.87 µs
block_size  128 | time 17.3360 ms | per token 2.12 µs
block_size  256 | time 19.3772 ms | per token 2.37 µs
block_size  512 | time 21.4683 ms | per token 2.62 µs
block_size 1024 | time 25.6833 ms | per token 3.14 µs

Using __shfl_xor_sync() without __shfl_sync()
block_size   32 | time 14.1287 ms | per token 1.72 µs
block_size   64 | time 13.2909 ms | per token 1.62 µs
block_size  128 | time 13.8408 ms | per token 1.69 µs
block_size  256 | time 16.6469 ms | per token 2.03 µs
block_size  512 | time 18.0218 ms | per token 2.20 µs
block_size 1024 | time 19.5242 ms | per token 2.38 µs

Thanks for your code review.
I'm just a cuda newbie and trying to participate some open source project to improve myself.
Respect you and your contribution 🙌.

xor shuffle is the way to go if you need the result in all threads. What it implements is a butterfly-shuffle type operation, that ensures that in the end, every thread actually computes the reduction over all values. Its actually not that complicated once you visualize what is going on, e.g., this picture was the first that came up on google. Then, of course, you need to convince yourself that the xor operation actually does create this pattern.
(In contrast, shfl down would have all  the arrows pointing to the left, so that only the leftmost element would actually get the full reduction; that's why you need one more shuffle to broadcast the results)
Because it is so useful but at the same time non-trivial, we actually do have a helper function in common.h that implements exactly this operation: warpReduceSum.
The changes actually give more improvement than I would have guessed  :)

Thank you for your comprehensive explanation. It really helps me understand these warp reduce functions.
I do know llm.c provides warp reduce API in common.h. Considering the reduction in online softmax requires additional comparisons, I haven't used them, which are suitable for more general cases.
BTW, I see that in most warp reduce API implementations, the offset is mostly chagned by offset /=2. Consider the warp size in most scenarios is fixed 32, will it more efficient that using offset >= 1 instead? Because in common sense, bitwise operation is more computationally lightweight than division. Or compiler actually do optimization for us and there is no difference?
Thank you for your reviewing and comment again.

I implement a new softmax forward kernel named softmax_forward_online_kernel9
Kernel 9 using x128 to decently acclerate memory access.
Benchmark
softmax_forward_online_kernel9
block_size   32 | time 14.5774 ms | per token 1.78 µs
block_size   64 | time 7.6058 ms | per token 0.93 µs
block_size  128 | time 5.8938 ms | per token 0.72 µs
block_size  256 | time 5.2009 ms | per token 0.63 µs
block_size  512 | time 4.3161 ms | per token 0.53 µs
block_size 1024 | time 5.4758 ms | per token 0.67 µs

Compares to the others:
softmax_forward_online_kernel8
Kernel 8 is online softmax forward without cooperative groups
block_size   32 | time 14.6022 ms | per token 1.78 µs
block_size   64 | time 14.3459 ms | per token 1.75 µs
block_size  128 | time 15.1699 ms | per token 1.85 µs
block_size  256 | time 19.2555 ms | per token 2.35 µs
block_size  512 | time 19.0878 ms | per token 2.33 µs
block_size 1024 | time 22.3713 ms | per token 2.73 µs

softmax_forward_online_kernel7
Kernel 7 is normal softmax optimized for very large C.
block_size   32 | time 21.3318 ms | per token 2.60 µs
block_size   64 | time 29.1571 ms | per token 3.56 µs
block_size  128 | time 38.7531 ms | per token 4.73 µs
block_size  256 | time 44.2141 ms | per token 5.40 µs
block_size  512 | time 48.5004 ms | per token 5.92 µs
block_size 1024 | time 50.4821 ms | per token 6.16 µs

softmax_forward_online_kernel6
Kernel 6 is online softmax forward with cooperative groups
block_size   32 | time 14.7439 ms | per token 1.80 µs
block_size   64 | time 14.3677 ms | per token 1.75 µs
block_size  128 | time 17.9260 ms | per token 2.19 µs
block_size  256 | time 20.7341 ms | per token 2.53 µs
block_size  512 | time 21.6989 ms | per token 2.65 µs
block_size 1024 | time 22.9575 ms | per token 2.80 µs


feat: add cloud logs policies

Description
Add cloud logs policies

Release required?
Add cloud logs policies

[ ] No release
[ ] Patch release (x.x.X)
[x] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

This time PR failed in EN integration code -
2024/10/25 09:00:55 Terraform apply | module.observability_instances.module.cloud_logs[0].ibm_logs_outgoing_webhook.en_integration["1"]: Creation complete after 4s [id=eu-de/e765aee9-9bd6-45f5-9493-cf0b875ffb80/968730df-7b2e-45fa-97bd-4155f2f61789]
 2024/10/25 09:00:55 Terraform apply |
 2024/10/25 09:00:55 Terraform apply | Error: ---
 2024/10/25 09:00:55 Terraform apply | id: terraform-693866e6
 2024/10/25 09:00:55 Terraform apply | summary: 'CreateOutgoingWebhookWithContext failed: No authentication information in
 2024/10/25 09:00:55 Terraform apply |   RequestContext'
 2024/10/25 09:00:55 Terraform apply | severity: error
 2024/10/25 09:00:55 Terraform apply | resource: ibm_logs_outgoing_webhook
 2024/10/25 09:00:55 Terraform apply | operation: create
 2024/10/25 09:00:55 Terraform apply | component:
 2024/10/25 09:00:55 Terraform apply |   name: github.com/IBM-Cloud/terraform-provider-ibm
 2024/10/25 09:00:55 Terraform apply |   version: 1.70.1
 2024/10/25 09:00:55 Terraform apply | ---
 2024/10/25 09:00:55 Terraform apply |
 2024/10/25 09:00:55 Terraform apply |
 2024/10/25 09:00:55 Terraform apply |   with module.observability_instances.module.cloud_logs[0].ibm_logs_outgoing_webhook.en_integration["0"],

I suggest to support creating multiple policies by using 1 input variable that is a list of objects

sure, will update the code accordingly.

/run pipeline

/run pipeline

PR failed with EN related issue -
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: ╷
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │ Error: ---
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │ id: terraform-693866e6
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │ summary: 'CreateOutgoingWebhookWithContext failed: No authentication information in
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │   RequestContext'
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │ severity: error
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │ resource: ibm_logs_outgoing_webhook
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │ operation: create
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │ component:
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │   name: github.com/IBM-Cloud/terraform-provider-ibm
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │   version: 1.70.1
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │ ---
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │   with module.observability_instances.module.cloud_logs[0].ibm_logs_outgoing_webhook.en_integration["1"],
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │   on ../../modules/cloud_logs/main.tf line 109, in resource "ibm_logs_outgoing_webhook" "en_integration":
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │  109: resource "ibm_logs_outgoing_webhook" "en_integration" {
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: │
TestRunUpgradeExample 2024-10-29T10:28:06Z logger.go:66: ╵
TestRunUpgradeExample 2024-10-29T10:28:06Z retry.go:99: Returning due to fatal error: FatalError{Underlying: error while running command: exit status 1;

re-running...

:tada: This PR is included in version 3.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Use suspense everywhere!

Close #49

I'm not sure this is worth it but I will merge it nonetheless


Browserify-support

I would love to use this library but I'm using Browserify, which isn't supported properly at the moment. I'm interested in creating a pull request for support, but in order to do that I would need to know a bit more about how the code functions.
When I tried it, it attempted loading the _JailedSite.js file using a script-tag. I assume this is done inside the iframe to allow access to it..? With Browserify this doesn't work because Browserify combines all code into one file, and that's the only file served publicly.
Would it be possible to do this without loading an extra file? Probably it would mean having _JailedSite.js return a function which will then be executed when the iframe loads.
As you can see, I'm clueless here so it would be great if you could briefly outline the way this script works and we could go from there.

There was a related discussion: https://github.com/asvd/jailed/issues/6
For now we came up with the following solution: bundle jailed.js into the application, put all other files shipped with jailed along with the bundle.
I'm going to play with bundling and proably figure out something more elegant later.

Yeah, that should work. Being able to rely completely on Browserify would be great though, so if you can think of a way to avoid this solution, that'd be awesome.

The problem is that there is some code loaded by the worker, and if not keeping it in a separate file, I would have to keep it as a string inside the main code, which is not very convenient.

Is it not possible to inject a simple script into the iframe, which will then call a function (doing what _JailedSite.js does) from the parent window (window.parent.jailedSiteCallback())?

The worker cannot access the code of the iframe. I can only send a message with a string, and then evaluate it on the opposite side.
Currently I keep the minimal amount of code for the worker which is needed to setup the initial communication:
https://github.com/asvd/jailed/blob/master/lib/_frame.js#L29
Then it loads _pluginWebWorker.js and sets up itself.

So I did implement such feature in my fork as well as some other improves like promises support. You may not want to just merge it but you can check my build process and may be reuse something from it
https://github.com/huston007/jailed

@asvd do you think you can add browserify support? Bundling is getting increasingly common and shipping it by the side feels like a hack


ENH: add clean up old test databases task

There already is a sake dev/tests/cleanupdb which does the same thing :(


Import c31559f956: formatting (by Caitlyn)

This is an automated proposal to look at a commit made by Caitlyn and import it into Overte

Commit:
c31559f956eaf515d0cc9f93e3c28dbc62f1f459

Author:
Caitlyn

Date:
Thu, 27 Feb 2020 01:32

formatting

Stats:

Filename
Stats
Lines
Added
Removed
Lines in blame

libraries/entities-renderer/src/EntityTreeRenderer.cpp

1
0
1
⚠ 0

1 files
-
1
0
1
0

To work on this, please assign the issue to yourself, then look at the commit and decide whether this would be a good addition to Overte.

If the commit is useful, tag it with "Tivoli: Keep", and keep it open until it's merged.
If the commit is not useful, tag it with "Tivoli: Discard", and close it.
If the commit is not useful right now, but might be later, tag it with "Tivoli: Maybe later", and close it.
If it's hard to decide, tag it with "Tivoli: Discuss", and keep it open.

Useful commits should be submitted as a PR against Overte. Tag this issue in PR, so that it's automatically closed once the PR is merged.
You can cherry-pick this issue with this command:
git cherry-pick c31559f956eaf515d0cc9f93e3c28dbc62f1f459

whitespace


Circular dependency is not spotted for code generated providers

To Reproduce
@riverpod
int foo(FooRef ref) {
  ref.watch(barProvider);
  return 0;
}

@riverpod
int bar(BarRef ref) {
  ref.watch(fooProvider);
  return 0;
}

This can be produced using riverpod 2.4.3

How does that differ from non generated code?

Yeah that's on purpose actually. The non-code-gen error is more of a Dart issue than a Riverpod feature. Codegen voluntarily solves this
It's quite useful when providers have arguments. It's not uncommon for a provider to watch itself with different args


I found this error about config.py of WISDOM

I can run these dataset(HAR)
But I met this error when I run this on WISDOM  using CoTMix

cuz the WISDOM class hasn't step_size and lr_decay in the config.py
one more error:

cuz the size of trg isn't equal to the size of src in the last batch.

you can set drop_last = True

@Onenormler Were you able to solve the step_size and lr_decay error?


remove the hack added in #498 to avoid InitError

closes #499

Codecov Report
Patch coverage has no change and project coverage change: -5.02 :warning:

Comparison is base (b61b39b) 90.92% compared to head (0135ecd) 85.91%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #500      +/-   ##
==========================================
- Coverage   90.92%   85.91%   -5.02%
==========================================
  Files          10       10
  Lines        2975     2882      -93
==========================================
- Hits         2705     2476     -229
- Misses        270      406     +136

Impacted Files
Coverage Δ

src/toplevel/virtualprocess.jl
96.49% <ø> (+0.24%)
:arrow_up:

... and 7 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[Labextention] After DaskLabextention powered cluster was shutted down, newly created cluster will crash

Symptoms:
---------------------------------------------------------------------------
KilledWorker                              Traceback (most recent call last)
<ipython-input-6-560a518ccf84> in <module>
      2
      3 start = time.time()
----> 4 output = processor.run_uproot_job(fileset,
      5                                 treename = 'Events',
      6                                 processor_instance = SignalProcessor(),

/opt/conda/lib/python3.8/site-packages/coffea/processor/executor.py in run_uproot_job(fileset, treename, processor_instance, executor, executor_args, pre_executor, pre_args, chunksize, maxchunks, metadata_cache)
   1056             }
   1057             pre_args.update(pre_arg_override)
-> 1058             pre_executor(to_get, metadata_fetcher, out, **pre_args)
   1059             while out:
   1060                 item = out.pop()

/opt/conda/lib/python3.8/site-packages/coffea/processor/executor.py in dask_executor(items, function, accumulator, **kwargs)
    658         # FIXME: fancy widget doesn't appear, have to live with boring pbar
    659         progress(work, multi=True, notebook=False)
--> 660     accumulator += _maybe_decompress(work.result())
    661     return accumulator
    662

/opt/conda/lib/python3.8/site-packages/distributed/client.py in result(self, timeout)
    223         if self.status == "error":
    224             typ, exc, tb = result
--> 225             raise exc.with_traceback(tb)
    226         elif self.status == "cancelled":
    227             raise result

KilledWorker: ('_get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-77', <Worker 'tls://red-c0805.unl.edu:32779', name: htcondor--16286262.0--, memory: 0, processing: 23>)

Logs:
istributed.scheduler - INFO - Register worker <Worker 'tls://red-c0805.unl.edu:32779', name: htcondor--16286262.0--, memory: 0, processing: 0>
distributed.scheduler - INFO - Starting worker compute stream, tls://red-c0805.unl.edu:32779
distributed.core - INFO - Starting established connection
distributed.scheduler - INFO - Remove worker <Worker 'tls://red-c0805.unl.edu:32778', name: htcondor--16286261.0--, memory: 0, processing: 166>
distributed.core - INFO - Removing comms to tls://red-c0805.unl.edu:32778
distributed.scheduler - INFO - Register worker <Worker 'tls://red-c0805.unl.edu:32778', name: htcondor--16286261.0--, memory: 0, processing: 0>
distributed.scheduler - INFO - Starting worker compute stream, tls://red-c0805.unl.edu:32778
distributed.core - INFO - Starting established connection
distributed.scheduler - INFO - Remove worker <Worker 'tls://red-c0805.unl.edu:32779', name: htcondor--16286262.0--, memory: 0, processing: 23>
distributed.core - INFO - Removing comms to tls://red-c0805.unl.edu:32779
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-145 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-121 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-89 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-9 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-1 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-143 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-127 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-23 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-93 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-101 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-77 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-125 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-21 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-157 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Task _get_metadata-e927e5c7-8348-4606-9e90-8f437a3e2ce8-133 marked as failed because 3 workers died while trying to run it
distributed.scheduler - INFO - Remove worker <Worker 'tls://red-c0805.unl.edu:32780', name: htcondor--16286263.0--, memory: 0, processing: 0>
distributed.core - INFO - Removing comms to tls://red-c0805.unl.edu:32780
distributed.scheduler - INFO - Remove worker <Worker 'tls://red-c0805.unl.edu:32781', name: htcondor--16286264.0--, memory: 0, processing: 0>
distributed.core - INFO - Removing comms to tls://red-c0805.unl.edu:32781
distributed.scheduler - INFO - Retire worker names (4, 5, 6, 7)
distributed.deploy.adaptive - INFO - Retiring workers [4, 5, 6, 7]
distributed.scheduler - INFO - Retire worker names ('htcondor--16286261.0--', 'htcondor--16286265.0--', 'htcondor--16286264.0--', 'htcondor--16286263.0--')
distributed.scheduler - INFO - Retire workers {<Worker 'tls://red-c0805.unl.edu:32778', name: htcondor--16286261.0--, memory: 0, processing: 0>}
distributed.scheduler - INFO - Remove worker <Worker 'tls://red-c0805.unl.edu:32778', name: htcondor--16286261.0--, memory: 0, processing: 0>
distributed.core - INFO - Removing comms to tls://red-c0805.unl.edu:32778
distributed.scheduler - INFO - Remove worker <Worker 'tls://oksana-2eshadura-40cern-2ech.dask-worker.coffea.casa:8788', name: kubernetes-worker, memory: 0, processing: 0>
distributed.core - INFO - Removing comms to tls://oksana-2eshadura-40cern-2ech.dask-worker.coffea.casa:8788
distributed.scheduler - INFO - Lost all workers

This is issue is reproducible just with a new  Dask cluster started from scratch

Problem is resolved by carefully checking version dask/distributed both on scheduler and workers.


Build Fails When Installed As Another Module's Dependancy

The build does not finish when htmlbars is a dependency of another npm module. It fails with this error:
ENOENT, no such file or directory '/Users/adammiller1/rebound/node_modules/htmlbars/.git/HEAD'
Error: ENOENT, no such file or directory '/Users/adammiller1/rebound/node_modules/htmlbars/.git/HEAD'
    at Object.fs.openSync (fs.js:432:18)
    at Object.fs.readFileSync (fs.js:289:15)
    at getRevision (/Users/adammiller1/rebound/node_modules/htmlbars/packages/index.js:12:25)
    at Object.<anonymous> (/Users/adammiller1/rebound/node_modules/htmlbars/packages/index.js:26:13)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)

It is because of the getRevision() function here:
https://github.com/tildeio/htmlbars/blob/master/packages/index.js#L26
When installed into the node_modules folder as a dependancy, npm does not keep the .git directory and this function fails hard.

Ember includes this as a dep of a dep (via emberjs-build) and it does work properly.
Can you provide more details? How have you referenced it in the package.json's of the various projects?  How are you requiring? etc....

But we should definitely make the getRevision function not blow up if .git isn't found.

What versions of node is ember tested against?

Also, the main entry point is dist/cjs/htmlbars.js (which is a file generated in npm prepublish), why require htmlbars/packages or htmlbars/packages/index?

@epicmiller - The Ember test suite runs against Node 0.11 I believe.

Let me update node and npm to the latest and see if it fixes things.
I'm pulling it down at a specific commit and it fails:
"dependencies": {
    "htmlbars": "git://github.com/tildeio/htmlbars.git#513c91780d0abb2fc03c91d34e54504490b103e5"
} ```

It will work fine if I use the version in npm

HTMLBars is not designed to be required via git as you have setup here.  The main entry point (which is used when you do something like this: var htmlbars = require('htmlbars');) is dist/cjs/htmlbars.js which is a file that is generated as part of npm prepublish.

npm install (for some reason) calls npm prepublish too: https://github.com/npm/npm/issues/3059. So if all of its other dependancies are install it will actually generate the /dist directory.
I suppose it would just be a nice-to-have, being able to test htmlbars integration at any specific commit :) That was more important when it was more in flux though I suppose. Feel free to close this if you think its an unnecessary feature!

'npm install' iwill call the prepublish script only within the htmlbars repo. If you have htmlbars as a dep, then call npm install on that parent repo the htmlbars prepublish is not called.

Never mind then, you learn something new every day!