random disconnect on windows

When running this project on Windows and connecting to it locally I am able to connect for ~30 seconds and then get disconnected. This doesn't happen when running on Mac and connecting locally. Also doesn't happen when running the server on Windows and connecting from another machine.
In other words:

client remote
client local

server Windows
👍
👎

server Mac
👍
👍

Here are logs from when running in the problematic setup:
server logs:
2020/12/18 10:05:16 http.go:135: OnICECandidate (IP removed)
2020/12/18 10:05:16 http.go:135: OnICECandidate (IP removed)
2020/12/18 10:05:16 http.go:135: OnICECandidate (IP removed)
2020/12/18 10:05:16 http.go:137: OnICECandidate <nil>
2020/12/18 10:05:16 http.go:250: OnICEConnectionStateChange connected
2020/12/18 10:05:16 http.go:264: start stream demo1 client 7C31F9E7-932A-494A-F07D-0EC2D58B5BCB
2020/12/18 10:05:16 http.go:131: OnConnectionStateChange connected
2020/12/18 10:05:48 http.go:131: OnConnectionStateChange disconnected
2020/12/18 10:05:48 http.go:250: OnICEConnectionStateChange disconnected
2020/12/18 10:05:48 http.go:250: OnICEConnectionStateChange closed
2020/12/18 10:05:48 http.go:280: Control closed
2020/12/18 10:05:48 http.go:266: stop stream demo1 client 7C31F9E7-932A-494A-F07D-0EC2D58B5BCB
2020/12/18 10:05:48 http.go:131: OnConnectionStateChange closed

client chrome webrtc-internals:
12/18/2020, 10:05:16 AM | iceconnectionstatechangeconnected
-- | --
12/18/2020, 10:05:16 AM | iceconnectionstatechange (legacy)connected
12/18/2020, 10:05:16 AM | connectionstatechangeconnected
12/18/2020, 10:05:16 AM | iceconnectionstatechange (legacy)completed
12/18/2020, 10:05:55 AM | iceconnectionstatechangedisconnected
12/18/2020, 10:05:55 AM | iceconnectionstatechange (legacy)connected
12/18/2020, 10:05:55 AM | iceconnectionstatechange (legacy)disconnected
12/18/2020, 10:05:55 AM | connectionstatechangedisconnected
12/18/2020, 10:06:05 AM | iceconnectionstatechange (legacy)failed
12/18/2020, 10:06:05 AM | connectionstatechangefailed

client console:
(index):109 (2) 1 track is delivered
(index):161 connectionstatechange connecting
(index):162 iceconnectionstatechange connected
(index):161 connectionstatechange connected
(index):162 iceconnectionstatechange disconnected
(index):161 connectionstatechange disconnected
(index):161 connectionstatechange failed

It appears as though the connection just quits... but this is all running locally! There is also no log in the Go code that would point to a reason for the disconnect.

This is similar to https://github.com/pion/webrtc/issues/1500.
Although I see in their log Client Close Keep-Alive Timer which indicates the heartbeat stopped or failed so the timeout was reached. I never got that message and in the latest code I removed the heartbeat code since it was using Timer.Reset incorrectly. From the docs:

Reset should be invoked only on stopped or expired timers with drained channels. If a program has already received a value from t.C, the timer is known to have expired and the channel drained, so t.Reset can be used directly. If a program has not yet received a value from t.C, however, the timer must be stopped and—if Stop reports that the timer expired before being stopped—the channel explicitly drained

However the fact this happens after 30 seconds seems suspicious.

