mongodb error

Hi,
I have been trying to deploy using  DSA_USER=$(id -u):$(id -g) docker-compose up. I am in an dind setting where the host docker is ubuntu 22.
I keep having this error about mongodb connectivity. Here are the logs:
dsa_girder
dsa-girder-1     | id: ‘112’: no such user
dsa-girder-1     | The user `ubuntu' is already a member of `root'.
dsa-girder-1     | net.ipv4.conf.eth0.route_localnet = 1
dsa-girder-1     | iptables v1.8.4 (legacy): Bad IP address ";;"
dsa-girder-1     |
dsa-girder-1     | Try `iptables -h' or 'iptables --help' for more information.
dsa-girder-1     | ==== Pre-Provisioning ===
dsa-girder-1     | ==== Provisioning ===
dsa-girder-1     | Running in mode: production
dsa-girder-1     | Connecting to MongoDB: mongodb://mongodb:27017/girder?socketTimeoutMS=3600000
dsa-girder-1     | Traceback (most recent call last):
dsa-girder-1     |   File "/opt/digital_slide_archive/devops/dsa/provision.py", line 604, in
dsa-girder-1     |     configureServer()
dsa-girder-1     |   File "/opt/girder/girder/utility/server.py", line 80, in configureServer
dsa-girder-1     |     api_main.addApiToNode(root)
dsa-girder-1     |   File "/opt/girder/girder/api/api_main.py", line 20, in addApiToNode
dsa-girder-1     |     _addV1ToNode(node.api)
dsa-girder-1     |   File "/opt/girder/girder/api/api_main.py", line 30, in _addV1ToNode
dsa-girder-1     |     node.v1.assetstore = assetstore.Assetstore()
dsa-girder-1     |   File "/opt/girder/girder/api/v1/assetstore.py", line 23, in __init__
dsa-girder-1     |     self._model = AssetstoreModel()
dsa-girder-1     |   File "/opt/girder/girder/models/model_base.py", line 76, in __call__
dsa-girder-1     |     cls._instance = super().__call__(*args, **kwargs)
dsa-girder-1     |   File "/opt/girder/girder/models/model_base.py", line 109, in __init__
dsa-girder-1     |     self.reconnect()
dsa-girder-1     |   File "/opt/girder/girder/models/model_base.py", line 116, in reconnect
dsa-girder-1     |     db_connection = getDbConnection()
dsa-girder-1     |   File "/opt/girder/girder/models/__init__.py", line 97, in getDbConnection
dsa-girder-1     |     client.server_info()
dsa-girder-1     |   File "/opt/venv/lib/python3.9/site-packages/pymongo/mongo_client.py", line 2086, in server_info
dsa-girder-1     |     return self.admin.command(
dsa-girder-1     |   File "/opt/venv/lib/python3.9/site-packages/pymongo/database.py", line 827, in command
dsa-girder-1     |     with self.__client._socket_for_reads(read_preference, session) as (sock_info, secondary_ok):
dsa-girder-1     |   File "/.pyenv/versions/3.9.16/lib/python3.9/contextlib.py", line 119, in __enter__
dsa-girder-1     |     return next(self.gen)
dsa-girder-1     |   File "/opt/venv/lib/python3.9/site-packages/pymongo/mongo_client.py", line 1478, in _socket_for_reads
dsa-girder-1     |     server = self._select_server(read_preference, session)
dsa-girder-1     |   File "/opt/venv/lib/python3.9/site-packages/pymongo/mongo_client.py", line 1436, in _select_server
dsa-girder-1     |     server = topology.select_server(server_selector)
dsa-girder-1     |   File "/opt/venv/lib/python3.9/site-packages/pymongo/topology.py", line 250, in select_server
dsa-girder-1     |     return random.choice(self.select_servers(selector, server_selection_timeout, address))
dsa-girder-1     |   File "/opt/venv/lib/python3.9/site-packages/pymongo/topology.py", line 211, in select_servers
dsa-girder-1     |     server_descriptions = self._select_servers_loop(selector, server_timeout, address)
dsa-girder-1     |   File "/opt/venv/lib/python3.9/site-packages/pymongo/topology.py", line 226, in _select_servers_loop
dsa-girder-1     |     raise ServerSelectionTimeoutError(
dsa-girder-1     | pymongo.errors.ServerSelectionTimeoutError: mongodb:27017: [Errno -3] Temporary failure in name resolution, Timeout: 20.0s, Topology Description: ]>

dsa_mongodb
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.344+00:00"},"s":"I",  "c":"CONTROL",  "id":23285,   "ctx":"main","msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.345+00:00"},"s":"I",  "c":"NETWORK",  "id":4915701, "ctx":"main","msg":"Initialized wire specification","attr":{"spec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":17},"incomingInternalClient":{"minWireVersion":0,"maxWireVersion":17},"outgoing":{"minWireVersion":6,"maxWireVersion":17},"isInternalClient":true}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.346+00:00"},"s":"I",  "c":"NETWORK",  "id":4648601, "ctx":"main","msg":"Implicit TCP FastOpen unavailable. If TCP FastOpen is required, set tcpFastOpenServer, tcpFastOpenClient, and tcpFastOpenQueueSize."}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.347+00:00"},"s":"I",  "c":"REPL",     "id":5123008, "ctx":"main","msg":"Successfully registered PrimaryOnlyService","attr":{"service":"TenantMigrationDonorService","namespace":"config.tenantMigrationDonors"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.347+00:00"},"s":"I",  "c":"REPL",     "id":5123008, "ctx":"main","msg":"Successfully registered PrimaryOnlyService","attr":{"service":"TenantMigrationRecipientService","namespace":"config.tenantMigrationRecipients"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.347+00:00"},"s":"I",  "c":"REPL",     "id":5123008, "ctx":"main","msg":"Successfully registered PrimaryOnlyService","attr":{"service":"ShardSplitDonorService","namespace":"config.tenantSplitDonors"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.347+00:00"},"s":"I",  "c":"CONTROL",  "id":5945603, "ctx":"main","msg":"Multi threading initialized"}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.348+00:00"},"s":"I",  "c":"CONTROL",  "id":4615611, "ctx":"initandlisten","msg":"MongoDB starting","attr":{"pid":1,"port":27017,"dbPath":"/data/db","architecture":"64-bit","host":"6289af38e480"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.348+00:00"},"s":"I",  "c":"CONTROL",  "id":23403,   "ctx":"initandlisten","msg":"Build Info","attr":{"buildInfo":{"version":"6.0.6","gitVersion":"26b4851a412cc8b9b4a18cdb6cd0f9f642e06aa7","openSSLVersion":"OpenSSL 3.0.2 15 Mar 2022","modules":[],"allocator":"tcmalloc","environment":{"distmod":"ubuntu2204","distarch":"x86_64","target_arch":"x86_64"}}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.348+00:00"},"s":"I",  "c":"CONTROL",  "id":51765,   "ctx":"initandlisten","msg":"Operating System","attr":{"os":{"name":"Ubuntu","version":"22.04"}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.348+00:00"},"s":"I",  "c":"CONTROL",  "id":21951,   "ctx":"initandlisten","msg":"Options set by command line","attr":{"options":{"net":{"bindIp":"*","maxIncomingConnections":1000},"storage":{"journal":{"enabled":false}}}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.348+00:00"},"s":"W",  "c":"STORAGE",  "id":22271,   "ctx":"initandlisten","msg":"Detected unclean shutdown - Lock file is not empty","attr":{"lockFile":"/data/db/mongod.lock"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.348+00:00"},"s":"I",  "c":"STORAGE",  "id":22270,   "ctx":"initandlisten","msg":"Storage engine to use detected by data files","attr":{"dbpath":"/data/db","storageEngine":"wiredTiger"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.348+00:00"},"s":"W",  "c":"STORAGE",  "id":22302,   "ctx":"initandlisten","msg":"Recovering data from the last clean checkpoint."}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.348+00:00"},"s":"I",  "c":"STORAGE",  "id":22315,   "ctx":"initandlisten","msg":"Opening WiredTiger","attr":{"config":"create,cache_size=63219M,session_max=33000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,remove=true,path=journal,compressor=snappy),builtin_extension_config=(zstd=(compression_level=6)),file_manager=(close_idle_time=600,close_scan_interval=10,close_handle_minimum=2000),statistics_log=(wait=0),json_output=(error,message),verbose=[recovery_progress:1,checkpoint_progress:1,compact_progress:1,backup:0,checkpoint:0,compact:0,evict:0,history_store:0,recovery:0,rts:0,salvage:0,tiered:0,timestamp:0,transaction:0,verify:0,log:0],,log=(enabled=false),"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.933+00:00"},"s":"I",  "c":"STORAGE",  "id":4795906, "ctx":"initandlisten","msg":"WiredTiger opened","attr":{"durationMillis":585}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.933+00:00"},"s":"I",  "c":"RECOVERY", "id":23987,   "ctx":"initandlisten","msg":"WiredTiger recoveryTimestamp","attr":{"recoveryTimestamp":{"$timestamp":{"t":0,"i":0}}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.939+00:00"},"s":"W",  "c":"CONTROL",  "id":22120,   "ctx":"initandlisten","msg":"Access control is not enabled for the database. Read and write access to data and configuration is unrestricted","tags":["startupWarnings"]}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:36:27.942+00:00"},"s":"I",  "c":"NETWORK",  "id":4915702, "ctx":"initandlisten","msg":"Updated wire specification","attr":{"oldSpec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":17},"incomingInternalClient":{"minWireVersion":0,"maxWireVersion":17},"outgoing":{"minWireVersion":6,"maxWireV
(mil) root@aida-ceacam5-mil-353632:/home/digital_slide_archive/devops/dsa# docker-compose logs mongodb
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:32.739+00:00"},"s":"I",  "c":"CONTROL",  "id":23285,   "ctx":"main","msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:32.741+00:00"},"s":"I",  "c":"NETWORK",  "id":4915701, "ctx":"main","msg":"Initialized wire specification","attr":{"spec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":17},"incomingInternalClient":{"minWireVersion":0,"maxWireVersion":17},"outgoing":{"minWireVersion":6,"maxWireVersion":17},"isInternalClient":true}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:32.741+00:00"},"s":"I",  "c":"NETWORK",  "id":4648601, "ctx":"main","msg":"Implicit TCP FastOpen unavailable. If TCP FastOpen is required, set tcpFastOpenServer, tcpFastOpenClient, and tcpFastOpenQueueSize."}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:32.742+00:00"},"s":"I",  "c":"REPL",     "id":5123008, "ctx":"main","msg":"Successfully registered PrimaryOnlyService","attr":{"service":"TenantMigrationDonorService","namespace":"config.tenantMigrationDonors"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:32.742+00:00"},"s":"I",  "c":"REPL",     "id":5123008, "ctx":"main","msg":"Successfully registered PrimaryOnlyService","attr":{"service":"TenantMigrationRecipientService","namespace":"config.tenantMigrationRecipients"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:32.742+00:00"},"s":"I",  "c":"REPL",     "id":5123008, "ctx":"main","msg":"Successfully registered PrimaryOnlyService","attr":{"service":"ShardSplitDonorService","namespace":"config.tenantSplitDonors"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:32.742+00:00"},"s":"I",  "c":"CONTROL",  "id":5945603, "ctx":"main","msg":"Multi threading initialized"}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:32.743+00:00"},"s":"I",  "c":"CONTROL",  "id":4615611, "ctx":"initandlisten","msg":"MongoDB starting","attr":{"pid":1,"port":27017,"dbPath":"/data/db","architecture":"64-bit","host":"62f37aa2c0fa"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:32.743+00:00"},"s":"I",  "c":"CONTROL",  "id":23403,   "ctx":"initandlisten","msg":"Build Info","attr":{"buildInfo":{"version":"6.0.6","gitVersion":"26b4851a412cc8b9b4a18cdb6cd0f9f642e06aa7","openSSLVersion":"OpenSSL 3.0.2 15 Mar 2022","modules":[],"allocator":"tcmalloc","environment":{"distmod":"ubuntu2204","distarch":"x86_64","target_arch":"x86_64"}}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:32.743+00:00"},"s":"I",  "c":"CONTROL",  "id":51765,   "ctx":"initandlisten","msg":"Operating System","attr":{"os":{"name":"Ubuntu","version":"22.04"}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:32.743+00:00"},"s":"I",  "c":"CONTROL",  "id":21951,   "ctx":"initandlisten","msg":"Options set by command line","attr":{"options":{"net":{"bindIp":"*","maxIncomingConnections":1000},"storage":{"journal":{"enabled":false}}}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:32.744+00:00"},"s":"I",  "c":"STORAGE",  "id":22315,   "ctx":"initandlisten","msg":"Opening WiredTiger","attr":{"config":"create,cache_size=63219M,session_max=33000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,remove=true,path=journal,compressor=snappy),builtin_extension_config=(zstd=(compression_level=6)),file_manager=(close_idle_time=600,close_scan_interval=10,close_handle_minimum=2000),statistics_log=(wait=0),json_output=(error,message),verbose=[recovery_progress:1,checkpoint_progress:1,compact_progress:1,backup:0,checkpoint:0,compact:0,evict:0,history_store:0,recovery:0,rts:0,salvage:0,tiered:0,timestamp:0,transaction:0,verify:0,log:0],,log=(enabled=false),"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.399+00:00"},"s":"I",  "c":"STORAGE",  "id":4795906, "ctx":"initandlisten","msg":"WiredTiger opened","attr":{"durationMillis":655}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.399+00:00"},"s":"I",  "c":"RECOVERY", "id":23987,   "ctx":"initandlisten","msg":"WiredTiger recoveryTimestamp","attr":{"recoveryTimestamp":{"$timestamp":{"t":0,"i":0}}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.465+00:00"},"s":"W",  "c":"CONTROL",  "id":22120,   "ctx":"initandlisten","msg":"Access control is not enabled for the database. Read and write access to data and configuration is unrestricted","tags":["startupWarnings"]}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.465+00:00"},"s":"I",  "c":"STORAGE",  "id":20320,   "ctx":"initandlisten","msg":"createCollection","attr":{"namespace":"admin.system.version","uuidDisposition":"provided","uuid":{"uuid":{"$uuid":"a61fe108-dc79-42c4-b3d5-b0ec4083a60f"}},"options":{"uuid":{"$uuid":"a61fe108-dc79-42c4-b3d5-b0ec4083a60f"}}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.511+00:00"},"s":"I",  "c":"INDEX",    "id":20345,   "ctx":"initandlisten","msg":"Index build: done building","attr":{"buildUUID":null,"collectionUUID":{"uuid":{"$uuid":"a61fe108-dc79-42c4-b3d5-b0ec4083a60f"}},"namespace":"admin.system.version","index":"_id_","ident":"index-1--8030490562494532539","collectionIdent":"collection-0--8030490562494532539","commitTimestamp":null}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.511+00:00"},"s":"I",  "c":"REPL",     "id":20459,   "ctx":"initandlisten","msg":"Setting featureCompatibilityVersion","attr":{"newVersion":"6.0"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.511+00:00"},"s":"I",  "c":"REPL",     "id":5853300, "ctx":"initandlisten","msg":"current featureCompatibilityVersion value","attr":{"featureCompatibilityVersion":"6.0","context":"setFCV"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.511+00:00"},"s":"I",  "c":"NETWORK",  "id":4915702, "ctx":"initandlisten","msg":"Updated wire specification","attr":{"oldSpec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":17},"incomingInternalClient":{"minWireVersion":0,"maxWireVersion":17},"outgoing":{"minWireVersion":6,"maxWireVersion":17},"isInternalClient":true},"newSpec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":17},"incomingInternalClient":{"minWireVersion":17,"maxWireVersion":17},"outgoing":{"minWireVersion":17,"maxWireVersion":17},"isInternalClient":true}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.511+00:00"},"s":"I",  "c":"NETWORK",  "id":4915702, "ctx":"initandlisten","msg":"Updated wire specification","attr":{"oldSpec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":17},"incomingInternalClient":{"minWireVersion":17,"maxWireVersion":17},"outgoing":{"minWireVersion":17,"maxWireVersion":17},"isInternalClient":true},"newSpec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":17},"incomingInternalClient":{"minWireVersion":17,"maxWireVersion":17},"outgoing":{"minWireVersion":17,"maxWireVersion":17},"isInternalClient":true}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.511+00:00"},"s":"I",  "c":"REPL",     "id":5853300, "ctx":"initandlisten","msg":"current featureCompatibilityVersion value","attr":{"featureCompatibilityVersion":"6.0","context":"startup"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.511+00:00"},"s":"I",  "c":"STORAGE",  "id":5071100, "ctx":"initandlisten","msg":"Clearing temp directory"}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.511+00:00"},"s":"I",  "c":"CONTROL",  "id":20536,   "ctx":"initandlisten","msg":"Flow Control is enabled on this deployment"}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.511+00:00"},"s":"I",  "c":"FTDC",     "id":20625,   "ctx":"initandlisten","msg":"Initializing full-time diagnostic data capture","attr":{"dataDirectory":"/data/db/diagnostic.data"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.514+00:00"},"s":"I",  "c":"STORAGE",  "id":20320,   "ctx":"initandlisten","msg":"createCollection","attr":{"namespace":"local.startup_log","uuidDisposition":"generated","uuid":{"uuid":{"$uuid":"ad633a7c-380a-4b08-9a26-1a3d8008e274"}},"options":{"capped":true,"size":10485760}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.560+00:00"},"s":"I",  "c":"INDEX",    "id":20345,   "ctx":"initandlisten","msg":"Index build: done building","attr":{"buildUUID":null,"collectionUUID":{"uuid":{"$uuid":"ad633a7c-380a-4b08-9a26-1a3d8008e274"}},"namespace":"local.startup_log","index":"_id_","ident":"index-3--8030490562494532539","collectionIdent":"collection-2--8030490562494532539","commitTimestamp":null}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.560+00:00"},"s":"I",  "c":"REPL",     "id":6015317, "ctx":"initandlisten","msg":"Setting new configuration state","attr":{"newState":"ConfigReplicationDisabled","oldState":"ConfigPreStart"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.560+00:00"},"s":"I",  "c":"STORAGE",  "id":22262,   "ctx":"initandlisten","msg":"Timestamp monitor starting"}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.561+00:00"},"s":"I",  "c":"CONTROL",  "id":20712,   "ctx":"LogicalSessionCacheReap","msg":"Sessions collection is not set up; waiting until next sessions reap interval","attr":{"error":"NamespaceNotFound: config.system.sessions does not exist"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.561+00:00"},"s":"I",  "c":"STORAGE",  "id":20320,   "ctx":"LogicalSessionCacheRefresh","msg":"createCollection","attr":{"namespace":"config.system.sessions","uuidDisposition":"generated","uuid":{"uuid":{"$uuid":"0375342f-9f31-4e83-8990-8aac3b341fc8"}},"options":{}}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.561+00:00"},"s":"I",  "c":"NETWORK",  "id":23015,   "ctx":"listener","msg":"Listening on","attr":{"address":"/tmp/mongodb-27017.sock"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.561+00:00"},"s":"I",  "c":"NETWORK",  "id":23015,   "ctx":"listener","msg":"Listening on","attr":{"address":"<IP_ADDRESS>"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.561+00:00"},"s":"I",  "c":"NETWORK",  "id":23016,   "ctx":"listener","msg":"Waiting for connections","attr":{"port":27017,"ssl":"off"}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.633+00:00"},"s":"I",  "c":"INDEX",    "id":20345,   "ctx":"LogicalSessionCacheRefresh","msg":"Index build: done building","attr":{"buildUUID":null,"collectionUUID":{"uuid":{"$uuid":"0375342f-9f31-4e83-8990-8aac3b341fc8"}},"namespace":"config.system.sessions","index":"_id_","ident":"index-5--8030490562494532539","collectionIdent":"collection-4--8030490562494532539","commitTimestamp":null}}
dsa-mongodb-1  | {"t":{"$date":"2023-06-01T19:39:33.633+00:00"},"s":"I",  "c":"INDEX",    "id":20345,   "ctx":"LogicalSessionCacheRefresh","msg":"Index build: done building","attr":{"buildUUID":null,"collectionUUID":{"uuid":{"$uuid":"0375342f-9f31-4e83-8990-8aac3b341fc8"}},"namespace":"config.system.sessions","index":"lsidTTLIndex","ident":"index-6--8030490562494532539","collectionIdent":"collection-4--8030490562494532539","commitTimestamp":null}}

Do you have any idea what can it be?
Thanks!

Hmm...  the error is that the girder container can't resolve the mongo container.  Normally, docker-compose creates a docker network for the compose group (probably called dsa_default).  A docker inspect of each of the dsa-girder-1 and dsa-mongodb-1 containers should show that they both have a NetworkMode of dsa_default and that they have aliases that include girder and mongodb respectively.  If docker inspect shows this, then I don't know how there is a failure in name resolution.  If not, then whatever is causing that network change is going to be the problem.

thanks @manthey , both containers have dsa_default  in NetworkMode. I couldn't find the issue, so I switched to another machine with centos instead of ubuntu and it is working fine.


Bug: Switching to IL2CPP is giving a JsonSerializationException

I am using a .net library (https://github.com/contentful/contentful.net) that loads json from a CMS online. I am also using this json library. Using Mono it works perfect.
As one of the project's targets is Android, Google has requested after it was submitted that it must be compliant with the Play 64-bit requirement.
It goes on to instruct to change the scripting backend to IL2CPP and check ARM64. When building and testing on Android the following error I think occurs when it hits this logic:
json.SelectToken("$.items").ToObject<IEnumerable<T>>(Serializer);

error that occurs:

Newtonsoft.Json.JsonSerializationException: Error converting value "Hero" to type 'System.Collections.Generic.Dictionary`2[System.String,System.String]'. Path 'fields.title'. ---> System.ArgumentException: Could not cast or convert from System.String to System.Collections.Generic.Dictionary`2[System.String,System.String].

