Bogus "tx_id" doesn't exist in function domain.

The following spec works fine in TLC, but fails exploration with tla-web with:
Error: argument "tx_id" doesn't exist in function domain.
    at assert (eval.js:39:15)
    at FcnRcdValue.applyArg (eval.js:422:9)
    at evalExpr (eval.js:3679:31)
    at evalExpr (eval.js:4000:16)
    at evalExpr (eval.js:3462:17)
    at evalExpr (eval.js:4000:16)
    at evalLetIn (eval.js:3161:26)
    at evalExpr (eval.js:3400:16)
    at evalExpr (eval.js:4000:16)
    at eval.js:2692:19

The source of the error appears to be StatusCommittedResponseAction.
---- MODULE SingleNode ----

EXTENDS Naturals, Sequences, SequencesExt

RwTxRequest == "RwTxRequest"
RwTxResponse == "RwTxResponse"
RoTxRequest == "RoTxRequest"
RoTxResponse == "RoTxResponse"
TxStatusReceived == "TxStatusReceived"

CommittedStatus == "CommittedStatus"
InvalidStatus == "InvalidStatus"
TxStatuses == {
    CommittedStatus,
    InvalidStatus
    }

FirstBranch == 1

Views == Nat

\* Sequence numbers start at 1, 0 is used a null value
SeqNums == Nat

\* TxIDs consist of a view and sequence number and thus start at (1,1)
TxIDs == Views \X SeqNums

\* This models uses a dummy application where read-write transactions
\* append an integer to a list and then reads the list
\* Read-only transactions simply read the list
Txs == Nat

VARIABLES history

HistoryTypeOK ==
    \A i \in DOMAIN history:
        \/  /\ history[i].type \in {RwTxRequest, RoTxRequest}
            /\ history[i].tx \in Txs
        \/  /\ history[i].type \in {RwTxResponse, RoTxResponse}
            /\ history[i].tx \in Txs
            /\ history[i].observed \in Seq(Txs)
            /\ history[i].tx_id \in TxIDs
        \/  /\ history[i].type = TxStatusReceived
            /\ history[i].tx_id \in TxIDs
            /\ history[i].status \in TxStatuses

\* Abstract ledgers that contains only client transactions (no signatures)
\* Indexed by view, each ledger is the ledger associated with leader of that view
\* In practice, the ledger of every CCF node is one of these or a prefix for one of these
\* This could be switched to a tree which can represent forks more elegantly
VARIABLES ledgerBranches

LedgerTypeOK ==
    \A view \in DOMAIN ledgerBranches:
        \A seqnum \in DOMAIN ledgerBranches[view]:
            \* Each ledger entry is tuple containing a view and tx
            \* The ledger entry index is the sequence number
            /\ ledgerBranches[view][seqnum].view \in Views
            /\ "tx" \in DOMAIN ledgerBranches[view][seqnum] => ledgerBranches[view][seqnum].tx \in Txs

\* In this abstract version of CCF's consensus layer, each ledger is append-only
LedgersMonoProp ==
    [][\A view \in DOMAIN ledgerBranches: IsPrefix(ledgerBranches[view], ledgerBranches'[view])]_ledgerBranches

vars == << history, ledgerBranches >>

TypeOK ==
    /\ HistoryTypeOK
    /\ LedgerTypeOK

Init ==
    /\ history = <<>>
    /\ ledgerBranches = [ x \in 1..FirstBranch |-> <<>>]

IndexOfLastRequested ==
    SelectLastInSeq(history, LAMBDA e : e.type \in {RwTxRequest, RoTxRequest})

NextRequestId ==
    IF IndexOfLastRequested = 0 THEN 0 ELSE history[IndexOfLastRequested].tx+1

\* Submit new read-write transaction
\* This could be extended to add a notion of session and then check for session consistency
RwTxRequestAction ==
    /\ history' = Append(
        history,
        [type |-> RwTxRequest, tx |-> NextRequestId]
        )
    /\ UNCHANGED ledgerBranches

\* Execute a read-write transaction
RwTxExecuteAction ==
    /\ \E i \in DOMAIN history :
        /\ history[i].type = RwTxRequest
        \* Check transaction has not already been added to a ledger
        /\ \A view \in DOMAIN ledgerBranches:
            \A seqnum \in DOMAIN ledgerBranches[view]:
                "tx" \in DOMAIN ledgerBranches[view][seqnum]
                => history[i].tx /= ledgerBranches[view][seqnum].tx
        \* Note that a transaction can be added to any ledger, simulating the fact
        \* that it can be picked up by the current leader or any former leader
        /\ \E view \in FirstBranch..Len(ledgerBranches):
                ledgerBranches' = [ledgerBranches EXCEPT ![view] =
                    Append(@,[view |-> view, tx |-> history[i].tx])]
        /\ UNCHANGED history

LedgerBranchTxOnly(branch) ==
    LET SubBranch == SelectSeq(branch, LAMBDA e : "tx" \in DOMAIN e)
    IN [i \in DOMAIN SubBranch |-> SubBranch[i].tx]

\* Response to a read-write transaction
RwTxResponseAction ==
    /\ \E i \in DOMAIN history :
        \* Check request has been received and executed but not yet responded to
        /\ history[i].type = RwTxRequest
        /\ {j \in DOMAIN history:
            /\ j > i
            /\ history[j].type = RwTxResponse
            /\ history[j].tx = history[i].tx} = {}
        /\ \E view \in FirstBranch..Len(ledgerBranches):
            /\ \E seqnum \in DOMAIN ledgerBranches[view]:
                /\ "tx" \in DOMAIN ledgerBranches[view][seqnum]
                /\ history[i].tx = ledgerBranches[view][seqnum].tx
                /\ history' = Append(
                    history,[
                        type |-> RwTxResponse,
                        tx |-> history[i].tx,
                        observed |-> LedgerBranchTxOnly(SubSeq(ledgerBranches[view],1,seqnum)),
                        tx_id |-> <<ledgerBranches[view][seqnum].view, seqnum>>] )
    /\ UNCHANGED ledgerBranches

\* Sending a committed status message
\* Note that a request could only be committed if it's in the highest view's ledger
StatusCommittedResponseAction ==
    /\ \E i \in DOMAIN history :
        LET view == history[i].tx_id[1]
            seqno == history[i].tx_id[2]
        IN /\ history[i].type = RwTxResponse
           /\ Len(Last(ledgerBranches)) >= seqno
           /\ Last(ledgerBranches)[seqno].view = view
           \* There is no future InvalidStatus that's incompatible with this commit
           \* This is to accomodate StatusInvalidResponseAction making future commits invalid,
           \* and is an unnecessary complication for model checking. It does facilitate trace
           \* validation though, by allowing immediate processing of Invalids without
           \* needing to wait for the commit history knowledge to catch up.
           /\ \lnot \E j \in DOMAIN history:
                /\ history[j].type = TxStatusReceived
                /\ history[j].status = InvalidStatus
                /\ history[j].tx_id[1] = view
                /\ history[j].tx_id[2] <= seqno
           \* Reply
           /\ history' = Append(
              history,[
                type |-> TxStatusReceived,
                tx_id |-> history[i].tx_id,
                status |-> CommittedStatus]
              )
    /\ UNCHANGED ledgerBranches

\* Append a transaction to the ledger which does not impact the state we are considering
AppendOtherTxnAction ==
    /\ \E view \in FirstBranch..Len(ledgerBranches):
        ledgerBranches' = [ledgerBranches EXCEPT ![view] =
                    Append(@,[view |-> view])]
    /\ UNCHANGED history

\* A CCF service with a single node will never have a view change
\* so the log will never be rolled back and thus transaction IDs cannot be invalid
Next ==
    \/ RwTxRequestAction
    \/ RwTxExecuteAction
    \/ RwTxResponseAction
    \/ StatusCommittedResponseAction
    \/ AppendOtherTxnAction
====

/cc @heidihoward @achamayou

Without StatusCommittedResponseAction, I can also trigger "argument "tx" doesn't exist in function domain.": https://will62794.github.io/tla-web/#!/home?specpath=.%2Fspecs%2FTwoPhase.tla&trace=58432bbb%2C265bd359%2C7adf95f4%2C7adf95f4%2C7adf95f4%2C7adf95f4

@lemmy Pushed some fixes to address this. I believe one issue was that the interpreter was not short-circuiting implication evaluation where possible. Pushed a change for this.
I think there is an additional issue that seems related to non-lazy evaluation semantics in the web interpreter. I've run into this a bit before but haven't yet made a directed effort to align lazy eval semantics of the web interpreter with TLC.  Saved an updated version of your spec that works around this here. I also added a local version of the SelectSeq operator inline. You can try opening that version in the web explorer now.
Also note that if you want the interface to properly display next possible actions, you should update the spec structure to have actions parameterized by any non-deterministic arguments (e.g. \E i \in DOMAIN history). Eventually I'll improve the interface to better handle specs that don't conform to this structure.

Also note that if you want the interface to properly display next possible actions, you should update the spec structure to have actions parameterized by any non-deterministic arguments (e.g. \E i \in DOMAIN history). Eventually I'll improve the interface to better handle specs that don't conform to this structure.

@will62794 It's nice that this lets the user pick the successor state, but it's no longer obvious what the name of the sub-action is. Can we have the cake and eat it too (see mock below)? :-)

@lemmy For which spec are you observing the behavior shown in that screenshot?

---- MODULE Consistency ----

EXTENDS Naturals, Sequences

----------------------------------------------------------------------

\* tla-web doesn't have a builtin for the standard module's Sequences!SelectSeq.
\* This is why its definition is included under a new name here.  TLC will suffer
\* a slowdown because it's module override won't be active for MySelectSeq.
MySelectSeq(s, Test(_)) ==
  LET F[i \in 0..Len(s)] ==
        IF i = 0 THEN << >>
                 ELSE IF Test(s[i]) THEN Append(F[i-1], s[i])
                                    ELSE F[i-1]
  IN F[Len(s)]

----------------------------------------------------------------------

\* The following four operators are taken from the CommunityModule's SequencesExt,
\* because tla-web does not have a module system.
Max(S) == CHOOSE x \in S : \A y \in S : x >= y

Last(s) == s[Len(s)]

SelectLastInSeq(seq, Test(_)) ==
  LET I == { i \in 1..Len(seq) : Test(seq[i]) }
  IN IF I # {} THEN Max(I) ELSE 0

IsPrefix(s, t) ==
  Len(s) <= Len(t) /\ SubSeq(s, 1, Len(s)) = SubSeq(t, 1, Len(s))

----------------------------------------------------------------------