I figured out how to turn on debug logging in pion:
2020/12/18 13:16:23 http.go:141: OnSignalingStateChange stable
2020/12/18 13:16:23 http.go:135: OnICECandidate <IP_ADDRESS>
2020/12/18 13:16:23 http.go:135: OnICECandidate <IP_ADDRESS>
2020/12/18 13:16:23 http.go:135: OnICECandidate <IP_ADDRESS>
2020/12/18 13:16:23 http.go:135: OnICECandidate (redacted)
[GIN] 2020/12/18 - 13:16:23 |←[97;42m 200 ←[0m|    141.1105ms |       <IP_ADDRESS> |←[97;46m POST    ←[0m "/rec
eive"
2020/12/18 13:16:23 http.go:137: OnICECandidate <nil>
ice DEBUG: 13:16:23.639030 agent.go:1123: adding a new peer-reflexive candidate: <IP_ADDRESS>:62637
ice TRACE: 13:16:23.639030 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host 172.31.112.
1:62641
ice TRACE: 13:16:23.640028 agent.go:983: ping STUN from host <IP_ADDRESS>:62641 to prflx <IP_ADDRESS>:62637
related :0
ice TRACE: 13:16:23.640028 agent.go:676: pinging all candidates
ice TRACE: 13:16:23.640028 agent.go:983: ping STUN from host <IP_ADDRESS>:62641 to prflx <IP_ADDRESS>:62637
related :0
ice TRACE: 13:16:23.641028 agent.go:983: ping STUN from host <IP_ADDRESS>:62642 to prflx <IP_ADDRESS>:62637 r
elated :0
ice TRACE: 13:16:23.641028 agent.go:983: ping STUN from host <IP_ADDRESS>:62643 to prflx <IP_ADDRESS>:62637
related :0
ice TRACE: 13:16:23.641028 candidatepair.go:92: failed to send STUN message: failed to send packet: write ud
p <IP_ADDRESS>:62643-><IP_ADDRESS>:62637: wsasendto: A socket operation was attempted to an unreachable netw
ork.
ice TRACE: 13:16:23.642029 agent.go:983: ping STUN from srflx (redacted):58686 related <IP_ADDRESS>:58686 to p
rflx <IP_ADDRESS>:62637 related :0
ice TRACE: 13:16:23.643050 selection.go:261: inbound STUN (SuccessResponse) from prflx <IP_ADDRESS>:62637 re
lated :0 to host <IP_ADDRESS>:62641
ice TRACE: 13:16:23.643050 selection.go:271: Found valid candidate pair: prio<PHONE_NUMBER>314175487 (local, pr
io<PHONE_NUMBER>) host <IP_ADDRESS>:62641 <-> prflx <IP_ADDRESS>:62637 related :0 (remote, prio<PHONE_NUMBER>)
ice TRACE: 13:16:23.644029 selection.go:261: inbound STUN (SuccessResponse) from prflx <IP_ADDRESS>:62637 re
lated :0 to srflx (redacted):58686 related <IP_ADDRESS>:58686
ice TRACE: 13:16:23.644029 selection.go:271: Found valid candidate pair: prio<PHONE_NUMBER>565797376 (local, pr
io<PHONE_NUMBER>) srflx (redacted):58686 related <IP_ADDRESS>:58686 <-> prflx <IP_ADDRESS>:62637 related :0 (remo
te, prio<PHONE_NUMBER>)
ice TRACE: 13:16:23.645029 selection.go:261: inbound STUN (SuccessResponse) from prflx <IP_ADDRESS>:62637 re
lated :0 to host <IP_ADDRESS>:62641
ice TRACE: 13:16:23.645029 selection.go:271: Found valid candidate pair: prio<PHONE_NUMBER>314175487 (local, pr
io<PHONE_NUMBER>) host <IP_ADDRESS>:62641 <-> prflx <IP_ADDRESS>:62637 related :0 (remote, prio<PHONE_NUMBER>)
ice TRACE: 13:16:23.688060 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host 172.31.112.
1:62641
ice TRACE: 13:16:23.688060 agent.go:653: Set selected candidate pair: prio<PHONE_NUMBER>314175487 (local, prio
2130706431) host <IP_ADDRESS>:62641 <-> prflx <IP_ADDRESS>:62637 related :0 (remote, prio<PHONE_NUMBER>)
ice INFO: 2020/12/18 13:16:23 Setting new connection state: Connected
pc INFO: 2020/12/18 13:16:23 ICE connection state changed: connected
dtls TRACE: 13:16:23.689025 handshaker.go:146: [handshake:server] Flight 0: Preparing
2020/12/18 13:16:23 http.go:250: OnICEConnectionStateChange connected
dtls TRACE: 13:16:23.689025 handshaker.go:146: [handshake:server] Flight 0: Sending
2020/12/18 13:16:23 http.go:264: start stream demo1 client 3124BDFF-A487-AC51-A636-EFAB0B3FA392
dtls TRACE: 13:16:23.689025 handshaker.go:146: [handshake:server] Flight 0: Waiting
dtls TRACE: 13:16:23.690030 handshaker.go:261: [handshake:server] Flight 0 -> Flight 2
dtls TRACE: 13:16:23.690030 handshaker.go:146: [handshake:server] Flight 2: Preparing
dtls TRACE: 13:16:23.690030 handshaker.go:146: [handshake:server] Flight 2: Sending
dtls TRACE: 13:16:23.690030 conn.go:371: [handshake:server] -> HelloVerifyRequest (epoch: 0, seq: 0)
dtls TRACE: 13:16:23.691027 handshaker.go:146: [handshake:server] Flight 2: Waiting
dtls TRACE: 13:16:23.691027 handshaker.go:261: [handshake:server] Flight 2 -> Flight 4
dtls TRACE: 13:16:23.692028 handshaker.go:146: [handshake:server] Flight 4: Preparing
dtls TRACE: 13:16:23.692028 handshaker.go:146: [handshake:server] Flight 4: Sending
dtls TRACE: 13:16:23.692028 conn.go:371: [handshake:server] -> ServerHello (epoch: 0, seq: 1)
dtls TRACE: 13:16:23.692028 conn.go:371: [handshake:server] -> TypeCertificate (epoch: 0, seq: 2)
dtls TRACE: 13:16:23.693029 conn.go:371: [handshake:server] -> ServerKeyExchange (epoch: 0, seq: 3)
dtls TRACE: 13:16:23.693029 conn.go:371: [handshake:server] -> CertificateRequest (epoch: 0, seq: 4)
dtls TRACE: 13:16:23.693029 conn.go:371: [handshake:server] -> ServerHelloDone (epoch: 0, seq: 5)
dtls TRACE: 13:16:23.693029 handshaker.go:146: [handshake:server] Flight 4: Waiting
dtls DEBUG: 13:16:23.694032 conn.go:721: CipherSuite not initialized, queuing packet
dtls DEBUG: 13:16:23.695029 conn.go:643: received packet of next epoch, queuing packet
dtls TRACE: 13:16:23.696026 conn.go:727: server: <- ChangeCipherSpec (epoch: 1)
dtls TRACE: 13:16:23.696026 handshaker.go:261: [handshake:server] Flight 4 -> Flight 6
dtls TRACE: 13:16:23.696026 handshaker.go:146: [handshake:server] Flight 6: Preparing
dtls TRACE: 13:16:23.696026 handshaker.go:213: [handshake:server] -> changeCipherSpec (epoch: 1)
dtls TRACE: 13:16:23.697028 handshaker.go:146: [handshake:server] Flight 6: Sending
dtls TRACE: 13:16:23.697028 conn.go:371: [handshake:server] -> Finished (epoch: 1, seq: 6)
dtls TRACE: 13:16:23.697028 handshaker.go:146: [handshake:server] Flight 6: Finished
dtls TRACE: 13:16:23.698028 conn.go:197: Handshake Completed
pc INFO: 2020/12/18 13:16:23 peer connection state changed: connected
2020/12/18 13:16:23 http.go:131: OnConnectionStateChange connected
sctp TRACE: 13:16:23.699030 association.go:282: [0xc00007a680] updated cwnd=4380 ssthresh=0 inflight=0 (INI)

sctp DEBUG: 13:16:23.699030 association.go:414: [0xc00007a680] readLoop entered
sctp DEBUG: 13:16:23.699030 association.go:438: [0xc00007a680] writeLoop entered
sctp DEBUG: 13:16:23.699030 association.go:778: [0xc00007a680] state change: 'Closed' => 'CookieWait'
sctp DEBUG: 13:16:23.700028 association.go:323: [0xc00007a680] sending INIT
ice TRACE: 13:16:23.738028 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host 172.31.112.
1:62641
ice DEBUG: 13:16:23.787106 agent.go:1123: adding a new peer-reflexive candidate: <IP_ADDRESS>:62637
ice TRACE: 13:16:23.787106 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:23.788027 agent.go:983: ping STUN from host <IP_ADDRESS>:62642 to prflx <IP_ADDRESS>:62637 re
lated :0
ice TRACE: 13:16:23.788027 selection.go:208: checking keepalive
ice TRACE: 13:16:23.788027 selection.go:261: inbound STUN (SuccessResponse) from prflx <IP_ADDRESS>:62637 rel
ated :0 to host <IP_ADDRESS>:62642
ice TRACE: 13:16:23.788027 selection.go:271: Found valid candidate pair: prio<PHONE_NUMBER>314175487 (local, pr
io<PHONE_NUMBER>) host <IP_ADDRESS>:62642 <-> prflx <IP_ADDRESS>:62637 related :0 (remote, prio<PHONE_NUMBER>)
ice TRACE: 13:16:23.837078 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:23.886239 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:24.939018 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:25.461102 selection.go:208: checking keepalive
ice TRACE: 13:16:25.941962 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
sctp DEBUG: 13:16:26.700902 association.go:323: [0xc00007a680] sending INIT
ice TRACE: 13:16:26.945686 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:27.460274 selection.go:208: checking keepalive
ice TRACE: 13:16:29.453635 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:29.461643 selection.go:208: checking keepalive
ice TRACE: 13:16:31.461009 selection.go:208: checking keepalive
ice TRACE: 13:16:32.011112 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
sctp DEBUG: 13:16:32.700921 association.go:323: [0xc00007a680] sending INIT
ice TRACE: 13:16:33.460376 selection.go:208: checking keepalive
ice TRACE: 13:16:34.567363 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:35.460982 selection.go:208: checking keepalive
ice TRACE: 13:16:37.123887 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:37.460060 selection.go:208: checking keepalive
ice TRACE: 13:16:39.460305 selection.go:208: checking keepalive
ice TRACE: 13:16:39.630048 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:41.460823 selection.go:208: checking keepalive
ice TRACE: 13:16:42.187835 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:43.460722 selection.go:208: checking keepalive
sctp DEBUG: 13:16:44.701495 association.go:323: [0xc00007a680] sending INIT
ice TRACE: 13:16:44.742514 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:45.460156 selection.go:208: checking keepalive
ice TRACE: 13:16:47.298958 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:47.460315 selection.go:208: checking keepalive
ice TRACE: 13:16:49.460631 selection.go:208: checking keepalive
ice TRACE: 13:16:49.856015 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:51.460768 selection.go:208: checking keepalive
ice TRACE: 13:16:52.412928 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:53.461631 selection.go:208: checking keepalive
ice TRACE: 13:16:54.970148 agent.go:1127: inbound STUN (Request) from <IP_ADDRESS>:62637 to host <IP_ADDRESS>:
62642
ice TRACE: 13:16:55.460383 agent.go:653: Set selected candidate pair: <nil>
ice INFO: 2020/12/18 13:16:55 Setting new connection state: Disconnected
pc INFO: 2020/12/18 13:16:55 ICE connection state changed: disconnected
pc INFO: 2020/12/18 13:16:55 peer connection state changed: disconnected
2020/12/18 13:16:55 http.go:250: OnICEConnectionStateChange disconnected
2020/12/18 13:16:55 http.go:131: OnConnectionStateChange disconnected
pc WARNING: 2020/12/18 13:16:55 Failed to accept RTP SessionSRTP has been closed
pc WARNING: 2020/12/18 13:16:55 Failed to accept RTCP SessionSRTCP has been closed
pc WARNING: 2020/12/18 13:16:55 Could not determine PayloadType for SSRC<PHONE_NUMBER>
pc WARNING: 2020/12/18 13:16:55 Could not determine PayloadType for SSRC 765241525
ice INFO: 2020/12/18 13:16:55 Setting new connection state: Closed
sctp DEBUG: 13:16:55.462323 association.go:434: [0xc00007a680] readLoop exited EOF
pc WARNING: 2020/12/18 13:16:55 Failed to start SCTP: association closed before connecting
pc INFO: 2020/12/18 13:16:55 peer connection state changed: closed
2020/12/18 13:16:55 http.go:280: Control closed
2020/12/18 13:16:55 http.go:266: stop stream demo1 client 3124BDFF-A487-AC51-A636-EFAB0B3FA392
2020/12/18 13:16:55 http.go:131: OnConnectionStateChange closed
sctp DEBUG: 13:16:55.464323 association.go:778: [0xc00007a680] state change: 'CookieWait' => 'Closed'
sctp DEBUG: 13:16:55.465323 association.go:466: [0xc00007a680] writeLoop exited
pc INFO: 2020/12/18 13:16:55 ICE connection state changed: closed
2020/12/18 13:16:55 http.go:250: OnICEConnectionStateChange closed
2020/12/18 13:16:57 main.go:20: Got signal interrupt

I tracked it down to this timeout: https://github.com/pion/ice/blob/b21607a3050e6b1237eee4ce2e846181601b7ec4/agent.go#L761

I added some logged the timeout and the keep-alive candidates. Turns out the timeout is from a 172 address which is from WSL vEthernet adapter. It seems pion was tracking a remote candidate that was using the 172 address, which times out after 30 seconds. The candidate using my real 192 address was perfectly fine.

upgrading to v3 fixed the disconnect issue


added margins for mobile view

Fixed Issue #550 for GCI :)

Coverage remained the same at 82.507% when pulling f1246446f9eee6f857c4f0d8d8b58c8cc3323c19 on namantechlabs:patch-1 into 2898a70401ae1d7521a9e8c51347ec9710a74bdf on CircuitVerse:master.

@namantechlabs can you add a screenshot too ,so i will be confirmed that It's working fine.

Done!


Remove not needed code

Coverage decreased (-0.01%) to 28.502% when pulling ca181561da3c688a023f208d4d72651372192c54 on qingweibinary:qingwei/fix_contract_bug into 6668038a796a97ccd17c3beac801ea6b1dd98b5c on binary-com:master.


Question -- ember-redux philosophy?

I'm coming from a react/redux background and I'm trying to understand the philosophy behind ember-redux. With react-redux, the developer is in charge of creating the store using the Redux. Then you pass your store to the <Provider store={appStore} /> component which handle the subscribe change handler and passes the updated state to the connect component. The connect component really is just a simple wrapper to organize the properties.
The difference I see with ember-redux is that it tries to take over the redux store creation and sets the store up as an ember service.
Correct me if I'm wrong, but ember-redux currently has these requirements:

Only a single top-level reducer
Reducer must be defined in app/reducer/index.js
Can only have a single app state (based on 1), not a different app state per route
All container components get access to the same (full) app state.

A couple things I have been missing based on my previous work with redux:

Cannot pass the initial state to the createStore method
Cannot specify which reducer to pass to the store. Ideally, I'd like to pass a different set of reducers to each route so they only get the part of the state they need (some routes and reducers may also be lazy-loaded)
There is no replaceReducer method (http://redux.js.org/docs/api/Store.html#replaceReducer).
A way to merge props in a container component with passed props from a higher level container component: https://github.com/reactjs/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options

To provide some context, I'm building an app that is a website builder. There are only a few routes (view, edit, manage-comments, etc.), some of which require only a small subset of the state or a different state altogether. Each user's website is saved as a simple JSON configuration. Part of the JSON is the components used in the website, and each component will have it's own set of reducers. Most of these components get added on load, but I also need the option to dynamically insert reducers to the store as a users adds/removes components from their website in the website editor.

Great question! We want to provide some convention (as you would expect in the ember ecosystem) by dropping the developer into the happy path/ pit of success. In theory this provides a much easier ramp up (as the details about store creation/ ember service injection are out of sight out of mind).
For the power user who needs (or simply wants) complete control over the details of store creation/ combing reducers /etc we are working on a PR that should provide a more robust redux service. This readme from @foxnewsnetwork is something I'm looking at to write up some new docs explaining "how to override" as needed. I'd like to think we are open to feedback if you want to look over that PR/ try out the branch I have up (to see if the extension points we have in place meet your needs).
The core philosophy for this addon could be stated as 3 points

we want api compatibility for connect (to enable a drop in replacement of react-redux)
we want to abstract the details of store creation/ provide a default middleware/ default enhancer to speed up initial development
we should allow power users to override the store creation step as needed (PR #121)

The main idea was that if you had a react app today, and had to join a team doing ember you could essentially copy the reducers/actions/middleware directories over and spin up a 100% green field ember-redux app having to write only new components as ember !== react.


tink 1.7.0 depends on protobuf 3.20.1 which has a security vulnerability patched in a newer version

tink 1.7.0 for Python depends on protobuf 3.20.1, which has an alleged security vulnerability as per this report from OSV:
https://osv.dev/vulnerability/GHSA-8gq9-2x98-w8hf
We can see the requirement here: https://github.com/google/tink/blob/1.7/python/requirements.txt
As per the report:

Please update to the latest available versions of the following packages:

protobuf-cpp (3.18.3, 3.19.5, 3.20.2, 3.21.6)
protobuf-python (3.18.3, 3.19.5, 3.20.2, 4.21.6)

Can you guys update tink to at least use protobuf 3.20.2?

Hi @darkvertex since https://github.com/google/tink/commit/a6b2384a5d98f6770523d0bf855867193235e025 Tink requires protobuf>=4.21.9. This will be included in the next release.

Hi @morambro could you please link to the release schedule? I couldn't find any information on when the next (presumably) 1.8.0 release is planned.

We are migrating each library to its own repository. The migration of each library coincides with the next release, which for Tink Python should be complete in Q3/23 (https://github.com/google/tink#tink).

1.8.0 is out (notes, pypi), which includes a fix for this issue.


An existing connection was forcibly closed by the remote host

On Microsoft Edge, make a request to a http server (vert.x for me) and close the browser, you will get "An existing connection was forcibly closed by the remote host" exception. There is no issue with other browsers.
If you make two requests from seperate tabs and close just one tab nothing happens.
If you make two requests from seperate tabs and close Windows Edge you get two exceptions.
Can be related with non-closed connections on process exit.

Hi @hiyelbaz, thank you for reporting this issue. However, this sounds like an Edge issue, not a ChakraCore issue- can you please open an issue with them using the tool at https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/.


Change ScopedVector to VectorRecycler to ease the usage

Change ScopedVector to VectorRecycler to ease the usage

Laith is looking for even less invasive solution.

Is it to overload the deleter of the shared ptr? It is a very good solution. But I am not very sure if we can guarantee the associated vector pool is always valid when the user drop the last shared reference on the buffer allocated from the vector pool?

Laith is looking for even less invasive solution.

Is it to overload the deleter of the shared ptr? It is a very good solution. But I am not very sure if we can guarantee the associated vector pool is always valid when the user drop the last shared reference on the buffer allocated from the vector pool?

Yes, my understanding is this is the approach Laith is looking into. CC: @laithsakka


IDFV for uniqueness

This uses https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor for uniqueness instead of the visit date. This data is never sent anywhere outside the device.

If I understand correctly, this would not work with our system. We have pageviews that are unique or non-unique. If there is only one unique page view per install, it would never show "visitors" after the first install date. Only pageviews.
Here we explain how it works a bit better:
https://docs.simpleanalytics.com/explained/unique-visits

I agree with @adriaandotcom, it seems this will not work correctly. The "unique" name is a bit misleading here, basically we want to flag a first pageview on a day as "unique", so it is counted as a "visitor". That is why I chose to use a date tracking mechanism to achieve this.


Dev/1.13.7

There was an issue with github actions yesterday. I think they would pass if it was working
https://www.githubstatus.com/

There was an issue with github actions yesterday. I think they would pass if it was working https://www.githubstatus.com/

It seems to be happening a lot, but thanks for letting me know. I want to wait until the actions pass because I've had issues with IntelliJ code formatting not catching everything since the latest update.

@it-hms @oliver-walker-hms PR updated to improve the flow of setting the keep-alive interval. It can now be optionally set via the constructor (falls back to the default if not specified).
I also added a commit to similarly improve the flow of configuring the MQTT thread sleep interval. It is now required to specify the MQTT thread sleep interval in the constructor.

Previously, it was necessary to call setMqttThreadSleepIntervalMs() before starting a connection. This could lead to unintended consequences (undefined sleep interval = 0) if the implementing developer forgot to make the call. This is no longer possible.


Nullable reference types tutorial, and nullable references overview

Fixes #8208
Fixes #8204
Relies on dotnet/samples#491
Add the overview and first tutorial for nullable reference types.
Overview preview link
Tutorial link

Closing and reopening to begin new build after dotnet/samples#491 was merged.

And I just noticed @rpetrusha had submitted his review while I was going through the PR. It seems some are duplicate which reinforces more the comments. 😄

@mairaw was reviewing as well during my reading. Duplicate feedback is not intended :).

Thanks for all the feedback @mairaw @rpetrusha @pkulikov! It really improves this article. 🎆 🍾


Show popup with what was copied with Text Extractor

Description of the new feature / enhancement
Show a small popup showing what was copied with Text Extractor.
Scenario when this would be used?
Would make it easy to know that text was indeed detected and copied. Know what was detected without needing to paste into text editor first.
Supporting information
No response

/dup #20305


Improve article [arXiv:2111.09543]

Exact location of issue
Table 1 of Section 3 of 2111.09543
Problem details
need to support \raisebox

Fascinating, it appears the contents of that macro were treated as neutralized, so the macro was never treated as proper TeX.
These are really hard to spot on our own, so this issue report is quite valuable - thank you for filing it in! It's a fidelity bug in latexml that we'll iron out.

This article also needs support for trimclip.sty.


Emoji Picker

Emoji are often used in personal, casual text messages. The latest versions of both Windows and macOS support a native emoji picker, but not everyone knows they exist.
So instead of implementing our own emoji picker or embedding a huge library, we simply display a small hint below textareas to make our users aware of the native picker if they are on a supported platform.
This is what it looks like on macOS:

Leave this one open for another solution


Adding MCAST - Malta College of Arts, Science and Technology

@Feramance I am sorry, the domain mcast.edu.mt is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Pack at https://education.github.com/discount_requests/application. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).


missing something similar to getCharacterMapping

robofab had getCharacterMapping returning a dict mapping glyphName to unicodes, this could be in nonelab the defcon.glyph.unicodeData as this is already a dict

This works:
from fontParts.world import RFont

font = RFont()
glyph = font.newGlyph("glyph1")
glyph.unicode = 123
glyph = font.newGlyph("glyph2")
glyph.unicode = 124
mapping = font.getCharacterMapping()

Layer also has a getCharacterMapping mapping.


Modify Kronecker Gaussian kernel to take advantage of factorized kernel.

Make use of the special structure in spatial covariance as described in #13

If you want to use a Kronecker factorization of the spatial covariance, then inputs need to be on a grid.

My conclusions so far:

The function gaussian_grid_inference is where most of the action is. Call chain is as follows: model = gp_grid_regression -> gp_grid -> gaussian_grid_inference.

gaussian_grid_inference is currently hard-coded to use rbf covariance.

The gradient update poses the main challenge. Because the full matrix K is so big, it is not possible to explictly compute dL_dK and pass that around the way GPy usually does it.

Need kernels to be able to provide dK_dTheta.

Code in need of testing:

stationary:dK_dParams with ARD=True


Edge and older browsers support

First of all, thank you for building this library, I have been using it for a while now, and I just love it. My only issue is that I haven't been able to run it inside Edge (which leads me to believe that IE11 might have the same issue).
We made the following site: TrueHome (I had to disable the animation with a display: none for edge, because the client required the change ASAP), and we can display all the images without any kind of issue in Chrome, Firefox and even inside Epiphany, (although I can see some flickering). But Edge doesn't seem to apply the animation.
I will continue testing with browserlist, polyfill and any other library related to compatibility between browsers, but do you have any idea of why this may be happening? Is this to be expected with some browsers?
Thanks in advance!!

wow awesome!! good job on the site, hmmm i haven't tested on Edge and IE 11... cause i am a mac boy hahaha. i will test it out next couple days and let you know.

Thank you so much for the quick response. My guess is that the issue is related to the IntersectionObserver, but I haven't been able to give it a look yet.
If you need anything from me, just let me know and thanks again, man!!

No worries mate, we are stop supporting on IE 11. but our tester have tested our website under IE 11 and Edge. looks fine with the image lazy loading. you can take a look as well link here.
For your case, maybe disable placeholder for IE 11 and edge? let me know if that solve the issue.

hey @letops how did you with it?

Sorry I haven't been able to respond.
I haven't had the time to find a solution for this, and the client requested us to put it on hold and include the library in a later version, but thank you so much for trying. I'll let you know if I find something else.
Cheers mate!!!

thanks @letops 👍


show next event on launch

scroll to the next event on launch, maybe today and maybe add now button.

and gray out old events


🐛 [mealie] Environment variables not being imported from the config.yaml

Description
I've set openapi variables in the config file.
However the addon does not seem to pick them up.
I 've restarted the addon multiple times
this is the content of /addon_configs/db21ed7f_mealie/config.yaml:
TZ: Europe/Paris
OPENAI_API_KEY: "******************************************************************"
OPENAI_SEND_DATABASE_DATA: False
OPENAI_WORKERS: 1

Reproduction steps
Go to /addon_configs/db21ed7f_mealie
Open the config.yaml file.

Add the variables and save the file

Restart the add-on

Addon Logs
-----------------------------------------------------------
/etc/cont-init.d/00-global_var.sh: executing
ALLOW_SIGNUP='false'
BASE_URL='http://homeassistant.local'
DATA_DIR='/config'
PGID='1000'
PUID='1000'
certfile='fullchain.pem'
keyfile='privkey.pem'
ssl='false'
Timezone set from Etc/UTC to Europe/Zurich
/etc/cont-init.d/01-config_yaml.sh: executing
Setting permissions for the config.yaml directory
Load environment variables from /config/config.yaml if existing
If accessing the file with filebrowser it should be mapped to /addon_configs/db21ed7f_mealie/config.yaml
---------------------------------------------------------
Wiki here on how to use : github.com/alexbelgium/hassio-addons/wiki/Add‐ons-feature-:-add-env-variables
... no env variables found, exiting
/etc/cont-init.d/01-custom_script.sh: executing
Execute /addon_configs/db21ed7f_mealie/mealie.sh if existing
Wiki here : github.com/alexbelgium/hassio-addons/wiki/Add-ons-feature-:-customisation
/etc/cont-init.d/31-nginx.sh: executing
[21:46:07] INFO: Adapting for ingress
[21:46:08] INFO: Exporting variables
ALLOW_SIGNUP=false
BASE_URL=http://homeassistant.local
DATA_DIR=/config
PGID=1000
PUID=1000
certfile=fullchain.pem
keyfile=privkey.pem
ssl=false
[21:46:14] INFO: config.yaml found in /config/config.yaml, exporting variables
Permissions adapted
[21:46:15] INFO: Starting nginx
[21:46:15] INFO: Starting app
INFO     2024-11-14T21:47:24 - Started server process [8]
INFO     2024-11-14T21:47:24 - Waiting for application startup.
INFO     2024-11-14T21:47:24 - start: database initialization
INFO     2024-11-14T21:47:24 - Database connection established.
INFO     2024-11-14T21:47:24 - Context impl SQLiteImpl.
INFO     2024-11-14T21:47:24 - Will assume non-transactional DDL.
INFO     2024-11-14T21:47:25 - Checking for migration data fixes
INFO     2024-11-14T21:47:27 - end: database initialization
INFO     2024-11-14T21:47:27 - -----SYSTEM STARTUP-----
INFO     2024-11-14T21:47:27 - ------APP SETTINGS------
INFO     2024-11-14T21:47:27 - {
    "TESTING": false,
    "PRODUCTION": true,
    "LOG_CONFIG_OVERRIDE": null,
    "LOG_LEVEL": "info",
    "theme": {
        "light_primary": "#E58325",
        "light_accent": "#007A99",
        "light_secondary": "#973542",
        "light_success": "#43A047",
        "light_info": "#1976D2",
        "light_warning": "#FF6D00",
        "light_error": "#EF5350",
        "dark_primary": "#E58325",
        "dark_accent": "#007A99",
        "dark_secondary": "#973542",
        "dark_success": "#43A047",
        "dark_info": "#1976D2",
        "dark_warning": "#FF6D00",
        "dark_error": "#EF5350"
    },
    "BASE_URL": "http://homeassistant.local",
    "STATIC_FILES": "/spa/static",
    "IS_DEMO": false,
    "HOST_IP": "*",
    "API_HOST": "<IP_ADDRESS>",
    "API_PORT": 9000,
    "API_DOCS": true,
    "TOKEN_TIME": 48,
    "GIT_COMMIT_HASH": "3e69ea94d5699da7ea1abe2fb77109bd38c8ded0",
    "ALLOW_SIGNUP": false,
    "DAILY_SCHEDULE_TIME": "23:45",
    "SECURITY_MAX_LOGIN_ATTEMPTS": 5,
    "SECURITY_USER_LOCKOUT_TIME": 24,
    "DB_ENGINE": "sqlite",
    "DEFAULT_GROUP": "Home",
    "DEFAULT_HOUSEHOLD": "Family",
    "SMTP_HOST": null,
    "SMTP_PORT": "587",
    "SMTP_FROM_NAME": "Mealie",
    "SMTP_FROM_EMAIL": null,
    "SMTP_AUTH_STRATEGY": "TLS",
    "LDAP_AUTH_ENABLED": false,
    "LDAP_SERVER_URL": null,
    "LDAP_TLS_INSECURE": false,
    "LDAP_TLS_CACERTFILE": null,
    "LDAP_ENABLE_STARTTLS": false,
    "LDAP_BASE_DN": null,
    "LDAP_QUERY_BIND": null,
    "LDAP_USER_FILTER": null,
    "LDAP_ADMIN_FILTER": null,
    "LDAP_ID_ATTRIBUTE": "uid",
    "LDAP_MAIL_ATTRIBUTE": "mail",
    "LDAP_NAME_ATTRIBUTE": "name",
    "OIDC_AUTH_ENABLED": false,
    "OIDC_CLIENT_ID": null,
    "OIDC_CONFIGURATION_URL": null,
    "OIDC_SIGNUP_ENABLED": true,
    "OIDC_USER_GROUP": null,
    "OIDC_ADMIN_GROUP": null,
    "OIDC_AUTO_REDIRECT": false,
    "OIDC_PROVIDER_NAME": "OAuth",
    "OIDC_REMEMBER_ME": false,
    "OIDC_USER_CLAIM": "email",
    "OIDC_GROUPS_CLAIM": "groups",
    "OIDC_TLS_CACERTFILE": null,
    "OPENAI_BASE_URL": null,
    "OPENAI_MODEL": "gpt-4o",
    "OPENAI_CUSTOM_HEADERS": {},
    "OPENAI_CUSTOM_PARAMS": {},
    "OPENAI_ENABLE_IMAGE_SERVICES": true,
    "OPENAI_WORKERS": 2,
    "OPENAI_SEND_DATABASE_DATA": true,
    "OPENAI_REQUEST_TIMEOUT": 60,
    "WORKER_PER_CORE": 1,
    "UVICORN_WORKERS": 1
}
INFO     2024-11-14T21:47:27 - Daily tasks scheduled for 2024-11-14 22:45:00+00:00
INFO     2024-11-14T21:47:27 - Application startup complete.

Architecture
amd64
OS
HAos

Hi, strange that the others variables are picked up and not that one. Please try with a fake simpler key to check if the issue is with Mealie not picking up on it (so perhaps an upstream issue), or if it's because their is non standard characters that are not supported by HA options thanks

I changed te config to just send the variable
LOG_LEVEL: "debug"

However, it still does not pick it up.
INFO     2024-11-17T12:01:24 - -----SYSTEM SHUTDOWN-----
INFO     2024-11-17T12:01:24 - Application shutdown complete.
INFO     2024-11-17T12:01:24 - Finished server process [7]
/etc/cont-init.d/00-banner.sh: executing
-----------------------------------------------------------
 Add-on: Mealie
 Mealie is a self hosted recipe manager and meal planner built in Vue
-----------------------------------------------------------
 Add-on version: v2.1.0-2
 There is an update available for this add-on!
 Latest add-on version: v2.2.0
 Please consider upgrading as soon as possible.
 System: Home Assistant OS 13.2  (aarch64 / green)
 Home Assistant Core: 2024.11.1
 Home Assistant Supervisor: 2024.11.2
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums
-----------------------------------------------------------
 Provided by: https://github.com/alexbelgium/hassio-addons
-----------------------------------------------------------
 Defining permissions for main user :
User UID: 1000
User GID : 1000
-----------------------------------------------------------
/etc/cont-init.d/00-global_var.sh: executing
ALLOW_SIGNUP='false'
BASE_URL='http://homeassistant.local'
DATA_DIR='/config'
PGID='1000'
PUID='1000'
certfile='fullchain.pem'
keyfile='privkey.pem'
ssl='false'
Timezone set from Etc/UTC to Europe/Zurich
/etc/cont-init.d/01-config_yaml.sh: executing
Setting permissions for the config.yaml directory
Load environment variables from /config/config.yaml if existing
If accessing the file with filebrowser it should be mapped to /addon_configs/db21ed7f_mealie/config.yaml
---------------------------------------------------------
Wiki here on how to use : github.com/alexbelgium/hassio-addons/wiki/Add‐ons-feature-:-add-env-variables
... no env variables found, exiting
/etc/cont-init.d/01-custom_script.sh: executing
Execute /addon_configs/db21ed7f_mealie/mealie.sh if existing
Wiki here : github.com/alexbelgium/hassio-addons/wiki/Add-ons-feature-:-customisation
/etc/cont-init.d/31-nginx.sh: executing
[12:01:46] INFO: Adapting for ingress
[12:01:47] INFO: Exporting variables
ALLOW_SIGNUP=false
BASE_URL=http://homeassistant.local
DATA_DIR=/config
PGID=1000
PUID=1000
certfile=fullchain.pem
keyfile=privkey.pem
ssl=false
[12:01:53] INFO: config.yaml found in /config/config.yaml, exporting variables
Permissions adapted
[12:01:53] INFO: Starting nginx
[12:01:53] INFO: Starting app
INFO     2024-11-17T12:04:35 - Started server process [7]
INFO     2024-11-17T12:04:35 - Waiting for application startup.
INFO     2024-11-17T12:04:35 - start: database initialization
INFO     2024-11-17T12:04:35 - Database connection established.
INFO     2024-11-17T12:04:35 - Context impl SQLiteImpl.
INFO     2024-11-17T12:04:35 - Will assume non-transactional DDL.
INFO     2024-11-17T12:04:35 - Checking for migration data fixes
INFO     2024-11-17T12:04:37 - end: database initialization
INFO     2024-11-17T12:04:37 - -----SYSTEM STARTUP-----
INFO     2024-11-17T12:04:37 - ------APP SETTINGS------
INFO     2024-11-17T12:04:37 - {
    "TESTING": false,
    "PRODUCTION": true,
    "LOG_CONFIG_OVERRIDE": null,
    "LOG_LEVEL": "info",
    "theme": {
        "light_primary": "#E58325",
        "light_accent": "#007A99",
        "light_secondary": "#973542",
        "light_success": "#43A047",
        "light_info": "#1976D2",
        "light_warning": "#FF6D00",
        "light_error": "#EF5350",
        "dark_primary": "#E58325",
        "dark_accent": "#007A99",
        "dark_secondary": "#973542",
        "dark_success": "#43A047",
        "dark_info": "#1976D2",
        "dark_warning": "#FF6D00",
        "dark_error": "#EF5350"
    },
    "BASE_URL": "http://homeassistant.local",
    "STATIC_FILES": "/spa/static",
    "IS_DEMO": false,
    "HOST_IP": "*",
    "API_HOST": "<IP_ADDRESS>",
    "API_PORT": 9000,
    "API_DOCS": true,
    "TOKEN_TIME": 48,
    "GIT_COMMIT_HASH": "3e69ea94d5699da7ea1abe2fb77109bd38c8ded0",
    "ALLOW_SIGNUP": false,
    "DAILY_SCHEDULE_TIME": "23:45",
    "SECURITY_MAX_LOGIN_ATTEMPTS": 5,
    "SECURITY_USER_LOCKOUT_TIME": 24,
    "DB_ENGINE": "sqlite",
    "DEFAULT_GROUP": "Home",
    "DEFAULT_HOUSEHOLD": "Family",
    "SMTP_HOST": null,
    "SMTP_PORT": "587",
    "SMTP_FROM_NAME": "Mealie",
    "SMTP_FROM_EMAIL": null,
    "SMTP_AUTH_STRATEGY": "TLS",
    "LDAP_AUTH_ENABLED": false,
    "LDAP_SERVER_URL": null,
    "LDAP_TLS_INSECURE": false,
    "LDAP_TLS_CACERTFILE": null,
    "LDAP_ENABLE_STARTTLS": false,
    "LDAP_BASE_DN": null,
    "LDAP_QUERY_BIND": null,
    "LDAP_USER_FILTER": null,
    "LDAP_ADMIN_FILTER": null,
    "LDAP_ID_ATTRIBUTE": "uid",
    "LDAP_MAIL_ATTRIBUTE": "mail",
    "LDAP_NAME_ATTRIBUTE": "name",
    "OIDC_AUTH_ENABLED": false,
    "OIDC_CLIENT_ID": null,
    "OIDC_CONFIGURATION_URL": null,
    "OIDC_SIGNUP_ENABLED": true,
    "OIDC_USER_GROUP": null,
    "OIDC_ADMIN_GROUP": null,
    "OIDC_AUTO_REDIRECT": false,
    "OIDC_PROVIDER_NAME": "OAuth",
    "OIDC_REMEMBER_ME": false,
    "OIDC_USER_CLAIM": "email",
    "OIDC_GROUPS_CLAIM": "groups",
    "OIDC_TLS_CACERTFILE": null,
    "OPENAI_BASE_URL": null,
    "OPENAI_MODEL": "gpt-4o",
    "OPENAI_CUSTOM_HEADERS": {},
    "OPENAI_CUSTOM_PARAMS": {},
    "OPENAI_ENABLE_IMAGE_SERVICES": true,
    "OPENAI_WORKERS": 2,
    "OPENAI_SEND_DATABASE_DATA": true,
    "OPENAI_REQUEST_TIMEOUT": 60,
    "WORKER_PER_CORE": 1,
    "UVICORN_WORKERS": 1
}
INFO     2024-11-17T12:04:37 - Daily tasks scheduled for 2024-11-17 22:45:00+00:00
INFO     2024-11-17T12:04:37 - Application startup complete.
INFO     2024-11-17T12:04:37 - Uvicorn running on http://<IP_ADDRESS>:9000 (Press CTRL+C to quit)
INFO     2024-11-17T12:04:47 - [<IP_ADDRESS>:53560] 200 OK "GET /api/app/about HTTP/1.1"

i even tried exporting them from the script addons_autoscripts/db21ed7f-mealie.sh. however the script is also not executed.
#!/bin/bash
# shellcheck shell=bash

#################
# CODE INJECTOR #
#################

# Any commands written in this bash script will be executed at addon start
# See guide here : https://github.com/alexbelgium/hassio-addons/wiki/Add%E2%80%90ons-feature-:-customisation

echo "############################################################# Starting sript execution #############################################################"

export LOG_LEVEL='debug'

log:

```INFO     2024-11-17T12:16:32 - -----SYSTEM SHUTDOWN-----
INFO     2024-11-17T12:16:32 - Application shutdown complete.
INFO     2024-11-17T12:16:32 - Finished server process [7]
/etc/cont-init.d/00-banner.sh: executing
-----------------------------------------------------------
 Add-on: Mealie
 Mealie is a self hosted recipe manager and meal planner built in Vue
-----------------------------------------------------------
 Add-on version: v2.1.0-2
 There is an update available for this add-on!
 Latest add-on version: v2.2.0
 Please consider upgrading as soon as possible.
 System: Home Assistant OS 13.2  (aarch64 / green)
 Home Assistant Core: 2024.11.1
 Home Assistant Supervisor: 2024.11.2
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums
-----------------------------------------------------------
 Provided by: https://github.com/alexbelgium/hassio-addons
-----------------------------------------------------------
 Defining permissions for main user :
User UID: 1000
User GID : 1000
-----------------------------------------------------------
/etc/cont-init.d/00-global_var.sh: executing
ALLOW_SIGNUP='false'
BASE_URL='http://homeassistant.local'
DATA_DIR='/config'
PGID='1000'
PUID='1000'
certfile='fullchain.pem'
keyfile='privkey.pem'
ssl='false'
Timezone set from Etc/UTC to Europe/Zurich
/etc/cont-init.d/01-config_yaml.sh: executing
Setting permissions for the config.yaml directory
Load environment variables from /config/config.yaml if existing
If accessing the file with filebrowser it should be mapped to /addon_configs/db21ed7f_mealie/config.yaml
---------------------------------------------------------
Wiki here on how to use : github.com/alexbelgium/hassio-addons/wiki/Add‐ons-feature-:-add-env-variables
... no env variables found, exiting
/etc/cont-init.d/01-custom_script.sh: executing
Execute /addon_configs/db21ed7f_mealie/mealie.sh if existing
Wiki here : github.com/alexbelgium/hassio-addons/wiki/Add-ons-feature-:-customisation
/etc/cont-init.d/31-nginx.sh: executing
[12:16:52] INFO: Adapting for ingress
[12:16:53] INFO: Exporting variables
ALLOW_SIGNUP=false
BASE_URL=http://homeassistant.local
DATA_DIR=/config
PGID=1000
PUID=1000
certfile=fullchain.pem
keyfile=privkey.pem
ssl=false
[12:17:00] INFO: config.yaml found in /config/config.yaml, exporting variables
Permissions adapted
[12:17:00] INFO: Starting nginx
[12:17:00] INFO: Starting app
INFO     2024-11-17T12:18:09 - Started server process [7]
INFO     2024-11-17T12:18:09 - Waiting for application startup.
INFO     2024-11-17T12:18:09 - start: database initialization
INFO     2024-11-17T12:18:09 - Database connection established.
INFO     2024-11-17T12:18:09 - Context impl SQLiteImpl.
INFO     2024-11-17T12:18:09 - Will assume non-transactional DDL.
INFO     2024-11-17T12:18:09 - Checking for migration data fixes
INFO     2024-11-17T12:18:12 - end: database initialization
INFO     2024-11-17T12:18:12 - -----SYSTEM STARTUP-----
INFO     2024-11-17T12:18:12 - ------APP SETTINGS------
INFO     2024-11-17T12:18:12 - {
    "TESTING": false,
    "PRODUCTION": true,
    "LOG_CONFIG_OVERRIDE": null,
    "LOG_LEVEL": "info",
    "theme": {
...

I found the issue.
In the documentation https://github.com/alexbelgium/hassio-addons/wiki/Add‐ons-feature-:-add-env-variables
it stated

The path is described in the starting log. To access it, you need to use my Filebrowser addon. Depending on the addon structure (old or new HA logic) you can look for the folder containing your addon name either in /addon_configs/XXX-name ; or in /homeassistant/addons_config/name. If you have started the addon at least once , it will contain a config.yaml file.

As i found the folders in /homeassitant i used those and did not look in the other directory.
However now i found i have the data in both locations /homeassistant/addons_config and /addons_config. when using the configs in the latter the addon does pick the variables up.

Indeed, /homeassistant are the folders pre-migration. I didn't delete it for continuity if people reload an older backup, but the log should make explicit which folder gets used. Glad it works!


Repository: setup tests

What is the expected enhancement?
Setup tests to validate the implementation.
Epic: #112

Added the main tests for nested program repository in #151


Firefox Extension

Flo has been extremely useful for developing, but requires you to work specifically with Google Chrome Inspector.
For developers who enjoy working with Firefox when developing it leaves them out in the cold.
What work would need to be done to make a Firefox Extension port for Flo?
It appears it's not too difficult to setup an add-on with a new tab in Firebug.

Also I saw this where they said they're implement this feature in the next quarter:

seems to me they forgot about it, but I asked about on uservoice

Thank you for reporting this issue and appreciate your patience. We've  notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

Would be nice to have firefox extension, even if it would support only css reloading!


performance: consider supporting "blake3-256:" digests?

https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf
^ blake3 is fast (but newer crypto)
Would help with building and verifying images, especially large images.

I believe this is a duplicate of #819.

Agreed 👍

The motivation for suggesting blake3 here is mainly for perf reasons. If there is another hash - secure and faster than sha2, that is something we should consider.

I think there are other benefits to blake3, but I'm far from the expert and I think #819 (the prior blake3 discussion which already has a lot of interesting discussion and useful links in it) is a more appropriate place to discuss further.


[BEAM-8155] Add static PubsubIO.readMessagesWithCoderAndParseFn method

[BEAM-8155] Add PubsubIO.readMessagesWithCoderAndParseFn method
Complements https://github.com/apache/beam/pull/8879; the constructor for a generic-typed PubsubIO.Read is private, so some kind of public constructor is needed to use custom parse functions with generic types.
R: @kanterov
Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

R: @lukecwik, @chamikaramj
OWNERS of google-cloud-platform module

LGTM. Thanks.
Can you please add a JIRA ?

@chamikaramj sure, added https://issues.apache.org/jira/browse/BEAM-8155

Thanks.


Match setup.py version to setup.cfg version

I would follow this pattern: https://github.com/farm-ng/farm-ng-amiga/blob/main/py/farm_ng/oak/init.py
to avoid maintaining from two different locations

Any reason not to require >=3.8 since ,=3.7 are all EOL ?

Seems this was unrelated to the problem at hand and that __version__ in setup.py is not visible from an API perspective


Issues with the /app/init-container.py

Describe the bug
Container initialization (Dockerfile line 43) does not work:
Traceback (most recent call last):
  File "/app/init-container.py", line 1680, in <module>
    globals()[subcommand_function_name](args)
  File "/app/init-container.py", line 1559, in do_initialize_files
    change_project_ini(config)
  File "/app/init-container.py", line 989, in change_project_ini
    old_database_url = config_parser.get('g2', 'G2Connection')
  File "/usr/lib/python3.7/configparser.py", line 780, in get
    d = self._unify_values(section, vars)
  File "/usr/lib/python3.7/configparser.py", line 1146, in _unify_values
    raise NoSectionError(section) from None
configparser.NoSectionError: No section: 'g2'

To Reproduce
docker build --build-arg BASE_IMAGE="senzing/senzing-api-server:2.0.0" --build-arg SENZING_ACCEPT_EULA=I_ACCEPT_THE_SENZING_EULA https://github.com/Senzing/docker-wrap-image-with-senzing-apt.git

It expected the file (that does not exist): /etc/opt/senzing/G2Project.ini
The files available are:
ls /etc/opt/senzing/
G2Module.ini  cfgVariant.json  customGn.txt  customOn.txt  customSn.txt  defaultGNRCP.config  g2config.json  stb.config

Expected behavior
Should just work
Desktop (please complete the following information):

Device: MacBookAir9,1 (Intel)
OS: macOS 11.3 (20E232)
Docker: Docker version 20.10.5, build 55c4c88

@fgka I was able to reproduce this and was able to get it building by changing line 42 to:
COPY --from=senzing/init-container:1.6.9  "/app/init-container.py" "/app/init-container.py"
This is updating to the latest init-container version. I'll create a PR to get this change properly reviewed, but until then give this a try and see if it works for you.

Hi Jeff,
I've just tested and it works perfectly, thank you very much for the prompt response.
Cheers,
Gustavi

Gustavo (@fgka )
Glad to hear it!
FYI, I've created a new release (1.0.4) with the changes. I'd suggest using it instead of local edits.
If you are satisfied with this fix, please close this issue. If we don't hear back in a week we'll close it assuming it is fixed. Feel free to reopen at that point it if it is not.

Thanks, this issue can be closed :-)


changed logic to use 2 decimals instead of 3

cc: @rushatgabhane
Details
We were allowing 3 decimal cases in the amount field on Send Money/Request money. Changed it to 2.
Fixed Issues
$ https://github.com/Expensify/App/issues/6286

I have read the CLA Document and I hereby sign the CLA

@danieldoglas, Great job getting your first Expensify/App pull request over the finish line! :tada:
I know there's a lot of information in our contributing guidelines, so here are some points to take note of :memo::

Now that your first PR has been merged, you can be hired for another issue. Once you've completed a few issues, you may be eligible to work on more than one job at a time.
Once your PR is deployed to our staging servers, it will undergo quality assurance (QA) testing. If we find that it doesn't work as expected or causes a regression, you'll be responsible for fixing it. Typically, we would revert this PR and give you another chance to create a similar PR without causing a regression.
Once your PR is deployed to production, we start a 7-day timer :alarm_clock:. After it has been on production for 7 days without causing any regressions, then we pay out the Upwork job. :moneybag:

So it might take a while before you're paid for your work, but we typically post multiple new jobs every day, so there's plenty of opportunity. I hope you've had a positive experience contributing to this repo! :blush:

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by @TomatoToaster in version: 1.1.17-8 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by @roryabraham in version: 1.1.18-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Add GitHub action for publishing java artifacts

This is step one of automating rc creation. I plan on adding more jobs for the remaining steps.
I validated that this worked and created a few candidates here - https://repository.apache.org/#stagingRepositories
Before merging, we need to:

[ ] Add the secrets used here to Apache's secret store.
[ ] Request that Infra allow list the gpg action I'm using here.

Doing so does not need to preclude reviewing the code though.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @jrmccluskey

Run Python_Runners PreCommit

TODO - this should be pinning to Java 8 before merging

Run Java PreCommit


feature request: inotify

On Linux, manually polling is not needed. Have you looked into inotifywait or something like https://github.com/xyproto/recwatch?
Switchboard is a neat idea!

Hey @xyproto, thanks for taking the time to use switchboard!
Yes, this is something I absolutely will be doing. In Linux, we can get file closed events, which avoids the need for polling altogether.
In the very near future, (potentially the next release) I will be looking to support this, and have polling as a fallback for other OS envs.
Stay tuned!


WIP: Add simple chunk type registry and defer as appropriate to upcast types

Adds a basic list-based registry of valid chunk types for use within dask.array.Array, with the ability to add otherwise unknown types with dask.array.register_chunk_type. When a type not in this list or defined/handled by Dask is encountered, defer to it instead. This means raising TypeError on creation/wrapping and returning NotImplemented in elemwise, __array_function__, and __array_ufunc__. With changes of this PR, dask.array.Array will be better able to respect a well-defined type casting hierarchy and will by default follow the generally-accepted hierarchy among common PyData/SciPy packages that I'm aware of. It is very much a breaking change for any array types not known by default to Dask, but these otherwise unknown types can be easily added with dask.array.register_chunk_type. It fixes bugs with non-commutative operations with Pint Quantities and xarray DataArrays.
Right now, this is a draft PR since I have not added tests for the new registry functions or for dask.array.Array respecting the type casting hierarchy. If at all possible, I'd like to get feedback/approval on this general approach before spending a bunch of time on the tests of it, in case it needs to be redone in a different fashion.

[ ] Tests added
[x] Tests passed
[x] Passes black dask / flake8 dask

Tagging @pentschev, @shoyer, @hameerabbasi, and @mrocklin based on input in https://github.com/dask/dask/issues/4583. I would greatly appreciate any of your feedback on this!
Closes https://github.com/dask/dask/issues/4583

Thank you for writing this up @jthielen .
I'm somewhat against an explicit whitelist of types by default.  If some small third-party library makes a numpy-compatible array library I don't want them to have to explicitly talk to us or import dask in order to have things work.  Ideally with protocols we're able to avoid pairwise library interactions like this.
I may be missing subtle points here though.

I'm somewhat against an explicit whitelist of types by default. If some small third-party library makes a numpy-compatible array library I don't want them to have to explicitly talk to us or import dask in order to have things work. Ideally with protocols we're able to avoid pairwise library interactions like this.

Thank you for the feedback! I took the list-of-downcast-types approach based on @shoyer's direction in https://github.com/dask/dask/issues/4583 (in contrast to the list-of-upcast-types approach we took in Pint in https://github.com/hgrecco/pint/pull/959). For a library like Dask that is generally in the middle of the type casting hierarchy, I would think either of those two approaches would be good, and I would have no problem swapping over to a registry of upcast types (e.g., xarray Variable/DataArray/Dataset, Pint Quantity) instead.
Also, please anyone correct me if I am wrong in this, but part of the reason I think those are the two options to decide between is that pairwise library interactions are unavoidable. The type casting hierarchy as defined in NEP 13 is a directed acyclic graph (and not a tiered or strictly ordered list of array priorities), so pairwise casting relationships are inherent to its structure and use. Perhaps a protocol establishing these pairwise relationships could be determined, but I'm not sure that gives any benefits over upcast/downcast type registries. Plus, given NEPs 13 and 18 and the work done across all the duck array libraries, we are very close to having structures like xarray > Pint > Dask > Sparse (among other combinations) working properly, and I'd hate to wait for a new protocol to be approved when it seems like we already have almost everything that we need once https://github.com/dask/dask/issues/4583 and https://github.com/pydata/xarray/issues/4208 are resolved.
But, I must admit that in all this duck array work, I've been hyper-focused on the type casting hierarchy, so I very well may be missing the forest for the trees here.

I think we need something like this to make the duck array ecosystem work. There’s no a priori way to know if dask arrays should handle pint or the other way around.
A some alternatives come to mind:

Put this logic (the which array handles which other arrays DAG) into a third party library, maybe eventually even in NumPy itself? This might make it easier to enforce invariants, like ensuring that type handling is indeed a DAG.

Use a protocol to enforce a global ordering between array types, like NumPy’s deprecated use of __array_priority__. This sounds fine in theory (any DAG can be topologically sorted, after all) but doesn’t scale — every library has to coordinate on what priorities they pick, and in practice that just doesn’t seem to happen.

Make registration opt-out instead of opt-in. But this means the default behavior would be undefined behavior rather than an error.

Use some sort of protocol attribute / method for recognizing valid (or invalid) chunk array types. This is a bit less flexible than explicit registration, though, because it needs to implemented on the Array object (at least for C extensions and objects that use __slots__). I think it’s more convenient to let anyone register chunk types.

On the whole, I think either this PR or some version of (1) would be the best option in the long term, but alternative (1) would be a lot more work and would be slow to roll out.

@shoyer It looks like we doubled up on our comments! I definitely agree with your points (and that is particularly good to note about your option 3 giving undefined behavior rather than an error, something I neglected to consider in my "either/or" stance).

I haven't thought about this problem too deeply, but here are my two cents:

Duck-arrays can be divided broadly into three categories, based on their interface:

The first is those that provide a (nearly) ndarray interface (Only one of these at a time).

CuPy
PyData/Sparse
JAX Array
(am I missing any?)

The second are those that purposefully diverge from the ndarray interface, but still follow it quite closely. These usually provide extra functionality and wrap other arrays (AFAICT, only one of these can be in a hierarchy at a time unless it forwards __getattr__ or some similar magic):

pint Quantity
udiff

Those that do not follow the ndarray interface at all, just wrap other arrays:

XArray DataSet/DataArray/Variable
Pandas (in the future, maybe?)

In my (admittedly limited) knowledge, any DAG should work so long as it topologically sorts things by the correct order as given above. The question is where Dask fits in... Does it go into category 1 or 2? Well, it's a bit special: It shouldn't wrap things from 2, only 1. So I'd put it as a 1.5.
I do agree with @shoyer that these libraries rarely coordinate on this front, but I think there's a reason for that: There's no good guidance on how to choose __array_priority__ in the first place other than going out and doing some research. Maybe the above could be added as guidance, perhaps multiplying numbers by 100?
Going even further, I think one can (for full functionality) pick something from category 1, multiple things from category 2, and one from category 3 again. So it's really only the libraries in category 2 that have to do some extra work, all others can just reject/accept as appropriate.

In my (admittedly limited) knowledge, any DAG should work so long as it topologically sorts things by the correct order as given above. The question is where Dask fits in... Does it go into category 1 or 2? Well, it's a bit special: It shouldn't wrap things from 2, only 1. So I'd put it as a 1.5.

I don't think Dask is so special here. Nearly every duck array adds at least something on top of NumPy -- otherwise it wouldn't have a good reason for existing! E.g., even with pydata/sparse, you can pull out attributes indicating the underlying representation of a sparse array, which is occasionally quite useful. So most of your examples might actually fall in between 1 and 2.
We might attempt to do a (near) complete census of hypothetical duck array types, and could perhaps come up with something like the following order:

CPU/GPU arrays
New dtype arrays (e.g, for bfloat16 or units or...)
Sparse arrays
Distributed arrays
Autodiff arrays (hypothetical duck array version of autograd)
Masked arrays (hypothetical duck array version of np.ma)
Labeled arrays (with compatible semantics to NumPy, like Pytorch)

Hopefully the issues with this sort of thing are self-evident:

It's almost assuredly still incomplete. Someone could come along with a new duck array type like awkward array (for ragged arrays) and we'd have to figure out how to slot it in.
Some duck array types fall into multiple categories. For example, JAX currently does (1), (2), (4) and (5).
The right ordering may depend on details of how array types are implemented, not just their category. For example, is a new dtype array implemented as a duck array on top of existing dtypes, or in terms of low operations specialized for particular hardware?
Sometimes the right ordering is rather arbitrary (e.g., for pint vs dask). There are arguments for doing it both ways. The most important thing is that it's picked consistently.

Also, to follow up on @shoyer's points, another problem with trying to base casting rules on an ordered/tiered list (rather than the full information of the DAG) is the implicit assumption that an array at any given level has to support wrapping any of those below, which may not necessarily be the case. Take the example hierarchy from NEP 13:

In any topological ordering of the DAG, C will be above D, but C cannot handle interactions with D (without B wrapping D). So, unless we force the DAG to be dense by requiring support for all arrays lower on the ordered/tiered list, the pairwise relationships between types (specific edges of the DAG) are required.

I'm happy to relax my concern on operations where many operands may want to take charge, like __array_function__ and my_dask_array + my_xarray.
I think that other operations like from_array or elemwise should work regardless of the input types.  The user is asking to turn that thing into a dask array.  Also, it's going to be near-impossible to predict every array storage type.

I'm happy to relax my concern on operations where many operands may want to take charge, like __array_function__ and my_dask_array + my_xarray.
I think that other operations like from_array or elemwise should work regardless of the input types. The user is asking to turn that thing into a dask array. Also, it's going to be near-impossible to predict every array storage type.

Would you be able to clarify this a bit further? Unless I'm not realizing the full extent of what elemwise does, I understood it as how all the operator methods (__add__, __lt__, etc.) are defined, so those all need to be able to defer properly to upcast types in the same way that __array_function__ and __array_ufunc__ do. Likewise, I think construction of a dask array needs to prohibit using upcast types inside the dask array, otherwise you could easily end up nasty constructs like Pint wrapping Dask wrapping Pint if a user or downstream library isn't careful. With that in mind, if we wanted those to work more flexibly with unknown input types, then we are in essence back to @shoyer's option 3 of opt-out. Does it make sense for some operations to be opt-in with registry of this PR (or a duck array DAG package like @shoyer's option 1) and others be opt-out?

I think that other operations like from_array or elemwise should work regardless of the input types. The user is asking to turn that thing into a dask array. Also, it's going to be near-impossible to predict every array storage type.

Would you be able to clarify this a bit further? Unless I'm not realizing the full extent of what elemwise does, I understood it as how all the operator methods (__add__, __lt__, etc.) are defined, so those all need to be able to defer properly to upcast types in the same way that __array_function__ and __array_ufunc__ do

I don't think we end up doing computation directly on the original array type with from_array, e.g., on zarr arrays. Slices get inserted, so arithmetic is actually does on chunk_array[:], which will typically be a NumPy array.
As for elemwise, yes, dispatch will need to happen inside of each chunk -- but that should happen automatically. We already know the result should be a dask array since user called dask.elemwise.

I don't think we end up doing computation directly on the original array type with from_array, e.g., on zarr arrays. Slices get inserted, so arithmetic is actually does on chunk_array[:], which will typically be a NumPy array.

Ah, got it. Although, for both prototypical upcast types of Pint Quantities and xarray DataArrays, chunk_array[:] is still just (a copy of) chunk_array, which we don't want inside the dask array.
So is there a better place for such a type check on the chunks on creation? Or would it make more sense to instead just write some tests that upcast types cannot mistakenly become chunks of a dask array, and see where that leads?

As for elemwise, yes, dispatch will need to happen inside of each chunk -- but that should happen automatically. We already know the result should be a dask array since user called dask.elemwise.

That make sense if the user calls elemwise (knowing that we're already within the realm of Dask-handled arrays which excludes upcast types), however, again unless I'm missing something big, I don't see where elemwise is used in this way...I can't find it anywhere in the docs. What looks to be more common is elemwise being used through dunder/operator methods, like my_dask_array * my_pint_unit. Here my_dask_array needs to return NotImplemented in elemwise (which is all __mul__ is calling) before delegating to blockwise application of operator.mul so that my_pint_unit properly handles the operation with its __rmul__ in order to construct a Quantity wrapping my_dask_array.

Here my_dask_array needs to return NotImplemented in elemwise (which is all __mul__ is calling) before delegating to blockwise application of operator.mul so that my_pint_unit properly handles the operation with its __rmul__ in order to construct a Quantity wrapping my_dask_array.

The NotImplemented logic could be handled inside __mul__ or __array_ufunc__. elemwise itself never should return NotImplemented, it doesn't need to worry about dispatch.

The NotImplemented logic could be handled inside __mul__ or __array_ufunc__. elemwise itself never should return NotImplemented, it doesn't need to worry about dispatch.

Makes sense now, thanks for clarifying! So, I'll plan on removing that check in elemwise and replacing it with a decorator for all the dunder/operator methods that does same check as __array_ufunc__.

Mostly I'm saying that I want Dask to be as permissive as possible, except
in cases where the behavior should definitely be undefined, as in x + y.
On Fri, Jul 10, 2020 at 2:08 PM Jon Thielen<EMAIL_ADDRESS>wrote:

The NotImplemented logic could be handled inside mul or
array_ufunc. elemwise itself never should return NotImplemented, it
doesn't need to worry about dispatch.
Makes sense now, thanks for clarifying! So, I'll plan on removing that
check in elemwise and replacing it with a decorator for all the
dunder/operator methods that does same check as array_ufunc.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/pull/6393#issuecomment-656891629, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACKZTFSXNLTJGIJCEC6NH3R257ODANCNFSM4OWC5UJA
.

Ah, got it. Although, for both prototypical upcast types of Pint Quantities and xarray DataArrays, chunk_array[:] is still just (a copy of) chunk_array, which we don't want inside the dask array either.

Yes, but hopefully you're not putting a pint.Quantity or xarray.DataArray as input into dask.array.from_array.
This isn't a recommendation pattern but I don't think we need to raise an error since it can't happen accidentally.

Mostly I'm saying that I want Dask to be as permissive as possible, except in cases where the behavior should definitely be undefined, as in x + y.

Sounds good. Implementing the type check on the dunder methods themselves rather than in elemwise should hopefully take care of that.

Yes, but hopefully you're not putting a pint.Quantity or xarray.DataArray as input into dask.array.from_array.
This isn't a recommendation pattern but I don't think we need to raise an error since it can't happen accidentally.

Sounds good as well. I guess I need to stop worrying so much about guarding for user mistakes.
With all that said, next up I'll go ahead with those changes and high-level tests for the type casting hierarchy working properly, and then check in again for a review. I do want to hold off on low-level tests for now until it is clearly decided which option (the current opt-in registry or one of @shoyer's 4 alternatives) to settle on.

Yes, but hopefully you're not putting a pint.Quantity or xarray.DataArray as input into dask.array.from_array.

FWIW I think that either of these are entirely reasonable actions, pint.Quantity especially, which I would hope would mostly work today.

Yes, but hopefully you're not putting a pint.Quantity or xarray.DataArray as input into dask.array.from_array.

FWIW I think that either of these are entirely reasonable actions, pint.Quantity especially, which I would hope would mostly work today.

Unfortunately, that indeed works right now and it is part of the problem I'm trying to fix in this PR. Take for example the following code snippet:
from pint import UnitRegistry
import dask.array as da
ureg = UnitRegistry()
l = da.array([0, 1, 2] * ureg.m)
t = 1 * ureg.s
s = (1 / t) * l
print(s.units)

which currently outputs
1 / second

when the correct unit is
meter / second

In order for intermediate operations with Quantities to work out in physical calculations, we need the units to be managed consistently, which can break entirely with this kind of Pint > Dask > Pint construction. I'm totally fine with not raising an error in Dask on this, but it definitely needs to be discouraged when working with Pint (which is how I hope we can manage it in MetPy).

Right, I agree that for operations where both sides want to assume control we need to be careful.
In case you all were interested in the Dask(Pint) approach, this example would work well-ish in Dask today if Pint didn't try to consume Dask.
In [1]: from pint import UnitRegistry
   ...: import dask.array as da
   ...: ureg = UnitRegistry()
   ...: l = da.array([0, 1, 2] * ureg.m)
   ...: t = 1 * ureg.s
   ...: s = (1 / t) * l
   ...: s2 = l / t

In [2]: s.units
Out[2]: <Unit('1 / second')>

In [3]: s2._meta.units
Out[3]: <Unit('meter / second')>

But there are probably lots of cases where this wouldn't work as cleanly, and regardless, Dask would need to learn to pass certain getattr calls through to _meta

Right, I agree that for operations where both sides want to assume control we need to be careful.
In case you all were interested in the Dask(Pint) approach, this example would work well-ish in Dask today if Pint didn't try to consume Dask.
...
But there are probably lots of cases where this wouldn't work as cleanly, and regardless, Dask would need to learn to pass certain getattr calls through to _meta

Indeed, this all goes back to the point that either Dask(Pint) or Pint(Dask) would technically work just fine, but we have to choose one and only one for everything to work out cleanly.

Hopefully I've finally gotten CI working again with the modifications made and binary operator, ufunc, and function tests added. If you're able, another look over the code here would be great.
A few questions I wanted to raise:

How should this be documented? It is a fairly substantial change for those interoperating with less common array types, and the error messages raised (no implementation found for types Array and "other") won't give a hint to the immediate fix (registering with register_chunk_type). I think something specific should be added to the docs, but I'm not sure where it would fit best.
How should scalars be handled? Right now, I've added checks against Number and np.ScalarType, as well as a somewhat hacky string-based check for Dask Scalar (since I couldn't seem to work around the circular import). Using an existing scalar check (like numpy.isscalar or is_scalar_for_elemwise) captures too many types that should be deferred to (e.g., Pint Units and scalar Quantities). I'm not sure if something more robust should be done or not.
Is the opt-in simple registry okay to settle on, or should this PR be put on hold to consider the other options more?

So to be clear, it sounds like the following will still work:
x = da.from_array(my_unknown_array_type)

But the following will err
x + my_unknown_array_type

In the latter case, it could be made to work if the user wrapped my_unknown_array_type in da.from_array.  Is that correct?  If so, we might consider adding an informative error message here, explaining the situation and giving them the two options of registering their type, or wrapping in da.from_array

So to be clear, it sounds like the following will still work:
x = da.from_array(my_unknown_array_type)

But the following will err
x + my_unknown_array_type

In the latter case, it could be made to work if the user wrapped my_unknown_array_type in da.from_array. Is that correct?

Yes, either
x + da.from_array(my_unknown_array_type)

or
da.register_chunk_type(type(my_unknown_array_type))
x + my_unknown_array_type

should work (this is probably a good test for me to add now that you point it out).

If so, we might consider adding an informative error message here, explaining the situation and giving them the two options of registering their type, or wrapping in da.from_array

I'm unfortunately not sure how to do that, since the error is raised in whatever is doing the dispatching rather than Dask (all Dask is doing is returning NotImplemented). While a warning could hypothetically be issued prior to returning NotImplemented, we'd then need a way to disable that warning for known upcast types (and unknown upcast types the user may want to add).

Ah, oh well
On Mon, Jul 13, 2020 at 7:58 AM Jon Thielen<EMAIL_ADDRESS>wrote:

So to be clear, it sounds like the following will still work:
x = da.from_array(my_unknown_array_type)
But the following will err
x + my_unknown_array_type
In the latter case, it could be made to work if the user wrapped
my_unknown_array_type in da.from_array. Is that correct?
Yes, either
x + da.from_array(my_unknown_array_type)
or
da.register_chunk_type(type(my_unknown_array_type))
x + my_unknown_array_type
should work (this is probably a good test for me to add now that you point
it out).
If so, we might consider adding an informative error message here,
explaining the situation and giving them the two options of registering
their type, or wrapping in da.from_array
I'm unfortunately not sure how to do that, since the error is raised in
whatever is doing the dispatching rather than Dask (all Dask is doing is
returning NotImplemented). While a warning could hypothetically be issued
prior to returning NotImplemented, we'd then need a way to disable that
warning for known upcast types (and unknown upcast types the user may want
to add).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/pull/6393#issuecomment-657610962, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACKZTGAYOUZAW4HDTZIXV3R3MOKVANCNFSM4OWC5UJA
.

Just bumping the discussion here since it's been over a week and I'd hope to be able to move forward with this. The two main points not resolved at this point are:

how/where should this chunk type compatibility be documented?
is everyone good with settling on the opt-in registry approach used here? (or does another approach from the options brought up by @shoyer need to be discussed?)

Thanks again for the feedback!

I'm good with this being merged for now. For the long-term, I'd prefer something along the lines of a semi-official numpy-duckhelpers project with these sorts of utilities.

I've added the remaining tests and included some brief additions to the docs, so this should be ready for a full review. I'd particularly like guidance on documenting this, since I couldn't find a real obvious place to do so, and I'm not sure how to best make it findable when users get the TypeError: operand type(s) all returned NotImplemented ... errors.

@jcrist if you have time to take a look at this, I'd be more comfortable with accepting this if it had your blessing

Sorry for the long delay here in addressing the review feedback! I've made the requested changes (recursion in the WrappedArray test class, explanatory docstring for register_chunk_type, and spelling correction in the check_if_implemented_given_other docstring), so hopefully this should be ready for a final review and merge. Though, the docstring for register_chunk_type ended up getting a little long, so please do let me know if that should be modified in any way.

Though, the docstring for register_chunk_type ended up getting a little long, so please do let me know if that should be modified in any way

I think that it's good.  The test itself didn't pass though.  I've modified the doctest a bit by adding an import and ellipses to remove some of the more detailed tracebacks.  However it looks like there might be an issue with the flag parameter that isn't being set correctly (I've provided a default value of None, which doesn't match the expected value provided from the operand.  I'm a bit out of my depth at this point, so I figured I'd pass it back to you.
I pushed to your branch, so you might have to git pull.  I hope that you don't mind.

@mrocklin Thanks for catching that! I simply forgot to set the flag value in the second part of the example. But, having the default value is a good idea, so I just set that to False. This FlaggedArray was simply something I wrote up quick as the minimal duck array implementation I could think of that does something other than just encapsulate the ndarray.
Hopefully the docs CI passes this time around!

I've just rebased to latest master, and the CI is all green, so unless there are any final comments, this should be ready to merge!

Thank you for your work here @jthielen .  I apologize for the long delay.  Given the positive reviews by the other folks here I'm going to go ahead and merge.
Also, I notice that this is your first code contribution to this repository.  Welcome!  It's quite an initial PR :)

Glad to be able to help! Thank you everyone for the great feedback along the way!


Let the end user know that there is a 2.174521 ada fee when entering pool

I'm a new user to daedalus and experimenting with it...One thing I found confusing was the 2.174521 ada fee...
Let the user know that there is a 2.174521 ada fee when entering pool. And that we recover this when we exit the pool.

It was very confusing to see -2.174521 ada substracted from my wallet with no consent or information anywhere on the screen.

Closing this ticket as it is a duplicate of https://github.com/input-output-hk/daedalus/issues/2116
Please see the details on the link above.


Added Remove all but latest, silent uninstall minus elevation prompt

Changed the code to remove all but latest version - had to convert WMI version to System.Version for sorting.
Used a select first to show current, select -skip 1 to remove all but current.
added /QN and IGNOREDEPENDENCIES=ALL for silent uninstall other than UAC prompt.

Much faster and safer now

I prefer the simplicity of the original script.

Fixed an issue where the SDK packages were also installed via the WOW6432Node

It would be better to choose the max version to remove with some wildcard/pattern

thank you


Features Checklist

Authlib features and their statuses.
Client

[x] OAuth1Session, compatible with requests-oauthlib
[x] OAuth2Session, compatible with requests-oauthlib
[x] OAuthClient, a mixed client for OAuth 1 and OAuth 2
[x] Flask integration
[x] Django integration
[x] OpenID Connect id_token parsing

Server

[x] Flask OAuth 1 provider
[x] Flask OAuth 2 provider
[x] Django OAuth 1 provider
[x] Django OAuth 2 provider
[x] Flask OpenID integration
[x] Django OpenID integration

Specifications

[ ] RFC4226
[x] RFC5849
[ ] RFC6238
[x] RFC6749
[x] RFC6750
[x] RFC7009
[x] RFC7515, JSON Web Signature
[x] RFC7516, JSON Web Encryption
[x] RFC7517, JSON Web Key
[x] RFC7518, JSON Web Algorithms
[x] RFC7519, JSON Web Token
[x] RFC7521
[ ] RFC7522
[x] RFC7523
[ ] RFC7591
[ ] RFC7592
[x] RFC7636
[x] RFC7662
[ ] RFC7797

Server integration with an async web engine such as aiohttp would be great.

Please consider implementing the User-Managed Access (UMA) 2.0 layer.


SPIKE: Can we put the K8 control plane inside of the VPN?

Currently the EKS master nodes and the ability to talk to them via kubectl and the http api is exposed to the internet and can be accessed by anyone who is able to obtain a kubeconfig and an aws token.  We could have better security for managing the cluster if the master nodes // control plane were inside of the VPN.
Is this possible?
What are the downsides?
Acceptance Criteria:

[ ] Answer the title question
[ ] Review findings with @jmorris-pillar to determine path forward
[ ] Write dev card(s) if applicable

@rob-h-m
This is specific to Columbus and should be moved to SmartColumbusOS


XFeat + LightGlue

Hello everyone,
I'm training some LightGlue variations (finding a neat trade-off between model size vs accuracy) and soon I will update the repo with the model and weights in the next weeks!
You can follow this issue if you are interested.
Best,
Guilherme

Hey guys, just released a version of LightGlue matcher, please check out in README

大家好，刚刚发布了一个版本的 LightGlue 匹配器，请在 README  中查看

Hello, author, didn't you say that XFEAT performance is better than Superpoint, why look at the data this time Superpoint is stronger

Hi @muchluv525,
Please notice that we trained a smaller and faster version of LightGlue.
Other than that, there are still a few reasons that SuperPoint + LightGlue might be still better than XFeat + LG (full size)
1 - Descriptor embedding: XFeat extracts a much more compact (64-D vs 256-D) descriptors;
2 - SuperPoint has a much larger backbone.

And the number of layers is just 6. BTW, would you upload the training code of LightGlue for XFeat?

嗨，
请注意，我们训练了一个_更小、更快_的 LightGlue 版本。
除此之外，SuperPoint + LightGlue 可能仍然优于 XFeat + LG（全尺寸）有几个原因 1 - 描述符嵌入：XFeat 提取更紧凑（64-D 与 256-D）的描述符; 2 - SuperPoint 具有更大的主干网。
I see, thank you for the answer, I'm a beginner and look forward to a more detailed explanation of xfeat

嗨，
请注意，我们训练了一个_更小、更快_的 LightGlue 版本。
除此之外，SuperPoint + LightGlue 可能仍然优于 XFeat + LG（全尺寸）有几个原因 1 - 描述符嵌入：XFeat 提取更紧凑（64-D 与 256-D）的描述符; 2 - SuperPoint 具有更大的主干网。

我明白了，谢谢你的回答，我是初学者，期待对xfeat进行更详细的解释

@guipotje Have you tried training Xfeat and LightGlue end-to-end?

Hello @noahzn, I haven't tried to train it end-to-end. It might deliver some improvements, as mentioned in SuperGlue's paper (section 5.4), when backpropagating through the descriptors. However, it also might lead to less generalization to different scenes.

Hello, I encountered an error while converting the ONNX model using torch.export. Here is the code we used for the model conversion.

This is the error.

Hello,
Thank you very much for your great work.
I am curious about the modifications made to the lightglue network structure to achieve the balance between inference accuracy and speed mentioned in the README. Will this part of the code be made publicly available?
I checked the match_lighterglue.py file, but it does not provide more information on this aspect.

Hello @noahzn, I haven't tried to train it end-to-end. It might deliver some improvements, as mentioned in SuperGlue's paper (section 5.4), when backpropagating through the descriptors. However, it also might lead to less generalization to different scenes.

Hi @guipotje I might try end-to-end training, do you have any idea about the implementation? Since XFeat and LightGlue use different homography code for training, I'm wondering if it's possible to keep their own random homography code, but only optimize two networks together. This may need XFeat to return a loss and then we add it to LightGlue's loss and backprop together. Do you think this is the minimal effort for an end-to-end training of the two networks?


Adding CMSoftwareDistributionComponent Module

Pull Request (PR) description
Adding resource for managing and configuring SoftwareDistributionComponent.  Also gives the ability to add\remove Network Access Acccounts.
This Pull Request (PR) fixes the following issues

Task list

[X] Added an entry to the change log under the Unreleased section of the
file CHANGELOG.md. Entry should say what was changed and how that
affects users (if applicable), and reference the issue being resolved
(if applicable).
[X] Resource documentation added/updated in README.md.
[X] Resource parameter descriptions added/updated in README.md, schema.mof
and comment-based help.
[X] Comment-based help added/updated.
[X] Localization strings added/updated in all localization files as appropriate.
[X] Examples appropriately added/updated.
[X] Unit tests added/updated. See DSC Community Testing Guidelines.
[ ] Integration tests added/updated (where possible). See DSC Community Testing Guidelines.
[X] New/changed code adheres to DSC Community Style Guidelines.

This change is

Tested this resource and it behaves as expected. Will do code review tomorrow.


How to disable two wheels vehicles like bicycle and motorbike in CARLA 0.9.10

I found it is easy to disable two wheels vehicles in CARLA 0.8.x, but I didn't find any python interface to achieve this function in CARLA 0.9.10. Does anyone know how to solve this?

Where are you planning on disabling them exactly? In general though, actor blueprints have a number_of_wheels attribute*, which allow you to filter them. Below is an image of how spawn_npc.py does it (check the first line after the conditional statement)


Issue8

Description
Draft PR for #8
Additional context
I have added some initial logic to support __gap storage gaps variable.

Okay, I've done some research and we're going to set one rule:
__gaps must be of size 32 * n. You don't need to worry about it because it's already what we're doing. Just a note to self that we may want to throw an error if that isn't the case.

We'll need problematicOnlyBecauseOfGap function:

IN: item from new layout, old layout OUT: whether item from new layout overlaps only with gap from old layout
The function just needs to iterate over the items from the old layout, and using the current item's start and end, check if there's an overlap with the provided item from the new layout (by comparing to its start and end). If there's an overlap, return false if the current item is not a __gap. If it is a __gap, just continue. Return true at the end, i.e., if we don't find an overlap with an item from the old layout that is not a __gap.
This should be straightforward to do.
Let's start from there - by adding this function. I'll continue to debug the code in the meantime. Let me know if you think this is a good idea.

This is the same as variableFitInGap function, isn't it?

It's another, separate function.
variableFitInGap check's if the variable fits in the gap wholly. That is to say, it starts and ends in the gap.
problematicOnlyBecauseOfGap checks for a partial overlap, and we'll use it to cover an edge case later.

It's another, separate function.
variableFitInGap check's if the variable fits in the gap wholly. That is to say, it starts and ends in the gap.
problematicOnlyBecauseOfGap checks for a partial overlap, and we'll use it to cover an edge case later.

I think it's probably good if you take it on from here, because you will have to explain each and everything and it will consume your much of time so maybe I'll close this PR and let you do your job. What do you think?

Whatever you prefer. I have something else to work on, so I won't get back to Storage Delta this week. Totally fine if you want or not want to give it a shot in the meantime.

Whatever you prefer. I have something else to work on, so I won't get back to Storage Delta this week. Totally fine if you want or not want to give it a shot in the meantime.

Okay @ZeroEkkusu! Btw it was great doing discussion with you on this and I definitely learned a lot! Thanks! Closing this PR.

Thank you,
Take care, @kamuik16!


Auto play problem in Full-screen mode when  autoplayOnHover = pause.

In full-screen mode can’t start auto play when  autoplayOnHover is set to pause.
It seems that there is no way to move the mouse pointer outside the slider container to trigger startAutoplay().

Well, when the slider is in full-screen mode, it occupies the entire screen, so you can't really move the mouse outside the slider area.
The solution is to disable the autoplayOnHover when the slider is in full-screen mode: $( '.slider-pro' ).sliderPro( 'autoplayOnHover', false ). Then, re-enable it when you exit the full-screen mode.

Changing the interface behavior between screens will confuse the users.
Is there a way to constrain the autoplayOnHover to sp-slides-container or sp-thumbnail-container div?

You can listen for mouse over/out events on any element and then use the stopAutoplay() and startAutoplay() methods to stop/start the autoplay. You will also need to disable the autoplayOnHover option.

Added:
var slider = $("#slider").data( "sliderPro" );
$( ".sp-thumbnails-container" ).on( "mouseleave", function() { slider.startAutoplay();});
$( ".sp-thumbnails-container" ).on( "mouseenter", function() { slider.stopAutoplay();});

Works but there are some issues:

Starts auto play when thumbnail is clicked. Even when mouse pointer is still hovering over thumbs container.
Won't start auto play when switched to full screen. Starts only after mouse is moved over thumbs container.

Try this:
var slider = $("#slider");
$( ".sp-thumbnails-container" ).on( "mouseleave", function() { slider.sliderPro( 'autoplay', true ); } );
$( ".sp-thumbnails-container" ).on( "mouseenter", function() { slider.sliderPro( 'autoplay', false ); } );

Seems to be working. Thank You.


Seeder fix

Had to use Promise constructor to async the user to data seed, then run the data extension seed. Back end just needs full crud for the data extension then you have a complete skeleton with data relations and login/logout and password hashing for your back end. Then I need to test all the api routes


Add scrollback hotkeys

This offers a few additional hotkeys that can be used in combination
with scrollback. None of these are used by default yet.
This implements the following bindings:

ScrollPageUp: Scroll exactly one screen height up
ScrollPageDown: Scroll exactly one screen height down
ScrollToTop: Scroll as far up as possible
ScrollToBottom: Scroll as far down as possible

This fixes #1151.

Could we add half a screen to? I think that would be the only one I would want actually.

I have no problem with that, but maybe there is a better way for doing this. Like being able to scroll by a specific amount of lines or something like that.

I don't know half a screen seems to be very common. It is good so that you see more, but at the same time you keep some context from before. A fixed number N of lines wouldn't make sense if you have differently sized terminals, right?

Good idea @jwilm, looks a lot cleaner now in the files that basically didn't get touched.

How do you feel about half-page scrolling @jwilm? I'd probably just merge this and then see how the feedback is, because it would be a non-breaking change.

The default in other terminals I've used is full page, but i'm not against it as an option. Let's consider it separately.


How to make inference fast (by adding caching of key / values)

How can we implement the below caching technique in the code?
That would be awesome.
What I have tried to speed up the inference in my custom implementations for autoregressive self-attention is caching the output of the self-attention at timestep T and then, in timestep T+1, passing the full keys/values but only passing the last element of the query sequence, then getting the output and concatenating it with the cache, that way each query can pay attention to the full previous sequence but we don't need to compute attention for all the previous queries when we only need the output at T+1
It looks something like this:

But I only achieved a x3 speedup 🤔
I actually needed to perform autoregressive inference in a very large dataset, and it was taking more than 1 day even with the above speedup. I am currently doing some weird custom stuff, keeping the Transformer attention layers but replacing the self-attention layers with LSTMs, which are way faster at generating sequences token by token, and with that I achieve the x10 speedup that I needed.
Originally posted by @pabloppp in https://github.com/lucidrains/x-transformers/issues/21#issuecomment-797589687

Well, I did mine in a custom Transformer implementation, what I basically did is the following:
The attention layers generally receive Q, K & V and output a sequence, I added an extra input called cache.
Then inside the attention layer, for Q I only took the element at the last position in the sequence:
q = q[-1:]

Then I applied regular attention to the new Q with the regular K & V, but the problem now is that your output sequence has length 1 because you only took your last Q, so here is where the cache comes to play, you will concatenate the cache to your output:
output = torch.cat([cache, output], dim=1)

and then you will keep your output as the cache for the next element in the sequence, so the final look of the attention layer would be:
output_t0 = attention(q_t0, k_t0, v_t0)
...
output_t1 = attention(q_t0, k_t0, v_t0, cache = output_t0)

@PhenomenalOnee Before I thought the PyTorch would automatically do self attention between the new token with previous tokens in the decoder, and cross attention between the new token with the tokens from encoder.  But the fact is that the when every new token comes in, the previous tokens would do cross attention again to get the same outputs for themselves. I don't know if I understand right but if it's the truth, the efficiency would be much low.

turns out you can actually go a bit faster https://crfm.stanford.edu/2023/10/12/flashdecoding.html but it requires that you are one of the CUDA experts out there

anyways, closing this as caching of key/values have been implemented!


Explore Importing More Properties/CSS Attributes

"How about importing the layers using the CSS attributes that Sketch spits out. Could then have editable layers based on the design."

Ideas:

shadowY, shadowX, shadowBlur, shadowColor
opacity
rotation
borderRadius

For text layers, start with the text contents and css.


Refactor printer.ts

Pull Request Test Coverage Report for Build 426913866

125 of 139 (89.93%)  changed or added relevant lines in 9 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.4%) to 90.61%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

packages/protoc-gen-nexus/src/dslgen/types.ts
28
42
66.67%

Totals

Change from base Build 422141586:
0.4%

Covered Lines:
280

Relevant Lines:
298

💛  - Coveralls


Fix .github/workflows/codeql.yml

The file had the - run: statement, which spanned across multiple lines, not completely commented out, resulting in syntax errors, which trigger emails being sent with each pushed commit.

In main as 4472df4a03b5078ef74ebc601758cbe107386144