This is the point in the json that it appears to be falling at - which is right near the start of the data:
      "fields": {
        "title": "Hero",
        "file": {
          "url": "//images.hero.jpg",
          "details": {
            "size": 10000,
            "image": {
              "width": 1024,
              "height": 768
            }
          },
          "fileName": "Hero.jpg",
          "contentType": "image/jpeg"
        }
      }

Expected behavior
For the app to run as it does in the editor or Mono
Actual behavior
Android build with IL2CPP and ARM64 gives the above error.
Steps to reproduce
Unsure how to simplify a reproduction of the issue.
Details
Developed on Windows 10
Targeting Android API Level 30
Android version 2019.3.2f1
Newtonsoft.Json-for-Unity package version 12.0.301
Checklist

[x] Shutdown Unity, deleted the /Library folder, opened project again in Unity, and problem still remains.
[X] Checked to be using latest version of the package.

Thanks.

Hi @jkafkaris ! Thanks for reaching out about this!
I've inspected this a bit but I can't come with any answers. I'm missing too much context.
Would it be possible if you could send the entire JSON text you're serializing (or as little as possible but still triggering the issue) as well as the type models? What is T in IEnumerable<T>? If you could give the whole tree of classes/structs that you're deserializing, the would be great!

Hi @jilleJr
Thanks for getting back to me! I'll be back on the project on Monday and will try collate some of the data you have requested and get back to you.