RwTxRequest == "RwTxRequest"
RwTxResponse == "RwTxResponse"
RoTxRequest == "RoTxRequest"
RoTxResponse == "RoTxResponse"
TxStatusReceived == "TxStatusReceived"

CommittedStatus == "CommittedStatus"
InvalidStatus == "InvalidStatus"
TxStatuses == {
    CommittedStatus,
    InvalidStatus
    }

FirstBranch == 1

Views == Nat

\* Sequence numbers start at 1, 0 is used a null value
SeqNums == Nat

\* TxIDs consist of a view and sequence number and thus start at (1,1)
TxIDs == Views \X SeqNums

\* This models uses a dummy application where read-write transactions
\* append an integer to a list and then reads the list
\* Read-only transactions simply read the list
Txs == Nat

----------------------------------------------------------------------

VARIABLES history

HistoryTypeOK ==
    \A i \in DOMAIN history:
        \/  /\ history[i].type \in {RwTxRequest, RoTxRequest}
            /\ history[i].tx \in Txs
        \/  /\ history[i].type \in {RwTxResponse, RoTxResponse}
            /\ history[i].tx \in Txs
            /\ history[i].observed \in Seq(Txs)
            /\ history[i].tx_id \in TxIDs
        \/  /\ history[i].type = TxStatusReceived
            /\ history[i].tx_id \in TxIDs
            /\ history[i].status \in TxStatuses

CommittedEventIndexes ==
    {i \in DOMAIN history:
        /\ history[i].type = TxStatusReceived
        /\ history[i].status = CommittedStatus
        }

\* Transaction IDs which received committed status messages
CommittedTxIDs ==
    {history[i].tx_id: i \in CommittedEventIndexes}
CommitSeqNum ==
    Max({i[2]: i \in CommittedTxIDs} \cup {0})

\* Abstract ledgers that contains only client transactions (no signatures)
\* Indexed by view, each ledger is the ledger associated with leader of that view
\* In practice, the ledger of every CCF node is one of these or a prefix for one of these
\* This could be switched to a tree which can represent forks more elegantly
VARIABLES ledgerBranches

LedgerTypeOK ==
    \A view \in DOMAIN ledgerBranches:
        \A seqnum \in DOMAIN ledgerBranches[view]:
            \* Each ledger entry is tuple containing a view and tx
            \* The ledger entry index is the sequence number
            /\ ledgerBranches[view][seqnum].view \in Views
            /\ "tx" \in DOMAIN ledgerBranches[view][seqnum] => ledgerBranches[view][seqnum].tx \in Txs

\* In this abstract version of CCF's consensus layer, each ledger is append-only
LedgersMonoProp ==
    [][\A view \in DOMAIN ledgerBranches: IsPrefix(ledgerBranches[view], ledgerBranches'[view])]_ledgerBranches

vars == << history, ledgerBranches >>

TypeOK ==
    /\ HistoryTypeOK
    /\ LedgerTypeOK

Init ==
    /\ history = <<>>
    /\ ledgerBranches = [ x \in 1..FirstBranch |-> <<>>]

IndexOfLastRequested ==
    SelectLastInSeq(history, LAMBDA e : e.type \in {RwTxRequest, RoTxRequest})

NextRequestId ==
    IF IndexOfLastRequested = 0 THEN 0 ELSE history[IndexOfLastRequested].tx+1

\* Submit new read-write transaction
\* This could be extended to add a notion of session and then check for session consistency
RwTxRequestAction ==
    /\ history' = Append(
        history,
        [type |-> RwTxRequest, tx |-> NextRequestId]
        )
    /\ UNCHANGED ledgerBranches

\* Execute a read-write transaction
RwTxExecuteAction(i) ==
\* RwTxExecuteAction ==
\*     /\ \E i \in DOMAIN history :
        /\ history[i].type = RwTxRequest
        \* Check transaction has not already been added to a ledger
        /\ \A view \in DOMAIN ledgerBranches:
            \A seqnum \in DOMAIN ledgerBranches[view]:
                "tx" \in DOMAIN ledgerBranches[view][seqnum]
                => history[i].tx /= ledgerBranches[view][seqnum].tx
        \* Note that a transaction can be added to any ledger, simulating the fact
        \* that it can be picked up by the current leader or any former leader
        /\ \E view \in FirstBranch..Len(ledgerBranches):
                ledgerBranches' = [ledgerBranches EXCEPT ![view] =
                    Append(@,[view |-> view, tx |-> history[i].tx])]
        /\ UNCHANGED history

LedgerBranchTxOnly(branch) ==
    LET SubBranch == MySelectSeq(branch, LAMBDA e : "tx" \in DOMAIN e)
    IN [i \in DOMAIN SubBranch |-> SubBranch[i].tx]

\* Response to a read-write transaction
RwTxResponseAction(i) ==
\* RwTxResponseAction ==
\*     /\ \E i \in DOMAIN history :
        \* Check request has been received and executed but not yet responded to
        /\ history[i].type = RwTxRequest
        /\ {j \in DOMAIN history:
            /\ j > i
            /\ history[j].type = RwTxResponse
            /\ history[j].tx = history[i].tx} = {}
        /\ \E view \in FirstBranch..Len(ledgerBranches):
            /\ \E seqnum \in DOMAIN ledgerBranches[view]:
                /\ "tx" \in DOMAIN ledgerBranches[view][seqnum]
                /\ history[i].tx = ledgerBranches[view][seqnum].tx
                /\ history' = Append(
                    history,[
                        type |-> RwTxResponse,
                        tx |-> history[i].tx,
                        observed |-> LedgerBranchTxOnly(SubSeq(ledgerBranches[view],1,seqnum)),
                        tx_id |-> <<ledgerBranches[view][seqnum].view, seqnum>>] )
    /\ UNCHANGED ledgerBranches

\* Sending a committed status message
\* Note that a request could only be committed if it's in the highest view's ledger
StatusCommittedResponseAction(i) ==
\* StatusCommittedResponseAction ==
\*     /\ \E i \in DOMAIN history :
           /\ history[i].type = RwTxResponse
           /\ Len(Last(ledgerBranches)) >= history[i].tx_id[2]
           /\ Last(ledgerBranches)[history[i].tx_id[2]].view = history[i].tx_id[1]
           \* There is no future InvalidStatus that's incompatible with this commit
           \* This is to accomodate StatusInvalidResponseAction making future commits invalid,
           \* and is an unnecessary complication for model checking. It does facilitate trace
           \* validation though, by allowing immediate processing of Invalids without
           \* needing to wait for the commit history knowledge to catch up.
           /\ \lnot \E j \in DOMAIN history:
                /\ history[j].type = TxStatusReceived
                /\ history[j].status = InvalidStatus
                /\ history[j].tx_id[1] = history[i].tx_id[1]
                /\ history[j].tx_id[2] <= history[i].tx_id[2]
           \* Reply
           /\ history' = Append(
              history,[
                type |-> TxStatusReceived,
                tx_id |-> history[i].tx_id,
                status |-> CommittedStatus]
              )
    /\ UNCHANGED ledgerBranches

\* Append a transaction to the ledger which does not impact the state we are considering
AppendOtherTxnAction ==
    /\ \E view \in FirstBranch..Len(ledgerBranches):
        ledgerBranches' = [ledgerBranches EXCEPT ![view] =
                    Append(@,[view |-> view])]
    /\ UNCHANGED history

\* Submit new read-only transaction
RoTxRequestAction ==
    /\ history' = Append(
        history,
        [type |-> RoTxRequest, tx |-> NextRequestId]
        )
    /\ UNCHANGED ledgerBranches

\* Response to a read-only transaction request
\* Assumes read-only transactions are always forwarded
\* TODO: Separate execution and response
RoTxResponseAction(i) ==
\* RoTxResponseAction ==
\*     /\ \E i \in DOMAIN history :
        \* Check request has been received but not yet responded to
        /\ history[i].type = RoTxRequest
        /\ {j \in DOMAIN history:
            /\ j > i
            /\ history[j].type = RoTxResponse
            /\ history[j].tx = history[i].tx} = {}
        /\ \E view \in FirstBranch..Len(ledgerBranches):
            /\ Len(ledgerBranches[view]) > 0
            /\ history' = Append(
                history,[
                    type |-> RoTxResponse,
                    tx |-> history[i].tx,
                    observed |-> LedgerBranchTxOnly(ledgerBranches[view]),
                    tx_id |-> <<ledgerBranches[view][Len(ledgerBranches[view])].view, Len(ledgerBranches[view])>>] )
    /\ UNCHANGED ledgerBranches

\* The set of views where the corresponding terms have all committed log entries
ViewWithAllCommitted ==
    {view \in DOMAIN ledgerBranches:
        /\ Len(ledgerBranches[view]) >= CommitSeqNum
        /\  \/ CommitSeqNum = 0
            \/ <<ledgerBranches[view][CommitSeqNum].view, CommitSeqNum>> \in CommittedTxIDs }

\* Simulates leader election by rolling back some number of uncommitted transactions and updating view
TruncateLedgerAction ==
    /\ \E view \in ViewWithAllCommitted:
        /\ \E i \in CommitSeqNum..Len(ledgerBranches[view]) :
            /\ ledgerBranches' = Append(ledgerBranches, SubSeq(ledgerBranches[view], 1, i))
            /\ UNCHANGED history

\* Sends status invalid message
StatusInvalidResponseAction(i) ==
\* StatusInvalidResponseAction ==
\*     /\ \E i \in DOMAIN history :
        /\ history[i].type = RwTxResponse
        \* either commit has passed seqnum but committed another transaction
        /\ \/ /\ CommitSeqNum >= history[i].tx_id[2]
              /\ Len(ledgerBranches[Len(ledgerBranches)]) >= history[i].tx_id[2]
              /\ ledgerBranches[Len(ledgerBranches)][history[i].tx_id[2]].view # history[i].tx_id[1]
        \* or commit hasn't reached seqnum but never will as current view is higher
            \/ /\ CommitSeqNum > 0
               /\ CommitSeqNum < history[i].tx_id[2]
               /\ ledgerBranches[Len(ledgerBranches)][CommitSeqNum].view > history[i].tx_id[1]
        \* or commit hasn't reached there,... but can never reach there
        \* note that this effectively allows StatusInvalidResponseAction to "declare" future transactions
        \* invalid, and requires a corresponding change in SingleNode::StatusCommittedResponseAction to
        \* constrain future commits. This combined change is unnecessary for model checking, but greatly
        \* simplifies trace validation.
            \/ /\ history[i].tx_id[1] = Len(ledgerBranches)
               /\ history[i].tx_id[2] > CommitSeqNum
        \* Reply
        /\ history' = Append(
            history,[
                type |-> TxStatusReceived,
                tx_id |-> history[i].tx_id,
                status |-> InvalidStatus]
            )
    /\ UNCHANGED ledgerBranches