Hi @jilleJr
Good news, I needed to include a link.xml file to stop Unity stripping out relevant code from the Contentful assembly.
I had it more narrowed but in the end preserved the whole assembly.
<linker>     <assembly fullname="ContentfulAssembly" preserve="all" /> </linker>
Works as expected now.


uart_read_bytes trow double char (IDFGH-2165)

Environment

Development Kit:      [none]
Module or chip used:  [ESP32-WROOM-32D]
IDF version (run git describe --tags to find it):
v4.1-dev-815-ga45e99853-dirty
Build System:         [Make]
Compiler version (run xtensa-esp32-elf-gcc --version to find it):
xtensa-esp32-elf-gcc (crosstool-NG esp32-2019r1) 8.2.0
Operating System:     [Linux]
Power Supply:         [external 3.3V]

Problem Description
We were using the version 3.3 before we got a problem with our system. I've than made a Ubuntu virtual machine to compile the project because the solution Espressif provide for Windows didn't worked for us.
By making the new virtual machine, I've downloaded the new IDF version (I'm not so sure how to pick the version I want). Everything is compilling (after some tweaks because of the new compiller), thought the project doesn't run as before.
After some tests, I saw that uart_read_bytes() always give one more character at the beginning of the received char array. I've try to debug the problem myself and I didn't found anything.
Expected Behavior
Received data on UART 0: 41 04 02 01
Decoded data by uart_read_bytes: 41 04 02 01
Actual Behavior
(example 1)
Received data on UART 0: 41 04 02 01
Decoded data by uart_read_bytes: 441 04 02 01
(example 2)
Received data on UART 0: A6
Decoded data by uart_read_bytes: AA6
Code to reproduce this issue
// the code should be wrapped in the ```cpp tag so that it will be displayed better.
#include "esp_log.h"

void app_main(){
    uart_flush(uart_num);
    while (bufferedSize == 0) {
	uart_get_buffered_data_len(uart_num, &bufferedSize);
    }

    if (uart_read_bytes(uart_num, &answerBuf[memIndexBuf], (uint32_t)bufferedSize, (100 / portTICK_PERIOD_MS)) == 0) {
	return ESP_FAIL;
    }

    ESP_LOGD(TAG_FUNC, "String in buffer: %s", answerBuf);
}

Other items if possible

[ ] sdkconfig file (attach the sdkconfig file from your project folder)
sdkconfig.txt

bzero(&answerBuf[memIndexBuf,bufferedSize+1);

if (uart_read_bytes(uart_num, &answerBuf[memIndexBuf], (uint32_t)bufferedSize, (100 / portTICK_PERIOD_MS)) == 0) {
	return ESP_FAIL;
    }

bzero

Thanks for the idea, but I already done it at the initialization (array[x] = {0};) and by a memset().

What is memIndexBuf

Hi, @caveman1996
Did you solve this issue?

@caveman1996 Thanks for reporting. Would you please help share if any updates for the issue? Has your issue been resolved? Thanks.

@caveman1996 Thanks for reporting, will close the ticket now due to short of feedback, feel free to reopen with more details/updates. Thanks.


Codeunit 6500 new event on procedure SumUpItemTracking

Hi,
We need a new event on Codeunit 6500 procedure SumUpItemTracking :
....
if ItemTrackingCode."Use Expiration Dates" then begin
                            ItemTrackingSetup.CopyTrackingFromReservEntry(ReservEntry);
                            ExpDate :=
                                ExistingExpirationDate(
                                    ReservEntry."Item No.", ReservEntry."Variant Code", ItemTrackingSetup, false, EntriesExist);
                            if EntriesExist then
                                TempHandlingSpecification."Expiration Date" := ExpDate;
                            // > New event
                            OnAfterTempHandlingSpecificationExpirationDate(TempHandlingSpecification, ReservEntry, EntriesExist);
                            // < New event
                        end;
                        OnBeforeTempHandlingSpecificationInsert(TempHandlingSpecification, ReservEntry);
...
[IntegrationEvent(false, false)]
    local procedure OnAfterTempHandlingSpecificationExpirationDate(var TempTrackingSpecification: Record "Tracking Specification" temporary; ReservationEntry: Record "Reservation Entry"; var EntriesExist: Boolean)
    begin
    end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


react-ladda from npm outdated

Hi,
I just installed react-ladda from npm npm install --save react-ladda, and I notice the code is outdated when compared to the repo.
This the code  of componentDidUpdate inside node_modules/react-ladda/index.js
componentDidUpdate: function() {
    if (!this.laddaButton) {
      return;
    }

    // Skip if the button was initially disabled.
    if (!this.props.loading && this.props.disabled) {
      return;
    }

    if (this.props.loading && !this.laddaButton.isLoading()) {
      this.laddaButton.start();
    } else if (!this.props.loading && this.laddaButton.isLoading()){
      this.laddaButton.stop();
    }

    if (typeof this.props.progress !== 'undefined') {
      this.laddaButton.setProgress(this.props.progress);
    }
  }

It seems the latest commit (29897875a575d355de0e6fca455ff33885da26e0) is not on npm, which is a same since it fixed the problem I'm having.

Thanks for noticing. I've just published the latest changes in<EMAIL_ADDRESS>

Thanks! :+1:

Hm, I've faced the same issue with 4.0.3. The code on the npm is still the same as in 4.0.1 version

@antoniopuero this should be fixed in<EMAIL_ADDRESS>


DC07RH 'Filter Life Level' "NaN"

LG Air Conditioner Model
LG DC07RH
RAC_056905_WW
Describe the bug
Filter level in ThinQ App showes percents correctly. But Plugin writes to log an error every time of refresh interval.
Symptom check

Does your unit appear in the Home app? Yes
Is the current on/off state, temperature, and mode being reported? Yes
Does your unit respond to the controls? Yes

Relevant logs
[8/6/2021, 3:48:36 AM] [homebridge-lg-thinq-ac] This plugin generated a warning from the characteristic 'Filter Life Level': characteristic value expected valid finite number and received "NaN" (number). See https://git.io/JtMGR for more info.
[8/6/2021, 3:49:06 AM] [homebridge-lg-thinq-ac] This plugin generated a warning from the characteristic 'Filter Life Level': characteristic value expected valid finite number and received "NaN" (number). See https://git.io/JtMGR for more info.
[8/6/2021, 3:49:36 AM] [homebridge-lg-thinq-ac] This plugin generated a warning from the characteristic 'Filter Life Level': characteristic value expected valid finite number and received "NaN" (number). See https://git.io/JtMGR for more info.
[8/6/2021, 3:50:07 AM] [homebridge-lg-thinq-ac] This plugin generated a warning from the characteristic 'Filter Life Level': characteristic value expected valid finite number and received "NaN" (number). See https://git.io/JtMGR for more info.

Is there any fix to this issue? I'm having the same situation as @LeonidPY .

Log error fixed in 22f0aa6007dc4ee993aed383e3c35afcc2707fd4, follow #94 for a fix for filter life being accurate


Please unify cloud provider tags

Describe what happened:
Currently, the tags Datadog collects and applies to cloud resources are 1) inconsistent and 2) varied.
1. For example, there is no convention or standardization between - and _
Please unify them on one or the other.
For GCP, these are the tags collected:
Zone
Instance-type
Instance-id
Automatic-restart
On-host-maintenance
Numeric_project_id

For AWS:
# EC2
autoscaling_group
availability-zone
instance-id
instance-type
security_group_name

In this case, there is

a difference between zone (GCP) and availability-zone (AWS), causing duplication & multiplication of tags (and therefore custom metrics) if you want to unify them across clouds (ie one app deployed in both)
a difference between _ and - within the same category

2. Duplicated tags from integrations
Along with the above, different integration levels collect the same tags with different keys, resulting in examples like this (GCP & K8s):
cluster_name
cluster-name

I have no idea which one did what because

the gcp docs don't say which tags are collected for what integration (like the aws docs)

the k8s docs don't say anywhere what tags are tacked on automatically (i assume it's cluster_name based on DD_CLUSTER_NAME

3. Another naming oddity
# EBS
volumeid, volume-name, volume-type
# EC2
instance-id, name, instance-type
# ECS
instance_id, clustername, servicename

4. cloud_provider tag is inconsistently automatically applied
For agents running in GCP, the cloud_provider:gcp tag is automatically added to all things.
However based on a chat with a support agent, the cloud_provider:aws tag is not automatically added for AWS:

This is inconsistent behavior
5. aws_account tag is inconsistently applied to AWS metrics
Some AWS metrics collected by the AWS integration are automatically tagged with the account number, while others lack this tag.
For example, ELB metrics have this tag, but EC2 metrics do not.
This makes filtering on this tag value difficult when building a multi-account dashboard.
This is not a problem with GCP as all metrics are tagged with project_id.
Describe what you expected:
I expect:

unifying all name separators with _ or - (probably _ since you automatically convert camelCase to underscores already)
use separators consistently (volume_id instance_id)
use names consistently (volume_name instance_name cluster_name service_name)
use "categories" consistently (zone)
unify tags between cloud providers (I know much of this is currently an afterthought)

This could be easier if I could actually configure how tags are formatted or configured.
It doesn't seem like the code allows for that right now since it is hardcoded:
https://github.com/DataDog/datadog-agent/blob/eb4fa9ce5edc05fd2ac61df19ce5b98b9f727b35/pkg/util/gce/gce_tags.go#L73-L92
It would also be helpful if I can pick and choose which tags are collected, but that's not possible either.
I ask for this because building multi/cross cloud queries & dashboards are not trivial.
This seems like a sensible thing to do (review tag names and make them conform to some "datadog-internal" standard) so user's don't have a poor experience when trying to correlate data from multiple sources.

Here's more anomalies:
AZs
The concept of zones use different tags for each cloud provider:

cloud
name

azure
availability_zone

aws
availability-zone

gcp
zone

Regions
The region tag is collected from Azure and AWS, however not from all GCP integrations. Some have it, but then some don't, like GAE, cloud nats, etc...
For select integrations it's named location instead, like cloud run, spanner, memcache, cloud tasks, dns, etc...

Tap, tap, tap... is this thing on? Just wondering if there's any plans to address this at all?
It makes it /really/ hard to build dashboards if the tagging isn't consistent.

@edwardaux Thanks for feedback. Have you raised this issue/open a ticket through the support channels? If not, I would advise that you do because most of the tagging issues you mentioned are not done by the agent (except maybe for the clustername in a k8s env); there are different teams involved with Crawler/Web/Cloud-based integrations that have no dependencies to the Datadog Agent (this repository). That said, a support ticket might be a better way for this issue to get more traction and have it routed to teams responsible.

@ian28223 I'm sorry but Datadog is a complete product, and as customers of this product it is surprising to me that this kind of interweaving and crosscutting issue is not of interest to be addressed.
Furthermore, asking customers to open tickets when employees can do so much easier is just shocking to me. Tickets opened often end up closed as a "thanks we'll file this as a feature request" with no accountability. Sharing here provides visibility to other customers that they're not the only ones having issues with that process and the product itself.
Lastly, it's unfortunate to see redirecting the responsibility and involvement of the Datadog agent. As I clearly linked to in the original comment, there are multiple places where tags are set or used by the agent.
The "different teams involved with Crawler/Web/Cloud-based integrations that have no dependencies to the Datadog Agent" together make the user experience for this product and the issues outlined result in a poor user experience.
I recommend Datadog (or the Datadog agent team) to revaluate the "somebody's else's problem" approach it takes to this kind of tech debt.

I'd like to add that this is very annoying because there are interfaces in Datadog that assume one type of tag. For instance, loading up the infrastructure map with gcp and gke looks like this by default:

Some of the group drop down options also don't work because they are named different in gcp:

I think an acceptable stop gap would be to allow aliasing tags, so if you were running in gcp and had a tag like cluster-location:us-east1 you could alias it to create region:us-east1.

I understand and I agree. I have raised this to the relevant team's PM. Proper tracking would still be via official support channels.

Here's more anomalies:
AZs
The concept of zones use different tags for each cloud provider:
cloud	name
azure	availability_zone
aws	availability-zone
gcp	zone
Regions
The region tag is collected from Azure and AWS, however not from all GCP integrations. Some have it, but then some don't, like GAE, cloud nats, etc...
For select integrations it's named location instead, like cloud run, spanner, memcache, cloud tasks, dns, etc...

Note that for GCP, location is not the same as region. They're two separate attributes that often have the same value, but they're not the same.
See Cloud Storage Locations for example https://cloud.google.com/storage/docs/locations

For compute, it's still zones and regions.
https://cloud.google.com/compute/docs/regions-zones
https://cloud.google.com/docs/geography-and-regions

location is not the same as region

Correct, they are supplementary to each other. While GCS doesn't allow you to choose a specific zone, they still have regions (which is conceptually shared across other products like compute) in addition to multi-region codes (aka locations).
For cloud run, you can only specify region (no zone or multi region).
gcloud storage buckets create gs://BUCKET_NAME --location=US --placement=US-CENTRAL1,US-EAST1
DD should collect tags for GCP's zone, region, and location as applicable - and unify them (or allow us to rename them so) to deal with multicloud setups.


Add Securitay!

Adds Securitay to Anything.js, so bad guys can't hack us

This probably counts as some form of advertising, but we have no rules against it. ¯_(ツ)_/¯


Font size option (make it bold)

Please add possibility to increase font size by making it bold. Atm it's too thin for poor old eyes of M&M7 veterans :)
Also maybe even add possibility to change font size... but even making it bold will help a lot!

Hi @igroglaz, in the meantime you can use the following code to create a bookmarklet that will toggle (on/off) bold text on cards for you:
javascript:!function(){var e=document.getElementById("arcomageBoldText");e?document.head.removeChild(e):((e=document.createElement("style")).id="arcomageBoldText",e.innerHTML='button [class*="text-"] { font-weight: 700 !important; }',document.head.appendChild(e))}();

You can create a bookmarklet by selecting all the code and dragging the it into your bookmarks bar in the browser, or add it manually:

Open your web browser and show the bookmarks bar.
Right-click on the bookmarks bar and choose to add a new bookmark.
In the Name field, enter a name for your bookmarklet, like "Toggle Button Style".
In the URL field, paste the JavaScript code.

Should you need a different font-weight (boldness), you can change the number 700 inside the script to either 600 or 800.
Card before:

Card after:


lvm2: link against libblkid

dmsetup requires it and is part of the extra-utils derivation used on all NixOS systems.

Motivation for this change
Fixes https://github.com/NixOS/nixpkgs/issues/96197.
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

Testing now. This will be a mass-rebuild though.

Current staging-next looks quite good. I suggest we merge that into master, and then have a staging-next iteration with this commit along with the systemd change (https://github.com/NixOS/nixpkgs/pull/94354).

Seems like dmsetup in lvm2.bin was fine already, just not in extra-utils for me. Strange...


Documentation slight outdated (for quick setup)

Tried to get this running. Looks super nice and promising. A few things I noticed while setting it up.

I needed to set min sdk to 26 (Oreo) to compile. Not a problem, and easily fixable through error messages

Could it be that .defineZoomLevel replaced .defineDetail and .addDetailLevel? readme.md refers to defineDetail in the quick setup , and the wiki uses addDetailLevel. The demo code shows how.

yeah the javadocs are completely outdated and i haven't gone through all the wiki pages.  the demo and readme should be relatively correct, although feel free to fork and PR (or just edit the wiki directly) if you have the bandwidth to correct any typos or misnamed methods.  otherwise i'll get to it when i can - i usually work in short bursts every few months.
yeah it's defineZoomLevel(int zoom, Object data) now.  https://github.com/moagrius/TileView/blob/master/tileview/src/main/java/com/qozix/tileview/TileView.java

you should be able to edit the wiki directly, but it's np i can do it - what page/line?

I also get an error message for min sdk to be 26. How can i fix this to use it with min sdk 19?

This should be in a different issue thread, but nity demo and library have minSdk of 19.  Check other Gradle or manifest settings in your project, or other dependencies

Also in README.md TileView.Builder().build() does not return the build TileView anymore but void and takes the TileView to build as a paramter.

i will fix this as soon as i get some time for this project (weeks away)


Add unit tests for Bundler::PathPreserver module

Related to #4256

@homu r+

:pushpin: Commit d9ac903 has been approved by segiddins

:zap: Test exempted - status


Move app service hosting to orcasound account

Tricky part is reusing the hostname

[x] Create OrcanodeMonitorStaging2 under orcasound
[x] Update github workflow to use OrcanodeMonitorStaging2
[x] Update IFTTT to use OrcanodeMonitorStaging2
[x] Create OrcanodeMonitor2 under orcasound
[x] Update IFTTT to use OrcanodeMonitor2
Make http://status.orcasound.net/ work (nope, requires non-free plan)
Make https://staging.status.orcasound.net/ (nope, requires non-free plan)
[x] Update github workflow to use OrcanodeMonitor2 publish profile
[ ] Create OrcanodeMonitorStaging under orcasound after a week has passed
[ ] Update github workflow to use OrcanodeMonitorStaging
[ ] Update IFTTT to use OrcanodeMonitorStaging
[ ] Create OrcanodeMonitor under orcasound
[ ] Update github workflow to use new OrcanodeMonitor publish profile
[ ] Update IFTTT to use OrcanodeMonitor
[ ] Update link in IFTTT notifications if needed

Closing this and just using 2 for now.
Can reopen if/when we find that the hostname is free again.


Convert Caffe Net to CNNdroid faild

There is my Net file of Caffe (prototext file)

name: "face_12c"
input: "X"
input_dim: 1
input_dim: 3
input_dim: 12
input_dim: 12
layer {
name: "conv1"
type: "Convolution"
bottom: "X"
top: "conv1"
convolution_param {
num_output: 10
kernel_size: 3
}
}
layer {
name: "relu1"
type: "PReLU"
bottom: "conv1"
top: "conv1"
}
layer {
name: "pool1"
type: "Pooling"
bottom: "conv1"
top: "pool1"
pooling_param {
pool: MAX
kernel_size: 2
stride: 2
}
}

When I use the script 'SavePycaffeModelInMessagePack.py'  to convert it to CNNdroid file, it make errors
Getting parameters: conv1 Getting parameters: relu1 Traceback (most recent call last):   File "SavePycaffeModelInMessagePack.py", line 55, in <module>     params = get_params(net)   File "SavePycaffeModelInMessagePack.py", line 41, in get_params     net_params[key] = [net.params[key][0].data, net.params[key][1].data] IndexError: Index out of range
I have read the document and make sure there was no wrong for the parameters. There seems to be something wrong when it converted the relu1 layer. So, how to solve this problem?

@yungs2017 ,I face the same problem and I have no solution to change the source code, can you tell me how to solve it? Thanks!

Do you also want to add PReLU layer?

@latifisalar  yes, I want to add PRelu  layer, but I don't know how to realize it in the source code, can you give me some suggestions?

Here are the modifications that are necessary:

You need to add PReLU layer functionality in CNNdroid/CNNdroid Source Package/java/layers/NonLinear.java:
NonLinear.java is dedicated for non-linear activation functions, so you can add the PReLU functionality besides ReLU function. Here is the overview of required changes:
- Line 4: Add import messagepack.ParamUnpacker;
- Line 8: Define new parameters for PReLU:

private String paramFilePath;           // name of the file which specifies alpha parameter
private ParamUnpacker paramUnpacker;    // for extracting the alpha from the parameters file
private float alpha;        //alpha parameter for PReLU

    - Line 12: Add PReLU in enumeration.
    - Line 16: Define a new constructor similar to ReLU one with the added alpha input:

   public NonLinear(String name, NonLinearType nonLinearType, String paramFilePath) {
       this.name = name;
       this.nonLinearType = nonLinearType;
       this.paramFilePath = paramFilePath;

       this.paramUnpacker = new ParamUnpacker();
       Object[] objects = paramUnpacker.unpackerFunction(paramFilePath, new Class[]{float.class});
       alpha = (float) objects[0];
   }

  - Line 27: Add the corresponding case in switch.
  - Line 42 & 63: Add similar functions for PReLU with the parametric functionality.

You also need to add PReLU layer parsing in CNNdroid/CNNdroid Source Package/java/network/CNNdroid.java:
CNNdroid.java is dedicated to parse NetFile and construct network compute flow. Here is the overview of required changes:
- Line 455: Add the following if statement for PReLU:

        else if (type.equalsIgnoreCase("PReLU")) {
            String parametersFile = null;
            for (int i = 0; i < args.size(); ++i) {
                String tempArg = args.get(i);
                String tempValue = values.get(i);
                if (tempArg.equalsIgnoreCase("parameters_file"))
                    parametersFile = tempValue;
                else
                    return false;
            }
            if (parametersFile == null)
                return false;
            NonLinear nl = new NonLinear(name, NonLinear.NonLinearType.<YOUR_PReLU_DEFINITION_in_ENUM>, parametersFile);
            lastLayer = nl;
            layers.add(nl);
            return true;
        }

Update the CNNdroid/Parameter Generation Scripts/SavePycaffeModelInMessagePack.py to save PReLU parameter in messagepack.

Let me know if you have question regarding any of the steps.
I can also add the optimized implementation in a couple of weeks when I have more free time.

Thanks for your reply!


getLocation error with non standard origins

Hi,
We are experiencing a lot of errors in the getLocation function (when coming from _getOrigin function).
In many cases, the origin of the event is chrome-extension://..., file:// , chrome://browser, about: etc.
When the origin is such a string, the  match function returns null, and an error is thrown when it tries to get a member of a null object.
Is there any solution to this case?
for example , check already in the _getOrigin function for validity of the event.origin
Thanks

Ok, so I've found the root cause of some of these issues.
There's a chrome extensions called "Buffer" which sends message events.
Easy XDM listens to these messages , and then tries to perform the regular flow, but the origin is chrome-extension://noojglkidnpfjbincgijbaiedldjfbhh , thus the failure in getLocation.
I was wondering what are the consequences for returning empty string when the origin is not a valid URL.
Any thoughts?

This seems like a fair thing to support, but generally I'd prefer the callers to instead explicitly check for null and do something sane.
Want to provide a PR?

Thanks.
I agree, but this extension is just one example.
BTW, the origin is not null, the null is the result of the match function.
I will provide a PR soon

We've run into this same issue.  Is there a timeframe for this to be addressed?  Thanks.
(Also, the call stack for the error is completely self-contained within easyXDM. The top is  _window_onMessage. I'm unclear how "callers would explicitly check for null...".  I don't see any way we can resolve this issue outside of an update to EasyXDM.)

@dtomack I would recommend that someone with a good example put up a PR for this issue. I'm happy to review and accept.

@dtomack

callers would explicitly check for null...". I don't see any way we can resolve this issue outside of an update to EasyXDM.)

I couldn't agree more.
I've put up a PR, hope it is good enough (this is how I solved it in my local code)
https://github.com/oyvindkinsey/easyXDM/pull/280 .
@oyvindkinsey , This is my first contribution to an open source, be easy on me :)