\* A CCF service with a single node will never have a view change
\* so the log will never be rolled back and thus transaction IDs cannot be invalid
Next ==
    \/ TruncateLedgerAction
    \/ AppendOtherTxnAction
    \/ RwTxRequestAction
    \/ RoTxRequestAction
    \/ \E i \in DOMAIN history :
        \/ RwTxExecuteAction(i)
        \/ RwTxResponseAction(i)
        \/ RoTxResponseAction(i)
        \/ StatusCommittedResponseAction(i)
        \/ StatusInvalidResponseAction(i)

Spec == Init /\ [][Next]_vars

====

Now also at https://will62794.github.io/tla-web/#!/home?specpath=https%3A%2F%2Fraw.githubusercontent.com%2Flemmy%2FCCF%2Fmku-ConsistencyMonolith%2Ftla%2Fconsistency%2FConsistency.tla

@fintara I just pushed a change so that simple conjunctions now short-circuit as well when possible. See if that fixes the issue in your spec above.


WebUrl

Hello, I was wondering if there is a web URL that can be called upon to get results from the API, and if so, what is it?

I'm not really sure if I understand you mean. Can you elaborate more?

Closing this due to inactivity. If you have other question feel free to open a new issue


Question

Hi, i am having difficulty when querying multiple tables and listening for changes.
Table1 is:
user_id: {
    roomId1:true,
    roomId2:true
}

and Table2 is:
roomId1:{},
roomId2{},

I have to query table1 first and get roomIDs of user. Then get details of each room from table2. Then listen for changes of table1 (if table1 changes, i have to requery table2).
Initially i have used RxFirebaseQuery but it does not listen for changes.

// returns Observable<List<Room>>
RxFirebaseDatabase.observeValueEvent(userRoomsTable.child(myUserId))
                                    .subscribeOn(Schedulers.io())
                                    .flatMap(dataSnapshot -> {
                                        if (dataSnapshot != null && dataSnapshot.getChildrenCount() > 0) {
                                            List<String> roomIds = new ArrayList<>();
                                            for (DataSnapshot itemSnapshot : dataSnapshot.getChildren()) {
                                                roomIds.add(itemSnapshot.getKey());
                                            }

                                            return Flowable.fromIterable(roomIds)
                                                    .flatMap(roomId -> {
                                                        return RxFirebaseDatabase.observeValueEvent(roomsTable.child(roomId), Room.class);
                                                    })
                                                    .subscribeOn(Schedulers.io())
                                                    .buffer((int) dataSnapshot.getChildrenCount());
                                        } else
                                            return Flowable.just(Collections.<Room>emptyList());
                                    })
                                    .toObservable();

This code returns List<Room> initially, and if room is deleted from userRoomsTable, it returns new List<Room>. So far so good.  But if specific Room is updated from roomsTable (e.g. last message field of Room), it does not produce updated List<Room> because of buffer((int) dataSnapshot.getChildrenCount());

When a query returns you a result that doesnt exist, if its a Maybe(like ObserveSinglevalueEvent) it will call to "onComplete". In other hand if you are using a ObserveValueEvent it will return you a DataSnapshot where Exists() is false. Your problem is that you are mapping the observeValueEvent, and the mapping is filtered by existing dataSnapshots.
Change  return RxFirebaseDatabase.observeValueEvent(roomsTable.child(roomId), Room.class); for  return RxFirebaseDatabase.observeValueEvent(roomsTable.child(roomId)); and check the dataSnapshot.exist() in your subscribe.
Happy coding ;)


Fix broken links

This fixes two of the three pages with broken links #66.
For the third (Contributing) page, I imagine it's not synced, since it works properly on my end.

Thanks <3


determinism/roll back

"It is not thread-safe as the execution of single-threaded simulations is trivially deterministic"
does this mean rs-ecs is deterministic and suitable for rollback netcode with serialization (serde) ?

does this mean rs-ecs is deterministic and suitable for rollback netcode with serialization (serde) ?

If your systems themselves are deterministic, then a simulation built using rs-ecs is deterministic in the sense that the ECS will produce exactly the same query results in the same order for every execution.
I am not sure whether this property is really related to "rollback netcode" though: If you rollback the world state and give it the same inputs, this should always result in the same updated state. But if you use different inputs, then the ECS itself will not ensure that the resulting state is somehow correlated even if your systems themselves are well-behaved. For example, if a changed input leads to a different order when inserting and/or removing components, the resulting ECS state will yield different results for subsequent queries.
On the other hand, if all nodes (after rollback if necessary) apply exactly the same modifying operations (adding/removing entities and/or components) on their World instances in the same order, then they will get exactly the same query results. Meaning that if the inputs fully determine what your systems do to the World, then there will be no interference from any hidden state like randomized hash functions or local state like memory allocation addresses.
I am admittedly not really sure for what property your are looking exactly. Does this answer your question? If not, could you be more specific which kind of determinism you need from your ECS to apply "rollback netcode"?

Your response answered my question precisely. Thanks!
What about serialization, what would I have to do to serialize the entire world state with serde ?

What about serialization, what would I have to do to serialize the entire world state with serde ?

Now this is a difficult one. Note that if you want to serialize a World, deserialize it later, continue the simulation and expect the same results as if you had continued with the serialization-deserialization step in between, you would need to include the order of the archetypes and the order of the entities in the archetypes in your serialization format.
At the moment, these internals are not exposed at all and I don't think you can just query all entities/components to serialize them and then just recreate them using methods like World::alloc and World::insert as this would yield a different order of archetypes and entities within the archetypes.
But doing so generically, e.g. something like impl Serialize for World, is also difficult as we cannot generally assume that all components implement Serialize themselves. And even if we did require that, we would need to store those vtables somewhere as we do not "know" the types generically.
Finally, do you strictly need serialization of the World state? I suspect you need that for the rollback part? If that is the case, wouldn't something simpler like being able to clone a World instance in memory suffice? So for example, cloning your world into a snapshot and later replacing your updated world with that snapshots ("rolling back") if inputs were predicted incorrectly?
Implementing this would be straight forward if it could be an unsafe operation that could assume that all components are Copy. If you store owning components like Vec or String, then this would need to integrate with Clone which I would need to like into but seems plausible still (basically store an optional function pointer per component type for cloning a single component value).

Hhhmmm, I do fear both automatic serialization and cloning would need specialization... Using stable Rust, only unsafe automatic cloning assuming purely Copy components seems achievable.

Now this is a difficult one. Note that if you want to serialize a World, deserialize it later, continue the simulation and expect the same results as if you had continued with the serialization-deserialization step in between, you would need to include the order of the archetypes and the order of the entities in the archetypes in your serialization format.

Wouldn't the same order be established by adding entities in the order (and archetype order) they had in the serialized world?
Create entities of the first archetype -> first archetype is created, and entities have the correct order. -> proceed with second archetype...
Just entity IDs would differ, or would need to be generated explicitly.

"Finally, do you strictly need serialization of the World state?"  Yes, the latter is what i desire. Some ECS's (brood, legion) have this feature & use serde for serialization

Now this is a difficult one. Note that if you want to serialize a World, deserialize it later, continue the simulation and expect the same results as if you had continued with the serialization-deserialization step in between, you would need to include the order of the archetypes and the order of the entities in the archetypes in your serialization format.

Wouldn't the same order be established by adding entities in the order (and archetype order) they had in the serialized world? Create entities of the first archetype -> first archetype is created, and entities have the correct order. -> proceed with second archetype...
Just entity IDs would differ, or would need to be generated explicitly.

Yes, but that could be one way to implement a deserialization method. The is point is that a careful implementation is required. And a serialization method (and format) which respects this ordering. Meaning it has bad ergonomics to let the user open code and this and it does place additional constrains on the serialization format as well which cannot be checked by the code here.

"Finally, do you strictly need serialization of the World state?" Yes, the latter is what i desire. Some ECS's (brood, legion) have this feature & use serde for serialization

They do this by requiring the user to enumerate all component types to collect up their Serialize impls and provide an externally visible and unique type name. Would these ergonomics be sufficient from your point of view? Personally, I find that much too fragile but I guess it could be implemented.

Out of curiosity, could you explain why serializing the inputs and snapshotting the world in memory is not sufficient for your use case resp. for rollback netcode in general?

While I did some experimentation on it, c.f. #35, I do not think I will add serializatzion support using Serde to this crate. The manual type registration using manually assigned keys is error prone and I do not see how deserialization could be made safe at all, as the various implicit invariants between the different indices could easily lead to type confusion bugs if a superficially correct but subtly invalid serialization is turned into a World. Additionally, the requirement to go through erased-serde significantly reduces the efficiency of the approach.
I will continue to investigate snapshotting/cloning a World in way that is compatible with stable Rust, i.e. using a manual type registry but at least one with a fully safe interface. I think this is more fruitful as it could eventually just become impl Clone for World when specialization is stabilized and it should be much more efficient that serialization for the rollback use case. Finally, I still think that snapshotting in memory and serialization of inputs is sufficient to implement rollback netcode and similar techniques.


Make Key Captialization Consistent

First of all I want to say I massively appreciate this project (both the Openmusic app and OMDB), they are incredibly well thought out and made it really shows that you put a lot of effort into them, hopefully it'll get more recognition at some point, I think you should try posting it to more places I'm sure there are a lot of people looking for free and open source music players but it's currently very hard to discover (I tried to make a hackernews submission, didn't get much traction though...)
I'm working on a rust crate for the api (client side) to hopefully make a desktop player at some point, and I've noticed the key names in the results have some weird inconsistencies with casing, here are some examples from /query on server.openmusic.app, with the first two being the most common:

AlbumType is PascalCase
Profile_Photo is PascalCase + snake_case
AlbumID has the D uppercase
allArtists is camelCase, and is not documented in this repo

I would personally prefer everything to be snake_case but I'm biased for rust and python, camelCase would also be fine but I would really appreciate ID being turned into Id to make it possible to automatically convert album_id -> albumId with serde (the serialization library used in the rust ecosystem).

Thanks for the input and your support! I’ll take this into consideration for the next update, but PostgreSQL is not case-sensitive anyways so you shouldn’t have issues in the meantime.

I welcome you to make a desktop player, so long as it’s open source as to uphold the purpose of Openmusic :)


Remove fsync in archive.NewTempArchive