@oyvindkinsey @matmiz Hi all, I see the PR was approved a while ago.  What are the next steps for getting this out in a release?  I just want to know what the timeframe is for seeing a fixed version.  Thanks.

@oyvindkinsey @matmiz Ping?

Hi @dtomack , I think that it's in the hands of @oyvindkinsey right now, there's nothing I can do,

Closing this as the pr was merged to master.


silence "warning: method redefined; discarding old attribute"

virtus/lib/virtus/builder.rb:73: warning: method redefined; discarding old attribute
virtus/lib/virtus/builder/hook_context.rb:43: warning: previous definition of attribute was here

This PR silences the above warning by first undefining the method before defining a new one.
I do not know if this is a good tactic. I assume the defined singleton method can not call super anyway, otherwise there would be no warning.

Thanks, when does this happen?


#8 - Add flip cards

Fixes #8
Added all the double-faced and flip cards to the token list. This way it's possible to flip without having to type the name, without having the card in the sideboard and by simply using the token shortcuts.
The double-faced cards are using the original art from gatherer, the suffix " (flip)" has been added to avoid collisions with the cards with the same name already coming from Oracle.
The flip cards are using the art for magic art as the flipped art from gatherer can't be obtained easily (the URL can't be used by Cockatrice).
The suffix " (flip)" has been added to avoid collisions with the cards with the same name.
Only the flip/double-faced cards up to Origin are added, the new planeswalkers from ORI aren't available yet.

At the moment some of those tokens are a bit wordy. Hopefully that will be fixed with Cockatrice/Cockatrice#241

Added actual flipcards (BOK/SOK/CHK)

Nevermind, it's been added to Cockatrice itself: https://github.com/Cockatrice/Cockatrice/releases

Thanks for the spam. :-1:


python installation failed because 'C compiler cannot create executables' (Mac OSX Lion)

I'm having this issue when trying to instal python 2.6. Here is my log:
/var/folders/r9/771hsm9931sd81ppz31384p80000gn/T/python-build.20150213120811.66272 ~
HTTP/1.1 200 OK
Date: Fri, 13 Feb 2015 11:03:26 GMT
Server: GitHub.com
Content-Type: application/octet-stream
Last-Modified: Tue, 04 Nov 2014 09:32:24 GMT
Expires: Fri, 13 Feb 2015 11:13:24 GMT
Cache-Control: max-age=600
Content-Length: 13285074
Accept-Ranges: bytes
Via: 1.1 varnish
Age: 1
X-Served-By: cache-fra1239-FRA
X-Cache: MISS
X-Cache-Hits: 0
X-Timer: S1423825404.761097,VS0,VE1588
Vary: Accept-Encoding
/var/folders/r9/771hsm9931sd81ppz31384p80000gn/T/python-build.20150213120811.66272/Python-2.6.9 /var/folders/r9/771hsm9931sd81ppz31384p80000gn/T/python-build.20150213120811.66272 ~
checking for --enable-universalsdk... no
checking for --with-universal-archs... 32-bit
checking MACHDEP... darwin
checking EXTRAPLATDIR... $(PLATMACDIRS)
checking machine type as reported by uname -m... x86_64
checking for --without-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in /var/folders/r9/771hsm9931sd81ppz31384p80000gn/T/python-build.20150213120811.66272/Python-2.6.9': configure: error: C compiler cannot create executables See config.log' for more details.
make: *** No targets specified and no makefile found.  Stop.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/8546891-python-installation-failed-because-c-compiler-cannot-create-executables-mac-osx-lion?utm_campaign=plugin&utm_content=tracker%2F282009&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F282009&utm_medium=issues&utm_source=github).

Read the error from your compiler.


Dashboard export fails with OSS beta 14

Steps to reproduce:

Create Dashboard
Attempt to export

Expected behavior:
Should be directed to the export window in order to choose the method for export.
Actual behavior:
The dashboard loaded just like when selecting the name
Environment info:

System info: Run uname -srm and copy the output here
Linux 5.4.0-42-generic x86_64
InfluxDB version: Run influxd version and copy the output here
InfluxDB 2.0.0-beta.14 (git: c8af0f35be) build_date: 2020-07-08T20:42:23Z
Other relevant environment details: Container runtime, disk info, etc
Nothing special

Config:
All is default and no config file.
Command line to start it:
nohup /home/darinf/work/influxdb/influxdb-runtime/influxd &>influx.out &
Logs:
Include snippet of errors in log.
Performance:
Generate profiles with the following commands for bugs related to performance, locking, out of memory (OOM), etc.
# Commands should be run when the bug is actively happening.
# Note: This command will run for at least 30 seconds.
curl -o profiles.tar.gz "http://localhost:8086/debug/pprof/all?cpu=true"
curl -o vars.txt "http://localhost:8086/debug/vars"
iostat -xd 1 30 > iostat.txt
# Attach the `profiles.tar.gz`, `vars.txt`, and `iostat.txt` output files.

This has been fixed in prod


Use /B to avoid closing console

Forgot to fix both exit lines in earlier pull request.
Without the /B, the window console closes when the script end, and the user has no real chance to see what happened.

@mbed-bot: TEST

@mbed-bot: TEST

@mbed-bot: TEST


gps: skip hidden directories when looking for packages

Stuff in hidden directories should stay hidden. In my case, I am using a special GOPATH and I don't want dep to look into it.

sorry, this can't be how this works. it is valid, even if inadvisable, to import packages under dot dirs, and ListPackages has to model all possibly-valid importable locations when creating its virtual representation of the filesystem.

go list also skips hidden directories. Moreover, by the same logic, VCS directories and Godeps shouldn't be skipped. Please, reconsider.

this decision has already undergone dozens of hours of consideration, and was not arrived at lightly. it is not the same domain as go list, and the same rules should not apply.
to reiterate: making this change would be equivalent to banning all import paths containing dot dirs. the compiler considers those valid, and we must as well - that is the domain we are in, not go list.
we cannot visit vendor or Godeps dirs because they are known to contain dependency code, and are thus out of scope for consideration. We exclude VCS dirs because there is no sane way in which go code contained in such dirs could be a part of a redistributable project. all of these are domain-specific considerations in a way that is not comparable to dot dirs.
there is a possible approach with the same outcome as this patch in >99.99% of cases, where we could conditionally avoid descending into dot dirs. it does add some complexity, as we have to adaptively determine from the import set in non-dot/underscore-led dirs whether or not it's needed to actually explore those, then restart work if we determine that it is. that's the only way this class of change could be accepted, and it hasn't really been necessary so far - but, if you're hiding an entire GOPATH under a dot dir, though, I can see it being worthwhile to skip that analysis 😀
On October 10, 2017 7:41:28 AM EDT, Vincent Bernat<EMAIL_ADDRESS>wrote:

go list also skips hidden directories. Moreover, by the same logic,
VCS directories and Godeps shouldn't be skipped. Please, reconsider.
--
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub:
https://github.com/golang/dep/pull/1251#issuecomment-335445787

In fact, the additional analysis doesn't bother me much but starting from 242e387235bf and 19c7f60dae622d4, pkgtree will recurse into dep itself and choke on invalid tests and I get this kind of error:
ensure ListPackage for project: import path hellogopher/.gopath~/src/github.com/golang/dep/internal/gps/_testdata/src/canon_confl had conflicting import comments: "vanity1", "vanity2"

For context, I am doing stuff like that to get a local GOPATH: https://github.com/vincentbernat/hellogopher/blob/master/Makefile#L26.
This is not something totally alien as some popular developers advertise this way of doing things (well, at least one): https://github.com/cloudflare/hellogopher/blob/master/Makefile.

uuuugghh.
yeah, we keep ping-ponging around on these individual package-level errors, as well as what we should be looking at at all (within the root project). this whole model needs improving.
#1253 will be where this can live on, as @darkowlzz is gonna take on making the necessary deeper improvements.


Unigine Superposition launcher crash

Software information
Unigine Superposition launcher crashes in kernel32
System information

GPU:  Nvidia GTX 750 Ti
Driver: proprietary
Wine version: wine-staging 2.21
DXVK version: latest

Apitrace file(s)
https://mega.nz/#!5YI2VQAB!p0069ISZdqoeMSXdPX20fJXlQQM8-C36ZjWhtYl48To
Log files

d3d11.log:
launcher_d3d11.log

dxgi.log: launcher_dxgi.log

wine.log

Will have to take a look at which interfaces it actually needs, but this sounds like a lot of work.

There is currently a bug generally in wine with the SuperPosition gui. Its relatively "garbled", but if you know appx where the buttons are, it works.
However, if you set "d3d11.dll" to "disabled", it will switch to DX9 (i think), and work fine.. but the benchmark will ofc not work for "DirectX". This bug is with ALL versions of Wine, so not really related only to running with dxvk dll's.
So it might be more to it than fixxing D3D11Texture2D transformation perhaps?

Hi guys,
I got it working more or less on Vega!
on native Win10 RX Vega..
the trick is not put d3d11.dll and dxgi.dll and launch the launcher..
of course it launches correctly and then selected custom medium quality windowed 1080p and before running putted back dxvk dlls on the folder (latest as of today)
see results:

superposition_d3d11.log
superposition_dxgi.log
seems logs complain a lot of:
D3D11Device::CreateGeometryShaderWithStreamOutput: Not implemented
CreateBuffer: D3D11_BIND_STREAM_OUTPUT not supported
D3D11DeviceContext::SOSetTargets: Not implemented
finally a warn about:
warn:  DxbcCompiler: Unhandled opcode class: DxbcOpcode::BfRev

@doitsujin
I'm getting these validation errors from spirv-val on these spir-v files in the  Superposition benchmark.
PS_ae8e6b1471b25a5db1b500dee170dc3a122bcd6c.spv
error: 514: Illegal number of components (5) for TypeVector
PS_b894ff8ee03e2fe3bf870fe31502f9b7d1b50aeb.spv
error: 376: Illegal number of components (5) for TypeVector
PS_d7347a5c4bb3b87ffab4c4eef3e49364215baf07.spv
error: 530: Illegal number of components (5) for TypeVector
PS_f3075e40e8dee2daa325b9c63685f1215fc5da6d.spv
error: 514: Illegal number of components (5) for TypeVector

invalid-spirv.zip

@ZeroFault Are you on Nvidia hardware?
Thing with Nvidia is that their driver is broken and requires packing the depth value into the component vector for depth-compare operations, which seems to cause trouble here since cube map array coordinates are already four-dimensional. I don't know if it is possible to fix this issue without breaking Nvidia support entirely.

@ZeroFault I found that adding --skip-validation helped for those TypeVector errors.
spirv-opt --inline-entry-points-exhaustive --skip-validation --eliminate-dead-code-aggressive
@doitsujin I mentioned washed out colors on the other thread..

The attached 3 shaders dumped from Superposition fails validation with spirv-val.
To be able to optimize those to work with nVidia, they need --skip-validation
Since im quite the n00b here, is it the driver that dump those .spv files, or is it dxvk?
broken.tar.gz

@doitsujin
Yes I am using Nvidia. Unfortunately, disabling the packDrefValueIntoCoordinates causes issues with rendering. I wish Nvidia would stop having so many issues with its driver.
@SveSop DXVK is dumping the .spv files

HI guys,
some updates( all on Win 10 native):