This makes the "Buffering to disk" part of docker push 70% faster in my use-case (having already applied #12833, and to be clear, we're talking 11s -> 3s).
AIUI, fsync'ing here serves no valuable purpose: if the drive's operation is interrupted, so it the program's, and this archive has no value other than the immediate and transient one.
Is my assumption incorrect in some way?

Seems legit for me.

LGTM

I added another ~identical case where a tempfile used during the V2 registry push was fsync'd. This one makes far, far less difference to my runtime, but is also needlessly wasteful.

LGTM


Fix #90, URI encoding issues

The multi-argument constructor automatically escapes any invalid characters passed, so I just switched to that
Verified working in production

Github doesnt seem to have picked this up properly, so fixes #90

oh my god. i knew this could cause the issue but couldn't trace it back to this specific instance. thank you!


Pycharm 2017 -> 2017.1.2

Motivation for this change
PyCharm was updated with a new release 2017.1.2. The commits here are pretty much minimal - just version and sha256 updates.
There's one thing, though - URL for pycharm-professional 2017.1 currently responds with 403 error for some reason (no issues for pycharm-community, that one works), which currently breaks release-17.03 if someone has idea.pycharm-professional in their configuration.nix. So, I'd ask to please backport the changes to 17.03. This could be slightly inconvenient, as the directory was renamed since then (from idea to jetbrains), so unless that change is also merged there probably will be a merge conflict. To save time, you may want to check my branch pycharm-2017.1.2-release-17.03, which does similar changes from current release-17.03 branch. Please tell if you'd want me to make a PR for this.
Thanks!
Things done

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

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

A PR for release-17.03 as well would be great

@joachifm Thanks for merging!
I've made a PR for release-17.03 at https://github.com/NixOS/nixpkgs/pull/25996


Support manage single node

What type of PR is this?

/kind feature
What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

[kwok] Support manage single node with --manage-single-node

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

NONE

CC @fuweid


Adding jruby-19mode

Adding JRuby support back in.

Nice, glad to see it's passing now!
/cc https://github.com/bkeepers/dotenv/pull/138


hhvm that does not support yield in a function argument

Trying to fix tests on hhvm and cleaning inconsistent use-statements

HHVM test still fail but at least we see the failures now instead of a syntax error.

I've found the problem. HHVM is not compatible with Generator::send, see https://github.com/facebook/hhvm/issues/6807

This is good to go. It won't get better.

Can second that finding, we see similar failures on the AWS SDK for PHP based on that HHVM issue.

I'm not sure what this change accomplishes. Guzzle coroutines are still incompatible with HHVM, and the HHVM team has announced that PHP compatibility is no longer a goal of the HHVM project.
This library does not work with HHVM, and I don't see that changing without a major version bump.

It accomplishes to see hhvm errors. I can also remove hhvm from travis config completely if you prefer that.

HHVM should probably stay in travis, at least to show the incompatibilities for those that explore it since there's no FAQ that provides this detail.
As for the fix itself, it's swapping out:

Fatal error: syntax error, unexpected T_YIELD in /home/travis/build/guzzle/promises/tests/functionsTest.php on line 536

for actual errors like:

GuzzleHttp\Promise\Tests\EachPromiseTest::testMutexPreventsGeneratorRecursion
Exception: Generator is already finished

I'm also in the not sure camp but lean towards cleaning this up since, while it doesn't provide anything functional, it more clearly defines that facebook/hhvm/#6807 is the real reason for this problem.

Is this going to get merged?

It's not possible to fix hhvm tests and most project dropped hhvm support, even composer https://github.com/composer/composer/issues/8127. So I removed hhvm and php 5.5 which is EOL since a while. This way I could also update phpunit.


[1.x] Docs workflow

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

Project coverage is 100.00%. Comparing base (0a13765) to head (119ef66).
Report is 4 commits behind head on 1.x.

Additional details and impacted files
@@            Coverage Diff            @@
##               1.x       #94   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           59        59
  Lines         2452      2452
=========================================
  Hits          2452      2452

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


Add a word limitation for Category name so that after that limit category name should display in different line

Framework Version: 0.1.5

Framework Version: 0.1.5
Fixed


locale.languageCode always returns 'en' on Linux

Hi,
I'm running my project on an Linux distribution where english isn't the main language. It seems the go-flutter-desktop doesn't read the "LANG" env variable before starting the app and the app is incorrectly using english on the localizationsDelegates.
This is a very simple issue I think and I would be very happy to contribute a PR myself if someone would provide some pointers on how to fix it.
I see there's some FlutterEngineUpdateLocales C call but I'm not sure if that's what I should use for that. Please let me know if you have some insights.
Hover doctor
hover: Running on linux
hover: Docker installed: true
hover: Sharing flutter version
Flutter 1.12.13+hotfix.6 • channel beta • https://github.com/flutter/flutter.git
Framework • revision 18cd7a3601 (il y a 4 mois) • 2019-12-11 06:35:39 -0800
Engine • revision 2994f7e1e6
Tools • Dart 2.7.0
hover: Flutter engine commit: https://github.com/flutter/engine/commit/2994f7e1e682039464cb25e31a78b86a3c59b695
hover: Finding out the C compiler version
gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

hover: Sharing the content of go.mod
module project/go

go 1.14

require (
        github.com/davidmartos96/go-flutter-plugin-sqlite v0.0.0-20200129162105-68dfe5aa4b3e
        github.com/go-flutter-desktop/go-flutter v0.36.1
        github.com/go-flutter-desktop/plugins/shared_preferences v0.4.3
        github.com/nealwon/go-flutter-plugin-sqlite v0.0.0-20190909095325-db6bdfd6b983
        github.com/pkg/errors v0.9.1
)
hover: Sharing the content of hover.yaml
target: lib/main_desktop.dart
branch: ""
cache-path: ""
opengl: ""
engine-version: ""
docker: false
hover: Sharing the content of go/cmd
go/cmd/main.go  go/cmd/navbarheight     go/cmd/options.go

Sure, I'll be happy to have you contribute onto the project.
I think the engine C call to FlutterEngineUpdateLocales should fix this issue.
Here are some pointer for you:

arguments to provide to FlutterEngineUpdateLocales
example of usage (from the unittests)
The wiki page that informs you how to work on go-flutter
An example of an engine call (with strings)

I think we are missing a C.free call here.

Where we start the engine (I would expect the call to FlutterEngineUpdateLocales must be performed AFTER the engine is started..)

Can I assign you to this task?

Thanks a lot, yes you can assign me, I'll try to make that work :)

The locale can be query through window.locales
// This example demos the TextField/SelectableText widget and keyboard
// integration with the go-flutter text backend

import 'package:flutter/material.dart';
import 'dart:ui';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    print(window.locales);
    print(window.locale.languageCode);
    print(window.locale.countryCode);
    print(window.locale.scriptCode);
    return MaterialApp(
      title: 'Flutter Code Sample for testing text input',
      theme: ThemeData(
        // If the host is missing some fonts, it can cause the
        // text to not be rendered or worse the app might crash.
        fontFamily: 'Roboto',
        primarySwatch: Colors.blue,
      ),
      home: Scaffold(
        appBar: AppBar(
          title: Text('Hover Example'),
        ),
        body: Text("Local: " + window.locale.toString()),
      ),
    );
  }
}


Improve swing foot plan

Remove online update for swing foot trajectory
Minimum circle search for foothold
Bug fix

Is there any additional test needed to cover this specific feature?

Is there any additional test needed to cover this specific feature?

I think it's fine, this PR is mainly to fix bugs. The only new feature might be the minimal circle, but the foothold test should already have that covered.

Looks good to me. Feel free to merge once pipeline is passing.


add 2021 talk by Pmunch + years

added one talk by @PMunch of 2021. I was adding also the year since I think it can be useful.
I checked all fosdem years using the page that list all the events (e.g. for year 2018: https://archive.fosdem.org/2018/schedule/events/). Any talk which add Nim in the name would have been found by this method.

Ah damn it, I thought I had gotten them all (that's the way I went about finding them as well). And it's even one of my own talks..


Bad Overlay Decoration performance on 1.19

Since the rewrite of the TextEditor rendering (which is pretty awesome, btw), performance of Overlay Decorations deteriorated. Badly... :(
Specifically, adding a ResizeObserver to each overlay doesn't scale well at all -- on my machine, each resize callback will take something from 1 to 3ms (this is just the overlay decoration from autocomplete-plus):

Let's add 100 more overlays and we get this beauty:

With Atom 1.18 (and 100 overlays), performance is much better (but not ideal):

The first thing I'd try here would be debouncing the didResize callback and not adding a ResizeDetector for each and every decoration, but I don't really understand why the ResizeDetector is needed anyways.
I'd be happy to look into this (and overlay performance in general), but would appreciate some guidance here. :)
MWE on @lee-dohm's request:
To reproduce this, paste
atom.commands.add 'atom-text-editor', 'generate-overlays', ->
  ed = atom.workspace.getActiveTextEditor()
  ed.setText("aa\n".repeat(100))
  for i in [0..99]
    m = ed.markBufferRange([[i, 0], [i, 2]])
    div = document.createElement('div')
    div.style.backgroundColor = 'white'
    div.innerText = "fooo#{i}"
    decoration = {item: div, type: 'overlay'}
    ed.decorateMarker(m, decoration)

into your init.coffee, reload Atom, open a new text editor and execute generate-overlays. You should immediately feel the drop in performance.
Additional info:

The tests above were performed on commit 85e65ff, on Windows 10, and on a fairly beefy PC.
ink (in conjunction with julia-client) was used to generate the inline overlays, but I suspect packages like Hydrogen will end up having the same issues.
If anyone is interested in the timelines I'd be happy to upload them (since they can finally be exported :D), but I do think the screenshots are enough of an explanation as to what is going wrong here.

cc: @nathansobo, @as-cii

Thanks for the report. We'll take a look at this today and I'm confident we can improve the performance before this code hits beta.


FRI >= 2: Invalid commanded_joint_position state interface

Hi,
I'm using an lbr med 7 R800 with FRI med 3.0. Unfortunately I was not allowed by my manager to contribute the package to the community due to legal issues.
I cloned everything as explained in the start up guide and followed the step by step guide to first run everything with FRI 2.5 using the simulators and things looked fine.
After, I replaced the FRI-Client-SDK_Cpp.zip with my new zip file and had to make some changes to the LBRServer.java to meet the new syntax requirements (things have been changed slightly between FRI 2.5 and 3.0). I rebuilt the package as well after replacing the zip file.
Finally LBRServer.java looks to run without errors on the smart pad. However, when I try to run the demos with the real hardware, the LBRServer app on the smart pad gives the error: "Timeout before FRI connection quality reached GOOD or EXCELLENT" after 10 seconds. I suspect that the UDP connection responsible for the FRI connection is not getting started thus getting this timeout error.
(I have checked the connection between the robot and PC by pinging the robot.)
I tried to look into the example codes but I wasn't able to find the place that the UDP connection is initiated (i.e. I'm not sure where the App and AsyncClient are being called when trying to tun "Joint Trajectory Controller" python demo.)
I have also attached a picture from my terminal which looks like the UDP connection is not getting started for some reason.
I would greatly appreciate any help.

hi @OmidRezayof, thanks for sharing. Let me try to answer the questions that can be answered first:

Where is the connection established? The system interface runs the connection here:

https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/a752eb21271b42be7f6e45cbb333def87731b175/lbr_ros2_control/src/system_interface.cpp#L206
The run_async method of lbr_fri_ros2::App creates an asynchronous thread
https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/a752eb21271b42be7f6e45cbb333def87731b175/lbr_fri_ros2/src/app.cpp#L105

Why is the connection to established?

Maybe try running the plain FRI (without the ROS 2 wrapper), as described here: https://github.com/lbr-stack/fri#build

License / legal? You can check KUKA's license note in the FRI files. From FRI 1.11 onward, these allow re-distribution. I don't know of 3.0

hi @fredRocs, could you please do me a massive favor and try connecting your robot? See if you get a similar error?

Thanks @mhubii for your reply!
I tried removing that line from the file you sent, rebuilt the whole lbr-stack workspace and now, I've got new errors.
Any idea about this?

Sorry about that. Will fix this proper soon.
See the error: expected 7, got 6?
There is a line in the code that requires changing to 6. Second.

No need to apologize I really appreciate your support.
It looks like I was finally able to open the UDP channel, but now it's complaining about not being able to find the robot I guess?
What I do is I first start the LBRServer with the recommended specs and then quickly run the launch file as in demo.
PS I have pinged the robot and it seems to be fine.

hi @fredRocs, could you please do me a massive favor and try connecting your robot? See if you get a similar error?

It seems to work fine on my side when I run ros2 launch lbr_bringup bringup.launch.py sim:=false ctrl:=joint_trajectory_controller model:=med14. The signal stays EXCELLENT

Dear @mhubii
I tried to fork the repo and send a PR so you can see my codes. Please accept my apologies since I'm not a pro in Github and may have made mistakes in this process (Github can be very confusing!!)
The final comments that I made on this issue thread were:

Apparently after changing the required numbers for state interface to 6, the UDP socket is opened, however now it cannot find the robot on the UDP channel.
I also reported the fact that I'm having warnings when building the packages in my lbr-stack workspace which I'm not sure if they're contributing to the issue we are discussing.

okay great. Thanks for the PR.
In your version of the LBRServer Java application, what IP do you set for the FRI connection? When you configure your FRI connection, there should be something similar to:
fri_configuration_ = FRIConfiguration.createRemoteConfiguration(lbr_, "<IP_ADDRESS>");

This IP should match your laptop's IP address.

Yes, I'm indeed using the same IP (.148) for my PC and am choosing the same on the SmartPad. Still not sure why the robot cannot find the communication line.
It's hard for me to tell if you have made any changes to the branch I made and did a PR. Have you made any changes that can possibly solve this?

no problem. Your changes are fine. One thing I would suggest now, is to try and run KUKA's demo applications with the raw FRI (no LBRServer, not ROS 2 integration). You can find some simple instructions here:

Build: https://github.com/lbr-stack/fri#build
Example applications: https://github.com/lbr-stack/fri#run-the-apps

I suspect it can be from the netmask issue.
I have set my PC ip: <IP_ADDRESS> and the netmask of my pc as: <IP_ADDRESS>
On the StationSetup > Configuration I see:
Subnet mask > FFFF0000
and KONI > Subnet mask > FFFFFF00
On my PC I have also tried using net masks of <IP_ADDRESS> and <IP_ADDRESS>
Still connection not established.

Please let me know if you see anything wrong.
I will be trying their own example applications soon.

@mhubii I finally got the permission from my PI to share the fri 3.0.
I'm not sure why I couldn't find my updated fri-3.0 branch on lbr-stack/fri but I uploaded the sdk under my forked repo which you should be able to see.
Let me know if you see anything that can fix the build issue.
PS the license wasn't the issue I just had to get the permission from my boss.

okay 2.7 is now live. One thing, I think I re-based your PR https://github.com/lbr-stack/lbr_fri_ros2_stack/pull/182
This might remove your contribution from the git history.
Could you please re-open a new PR with the same changes against this branch:
https://github.com/lbr-stack/lbr_fri_ros2_stack/tree/dev-humble-state-interface-fix
Want to make sure your contribution is rightfully attributed.

Hmm, not sure why 2.7 because it has been mentioned as 3.0 on all their documentations and everything.
I will try it with the new codes and see if it fixes the build problems.
And for the new PR, do I have to do it just for the lbr_fri_ros2_stack or also for fri-2.7?

For lbr_fri_ros2_stack. It is strange because in the source code it says version 2.7.0

@mhubii I tried running the example application and I was getting all kinds of different errors on my PC every time I run the LBRJointSineOverlay.java on the smartpad:
!!decoding error on Monitor message: invalid wire_type!!
!!decoding error on Monitor message: missing required field!!
!!decoding error on Monitor message: end-of-stream!!
!!decoding error on Monitor message: parent stream too short!!
!!decoding error on Monitor message: end-of-stream!!
I suspect this is an issue with the new released fri package cuz when I downgraded to Sunrise 2.6 and fri 2.5, I didn't have this problem.
I was able to succesfully establish the ROS/fri connection and move the joints using demo.
As of now, I think I will continue using fri 2.5 and if any updates after 3.0 was made by KUKA, I can maybe try to see if I can get it to work.
I just wanted to thank you a lot for the troubleshooting @mhubii .

Ah okay great, well this issue here still needs fixing, will merge your contribution asap.
I would contact KUKA because there appears to be some version mismatch between the FRI client SDK (2.7.0) and what is on the controller. This might be a bug on their end?

Sorry for my late reply. I'm not super sure what is exactly the version mismatch that you are talking about.
I do see the version 2.7.0 on the header files but that could be potentially the Sunrise.workbench version, since we were actually using Sunrise.workbench 2.7.0, but I'm pretty sure all the documents that we have, even the file name of the fri option package we have received have been labeled fri-3.0.
It could be potentially that the CMake support codes that you have written for fri<=2.x is not suitable for compiling fri-3.0? I have no idea but I wasn't able to run KUKA's example fri codes using the fri-3.0 SDK so I'm assuming it's either a KUKA issue or an issue from the CMake compatibility codes.

So this is the documentation that's included in the .zip file

It says version 2.7.0, which is a little confusing. It could of course be, that something with the CMake compilation is odd. Would have to check that

thank you again @OmidRezayof  for you contribution! You should now be listed for you efforts.
I am closing this as the initial issue was resolved. As for the FRI, please feel free to open a new issue, either here or here https://github.com/lbr-stack/fri.
Please make sure to pull the latest changes. When running, make sure to specify your FRI version here
https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/77f6979b3bf19596286d723598de6c4419d2ea48/lbr_ros2_control/config/lbr_system_parameters.yaml#L4
Happy to dig further into FRI 3 / 2.7. Have a good weekend


Add threads support

https://github.com/ayush6624/go-chatgpt/blob/8aeb6014ac365cde80d249468eb00fdd17beb03d/chat.go#L134-L139
It would be really cool to add Threads support -- I can work on this if you want!
https://platform.openai.com/docs/api-reference/threads
Thanks for this project btw, I was able to use it and found it super useful!

I'm glad you found it useful!
Please go ahead and create a PR!

Hey! I added a PR that includes added support for threads and other new parameters! Go ahead and take a look! 😄
#12


fix: preserve the constant pool order

Reference: https://stackoverflow.com/questions/78221149/asm-does-not-preserve-order-in-the-constant-pool-table
ClassWriter(ClassReader, int) preserves the order of constant pool. However, there is one caveat that the order of attribute could change. We will see how it affects us.

This approach does not change SHA256 hash for java/util/stream/DoubleStream at least.


Create test cases for support-scheduler

Set scheduler to clean up data.

Reopen for test case implementation.


toAnnData should transform features to a Pandas DataFrame if its a GenomicRanges object

see https://github.com/BiocPy/SingleCellExperiment/commit/a0a4b20a8d3d15119c592e427f8057905438b1b1


Dev Board Micro not being detected when plugged in

Tried using two machines for this, one windows 10, and the other a raspberry pi 4 for ubuntu.
To preface, I have tried all of the troublshooting advice here https://coral.ai/docs/dev-board-micro/arduino/#troubleshooting
When I plug the coral micro into any device, only the red STAT light turns on. The device does not get recognized on Ubuntu (it does not show up when running "lsusb") and on Windows I get an error too (described above). Holding the "USR" button and then pressing the Reset button does nothing. The device only gets recognized for a split second after being plugged in or being reset, then it stops being recognized again (after about 0.5 seconds)
To reproduce: Out of the box the coral micro worked normally, with the face detection running. I connected it to a Windows machine and flashed it with "blink-led" Arduino script on Arduino IDE 2.2.1, which worked fine. Afterwards I flashed it again with the "person_detection" script from the Tensorflow Lite library. After this the device broke and started acting as described above.

same problema here

I have the same issue. I used a mac to flash it with detectface example project on Arduino and it just broke. The dev board micro can't be detected anymore.

I solved the problem,
First you have to go into SDP mode, explained in the troubleshooting page: https://coral.ai/docs/dev-board-micro/arduino/#troubleshooting
The way it's explained was weird and I couldn't get it into SDP mode because I was holding the User button down for too long. Just hold it for a second or two while plugging it in and then let. Then when you run lsusb the board should be listed as:
NXP Semiconductors SE Blank RT Family
Finally, just follow the getting started example and flash it with the face detection example and the board should be fixed! (I did run into some problems when running setup.sh and I manually installed some of the packages and the flashing worked)


Axe Rework

Battle Hunger:
Removes infinite duration.
Duration is now paused when the target doesn't deal damage for 2 seconds. (debuff is still removed on fountain).
Whenever the target attemps to attack, it has 25% chance to attack another target instead, unless the target is Axe. The other target can be either its ally or enemy. For the duration of the attack (depends on its attack speed), the target cannot issue commands.
Counter Helix:
Each time Axe spins, the spin radius increases by 15, up to 5 stacks. Stacks are refreshed on a successful spin and last 4 seconds.
For each taunted enemy around you when you spin, increases the bonus damage percentage.
Culling Blade:
Can cull a target if it has health below the threshold, or has lower than 15% max health. On a successful culling, increases the kill threshold by 100 and the max health threshold by 3%. This buff immediately ends if failing a Culling. Stacks are refreshed and last 60 seconds.

TALENTS:
Remove:
+90 Berserker Call radius.
+90 Counter Helix radius.
+100 Battle Hunger DPS.
+150 attack speed on Berserker Call.
+400 Culling Blade threshold.
Apply:

Self-Casting W applies it to everyone affected by Q.
If an enemy unit with Battle Hunger attacks an ally, that ally also gains the Battle Hunger debuff.
Counter Helix chance doubles, but each Counter Helix deals half the damage.
When Counter Helix procs, it has 25% chance to immediately proc again. Psuedo Random chance. The extra proc cannot trigger this again.
Counter Helix's damage is increased by 1 for each point of Armor Axe has.

Suggestions:

make W's cast point much quicker while Q is active (or instant);
talents 3, 4 and 5 seem really weak (4 a bit less weak but essentially a 25% damage increase to helix);
Cull stacks need a threshold, even if the situation where it would become excessive seems rare. I'd suggest a cap of 5 stacks.

I agree with capping Culling Blade.

make W's cast point much quicker while Q is active (or instant);
I'm not sure what is exactly the point of having a hasted Battle Hunger. You usually cast in on heroes that are a bit further away of you, and it can be used while spinning. In addition, taking the first talent (cast W on self) already has an immense effect.

talents 3, 4 and 5 seem really weak (4 a bit less weak but essentially a 25% damage increase to helix);

Talent 3 is a talent that was practically popular because it turns Axe into an helicopter. I can probably make the damage loss a 1/3 instead. (-33% damage).
Talent 4 works well with talent 3, otherwise yes, it's pretty much a damage bonus.
Talent 5: I think you're underestimating it. When you're using Q, you get 100 armor. Having +100 damage per Counter Helix, especially combined with the double proc chance, can be very deadly.

Yeah I totally forgot q armor, good one

If an enemy unit with Battle Hunger attacks an ally, that ally also gains the Battle Hunger debuff.


HARVESTER: We can set negative integer value to Termination Grace Period field and write into VM yaml

Summary
PR Checklist
~- Is this a multi-tenancy feature/bug?
- [ ] Yes, the relevant RBAC changes are at:~
~- Do we need to backport changes to the old Rancher UI, such as RKE1?
- [ ] Yes, the relevant PR is at:~
~- Are backend engineers aware of UI changes?
- [ ] Yes, the backend owner is:~
Fixes We can set negative integer value to Termination Grace Period field and write into VM yaml

Occurred changes and/or fixed issues

https://github.com/harvester/harvester/issues/3946

Technical notes summary

Add positive for UnitInput component
Areas or cases that should be tested

Areas which could experience regressions

Screenshot/Video

@mergify backport relase-harvester-v1.2


"cleos get table" support find by string

i have the following information in my testtable.
cleos get table chan chan testtable --key-type i64 --index 1

i can Select the phone(string) info of "wls"
cleos get table chan chan testtable --key-type i64 --index 3 --indexbystr true --findbystr wls

You must make some change like this when you create contract

@evsward It's not necessary to comment on an issue or pull request in order to track it.  Just click the 'Subscribe' button under 'Notifications' in the right side bar.


Seed values

Hi,
Thanks for sharing the code of the models you used in the paper. I'm wondering what seed values did you use to run models three times? I tried with different seed values (seed=0,1,2) but the average of the scores that I get is different from what you have in the paper.
For example for task order 1 (ag-yelp-yahoo) the FineTune model in Table 3 achieves 25.79% acc. I get  28.79% acc.
Looking forward to hearing form you,

Thank you for your interest in this work!
To clarify, I think we used seed=0,1,2 in our experiments.
For the reason why you and we got different numbers:
You can ONLY get the same numbers with us while you are using the same software setting (e.g., PyTorch version, CUDA version, and every related library version) AND the same hardware setting (e.g., The graphics card type and CPU type) as we did, which is almost impossible in practice.
The performance gap could be relatively big in those situations where variance is big. The FineTune model, as you mentioned, is possible to have this issue, since it sequentially learns several tasks without replay or regularization, thus tend to have big performance variance.
Also, considering the situation above, I suggest you verify the validity of the conclusion (IDBR is better than regularization, regularization is better than replay, replay is better than finetune), INSTEAD OF trying to reproduce exactly the same number.


Loggly integration

Any news on this? Seems very interesting the possibility of this integration.

For our usage, we use the file log plugin (https://getkong.org/plugins/file-log) and we send logs to Loggly with Logstash (https://www.elastic.co/products/logstash) via the Loggly's plugin (https://www.loggly.com/docs/logstash-logs).
It works very well and we use logstash to pre-process logs (hash the API keys, add geo IP information, ...).
Example of configuration:
filter {
    if [type] == "kong" {
        # Set the timestamp
        date {
            locale => "en"
            timezone => "UTC"
            match => [ "[kong][started_at]", "UNIX_MS" ]
            target => "timestamp"
        }

        # Anonymize API keys
        anonymize {
            algorithm => "SHA256"
            fields => ["[kong][authenticated_entity][key]", "[kong][request][headers][apikey]"]
            key => '<your_hashing_key>'
        }
        # Remove raw message due to API keys in the message
        mutate {
            replace => [ "message", "This field was cleaned due to API keys" ]
        }

        # Extend client_ip information
        geoip {
            source => "[kong][client_ip]"
            target => "geoip"
            database => "/etc/logstash/GeoLiteCity.dat"
            add_field => [ "[geoip][coordinates]", "%{[geoip][longitude]}" ]
            add_field => [ "[geoip][coordinates]", "%{[geoip][latitude]}"  ]
        }
    }
}

output {
    # Send logs to loggly
    loggly {
        key => "<your_loggly_key>"
        proto => "http"
        tag => "%{type}"
    }
}

@rafaelspecta A Loggly plugin was implemented in #698, and should be available in the next major release. We are thinking about doing an RC release very soon.

@vmercierfr thanks, @thibaultCha great and is there an ongoing changelog for this next RC ?

The Changelog (in next) has an "unreleased" section but it is still incomplete for now. It is missing changelog for clustering, new cassandra driver and configuration file changes. A look at the commits added between 0.5.4 and next (by clicking on "Unreleased" will give you a better idea (but no complete either as everything is not merged in next yet).

Implemented in 0.6.0


babel插件错误

first run
npm install --save react-image-crop

then
info All dependencies
├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS><EMAIL_ADDRESS>└─<EMAIL_ADDRESS>I import ReactCrop from 'react-image-crop' in my project;
A compilation error occurred
ReferenceError: Unknown plugin "@babel/plugin-proposal-class-properties" specified

The babel-plugin i did not use, why did the compilation error occurred ????

I'm not sure seems like there is something strange with the set up of your project it's the first time I've seen such an error, the package doesn't use that plugin either

Closing due to lack of activity


ENG-253: Include default .git* files

Files to incorporate in the PR

.gitignore - Indicate how to use the .gitignore templates
.gitattributes -  Indicate how to use the .gitattributes templates and link to relevant documentation that describes how GitHub uses it to produce language statistics

This has been completed

https://github.com/nhs-england-tools/dotfiles/blob/main/dot_gitignore.tmpl
https://github.com/nhs-england-tools/dotfiles/blob/main/dot_gitattributes


mechanism to install advanced features on top of current installation

We need an extension-based framework to install advanced features on top of the existing installation, which means the user should be able to install additional features after the app is installed.
For example: several advanced readers use unstructured, which is a bit tricky to implement and takes up a decent amount of storage. So this can be an optional feature that user can install on-demand.

@taprosoft can you reopen this issue ? I think it's still a valid future feature.

Currently in discussion https://github.com/Cinnamon/kotaemon/pull/274


Create FE Smoke tests in accordance with our FE testing plans

Problem statement
After adding the ability to choose which data to run E2E tests against, we want to create FE Smoke tests that can be run against a desired data set (Staging, Mock, Production, etc)
What you need to know

This is based off the investigation from #11307
e2e_Tests_audit.xlsx has notes pointing out specific concerns/targets on some pages

Acceptance Criteria

[x] Define what E2E test should be used as Smoke tests
[ ] Identify time to run the smoke tests
[ ] Enable and test one FE smoke test
[ ] Review with Tech Lead and create follow-on ticket for remaining smoke tests

To Do

[ ] Align with other engineering teams and Engr Manager on when to run FE Smoke tests

No longer needed per Penny's follow on tickets:


First class mapped (folded, appended, traversed, etc.) types

Search Terms
Mapped types, dependent typing, higher kinded types, type families
Suggestion
TypeScript currently has baked in support for mapped types, with special syntax for transforming type level maps and type level lists (tuples). Borrowing an example from #26063:
type Box<T> = { value: T }
type Boxified<T> = { [P in keyof T]: Box<T[P]> }

type A = [string, number]
type MappedA = Boxified<A> // => [Box<string>, Box<number>]

type B = { foo: string, bar: number }
type MappedB = Boxified<B> // => { foo: Box<string>, bar: Box<number> }

The logic for when a type is treated as a mappable type unto itself, and when it is simply treated as an heterogeneous map for the purposes of type mapping is built out of various edge cases.
The code above is analogous at the value level to writing the following:
const box = t => ({ value: t })
const boxified = t => MAP{ [p in t]: box(t[p]) } // Special syntax baked into the language

const a = ["hello", 1]
const mappedA = boxified(a) // => [{ value: "hello" }, { value: 1 }]

const b = { foo: "hello", bar: 1 }
const mappedB = boxified(b) // => { foo: { value: "hello" }, bar: { value: 1 } }

The MAP{ [p in t]: box(t[p]) } thing above stands out as something of an oddity; you don't usually see a "map operator" built directly into a language. Given a way to inductively break down and reconstruct data, users are perfectly capable of defining a map function for each type of data themselves:
// There are no linked lists in JS, so let's graft an algebra onto arrays
// for breaking them down and building them up recursively
const nil = []
const cons = x => xs => [x, ...xs]
const match = ({ nil, cons }) => xs =>
  xs.length === 0 ? nil : cons(xs[0])(xs.slice(1))

// How to map over lists (ignoring the baked in `.map` operation from the prototype or a sec)
const map = f =>
  match({
    nil: nil,
    cons: x => xs => cons(f(x))(map(f)(xs))
  })

console.log(map(x => x * 2)([1, 2, 2, 3]))
// => [2, 4, 4, 6]

Similarly, for maps:
// Again, need to graft on an algebra for deconstructing and reconstructing objects
const empty = {}
const withKey = k => v => o => ({ [k]: v, ...o })
const match = ({ empty, withKey }) => o => {
  const keys = Object.keys(o)

  if (keys.length === 0) return empty

  const [k, ...ks] = keys
  const { [k]: v, ...o_ } = o
  return withKey(k)(v)(o_)
}

// How to map over objects
const map = f =>
  match({
    empty: empty,
    withKey: k => v => o => withKey(k)(f(v))(map(f)(o))
  })

console.log(map(x => x * 2)({ foo: 1, bar: 2, baz: 2, quux: 3 }))
// => { foo: 2, bar: 4, baz: 4, quux: 6 }

The important thing to notice here is that once we have a way to break down and reconstruct the data recursively, we don't need any language-level features to express mapping over the data; both implementations of map require only the ability to define and apply functions, and for such functions to themselves be valid arguments and results (i.e. the features found in a minimal lambda calculus).
Moving back to the type level, we can promote our value level implementation of map to a type constructor in pseudo-TypeScript:
type Nil = []
type Cons<X, R> = [X, ...R]

type Map<F, A> =
  A extends Nil ? Nil :
  A extends Cons<infer X, infer R> ? Cons<F<X>, Map<F, R>> :
  never

// NB: we need a type level bottom that inhabits all kinds (corresponding
// to a type error), never is not the right answer here

type Box<V> = { value: V }
type A = [number, string]
type MappedA = Map<Box, A> // => [{ value: number }, { value: string }]

Using the ability to abstract over type level functions and to apply them, i.e. utilizing the lambda calculus at the type level, the user is able to define "mapped types" without the need for this to be implemented in the language.
In fact, mapped types (i.e. structure preserving transformations), are just one useful tool for massaging types. It would similarly be useful for the user to be able to fold down a type level list into a type level union (using the binary | type constructor), or to fold down a type level list of object types into their intersection (using the binary & type constructor).
AFAICT the primary missing feature here is HKTs (#1213), but it's possible there's other features related to spread types, conditional types, and infer that are missing. This provides good motivation for implementing these features in a sound way; it would allow powerful abstractions like mapped types to be implemented and extended in libraries rather than in the core language.
Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. new expression-level syntax)

What does the type-level version of map look like for objects under this proposal?


Why is this package not included in the fluttercommunity repository?

I came across it being promoted in the get_it package, but it's a personal repository, which is confusing.

Hi,
I might move it to the Flutter community org in the near future but as I m the only maintainer of my packagesbfor most of the time I didn't see the need yet.
But good to know that it is important for users. So I will probably move it
Cheers
Thomas
Am 15. Juli 2024, 05:28 +0100 schrieb xpwmaosldk @.***>:

I came across it being promoted in the get_it package, but it's a personal repository, which is confusing.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

Thank you for the response.
If the repository is moved, I think there will be more contributors.
If it is moved and settled in the fluttercommunity, I would also like to try using it.
It's very intuitive and easy, which is great.


Add ReplicationClient

The ReplicationClient sends read-only commands to replicas by default and all other commands to the primary/master. You can override the decision by calling on_primary or on_replica. This is useful for when this shard doesn't know about the command you're using. For example, it's not yet implemented (issues/PRs welcome!) or it's from a custom Redis module.
redis = Redis::ReplicationClient.new

redis.on_primary do |primary|
  primary.run({"your", "command", "goes", "here"})
end

redis.on_replica do |replica|
  replica.run({"your", "command", "goes", "here"})
end

If you want some commands to automatically be routed to replicas, you can add them to the set of Redis::READ_ONLY_COMMANDS. Add this to your app's Redis configuration file:
Redis::READ_ONLY_COMMANDS << "mymodule.ro_cmd1" << "mymodule.ro_cmd2"

Then any time you use those commands (even passing arbitrary commands to ReplicationClient#run), they'll automatically be routed to replicas. This constant was extracted from Cluster so both classes could benefit from it and expanded to contain all of the read-only commands that redis-stack-server knows about (which should remove the need for lines like require "redis/cluster/json" in your app)
How is ReplicationClient different from Cluster?
Redis replication is a distinct concept from Redis's "cluster mode" so Redis::ReplicationClient has to be a separate concept from Redis::Cluster.
Cluster mode shards your data across multiple primaries and has replicas follow those primaries. There are restrictions on which primaries can operate on which keys since you can only operate on a key that exists on the node you sent the command to. That also means that atomic multi-key operations (like LPOPRPUSH or BLPOP against multiple lists) requires that all specified keys reside on the same shard.
Replication, conversely, involves no sharding. It just replicates all of your data in the primary to the replicas. This means there are no limitations imposed by Redis on what operations you can perform on which keys on the primary.
The way cluster mode and replication are exposed to clients is also very different — INFO CLUSTER vs INFO REPLICATION. We could probably paper over some of that, but Redis::Cluster defines some methods specifically because the keys aren't all colocated on the same node. For example, Cluster#pipeline requires a key : String argument that Connection does not because it has to know which node you're going to run the pipeline on. This method doesn't make sense for plain-old replication. If you want to run a pipeline with ReplicationClient, you specify redis.on_primary &.pipeline { |pipe| ... }.
Why ReplicationClient?
Yeah, I don't love the name. I really like how succinct the name Cluster is, but Replica doesn't make sense here because it also talks to the primary.
Depending on how we move forward with this, though, Cluster could end up using ReplicationClient under the hood to handle the split between primaries and replicas. Currently it implements its own based on the data returned from INFO CLUSTER.
Chained replication is not (yet?) supported
If C is a REPLICAOF B which is a REPLICAOF A, ReplicationClient will send write commands to A and read-only commands to B, but will ignore C completely.
It might be a good idea not to support chained replication, depending on why it's setup that way. For example, if C is used for long-running commands (think analytical vs transactional queries), you may not want your app sending queries to it expecting them to be fast.
Replication topology discovery
You can point this class at any Redis node in your setup (I keep having to stop myself from saying "cluster") and it will discover which is the primary and which are the replicas.
Additionally, changes in the replication topology (replicas added, removed, or primary failover) will automatically be updated in ReplicationClient. Currently, this is implemented by throwing away the previous connection pools, but this could be improved to make smaller changes.
Unfortunately, in the current implementation, taking a replica offline won't be handled gracefully. You'll still get errors in trying to talk to replicas, but those should disappear during the next periodic topology scan (defaults to 10-second intervals).
No replication required
You can even use this if you aren't doing replication at all — it will just send all commands to the one node. If you add replicas later, it will automatically pick them up during the next topology scan and begin routing read-only commands to the replicas.
This is important if you replicate only to a single node, which you take offline to upgrade before upgrading the primary.
Real-world testing
I've been testing this on a 3-node Dragonfly DB in one of my Kubernetes clusters (they offer a Kubernetes operator that's easy to work with and the Redis operator is enterprise-only) and it's working really, really well. As noted above, I get some errors when removing replicas (chaos engineering ftw), but they go away after a few seconds.

cc @jwoertink IIRC you were using Redis replication on AWS, right?


Updating predictions with golden labels

Thanks for the great work on this project!
In the "evaluate" function in your code, this function is used:
https://github.com/yanzhh/HGERE/blob/e37ca9b08171b54d143642cf4ef50d3e4e0560f9/run_pruner.py#L976C1-L984C18
As I understand it, this uses the real labels of spans to update the labels given to predicted spans. This seems like something that should only be happening in evaluation during training and not when using "evaluate" function for final testing. when I use the code to test without passing real labels, as in a real world situation. there is a performance drop.
Is this a known issue? Do you have any suggestions on overcoming the performance drop that will occur when using the model on unseen data?

Thank you for your interest in our project. Regarding your question, this was intentionally designed for simplicity. For the pruner, we only need to predict the span's mention correctly, as the label prediction is the task for the ERE model. To minimize changes to the codebase of PL-marker, the gold label was included when evaluating the prediction of span mentions, so that as long as the span mention is predicted correctly, the pruner's prediction is considered correct.


safari multiplefile upload not working

hi,
In Safari browser only single file upload is only working,
and by using multiple file upload, it upload all the files, with no contents, means file uploaded with 0 size. and also max limit for the file size is not working in safari.

fixed issues in latest plugin


Suggestion: It would be helpful if you provide copy button next to Project Name, Solution Name, Nuget package etc.

It would be helpful if you provide copy button next to Project Name, Solution Name, Nuget package etc. This will help us to follow article quickly (The way we have copy button next to code segments)

Thanks,

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

ID: 08de9daf-79aa-ee76-431e-f2432f8d691e
Version Independent ID: 1a1ee728-1741-c82a-75e1-06159709935b
Content: Use ASP.NET Core SignalR with a hosted Blazor WebAssembly app
Content Source: aspnetcore/tutorials/signalr-blazor-webassembly.md
Product: aspnet-core
Technology: aspnetcore-tutorials
GitHub Login: @guardrex
Microsoft Alias: riande

Hello @chinmay-trivedi ... We don't control the docs system here, just the content. Make your suggestion here ...
https://github.com/MicrosoftDocs/feedback/issues

Hi @guardrex , I have clicked on below button and end up reaching to this repo. I believe below button redirection link need to be changed then.

The feedback button/form is for "this page" ... i.e. ... this page's content. We control that here. We author the docs and work on doc samples here.
The docs system ... the whole system ... is controlled by another team. Your feedback is about the docs experience. They hope readers will see the link at the bottom of the page for "site feedback" ...

If you think this is all too cryptic in terms of where/how to provide feedback, that's also a suggestion for that team. Like I said, we only work on the content, text and examples, on this repo.

Perhaps, they should have a third button in the Feedback section: "Site feedback". If you agree, you can create another issue for them. They prefer to work each issue separately, so that would be a new issue from the one you opened with them.


init

Closed because there is no useful information, welcome to re-file one if you want to contribute.


[BUG] Endless Update Cycle

Office Tool Plus Version, e.g. <IP_ADDRESS>:

<IP_ADDRESS> (09.09.2023 Distribution)

Operating System, e.g. Windows 10 20H2 or Windows 7 SP1:

Windows 10 22H2

Error description (required):

Endless Update Cycle.
The utility tries to update itself. It downloads 120 files for \files\preferences
but they are either wrong or corrupt. They match the structure but don't match sizes.

Reproduction steps (suggested):
Just update.
Screenshot (suggested):

It say It can't update please download the latest version manually.
Additional information (optional):
From the log.
26.09.2023 7:30:41	Info	Update	Update(s) available.
26.09.2023 7:30:41	Info	Update	Downloading update(s).
26.09.2023 7:31:12	Error	Update	Errors occurred while checking updates. Exception: One or more errors occurred. (Hash value check failure, file: files\preferences\es-es\settings-office-es.json, hash: 91d7cab9be753780d5008158d10c5a5eedb5001ff50e9f3e76e0b0c708097f07). Inner exception: Hash value check failure, file: files\preferences\es-es\settings-office-es.json, hash: 91d7cab9be753780d5008158d10c5a5eedb5001ff50e9f3e76e0b0c708097f07
26.09.2023 7:31:25	Info	Update	Checking updates.
26.09.2023 7:31:25	Warning	ClientUpdate	Can not connect to server. Exception: Response status code does not indicate success: 502 (Bad Gateway).
26.09.2023 7:31:31	Info	Update	Update(s) available.
26.09.2023 7:31:31	Info	Update	Downloading update(s).
26.09.2023 7:31:53	Error	Update	Errors occurred while checking updates. Exception: One or more errors occurred. (End of Central Directory record could not be found.).
Maybe you update the distribution with the latest configuration files available so won't be any problems.

Hi, thanks for your information, it should be normal now, please restart your Office Tool Plus to check it again.

Yep! It's fixed :)

Yep! It's fixed :)


Nonzero exit code when diff is not clean

Store diff prints to text buffer and exit program with code 2 when the diff is not empty.

You're right this solution is cleaner. It required to track the changes on print_team_members_diff where we instantiate a Diff and when the we check if the organizations matches.
I needed to add a boolean variable in print_diff and print_team_members_diff to go through all the if statements. I called it has_diff to match with the function names and not to confuse it with has_changes in the main function.

This looks good! Only please make sure the file typechecks, you can typecheck it with mypy --strict.

Thanks I was not aware of this tool. I will use it in the future.

Hmm something weird happened, this pull request now touches LICENSE and nixpkgs-pinned.nix, and I see some commits that I authored but you committed ... I think you rebased too much. You could fix this with
git fetch origin
git rebase --onto origin/master 3_nonzero_exit_code_diff^ 3_nonzero_exit_code_diff

This is not the first time that I rebased too much and past commits are never added. I tried to reproduce what happened by adding a commit and squashing it to the previous with git rebase -i HEAD~8 but it didn't work :confused:
Thanks a lot for the fix, it worked perfectly !


Improve Contributor Experience

[ ] Kokoro feedback should be fast and reliable
[ ] Kokoro should test on OSx
[ ] Instructions on how to run the tests locally should be visible and simple
[ ] Running tests in parallel should create no problems
[ ] There should be linter rules and Kokoro should check them
[ ] README generation should be automated where reasonable.

What is README generation? Do we need READMEs?

Hi @tbpg,
Sample tests may have different setup instructions. Additionally, we've in the past added CLI commands to our README's and usually a manual process. It would be nice to have automation for these tasks similar to Python-docs-samples.
@TheRoyalTnetennba It might be a good idea to flesh out this work item more.


SecureBoost online

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

support secureboost online inference in fate-serving


Deprecation warnings from setuptools

Describe the bug
vmware/vapi/vsphere/__init__.py:5
    /root/.pyenv/versions/3.11.2/lib/python3.11/site-packages/vmware/vapi/vsphere/__init__.py:5: DeprecationWarning: Deprecated call to `pkg_resources.declare_namespace('vmware.vapi.vsphere')`.
    Implementing implicit namespace packages (as specified in PEP 420) is preferred to `pkg_resources.declare_namespace`. See https://setuptools.pypa.io/en/latest/references/keywords.html#keyword-namespace-packages
      pkg_resources.declare_namespace(__name__)

Reproduction steps

Install latest SDK:
pip install --upgrade git+https://github.com/vmware/vsphere-automation-sdk-python.git
Run code that uses the SDK.

Expected behavior
No warnings.
Additional context
No response

Hi @sodul
As of setuptools v67.3.0 the use of "pkg_resources.declare_namespace" method raises deprecation warning.
Our Python SDK uses setuptools v62.0.0 as mentioned in requirements.txt
We highly recommend following our installation guide - https://github.com/vmware/vsphere-automation-sdk-python#quick-start-guide

@aagrawal3 we have other dependencies that cannot install with setuptools v62.0.0. Our workaround is to install the sdk first and then our stack on top and ignore what the SDK claims in its requirements.
This is still a forward compatibility bug and I believe the SDK should be fixed to work with newer versions of setuptools.

@aagrawal3 I have the same problem. Even I rollback my python to 3.6.x, it also tells me the setuptools have an error, and can't collect it from pip official site. When I manually download it to install, it tells me that "future feature annotations is not defined".


Add Iterator#slice_after

Part of #7142

Note that this PR is complete by itself. I will add the other methods slice_before, slice_when after this one is merged. I might reuse some code between them, but I think adding one PR for each method will be easier to review.

I don't understand why it's called slice_after based on what it does.. I seems better to me to call it slice_until, as it'll add things to the slice until the block is true.

@bew After it finds the value it "slices" the enumerable. Or put another way, it slices the enumerable after each time returns a truthy value.

Ooh ok I get it, is it possible to add an explanation like this in the doc? I think it'd help memorize the naming logic (and probably help with the other iterator you're planning to add)

An spec for why the reuse is not Bool | Array(B) might be worth it ;-)

Yes, I thought about putting a restriction to reuse, but none of the other methods have that restriction. I'll add it just for this one and in a separate PR I'll add the rest of the restrictions.

Updated:

put a restriction on reuse
document reuse

Also added a small explanation to why it's called slice_after.

For the record: removing the restriction is not possible (or not worth the effort).


Device with a notch - cosmetic issue in dark mode

I've been informed that there is a cosmetic issue with iPhone featuring a notch. The area around the notch has light background (#fffdf1 I guess, the background color of the light mode) when using the darkmode.
It seems that <meta name="theme-color"... should be changed.
One possible solution is to change it to the color of the navbar. It looks good on iPhone with a notch, I'm not not sure about other devices.
<meta name="theme-color" content="#343a40">

I tried this as well:
<meta name="theme-color" content="#262626" media="(prefers-color-scheme: dark)">
<meta name="theme-color" content="#fffdf1" media="(prefers-color-scheme: light)">

Unfortunately it doesn't change dynamically when the user changes the theme (at least on Safari Mobile 15.5).
Personally I prefer the first solution, but the pool of devices I could check on is very limited, so I'm not sure if it would be better for most users.

Fixed in #124


Issues with tap and swipe. How should I optimize?

Hello!
I am working on a game where there is a hero. The hero can jump with swipe up on the stage and he can fire with tap on the stage. Things get a little wonky and weird when I try and do some rapid fire and quick jumping. How can I optimize this to work better? Should be adding eventListeners with separate methods?
Here the code... any help MUCH appreciated.
tap.addEventListener(GestureEvent.GESTURE_STATE_CHANGE, onGesture);
swipe.addEventListener(GestureEvent.GESTURE_STATE_CHANGE, onGesture);

private function onGesture(event:GestureEvent):void
		{
			trace(event.target+ event.newState.toString());

			if(event.target == tap){
				if(event.type == "gestureRecognized"){
					bulletManager.fire();
				}
			}else if(event.target == swipe){
				if(event.type == "gestureRecognized"){
					heroJump(event);
					swipe.removeEventListener(GestureEvent.GESTURE_RECOGNIZED, onGesture);
				}else if(event.type == "gestureIdle"){
					swipe.addEventListener(GestureEvent.GESTURE_RECOGNIZED, onGesture);
				}
			}
		}

@BeauKelsey dude I wish I could help you, but your problem description is "a little wonky and weird"... add some logs, analyze what is unexpected-undesired.

The code above works. However, when I tap on the screen and swipe up rapidly around at the same time... both gestures fail. See the below trace:
[object TapGesture]GestureState.POSSIBLE
[object SwipeGesture]GestureState.POSSIBLE
[object TapGesture]GestureState.FAILED
[object SwipeGesture]GestureState.FAILED
[object SwipeGesture]GestureState.IDLE
[object TapGesture]GestureState.IDLE

How Can I optimize my gestures so that firing(tap) and jumping(swipe) are happening seamlessly.
Is it best practices to fire the same method for both gestures and use if statements to decide which gesture it is? To put it another way... I only have a fraction of a second to figure out if it's a tap or a swipe.
Is my example above the best way to do that?

@BeauKelsey first thing I'd recommend you is to understand why each fails. Add some extra logging (get the stack trace) when state is changing to FAILED.


Longest Common Subsequence (Algorithm) | GSSOC'23

Hello @aaryahjolia 👋,
I want to contribute into your repository under GSSOC '23.
I want to add Longest Common Subsequence (Algo + Intuition+Code+ with diagram and complete explanation).
Also, if you allow, I will add links to some questions based on the same approach.
I will make sure about:

Quality of content.
Easy and Clean Code
Diagrammatic explanation

My leetcode profile for your reference: https://leetcode.com/ashu012002/
Please assign me this issue, I will do my best.

Please assign me this issue so that I can resolve it under GSSOC-23

Please assign me this issue under GSSOC-23


A question in Marlin paper in section 5.3.2

Hello arkworks-rs, thanks for your the greater work Marlin. While reading the paper I encountered a question.
In page 28, section 5.3.2, it says:

However, in the same page equation (6) it says  sums to  on H. Therefor, according the univariate sumcheck for subgroups protocol introduced in section 5.1,  should be written as:

if  is not zero. Is my understanding about wrong or something I have missed? Any help is appreciated, thanks.

I feel it is a typo, but @Pratyush can confirm.
On Figure 5 on page 32, we can see that \sigma_1 is back. And \sigma_1 is the sum of the mask polynomial s(\kappa) on domain H, which is unlikely to be zero.

Marked as closed.

we can sample the mask polynomial to indeed sum to zero on H, so in this case the two would be equivalent.


GPU ran out of memory

Currently my GPU is 3080 16gb of vram and yet my cuda ran out of memory
RuntimeError: CUDA out of memory. Tried to allocate 1.43 GiB (GPU 0; 15.64 GiB total capacity; 2.04 GiB already allocated; 1.40 GiB free; 4.59 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation

Not sure if there are any tips to resolve this error?

my GPU 4090 RTX 24GB also CUDA out of memory when running EuRoC V202medium, why?

my GPU 4090 RTX 24GB also CUDA out of memory when running EuRoC V202medium, why?

I've solved it by using back cuda11.3, this problem happend with cuda11.7