implementing bfrev fixed graphics issues on AMD Vega now renders correctly at medium and high settings..
tested also on Nvidia fixing the shaders (spir-opt legalize-hlsl) without the bfrev commit and also exact graphics issues were present but after that patch also renders perfectly on Nvidia..

so basically two issues to say:

settings shaders at maximum quailty (maybe called ultra) is only path that renders with graphical issues.. maybe that's the only path making use of geometry shaders and hitting this issues seriously:
D3D11Device::CreateGeometryShaderWithStreamOutput: Not implemented
CreateBuffer: D3D11_BIND_STREAM_OUTPUT not supported
D3D11DeviceContext::SOSetTargets: Not implemented

2)but a bat file I legalize shaders with something like:
for /f %%f in ('dir /b *.spv') do spirv-opt %%f --legalize-hlsl -o %%f.leg
@ZeroFault @SveSop @doitsujin
I'm using the spirv-opt executable included in the new Vulkan SDK 1.0.68 for Windows:
and as I say I don't see any errors like:
error: 514: Illegal number of components (5) for TypeVector
and also don't need to use --skip-validation argument in spirv-opt as I say it runs correctly with:
spirv-opt %%f --legalize-hlsl -o %%f.leg
may be spirv-tools may diverged a bit between the included in SDK and in github master..
I get in SDK:
spirv-opt --version
SPIRV-Tools v2018.1-dev v2018.0-6-g9e19fc0

@pingubot @doitsujin don't worry, I, as crazy as I am :-), bombarded all NV Vulkan dev techs I know pointing to this issue:
https://twitter.com/oscarbg81/status/964301753184333824
but if it's not enough let's ping also to his github names:
@pdaniell-nv what do you say about:

Thing with Nvidia is that their driver is broken and requires packing the depth value into the component vector for depth-compare operations, which seems to cause trouble here since cube map array coordinates are already four-dimensional. I don't know if it is possible to fix this issue without breaking Nvidia support entirely.

also that some shaders that are consumed correctly by AMD closed driver or even RADV fail on Nvidia without doing some:
spirv-opt --inline-entry-points-exhaustive --skip-validation --eliminate-dead-code-aggressive
on this shaders..
even with that or a full "spirv-opt --legalize-hlsl" pass some shaders still present issues..

What specific SPIR-V OpImage function is having the issue? Eyeballing our shader compiler it appears dref is picked up as a separate operand, rather than the 4th component of the coord, from functions like OpImageDrefGather. What driver version are you using?

@pdaniell-nv IMHO the fastest way to test is this:
a)test on Windows to avoid setting up Wine-staging or from https://github.com/roderickc/wine-vulkan
b) if you don't want to compile by yourself download precompiled binaries from: https://haagch.frickel.club/files/dxvk/
for examples from latest commit download both d3d11.dll and dxgi.dll from:
https://haagch.frickel.club/files/dxvk/r608.8ebffc1/64/bin/
or
https://haagch.frickel.club/files/dxvk/r608.8ebffc1/32/bin/
as needed by the app..
if you don't trust this guy, you can also build DXVK from Windows (basically to obtain the 2 DLLs this project is about (d3d11.dll and dxgi.dll)
for 64 bit DLLs:
I download https://nuwen.net/mingw.html launch his shell with compilers in path and then
clone this project and modify build-win64.txt:
comment "exe_wrapper = 'wine':"
#exe_wrapper = 'wine'
and remove "/usr/bin/x86_64-w64-mingw32-" from all this lines:
c = '/usr/bin/x86_64-w64-mingw32-gcc'
cpp = '/usr/bin/x86_64-w64-mingw32-g++'
ar = '/usr/bin/x86_64-w64-mingw32-ar'
strip = '/usr/bin/x86_64-w64-mingw32-strip'
then following his instructions you should obtain the 2 DLLs ..
c) put the dlls in the executable to test..
altough I pointed to this issue because of developer talking about Nvidia problems I would suggest for a simple failing program test ComputeMark2 program..
you have to trust the file I uploaded because this program has dissappeared from the web altough it was popular by review sites for new GPUs in the early D3D11 days (2010s):
https://github.com/doitsujin/dxvk/files/1670646/ComputeMark2.zip
it a good test because has very few shaders (less than 10) mostly compute shaders that all fail to compile under
Windows+Nvidia GTX 970 +390.65 drivers..
start a cmd.exe:
set DXVK_SHADER_DUMP_PATH=c:\dxvk\shaders
set DXVK_SHADER_READ_PATH=
set DXVK_HUD=1 (optional but to verify the D3D11 it's using Vulkan)
ComputeMark2.exe
that should get spv files and dxbc files c:\dxvk\shaders
using spirv-opt.exe from Vulkan SDK 1.0.68 I run on all shaders:
(with a script)
spirv-opt --legalize-hlsl file.spv -o file.spv.legal and copy spv.legal to .spv
my bat is
for /f %%f in ('dir /b *.spv') do copy /y %%f %%f.ori >nul
for /f %%f in ('dir /b *.spv') do spirv-opt %%f --legalize-hlsl -o %%f.leg
for /f %%f in ('dir /b *.spv') do copy /y %%f.leg %%f >nul

and then run:
set DXVK_SHADER_DUMP_PATH=
set DXVK_SHADER_READ_PATH=c:\dxvk\shaders
ComputeMark2
I run spirv-opt --legalize-hlsl because that is shown to fix issues on Unigine Heaven and Valley benchmarks (i.e. this SPIR-V programs weren't compiling successfully but with this pass they make NV SPIR-V compiler happy)..
in practice means going from the app running but seeing a black screen to rendering perfectly fine..

@pdaniell-nv You can also get some DXVK binaries from OpenSUSE's OBS.
This archive contains all the vertex and fragment shaders for Unigine Valley. The .spv files are SPIR-V files, the .dxbc files are the Direct3D11 shader files. The game launches but shows a black screen, and DXVK says it failed to create the graphics pipelines.
shaders.zip

@GabrielMajeri @pdaniell-nv
this is good to test but not perfect because as has said before with
spirv-opt --legalize-hlsl
this "NV problematic" spirv shaders get fixed..
instead Computemark2 shaders are less than 10 and continue being problematic on Nvidia driver even after "legalized" with spirv-opt --legalize-hlsl...
so I believe NV must see because hlsl-legalized spv shaders don't compile fine and the can attack the spv shaders that can be fixed by spirv-opt --legalize-hlsl..
if course just my IMHO..

@pdaniell-nv
Here is one example of a shader which requires spirv-opt on NVIDIA from Unigine Valley:
W/O spirv-opt (crashing): https://paste.ubuntu.com/p/SqyDxQbKwn/
W/ spirv-opt (not crashing): https://paste.ubuntu.com/p/xDgZXbhfWc/

@pdaniell-nv @doitsujin @SveSop @pingubot @Guy1524 @GabrielMajeri @ZeroFault
just found that AMDVLK latest 2.0.15 open source driver on Vega build runs Superposition (previously ones didn't launch correctly) and what a surprise(!) also need "hlsl-legalization" (spirv-opt --legalize-hlsl) on some shaders to render correctly.. so very similar to Nvidia driver and this just proves that we just were lucky with AMD RADV and closed AMDGPU PRO driver in that accepted more relaxed SPIR-V shaders..
still Nvidia has more problems than even AMDVLK seems..

In the https://paste.ubuntu.com/p/SqyDxQbKwn/ shader, it's causing a crash because there is "OpTypeImage %float 3D 1 0 0 1 Unknown" in the shader that we don't handle. There is no crash in https://paste.ubuntu.com/p/xDgZXbhfWc/ because the dead-code elimination has removed it since it's not referenced anywhere. We have no support for depth-sampling a 3D image so never expected to see a 3D image created with depth set. Any ideas why this OpTypeImage is being emitted?

Hmm, looks like a bug in the DXBC to SPIRV compiler to me.

https://github.com/doitsujin/dxvk/search?utf8=✓&q=defImageType&type=

one more post here today..
I tested forcing disabling depth bounds test and 2 other caps requeriments for DXVK working on Intel HD530 with Anvil Mesa driver and tested lots of games..
good news is compatibility is very high.. lots work OK..
even Superposition and doesn't need hlsl legalization.. just as good as RADV..
proof:

@pdaniell-nv DXVK generated those depth types for all sampled image types. As far as I'm aware, it's not illegal to do that in SPIR-V, although certainly unnecessary. In any case, thanks for the information - I restricted that to 2D and Cube textures now though, so this particular problem should be fixed.
There are however more issues. I don't have an Nvidia card myself to test at the moment, but an example of a compute shader that apparently crashes the driver is https://pastebin.com/6cmCE49u this one. Inlining the cs_main function seems to do the trick in this case.
@oscarbg good job. Disabling depth bounds test on Intel is something I had in mind as a potential workaround, but the other two (image store/load without format) are a bit more problematic.

@pdaniell-nv I already reported this example in Nvidia customer care, but all you need to do is start start.bat file in debugger
https://mega.nz/#!ZJI31JwS!k2grgsQwxmvojVvhqhSnHYIQkv30Yr5FHRqfrbs6LbI

There are 3 different shaders in bin\example\shader_opt:

default produced by dxvk (crash): CS_3e57aa98bdc58df0415b95c62877ef9e630eff9f.spv_unopt
optimized using SPIRV Tools (no crash): CS_3e57aa98bdc58df0415b95c62877ef9e630eff9f.spv_opt
modified by removing inline (no crash): CS_3e57aa98bdc58df0415b95c62877ef9e630eff9f.spv_mod

Disassemblies:

default : unopt_dis
modified: mod_dis

Replace wanted shader with CS_3e57aa98bdc58df0415b95c62877ef9e630eff9f.spv

Start program using bin\example\start.bat

@oscarbg

with a bat file I legalize shaders with something like:
for /f %%f in ('dir /b *.spv') do spirv-opt %%f --legalize-hlsl -o %%f.leg
@ZeroFault @SveSop @doitsujin
I'm using the spirv-opt executable included in the new Vulkan SDK 1.0.68 for Windows:
and as I say I don't see any errors like:
error: 514: Illegal number of components (5) for TypeVector
and also don't need to use --skip-validation argument in spirv-opt as I say it runs correctly with:
spirv-opt %%f --legalize-hlsl -o %%f.leg

If you look at spirv-opt --help, you can see that --legalize-hlsl does the following:
--legalize-hlsl
               Runs a series of optimizations that attempts to take SPIR-V
               generated by and HLSL front-end and generate legal Vulkan SPIR-V.
               The optimizations are:

		inline-entry-points-exhaustive
		eliminate-dead-functions
		private-to-local
		scalar-replacement
		eliminate-local-single-block
		eliminate-local-single-store
		eliminate-local-multi-store
		simplify-instructions
		eliminate-dead-branches
		eliminate-dead-inserts
		eliminate-dead-code-aggressive

               Note this does not guarantee legal code. This option implies
               --skip-validation.

Note the latest about --skip-validation
What i and others did was try to pinpoint which of THOSE was necessary to run superposition, and it seems as 3 shaders needs: --inline-entry-points-exhaustive --skip-validation --eliminate-dead-code-aggressive
Running eg. Unigine Valley/Heaven, the --skip-validation is not necessary.
Recap: Running --legalize-hlsl does ALL of the above optimizations, including --skip-validation, therefor you will not see that particular error mentioned earlier :)

@doitsujin Regarding https://pastebin.com/6cmCE49u it appears we have a couple of issues with this. Our inliner didn't handle this well, which is why when you inlined it yourself it worked better. I'm not sure yet why our inliner had a problem, but I'll report it to our compiler team to investigate.
The other issue we have with that shader is we don't support OpImageQuerySizeLod or OpImageQueryLevels on non-sampled images. If these ops were used on the %16 image "OpTypeImage %float 2D 1 0 0 1 Unknown" they would have worked okay. Core Vulkan/SPIR-V doesn't really support levels with storage images; there is no way to access texels from Lod>0 through OpImageRead/OpImageWrite. Because of this there is probably limited utility in using OpImageQuerySizeLod or OpImageQueryLevels on non-sampled images.
In that shader, you can get it to work by making the following modification:
         %31 = OpLoad %16 %u0  # changed from %17 to %16
         %33 = OpImageQuerySizeLod %v2uint %31 %30
         %34 = OpLoad %16 %u0  # changed from %17 to %16
         %35 = OpImageQueryLevels %uint %34

That appears to fix the inlining crash too, so they're probably related.
I may investigate a SPIR-V spec fix for this. I think in unextended SPIR-V 1.2 that OpImageQuerySizeLod and  OpImageQueryLevels  should only be defined to work with sampled images. It looks like the SPV_AMD_shader_image_load_store_lod extension adds Lod support to storage images.

@nairaner This looks like another case of OpImageQueryLevels being used with a storage image rather than a sample image. If possible, try to use OpImageQuerySizeLod and OpImageQueryLevels only with sampled images.
Actually, the CS_3e57aa98bdc58df0415b95c62877ef9e630eff9f.spv shader looks similar to https://pastebin.com/6cmCE49u.

@pdaniell-nv I did some testing with Unigine Heaven, and found the two shaders i need to get things running.
Take a look at : nVidia issues #64

Here is wine log for default Medium preset but Windowed on GeForce GTX 750 Ti 387.34.
Looks normal as I see this benchmark for the first time. First scene starting with too dark environment but later all looks good. Min:11-15/Avg:18/Max:23-25 fps
dxvk-superposition-wine.log
It's custom linux build w/ dll-redirect support and "auto legalizer", so I can run lancher with d3d11.dll and set redirects to d3d11_vk.dll only for superposition.exe. Then it runs.
Otherwise launcher starts as black screen with no controls visible. Trick with replacing original dlls with dxvk "on the fly" works too.

@pdaniell-nv that makes sense, again thanks for the info. That looks like a problem in my implementation of the resinfo instruction (and possibly others) when used on image UAVs, which are mapped to non-sampled images.

@pingubot Could you test if Superposition starts and runs until scene #9 with the 3 shaders attached in "working.tar.gz"?
The broken ones i attach in "broken.tar.gz". I ran: spirv-opt --inline-entry-points-exhaustive --skip-validation --eliminate-dead-code-aggressive to get them working.
Just be aware that there is 1 or maybe more shaders that does not work tho, cos it will crash at "scene #9" when running benchmark or cinematic mode.
broken.tar.gz
working.tar.gz

@pingubot Found the 4th one that will make Superposition run without crashing. Same deal "working.tar.gz" and "broken.tar.gz" for comparison.
@pdaniell-nv This is with nVidia Linux driver 390.25 tho. And if you look at my earlier post with the screenshot Screenshot Its almost as its a thin layer of dust on everything. (Perhaps not that bad, since it looks like a lab from the 60'ies heh)
broken.tar.gz
working.tar.gz

Have been so caught up with finding crashing shaders, that i havent really payed much attention to the logs.. But now that those 4 shaders get things running somewhat "ok", i saw the logs having quite a few:
err:   D3D11Device::CreateGeometryShaderWithStreamOutput: Not implemented
Guess something that will be implemented at some point?
err:   D3D11Device::CreateBuffer: D3D11_BIND_STREAM_OUTPUT not supported
err:   D3D11DeviceContext::SOSetTargets: Not implemented

More of the same i guess.
Attaching logs for giggles and laughs :)
superposition_d3d11.log
superposition_dxgi.log

@doitsujin sorry for lack of clarity for Intel HD graphics working I disabled depth bounds which upped support to feature level 10.1 but for 11.0 only needed disabling shaderStorageImageReadWithoutFormat as shaderStorageImageWriteWithoutFormat is already supported (see: https://vulkan.gpuinfo.org/displayreport.php?id=2600#features)  the other one I have to disable is variableMultisampleRate (as you can see from linked report is missing on Intel Mesa aka Anvil driver)..
anyway I still have working antialiasing on some apps like on Witness on iGPU so what you are using variableMultisampleRate for?
good news is that variableMultisampleRate is supported on Windows Intel HD graphics closed source Vulkan driver (see: https://vulkan.gpuinfo.org/displayreport.php?id=2529#features) so should have to disable only depth bounds and shaderStorageImageReadWithoutFormat  there.. it also shows that Mesa devs can implement variableMultisampleRate support on Intel HD graphics.. perhaps do a request on mesa-dev mailing list? I mean is not like depth bounds test support that seems is not supported in HW by current Intel HD graphics..
but somewhat sad is I tested also Intel HD graphics on Windows closed source Vulkan driver but I'm getting a hang somewhere inside their driver igvk64.dll  I think.. so have to debug more..

@pdaniell-nv @doitsujin
I think I'm on to something interesting with DXVK+NV using ComputeMark2..
Please test these repro:
ComputeMark2repro.zip

it's ComputeMark2 with DXVK precompiled and included spir-v files of all benchmarks..
I'm using the latest dxvk including all latest 2 NV fixes:
[dxbc] Use correct image query instructions for UAVs
[dxvk] Only emit depth image types for 2D and Cube images
Please run either ComputeMark.exe or runanddump.bat file that will also redump files..

it's very easy from Windows10 just run ComputeMark.exe then from "Burn test demo" select the individual test you want and select Go button: MandelS and Fluid3D are of interest.. a window will be created for running the test but this window will remain black all the test..
at least for me on Nvidia GTX 970+390.65 driver..
the thing is all spir-v files produced by DXVK are now valid according to spirv-val (i.e. doesn't require running spirv-opt)..
you can check that files on spirvshadersnv folder and from that folder a valshaders.bat will run spir-val for each spir-v file without any warnings/or errors..
even one test (MandelS) doesn't report any errors creating pipelines (see ComputeMark_d3d11mandels.log captured with "DXVK_LOG_LEVEL=debug").. still the windows obtained is black..
"err:   DxvkComputePipeline: Failed to compile pipeline"
there are two cases to test:
a)run
of course all this run and render OK on AMD Vulkan driver on Windows..

Thanks @oscarbg. I ran the new ComputeMark2repro.zip. The shaders that have OpBitFieldInsert found a bug in our compiler in that we didn't handle the "Offset" and "Count" operands being anything other than signed int. This causes a crash in the compiler. I fixed it locally to handle both signed and unsigned and I was able to get all ComputeMark.exe tests to compile without fault in our compiler.
Unfortunately, all tests produce a black window. I didn't get a chance to investigate why this is. My guess is maybe there is a mismatch between the shader and the pipeline layout such that some resources aren't being picked up.
Have you tried running this with Vulkan validation enabled? Perhaps tweak DXVK to emit integers for the "Offset" and "Count" operands of OpBitFieldInsert and OpBitField{S,U}Extract and see what the Vulkan validation says.
In the meantime we'll work on getting the compiler fixes for the driver released.

FYI, I force enabled validation layers locally and there are a few errors being output. One of them which may give a clue is this one:

DS(ERROR / SPEC): object: 0x452 type: 23 msgNum: 364905100 - vkUpdateDescriptorSets() failed write update validation for Descriptor Set 0x452 with error: Write update to descriptor in set 1106 binding #3 failed with error message: Attempted write update to image descriptor failed due to: ImageView (77) with usage mask 0x23 being used for a descriptor update of type VK_DESCRIPTOR_TYPE_STORAGE_IMAGE does not have VK_IMAGE_USAGE_STORAGE_BIT set.. The spec valid usage text states 'If descriptorType is VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER, VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE, VK_DESCRIPTOR_TYPE_STORAGE_IMAGE, or VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT, the imageView and imageLayout members of each element of pImageInfo must be a valid VkImageView and VkImageLayout, respectively' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkWriteDescriptorSet-descriptorType-00326)

Can confirm the error output. Strangely though, explicitly adding VK_DESCRIPTOR_TYPE_STORAGE_IMAGE to the usage flags of all images created by D3D does not solve the problem, so right now I have no idea what might be causing this.

@pdaniell-nv thanks for giving an inspection to the repro and glad to help NV fix some bugs.. to be clear I'm not a dev of DXVK only pointed you to issues using it on NV GPUs vs on AMD..
@doitsujin sad it's an app bug.. thanks also for giving some of your time to investigate the cause.. seeing your findings and if not much work would be glad if you implement that workaround.. primary reason is maybe is not be the unique D3D11 app doing it badly but working OK on D3D11 drivers..
also strangely enough this app works correctly on Wine D3D11->OGL wrapper on AMD and NV GPUs if I recall correctly so seems in some way OpenGL is more forgiving or Mesa devs also ignore/set some flags independent of what the app says..

@oscarbg OpenGL simply does not have explicit usage flags, so you can't get them wrong in the first place.

Edit: The validation errors actually seem to be caused by an application bug, it's trying to use a depth-stencil image with a UAV but never sets the appropriate D3D11 bind flags. Might call for an application-specific workaround.

I think it's a DXVK bug. CreateUnorderedAccessView() should fail if  D3D11_BIND_UNORDERED_ACCESS is not set. There is probably a test for this behavior in Wine conformance tests.

@pingubot Are you referring to https://github.com/doitsujin/dxvk/issues/70#issuecomment-366338851?

I figured out what was causing the ComputeMark issue, the application wants to use the swap chain image as an unordered access view which was not handled properly. It's the first time I see an application do that.
Fixed in 8813ff979a49d2ae0ae3e6d1a88ad0ac12d48993.

@doitsujin aargh.. first thanks to all @jozefkucia @pdaniell-nv and for your effort I feel somewhat guilty now.. I remember reading that many many years ago by the guy who implemented that.. really I vaguely remembered that this app "rendered right from the RWTexture it use to simulate"  so I already have in my mind some though that ComputeMark was a "special" D3D11 to test so I insisted you to fix support it the same way  a year ago already insisted Wine D3D11 devs to make it work..
I have been spending some time to refind it.. and so here, just for completeness, let's point to original individual demos (with source code!) done by Voxilla very shortly (within 1 month) D3D11 drivers started appearing for AMD 58xx series.. (circa end 2009) (maybe some of you were kids still by then :-)) :
users.skynet.be/fquake/
here you can find also some demo not included in ComputeMark:
3D waves simulator (DX11) tough I expect it to work..
and now I see under "DX11 DirectCompute Mandelbrot and Julia viewer" on this site,
a DX11 feature level DX10 version:
http://users.skynet.be/fquake/MandelDX11_10.zip
and note this:

DX10 support
In order to support DX10 GPUs the DX11 feature level DX10 version should be used.
It will try to make use of compute shader 4 instead of compute shader 5.
This requires an additional pass with a pixel shader to copy compute shader output to the screen.
this demo should work now on Intel HD 530 Mesa driver now that you disabled depth bounds requeriment so gonna give it a try..

@doitsujin been playing with these demos and found that is has built a new Mandel version with AVX512 demo (http://users.skynet.be/fquake/Mandel_AVX512.zip)..
seems no source code shared but what it's interesting on this demo it uses HLSL doubles..
maybe one of few codes/demos using it..
using your latest DXVK says with a popup window: (GPU doesn't support doubles (FP46)
as expected, as DXVK doesn't support that optional D3D11 cap..
as said not really needed, only poiting for if you someday feel really bored..
see doubles in use:
`void CSMandelJulia_scalarDouble1( uint3 Gid : SV_GroupID, uint3 DTid : SV_DispatchThreadID, uint3 GTid : SV_GroupThreadID, uint GI : SV_GroupIndex )
//****************************************************************************
{
int counter = max_iterations & (~(UNROLL-1));
**double** u,v;
u = (**double**)(a0 + da*DTid.x);
v = (**double**)(b0 + db*DTid.y);

double a,b;
a = (julia) ? (double) ja0 : u;
b = (julia) ? (double) jb0 : v;
bool inside;
double ur, vr, t;`

Two comments from previous posts:
*Please don't waste time with http://users.skynet.be/fquake/MandelDX11_10.zip I wasted my time already it doesn't even work natively on Windows..
*Note also Wine D3D11 also doesn't support doubles from my testing.. @jozefkucia, right?

*Note also Wine D3D11 also doesn't support doubles from my testing.. @jozefkucia, right?

Yes, wined3d doesn't support doubles yet.

One funny side-effect of https://github.com/doitsujin/dxvk/commit/4c693fc2624a8d37288815125aba19fa0a3aef0b is that Superposition GUI almost works as it should.. It's still no better than wine-devel, as the text in the menus will be gone once you click on them, but vs. the black box before spirv-tools auto-optimize its a improvement :)
Now if only @pdaniell-nv  would come up with an idea why #90 happens to me and another user with GTX 970, but not for one with GTX 750, that would be great :)

Nothing springs to mind. Do you see any validation errors?
There are a few physical device feature and property differences between GTX 750 and GTX 970. There is this new LunarG layer that fakes the physical device properties (https://www.lunarg.com/new-vulkan-dev-sim-layer/). It might be worth simulating the GTX 750 on your GTX 970 and see if if produces the same result. If so, then I guess DXVK is reacting to some physical device property.
If you want me to look more into it, would you mind making it easy to reproduce on Windows. Perhaps with some instructions or a .zip package with some binaries. Thanks.

@pdaniell-nv Since you hopefully have kept up with the dxvk<->spirv problems when it comes with different validations for nVidia, things work "out-of-the-box" for AMD, but nVidia needs different spirv-opt (like --legalize-hlsl) to not crash. After doing this, there is no validation errors on the shaders, and driver does not crash... but for me atleast produces this weird coloring.
I will look into this simulation thing, and see if i can "fake" a 750.
I have not tested this in "real" windows, but what i have tested is Unigine Superposition https://benchmark.unigine.com/superposition?lang=en (free version), both wine-staging-2.21 and wine-vulkan-3.2 with DXVK. Tested 387.34 and 390.25 driver in Linux. The driver revisions is different in Windows as you are quite aware of, but what 390.25 corresponds to in windows i dont know.
In theory if it is the driver and the same bug with dxvk, it should happen in windows to.
Binary builds of DXVK: https://haagch.frickel.club/files/dxvk/
There SHOULD not be a difference if i use the Ubuntu binary .deb driver vs. downloading the .run file from nVidia.com? I mean, the "driver" part is closed source binary blob and not really what is being compiled afaik?

@pdaniell-nv
Did some fiddling with the simulation layer, and saw that both the "DXVK HUD" showed changes, and VulkanCapsViewer showed changes when i used different layers. I downloaded a few for testing from https://vulkan.gpuinfo.org/
Tried with various 750Ti driver versions and Linux/windows++ and tested with a few different from 970. Problem did not change, although i had a couple of instances with random weird artifacts. I also tested with Intel/Amd, but not suprisingly that ended up in a crash.
It does seem to do with surface lightning of some sort.. Might be hard to see just from the couple of screenshots i have put up, but when (in Superposition) i move to dark spots with low light, the surfaces look mostly normal... its when the light kinda shines "too bright" on the surface that it looks that bad. I guess its the same in Unigine Valley, as some darker scenes does not look that bad, but when the well-lit hillsides show up, its just "too bright".

@pdaniell-nv Also take a look at my screenshots https://github.com/doitsujin/dxvk/issues/90#issuecomment-368323734
And my comment above in the same thread does not show this bug in "The Talos Principle" either with wine vulkan, or wine dxvk. Two different graphics engines tho.

@pdaniell-nv
I don't think declaring Integer depth images makes any sense, so I guess I'll change the compiler to only emit depth image declarations when they are actually needed - which is a bit of a hassle, but should prevent bugs like this one in the future. For now I've filtered out the
As for the signed integer issue, are you aware of any other instructions which make this assumption? I changed the compiler to use signed integers for those instructions (as well as OpBitFieldInsert).
I also disabled the workaround that packs the reference value from depth-compare operations into the coordinate vector, which was why the five-dimensional vectors were generated. Hopefully this workaround is actually not needed (anymore) for those instructions.

@pdaniell-nv
Thank you for help on these issues. We really appreciate it.
Your OpBitField suggestion helped compile those shaders from Heaven's benchmark successfully.
There is another issue in Heaven's benchmark that we need help with. These shaders are crashing in the Nvidia driver. This happened after we removed the packing Dref value into the coordinate vectors in the lastest commit of DXVK. These shaders work fine on AMD.
dref_failingshaders.zip

@doitsujin Somewhat minor issue with that commit
https://github.com/doitsujin/dxvk/commit/8bfd12067aaaaab34a1cd9036be1e66b99f12434#commitcomment-27846864

@SveSop I'm fully aware that the commit breaks pretty much everything on Nvidia. But the old workaround was fundamentally broken as it caused the compiler to generate invalid SPIR-V in a lot of cases.
What I need is clarification as to why depth-compare operations don't work properly on their driver and what I can to to work around it.

@doitsujin Since you were fully aware, a comment about "Will break nVidia rendering" on the commit text would be nice :)

@doitsujin

I'm fully aware that the commit breaks pretty much everything on Nvidia.

Not sure about this one but recent commits fixes invisible character and NPCs heads in The Witcher 3. Heads a bit not synchronized with body while they (characters) moving (that looks like in scary movie when face changed reveals villain's real nature) but visible.

@ZeroFault Thanks for attaching the broken shaders. I investigated the issue and it appears to have hit another bug in our compiler. I'm confirming with our compiler guys to be sure. In this case it appears we're not handling OpImageSampleDrefExplicitLod correctly. Our bug here is probably what drove the work-around DXVK implemented for NVIDIA that packs the depth parameter with the coordinate. FWIW, you shouldn't need this work-around for cube, cube-array and 2d-array depth images. I think those are probably the cases that generate the OpTypeVector(5), so you can fix that too.
A slightly simpler work-around is to simply use a +1 larger Coordinate vector for the dref Ops. The last component is actually ignored and the proper Dref is the one it actually uses. The larger Coord vector is needed because internally we move the Dref into that last slot and our bug was that we neglected to increase the size of the vector to take the Dref. So with your work-around of putting the Dref into the Coord effectively made it +1 bigger and worked-around the bug.
I'll see what our compiler folks say and try to get the fix in the driver asap.

Thinking about this more, it seems crazy we have this bug because surely Vulkan CTS would have caught it, because it definitely tests all the Dref image ops.
Turns out a bug in glslang is masking it, and most Vulkan CTS tests are written in GLSL.
With GLSL you have to pack the Dref into the cord. The prototype is "textureLod(sampler2DShadow, vec3, float)". The Dref is in the last slot of the vec3 coordinate. When glslang generates the SPIR-V what it should do is shrink the coord down to a vec2 since OpImageSampleDrefExplicitLod with a 2D depth image only needs a vec2, but it doesn't, it leaves it as vec3. This masked our bug.

I don't really think it's a bug in glslang, it's just being lazy and exploiting the SPIR-V spec:

Coordinate must be a scalar or vector of floating-point type. It contains (u[, v] . . . [,
array layer]) as needed by the definition of Sampled Image. It may be a vector larger
than needed, but all unused components will appear after all used components.

Anyway, I'll implement a new workaround.

0e9b7d7ccdcc6ca457576f44c2e2201c59e4a968 adds a new workaround for the dref issue.

@pdaniell-nv while you watching
https://forums.geforce.com/default/topic/1014038/nvidia-driver-bug-with-glsl-mat3-in-vulkan-/
Met this while googling some time ago. Maybe it's not related or not a bug.

Hi all,
@doitsujin
fixed Intel HD Windows driver support.. the issue is about calling vkCreateInstance on his driver ends up calling your dxgi CreateDXGIFactory or CreateDXGIFactory1 method which also ends up calling vkCreateInstance
I created a very lame patch to solve the issue.. (I opened a issue: with the diff I apply)
of course disable shaderStorageImageReadWithoutFormat and with that
just completed testing DXVK in the latest Vulkan Desktop driver remaining: the Intel HD Windows Vulkan driver..
results seems pretty good:

Closing because the original issue has been resolved.


dyld: Library Not Loaded

I have issues
Installing the EKS module with VPC
I'm submitting a...

[X ] bug report
[ ] feature request
[ ] support request - read the FAQ first!
[ ] kudos, thank you, warm fuzzy

What is the current behavior?
Terraform errors out at the end of applying my plan with this message:
module.my-cluster.module.my-cluster.null_resource.wait_for_cluster[0]: Still creating... [3m0s elapsed]
module.my-cluster.module.my-cluster.null_resource.wait_for_cluster[0] (local-exec): dyld: Library not loaded: /usr/local/opt/libidn2/lib/libidn2.4.dylib
module.my-cluster.module.my-cluster.null_resource.wait_for_cluster[0] (local-exec):   Referenced from: /usr/local/bin/wget
module.my-cluster.module.my-cluster.null_resource.wait_for_cluster[0] (local-exec):   Reason: image not found
module.my-cluster.module.my-cluster.null_resource.wait_for_cluster[0] (local-exec): /bin/sh: line 1: 46698 Abort trap: 6           wget --no-check-certificate -O - -q $ENDPOINT/healthz > /dev/null
module.my-cluster.module.my-cluster.null_resource.wait_for_cluster[0] (local-exec): dyld: Library not loaded: /usr/local/opt/libidn2/lib/libidn2.4.dylib
module.my-cluster.module.my-cluster.null_resource.wait_for_cluster[0] (local-exec):   Referenced from: /usr/local/bin/wget
module.my-cluster.module.my-cluster.null_resource.wait_for_cluster[0] (local-exec):   Reason: image not found
module.my-cluster.module.my-cluster.null_resource.wait_for_cluster[0] (local-exec): /bin/sh: line 1: 46700 Abort trap: 6           wget --no-check-certificate -O - -q $ENDPOINT/healthz > /dev/null
module.my-cluster.module.my-cluster.null_resource.wait_for_cluster[0]: Still creating... [3m10s elapsed]

If this is a bug, how to reproduce? Please include a code sample if relevant.
I'm not sure what would be helpful to reproduce this error. As far as I can remember this code was working, but when I reran it recently I ran into this error.
What's the expected behavior?
EKS cluster should be created without error.
Are you able to fix this problem and submit a PR? Link here if you have already.
Environment details

Affected module version:

provider.aws v2.53.0
provider.http v1.1.0
provider.kubernetes v1.11.3
provider.local v1.4.0
provider.null v2.1.2
provider.random v2.2.1

OS: mac high sierra 10.13.4
Terraform version: Terraform v0.12.19

Any other relevant info

Looks like there's either something wrong with your wget install or how Terraform is trying to call it. What happens if you run /usr/local/bin/wget directly?

I missed that in the output, thanks for pointing it out.  I'm on a mac, so reinstalling wget with brew brew reinstall -s wget is what got it working. Thanks.