Claims-based authorization

I'm thinking about implementing a system based on automerge with claims-based authorization (like JWT).
While I can sign changes from getChanges and verify the signature before calling applyChanges to ensure the authenticity, I don't see a way to implement authorization with the current API.
The basic idea is to augment each change with a signed token that proves that the actor (or associated user) is allowed to perform that change. I think automerge should stay agnostic to the concrete implementation, but providing an API to enable that would open up interesting opportunities, especially for decentralized software.
From my current understanding I think this requires at least:

a callback as optional argument to applyChanges that gets called for each decoded change and can decide wether to apply or decline the change based on the decoded change and the path from the root of the document to the object being updated.

In addition it might be interesting to

allow client specific meta-data for changes (which then are also passed as argument to the callback)

This meta-data could be used to associate the change with the respective signed token. I think the meta-data might be optional and an external association could be implemented by the consuming project. On the one hand it would make the API more convenient, but looking though the implementation, especially the columnar once, that would require a lot of changes and require the client project to implement custom decoders.

I've handled this out-of-band, in the transport layer. If communication occurs via an HTTP API, then the access token can be included in an Authorization header. If communication occurs over a web socket, there isn't a standardized way to include credentials, but I've done it by including the token as a field (in JWT form) in the data packet. In either case, the recipient can validate the token prior to accepting the changes included in the payload.
This implies the presence of some kind of authorization service whose role is to validate the credentials associated with each change, which in turn suggests some kind of client-server setup. I can't imagine that you'd want to be broadcasting tokens around a peer-to-peer network.

@MeneDev I think your approach is really interesting but there are a few problems to solve. First is, as @Steve-OH points out, that you might not need to actually change Automerge to do this, but can simply unbox the changes, check their signatures, and then decide whether to pass them into applyChanges if they pass muster.
I think more interestingly the question is what to do if you get a change that is no good. Right now, every change in Automerge depends on every change that was locally visible when the change was made, and each local node has only a single linear history. That means that if you reject a change from a source you won't be able to apply any further changes from it ever, nor will you be able to accept changes from people who do. That might not be a problem in your case -- perhaps quarantine / excision of misbehaving nodes is desirable? -- but it does limit the flexibility of the approach.

The "decide whether to pass them into applyChanges" step can be complicated if you're doing anything more difficultthan simple read/write checks on the whole document. For example, you might have a "comments" array which anyone is allowed to write to but a "description" field which is only allowed to be modified by changes signed by a particular key. Authorization in a local-first context is determining whose changes you are going to accept, so access control is the same as schema validation.
Therefore finding solutions to the problem of changes which depend on changes which we don't want to accept would be very useful. Even if there's no way to allow that it would be useful to be able to roll back a single change - that is, to expunge it from the backend and emit a diff which removes it from the frontend. At the moment to check a change you have to apply the change, examine the result and if it is invalid you have to throw the whole document away and rerun the history up to the offending change.

Yes, I think this is a very interesting line of reasoning to work down and I'm excited about the promise of the approach you're exploring here.
I do want to suggest that as a foundational concept we should always allow local editing of any information and make agreement optional (though convenient and by default).
Consider, in your example, what we would do if you lost your signing keys. Now the document's time would become immutable! There would be no way for us to agree to your new key. This would be no big deal, perhaps, for a short-lived document, but could be a big problem if the document was a shared calendar for a workplace.
The extremely shorthand way I describe this change in perspective is "attention, not permission". I can scribble all over my copy of the building codes, but the inspector won't care when she comes to check if I've got the wiring right. Still, it is useful and important for me to do just that, and it's hard to predict who will participate in a system in the future: perhaps I might want to work on a proposal for a new version of that document with some collaborators. My edits may (or may not) ever be accepted upstream but there's no reason I shouldn't be able to edit, annotate, or otherwise alter my version.

@MeneDev
Since you've invited @pvh and me to your network...
The more I think about it, the more I come to the conclusion that authorization in a true peer-to-peer network is equivalent to the Byzantine generals problem. And the solution to that problem is well known: A two-peer network cannot tolerate any "traitors," A three-, four-, or five-peer network can tolerate one "traitor." Six through eight peers can tolerate two "traitors," and so on. In general, the number of traitors cannot be more than 1/3 the number of peers.
You can make the system more robust against treason unauthorized access by dropping the peer-to-peer requirement on authorization, but that means having some sort of trusted authority. And once you have a trusted authority, I don't know if it makes sense to distribute the burden of access validation among the peers; you may as well centralize that, too.

@Steve-OH you're right, to make that work you either need byzantine quorum (as far as I know that's what usually happens in blockchains, but I'm by no means an expert) or a trusted authority. In this approach that trusted authority does two things: issue the certificates that are used for signing, sign the tokens that contain the claims.
The benefit of this "almost peer-to-peer" network is that the requirements on availability of the server-side infrastructure are much lower. Even if all central servers are down, no one would even notice unless you want to invite someone new to your party. It degrades a little, but the core keeps working. The difference for users between 95% uptime and 99.9…% become much less relevant. You can also have "true" microservices that don't require any centralized communication that may become a bottleneck.
From my minimal understanding of blockchains, I think this approach of something like a middle-ground between client-server architecture and blockchain.

@pvh good thoughts, I need to think about them a bit more. From the top of my head:

if you lost your signing keys. Now the document's time would become immutable

That is correct, I'm not sure if I would consider that a problem that automerge has to solve – in fact I would like automerge to not know about the concept of signing keys at all. By extend this also covers that scenario. If it's important that this must not happen, there are ways: multiple owners to increase redundancy or a central server that stores the keys. But I think that really depends on the domain of the concrete project that uses automerge.

always allow local editing of any information

I think that would be domain specific, too. The problem here is that there is a canonical "upstream" version, the one that everyone, including the inspector, has agreed upon. Once we start building, that's what we'll do. At the same time you work on a draft version. You can make suggestions, but you cannot decide if these suggestions are legal. However, the verification process is done on a concrete version of a document, not on single changes, so I think it's a slightly different usecase.
Still I can imagine a scenario where this approach is beneficial. When you are working on a big building and have several departments that work on different parts of the building, and each of those departments have a supervisor.
Inside a department everyone may change things, however, when the department wants to commit to the upstream version, the supervisor must sign each change accordingly. But the token of each supervisor only allows to perform changes in their respective part of the building.
If you – as a non-supervisor – want to, you can change anything. But if you want your changes in a different department to make it to the upstream, you have to talk/give your changes to a different supervisor.
The team that is responsible for assembling the final version of the document from each department can now rely on each incoming changes from each supervisor to only relate to their part of the building, a guarantee that could help to prevent mistakes or malicious behavior.
This could be implemented in a project with a applyChanges callback that allows unsigned changes in draft versions, but requires signed changes in the upstream version.
And one thing not to forget regarding your concern that documents become immutable: the documents / the changes are not encrypted. It's still possible to create a copy with new keys. It's however, not the same document anymore.

I think it's quite promising to have a callback in applyChanges that allows application code to validate whether a change is allowed to be applied (e.g. based on which properties of the document it modifies). That would allow apps to specify their own policies without baking any particular policy mechanism into Automerge. However, if we do this, there are a few caveats that will require care:

As @pvh pointed out, if one change gets rejected, then Automerge will also have to reject any subsequent change that depends on the rejected change. This is because, for example, the rejected change may create some object, and subsequent changes may refer to the object ID that was created in the rejected change.
The app will be responsible for ensuring that all clients make the same decision on whether to accept or reject a change. If some clients accept a change and others reject it, they will become permanently inconsistent, and all CRDT guarantees are gone. This could happen really easily — for example, say you have a policy that an authentication key can only be used as long as it is not expired. Depending on the system clock on different clients, some clients may decide that a key has expired while others may decide that it is still valid.

If these caveats are acceptable, I'd welcome proposals for what the API should look like.

Apologies for weighing in six weeks after the fact (I was offline for a while), and also apologies for repeatedly spamming this repo to talk about a different library! 😬
I've been working almost exclusively on this problem for the last 18 months or so. Some thoughts:
I don't think it makes sense to try to solve this within Automerge. Instead, I'd suggest determining identity (authentication) and permissions (authorization) elsewhere, and then using that information to inform who you're willing to talk to, and what changes from them you're willing to accept.*
The best solutions I've found for purely peer-to-peer authentication & authorization are applied in a library I've been working on that I think is almost ready to release: localfirst/auth. In brief,

Authorization is determined via a chain of permission grants that can be traced back to the group's founder (or document author). No consensus is required, byzantine or otherwise; neither is a central server.
Authentication is done using signature challenges (here's some data that includes a random element, sign it with your private key and we'll check it against your public key to know if it's really you).
The history of the group (invitations, role assignments, removals, key changes, etc.) is recorded in a directed acyclic graph (DAG) of signed, hash-chained actions that we call a "signature chain".
Each device generates its own private keys that never leave that device. Public keys are recorded on the signature chain.

There's lots more interesting stuff: How do you securely invite someone to your group? How do you handle potentially conflicting concurrent membership changes? How do you enforce read permissions? For answers to these questions and so much more, please see this (draft) blog post.

*If someone makes an invalid change (e.g. one they don't have permission to make), the most straightforward solution is to refuse to merge with them until their document is back in a valid state. To continue @pvh's analogy, I'm free to edit my copy of the city's building codes on my own computer. However, I shouldn't reasonably expect anyone to pay attention to my copy, and I also shouldn't expect to be able to cleanly merge in an updated version of the official codes.

Thanks for spamming 😅  I read the blog article and I think I agree with everything in it. Especially the wording of attention vs privilege seems to be an improvement in the semantics.
What I don't see is how that disagrees with this issue.

I don't think it makes sense to try to solve this within Automerge

That's not what I have in mind. All I want is a callback that allows logic outside of automerge to ignore changes – an attention-callback, to use your wording.
Whether you use claims for that or "a chain of permission grants" is an implementation detail. What is important is that the logic outside of automerge understands the operation that will be applied. And for that I see two ways:

parse the operation outside of automerge; or
let automerge parse it and provide a callback

to determine if we want to pay attention or ignore the operation.
I looked at the code and I could only find authorization with regards to the administration of the team or infrastructural actions like changing keys.
What I don't see is fine-grained authorization in the fashion of: is Bob allowed to change element company[2].name of a team-wide document.
(Where "team-wide document" means a copy everyone has that we expect to be mergeable with all the other copies inside the team)
From what I understand that also isn't the scope of local-first-web/auth?
In fact I think adding this attention-hook to automerge would make the two libraries a nice complement to each other.

@MeneDev — I agree, and I don't object to adding this callback API to Automerge. That would be useful and probably sufficient for many use cases.
I personally would hesitate to use that approach for an application of any complexity. Yes, you could intercept Automerge's low-level operations, and then guess the implicit semantics of the change based on JSON paths, but that feels messy and brittle to me. I prefer to use changes with explicit semantics — Redux-style named actions + payloads — that I can then reason about in a very straightforward way. So instead of detecting that Bob wants to change company.*.name, you see that Bob wants to apply an action of type CHANGE_COMPANY_NAME, and you can then look that action up somewhere to see if Bob has permission.
(There's a similar problem when it comes to using Automerge.getConflicts() to apply any kind of alternative conflict resolution: You have to back out the semantics of changes from the way they affect your JSON tree.)
You could then use Automerge to store your named actions + payloads — I went a long ways down that path with a library called localfirst/state (formerly "cevitxe"). But what I've only recently come to realize is that a Redux-style event stream isn't that far off from being a full-fledged CRDT itself — all you need to add is a way of recording and resolving concurrent actions. (easy! 😅)
The good news is that I've built that exact machinery for localfirst/auth — that's the "signature chain", a git-style DAG of signed, hash-chained actions — and I've refactored it out into a standalone library called CRDX that you can use to create a CRDT with your own semantics, validation rules, and conflict-resolution logic.⚠
This is maybe where I'm at with Automerge: I think its biggest selling point is it works with plain old JSON objects. And I think its biggest limitation is that it works with plain old JSON objects. To the extent that a big JSON blob works for you as a way of storing state, Automerge is a good choice. If event streams or Redux or the like would make more sense for your app, using something like CRDX might put you on more solid footing. Or you could roll your own simple custom CRDT, turns out there's no magic involved. This is the approach that @jlongster took with Actual and that @vjeux et al took with Excalidraw.

James Long: CRDTs for Mere Mortals
Building Excalidraw's P2P Collaboration Feature by @idlewinn

⚠CRDX is unreleased at the time of writing, docs are patchy, API may change, use at your own risk

Based on some of my research and conversations with @ept and @HerbCaudill, it seems that conditionally rejecting / ignoring writes (i.e. to preserve application invariants or to deny an unauthorized write) are fundamentally at odds with eventual consistency. One solution is to coordinate such writes using consensus or a "lead actor". But, if you really want to follow Automerge's eventual consistency model, all writes causally dependent on a rejected write must also be rejected (as explained by @pvh above). Unfortunately, actors that have not synchronized in a long time may cause a very old write to be rejected, and to ensure eventual consistency, any actor who has "seen" the rejected write must subsequently reject any causally dependent writes. Thus, it is possible that days after a given state has settled, a single actor can cause a vast number of writes to be rejected due to a single rejected write. In my opinion, this trade-off is simply not acceptable for most applications; the entire reason for convergence and consistency is to provide the user with a reasonably stable application state. Somewhat ironically, preserving eventual consistency while rejecting writes would very likely confuse users and either cause data loss or a large number of conflicting writes.
All of that said, it appears that decentralized authorization can be achieved with Automerge if you never want to revoke access to a document in the future.
Finally, in my experience, there are many applications where a vast majority of writes can be eventually consistent, but unfortunately, there are few applications where all writes can be eventually consistent. In my view, Automerge is a tool to augment performance and provide a well-designed "offline mode" for eventually consistent writes. Still, for most apps, another tool or database will be required to provide durability and strong consistency guarantees.
I would love to be wrong about any of this. Sadly, if I am correct, it seems that rejecting writes is not something that Automerge should do if it does not embrace some form of consensus for those writes. What do you think? Is this outside the scope of Automerge? Should this issue be closed?

I think, broadly, what we're seeing is a pull to transition from "CRDT-as-mechanism-for-guaranteed-consensus" to "CRDT-as-engine-of-document-versioning". All of us around the lab have been thinking about this for a while now and I think that once the performance & sync work clears off our plate this is going to be an area of major focus.
I'm not entirely sure what the trade-offs are for your application, but in a general sense, I think the short-term solutions are 1) don't sync with people you don't trust, with traditional documents if you let a stranger write to your files you're going to have a bad time and 2) think about the fact that late-arriving data probably shouldn't blow away work that depended on it, but we could at least detect it and surface the problem: "Hey, you probably want to audit this set of changes since they all depend on work done by someone we now know to be suspicious."
Do either of those help in your situation, @bminer?

@pvh - Thanks for your response! I find it really interesting to discuss this stuff.
Regarding (1): sometimes you sync with people you trust, and then after some time passes, you don't want to trust them anymore (i.e. an employee who leaves to work for a competitor or a customer who stopped paying their bill). If you can afford to always allow reads and writes, then I think Automerge works well.
Regarding (2): if late-arriving data conflicts with a large number of writes, what do you do about it? If you can afford to always accept the write, then Automerge again works well. I like your suggestion of detecting a suspicious write and perhaps asking the user to undo it if needed. Still, this does not prevent future writes and requires manual user intervention. I suppose if a malicious person continues to write to a document, actors could coordinate to copy the document from an agreed-upon snapshot to a new document and continue writing it from there. Still, this requires consensus among actors, which @ept has expressed might be outside the scope of Automerge.
At a high level, this issue is about authorization, which implies that unauthorized writes need to be rejected. Maybe this is something Automerge should not support? I don't know. Thoughts?

All other ideas I have about rejecting writes involve consensus in some form or another. For example, (perhaps outside of Automerge) actors can form a consensus about a document and agree to ignore writes from an actor after a particular logical timestamp. 🤷

sometimes you sync with people you trust, and then after some time passes, you don't want to trust them anymore

Right -- what I'm saying is that right now the way you can solve this is to stop syncing with them. In the future we may be able to get clever-er, but maybe this solution is good enough?
I think on the whole that if you think about this as a git repository you'd have most of the same dynamics. If someone has made commits and you have decided you don't want them around anymore, you just have to stop pulling from their repo / stop letting them write to yours. If someone else you know already accepted writes from them and then built on them... you'll have to audit those commits to make sure there wasn't any malfeasance but you can't really just drop them.
We've got some upcoming research into this kind of thing (though not necessarily exactly down this vector) which might provide the necessary infrastructure to do what you want to do, but on the whole the more we discuss this the more it seems to me that the best place to solve these problems is up in the sync layer.
I think the peer-to-peer document-identified-by-public-key approach typified by Hypermerge is a bust in this regard. I think what you want is something that feels more like git remotes except... not... bad.

At a high level, this issue is about authorization, which implies that unauthorized writes need to be rejected. Maybe this is something Automerge should not support? I don't know. Thoughts?

As elaborated by Herb Caudill in his blog post (still unpublished, I believe), at https://draft.herbcaudill.com/words/20210228-establishing-trust-in-a-world-without-servers, the concept of "authorization" doesn't fit at all well with local-first distributed collaboration. You either have to replace authorization with some other concept (e.g., you can simply disregard the contributions of someone who is "unauthorized"), or continue using a centralized authorization server, which is necessarily outside the scope of Automerge.

Right -- what I'm saying is that right now the way you can solve this is to stop syncing with them.

@pvh - Yeah, I agree; this problem can be solved at the sync layer, but...

If someone else you know already accepted writes from them and then built on them... you'll have to audit those commits to make sure there wasn't any malfeasance but you can't really just drop them.

This is exactly my point. How should one handle this case? Some actors could accept a sync from an unauthorized actor (perhaps even "honestly" due to timing / network issues) and then propagate those changes through to other actors. It seems to me that a consensus among actors is required to prevent further syncing with an unauthorized actor. I suppose if you used a set of trusted, centralized sync servers instead of peer-to-peer syncing, this problem fades away, as in your example of a central Git repository.
The more I think about this, the more I feel like writes should simply never get rejected. You can try to block actors by attempting to stop syncing with them, but this is not foolproof. Maybe this is good enough? Thoughts?

The nice thing about automerge is you always have the full history of every document. As with a physical document, anyone can write anything they want... you just don't have to pay attention.

It makes me sad (a little) seeing how "crypto" (read shitcoins and "blockchains") confused people. Byzantine problem and its solution have one very special purpose in Bitcoin and Bitcoin only. A very special problem with a very special solution. Auto merge is totally different. The only similarity is a Git-like hashing.
Any authorization and authentication in Automerge must be based on public/private key cryptography. No voting and no consensus are needed nor required.
Privileges to read and modify can be done as in OpenPGP when multiple recipients are specified. The approach is simple. Data are encrypted with a symmetric key and that key is asymmetrically encrypted for each public key. If someone already wrote it, then sorry. I am unable to read texts where a "blockchain" term is used because it melts my brain. That word means nothing real (except in Bitcoin). Sorry for the off-topic and tone.

@steida I don't think anybody here is inappropriately pushing cryptocurrencies or blockchains. Please keep the discussion polite and on-topic.

@ept OK, I deleted it.

@ept Does authorization belong to Automerge? Isn't it solvable by public/private key cryptography outside of the Automerge? What is the current vision? Thank you.

@steida Cryptography is good for authenticating the author of a change, by signing it with the author's private key. That can be easily be done outside of Automerge, but it's only the first step. What we're discussing here is a more difficult issue: once you've authenticated the user who made a change, how do you determine whether that user is actually allowed to make that change? If they are not allowed to make a change, we need to ignore the change. This seems to require some degree of "business logic" (e.g. some fields are editable but others are not), and is harder to do outside of Automerge without some API support.

Thank you for the explanation. As I see it, if someone gets access to Automerge data, they can do whatever they want. The only thing we need to know is whether allowed changes come from specified users, I suppose.

how do you determine whether that user is actually allowed to make that change?

If someone makes a change that they are not supposed to do, remove their public key from the encrypted document so they lost access to it.
But I just started thinking about that so I am likely overlooking something.

If someone makes a change that they are not supposed to do, remove their public key from the encrypted document so they lost access to it.

That doesn't prevent a malicious user corrupting the document, and would require manual intervention. It seems reasonable to me that app authors would want a way to specify which changes they want to accept from collaborators and which they want to ignore. Just like in a centralised web app, where the server can perform validation of user input and reject the request if the user does not have permission to do the thing it's trying to do.

if someone gets access to Automerge data, they can do whatever they want.

Users can update their own copy of a document in whatever way they want, and we can't stop that. But we can allow users to have rules that determine whether to accept or ignore such changes.

I've looked into this again and found that automerge now has a patchCallback. I was able to get the desired behaviour by  throwing an exception from there. While that's not completely unidiomatic, I'd prefer to see a return type indication that this patch should not be applied (and with my limited rust knowledge, panicking if off-limits there). My assumption is: since automerge is immutable on the inside, this is basically like rolling back a transaction in a relational database.
My current proof of concept looks like this:
function verifyingPatchCallback(patch, doc, newDoc, isLocal, binChanges) {
    for (let change of binChanges.map(decodeChange)) {
        let ops = change.ops
        for (let op of ops) {
            // TODO resolve full path
            if (op.key === 'restricted') {
                throw new Error("Can't touch this")
            }
        }
    }
}

I would favour something like
function verifyingPatchCallback(patch, doc, newDoc, isLocal, binChanges) {
    for (let change of binChanges.map(decodeChange)) {
        let ops = change.ops
        for (let op of ops) {
            if (op.key === 'restricted') {
                return ROLLBACK
            }
        }
    }
    // optional in js, mandatory in rust
    return OK
}

And the places actually calling the callback would become something like this:
if (patchCallback) {
  const result = patchCallback(patch, doc, newDoc, false, changes)
  if (result === ROLLBACK) {
    // return the unmodified document
    return doc
  }
}

In the rust implementation patchCallback is still a TODO.
Do you think that makes sense? What about the wording, is it a "transaction"?

Hi @MeneDev, unfortunately the patch callback is called after the internal state of Automerge has already been updated, so by this point it's too late to stop the update from happening. Moreover, while Automerge's external API is immutable, its internal state uses mutable data structures (it would be too slow otherwise), so the rollback is not quite as straightforward as discarding the updated state. The Rust implementation does have a rollback feature, but I believe this is primarily for locally originated changes, and I'm not sure it can be used to rollback remote changes (someone correct me if I'm wrong). Therefore, while the general idea of having an authorisation callback makes sense, some groundwork in the internals probably needs to be laid before it can be used in practice.

Ok, thanks for clarifying!
Martin Kleppmann @.***> schrieb am Do. 15. Sept. 2022
um 12:35:

Hi @MeneDev https://github.com/MeneDev, unfortunately the patch
callback is called after the internal state of Automerge has already been
updated, so by this point it's too late to stop the update from happening.
Moreover, while Automerge's external API is immutable, its internal state
uses mutable data structures (it would be too slow otherwise), so the
rollback is not quite as straightforward as discarding the updated state.
The Rust implementation does have a rollback feature, but I believe this is
primarily for locally originated changes, and I'm not sure it can be used
to rollback remote changes (someone correct me if I'm wrong). Therefore,
while the general idea of having an authorisation callback makes sense,
some groundwork in the internals probably needs to be laid before it can be
used in practice.
—
Reply to this email directly, view it on GitHub
https://github.com/automerge/automerge/issues/419#issuecomment-1247914306,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABJGCW476272KQDTTNJHGQLV6L3W3ANCNFSM5BMSIL6Q
.
You are receiving this because you were mentioned.Message ID:
@.***>

I'm also interested in rejecting "bad" changes. In the Rust implementation we could achieve this by adding a return type to the various methods of the OpObserver trait to indicate whether an op (and therefore it's encapsulating change) should be allowed to proceed. We could handle all the rollback work here. This would be quite a low level API though and I think you would have to be careful not to break things by rejecting changes in a non-commutative fashion - it would be nice if we could find a way to present an API which doesn't require people to reason about concurrent changes.

Sorry to ping, but several months have gone by.  @ept - Any ideas / new research that might address this issue?

@bminer Nothing new on this particular issue, I'm afraid — we have been focussing on other areas.

I watched Brooklyn Zelenka presenting UCAN at Local-First Conf and that brought me back here.
It has a similar idea to what has been outlined in this issue. Back when I was experimenting with that idea, I hit a wall at some point and I just wanted to share the problem and my solution.
The idea of separating the tokens/certificates from the payload opens the system to something I'd call a "foresight attack".  From the outside the attacker plays nice for a while, but may performs the attack at any time after gaining trust, even when the trust is lost later on. Examples would be a seemingly good employee who secretly prepares malice, maybe a XZ Utils co-maintainer.
With a "true microservice" to authorize a change, the attack is trivially possible after permissions have been revoked from the attacker.
Preparation

create a local copy of the local state ("good state")
perform malicious changes
get malicious changes approved
backup the local state without synchronizing with other users
revert the local state to the "good state"

Attack
Even when the position of trust has been lost, for example after the working contract has ended, and all permissions have been revoked, the attacker can still revert any of the backups with malicious changes and sync them.
Prevention
I've played around with some ideas like forcing key rotation after each time permissions are changed, using wall clock or logical (I think that was just pointless) time to add a due date to the signature, revoking changes, but they all either beak the CRDT contract, don't work at all, are hard to implement, expose end users to odd UX, or a combination of those.
A simple solution: if an authority (central server or quorum) grants a permission, it must also distribute the payload, and once a payload is signed, it is eternally valid.
Note that this still allows the payload to be encrypted.
Sidenote: I haven't looked into details of UCAN yet. The video doesn't seem to mention something like a expiration, the website uses a unix timestamp like JWT. But my notes on this are from 2023-01-20 and I've been meaning to write this down here for some time 🙈


Reduce heap usage by using jsmn for weather API instead of cJSON

cJSON uses 30kB of heap space for the api.weather.gov 17kB response, and this is very expensive making it difficult to add new features. Currently we only have about 3kB of headroom when parsing the response.

discussion here https://github.com/goat-hill/bitclock/pull/13#issuecomment-2510305218


Welcome saarantrass

Hello world, am I doing this right?

Reopened,
Needs a commit, and usage of #Closes in commit message :)


Guild administration menu

Implements join guild, leave guild, create guild

Tested Leave, Join, and Create all working :)


Click outside the handle's Y axis doesn't teleport it anymore

When we click somewhere on the scrollbar we are teleport at this point.
I noticed the Android's Contacts app doesn't have this behavior, you have to click on the handle to use the fastscroll.
So in this PR there is an additional check to avoid the fastscroll if the TouchEvent is outside the handle Y area.
Is it the expected behavior ? :)

I don't understand what you describe. Can you show a video?
Also, note that what I did here is not from the original code, but I made it from some tutorial, and modified it to work fine.

Also, note that what I did here is not from the original code, but I made it from some tutorial, and modified it to work fine.

Yeah, I read it in the readme's projet. Good job btw ! :)
Here is a gif with the current behavior. If you click somewhere in the handle's X area, you're teleport. I suppose this isn't the expected behavior because it's not the same as the Android contacts app.

With the PR

The PR just add a check:

if the TouchEvent is inside the handle area, then handle is selected

I think I understand now what you mean.
You mean that the handle should only be dragged when started touching on it.
If this is what you mean, can you please make it an optional (and the
default) behavior?
I think that I've seen the other behavior on some apps before.
On Sat, Jun 4, 2016 at 9:29 PM, DarzuL<EMAIL_ADDRESS>wrote:

Also, note that what I did here is not from the original code, but I made
it from some tutorial, and modified it to work fine.
Yeah, I read it in the readme's projet. Good job btw ! :)
Here is a gif with the current behavior. If you click somewhere in the
handle's X area, you're teleport. I suppose this isn't the expected
behavior because it's not the same as the Android contacts app.
[image: ezgif com-resize]
https://cloud.githubusercontent.com/assets/4621928/15801359/84bb147a-2a92-11e6-90b3-cf579e1f0bf2.gif
With the PR
[image: ezgif com-resize 1]
https://cloud.githubusercontent.com/assets/4621928/15801361/999a2c3c-2a92-11e6-91c7-ebf4191ab88e.gif
The PR just add a check:

if the TouchEvent is inside the handle area, then handle is selected

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/AndroidDeveloperLB/LollipopContactsRecyclerViewFastScroller/pull/16#issuecomment-223770706,
or mute the thread
https://github.com/notifications/unsubscribe/AFG_1qviLPiuIzumZGKcrjCe5dxlaaBPks5qIcP_gaJpZM4It7_E
.

Exact !
I'll do it after my vacation then :)

ok, have a nice vacation !

Hey !
Here are the modifications you asked me.
By default, we have to touch the handle to drag it. There is a boolean to disable this constraint.
If you have a better name for the boolean param, feel free to change it :)

Too many in my opinion, but ok. Thank you :)


Auto-install and run standalone test proxy server per test package

This update brings the go test recording behavior in line with other languages by removing the need to manually install/run the test proxy, and resolves some multi-module test run conflicts we had been seeing with single server test proxy sessions. See https://github.com/Azure/azure-sdk-tools/issues/6483#issuecomment-1629899174 for a description of the issue.
Now on test start we will check if the latest proxy version is downloaded, install if missing, and then run on a random port local to the test process.
Fixes #21129

@chlowell @jhendrixMSFT let me know if you want to put any eyes on this.

/azp run go - internal - ci

/azp run go - internal - ci


Honeywell Climate Component Not Reporting Quite Right Since 0.96 Migration

Home Assistant release with the issue:
0.96.3
Last working Home Assistant release (if known):
0.95.4
Operating environment (Hass.io/Docker/Windows/etc.):
Hassio/Hassos/RPI 3B+
Component/platform:
https://www.home-assistant.io/components/honeywell/
Description of problem:

The honeywell climate component is showing 2 cooling values and 2 sliders controls, there should only be one and in the case below it should be 77.

70 is actually the heating setting that would be scheduled if the thermostat was set to heat. I can see this value change with the scheduled heating value throughout the day. See schedule below as this may be confusing (from the honeywell IOS app)

2) As seen below, there is no indication in the pop-out graph that the system has been cooling.  It used to show a shaded area in the graph when the system was actively cooling. The scheduled "heat" mode temperature (not used in summer) is incorrectly plotted as target temperature low (blue line). The setting at bottom left (70) is not needed here, it is the value for "heat" mode when I set the thermostat to heat in the winter.

3) Due to the "heat" setting being reported as target temperature low, homekit homeassistant is relaying the thermostat setting incorrectly to Apple Homekit. In the example below the setting and actual temperature seen the Apple IOS Home app should both be 77.

I suspect there will be similar issues in the winter when set to "heat" mode.
I do not use the "auto" mode, just "heat" or "cool".
Thanks for looking into these minor issues, I appreciate the developers efforts, especially @zxdavb for taking on the migration of this component!
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
- platform: honeywell
  username: redacted
  password: redacted
  scan_interval: 600
  region: us

Traceback (if applicable):

Additional information:

@Hackashaq666 Thanks for your useful submission.
The base problem is that I didn't really have access to a Honeywell HVAC system to test against when I was refactoring this code.
There is a new PR (#25369) that make quite a few changes in this area.  It also fixes some other bugs (identified with a code walk-through).  Already, from what I see above, I will need to make a few more changes to that...
What I really need is someone to do some testing against a live system...
Are you able to run a version of HA from git, or would you will willing for me to access your system directly (we can do that via PM).

OK, looking at the 0.94.x code, there was only SUPPORT_TARGET_TEMPERATURE (no _range), and no max_temp, min_temp.
When I refactored for 0.96, I added SUPPORT_TARGET_TEMPERATURE because the JSON has:
"SwitchAutoAllowed": False,
"SwitchCoolAllowed": True,
"SwitchOffAllowed": True,
"SwitchHeatAllowed": True,

Two reasons: SwitchAutoAllowed, and can allow heat SP to be set even if system_mode set to cool.

@Hackashaq666 Thanks for your useful submission.
The base problem is that I didn't really have access to a Honeywell HVAC system to test against when I was refactoring this code.
There is a new PR (#25369) that make quite a few changes in this area. It also fixes some other bugs (identified with a code walk-through). Already, from what I see above, I will need to make a few more changes to that...
What I really need is someone to do some testing against a live system...
Are you able to run a version of HA from git, or would you will willing for me to access your system directly (we can do that via PM).

I can run a test version as a custom component if that will help or is even possible with this component? Would this help?

It should convert into a custom component OK (although I haven't tried it myself). Do you know how to do that - I think just a matter of copying the files into the correct folder.
Giving me access to your system is straightforward: you just just do it through the TCC website - it's a matter of sending an 'invitation' to my account.
My preference would be if you you could run my version of HA...
I could set you up a website using my credentials, if you gave me access via TCC, but I may have talked HA into accepting the PR by then.

I can try to install as custom component when I have time this evening, I have done so in the past with the old component when I made a minor change to get the indoor humidity value.
Just point me to the location of your test version, I will be downloading the zip file.
Thanks!

Easiest way is to pull the files from: https://github.com/zxdavb/home-assistant/tree/tweak_honeywell_migration/homeassistant/components/honeywell - this is where teh PR is coming from.

As PR merged, now pull from: https://github.com/home-assistant/home-assistant/tree/dev/homeassistant/components/honeywell

I had the chance to test the merged PR as a custom component.
The changes are looking good but there is one new issue.
The component is reporting "Idle" whether the system is cooling or not.
Thanks again for your work on this!

Ok, now the component is correctly reporting "cooling". Maybe took a few minutes to report correctly.

Ok, the delay is as it should be based on the scan_interval set to 600 in the configuration.yaml
Only thing missing now is shaded part of graph indicating when the system is actively cooling or heating.


Segmentation Fault, Swift Reflection

Segmentation Fault of Swift Reflection
I recently use swift reflection to convert json string to a struct, but got "Segmentation Fault" in runtime. As the test code is too much to write here, I committed my test code in github, can you help have a look, thanks.
Steps to reproduce
$uname -a
Linux dev 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ swift --version
Swift version 3.0 (swift-3.0.1-PREVIEW-1)
Target: x86_64-unknown-linux-gnu
$ git clone https://github.com/hikelee/SegmentationFault.git
$ cd SegmentationFault
$ swift build
Cloning https://github.com/Zewo/Reflection.git
HEAD is now at 2bc1a76 make mappable tests public on reflection
Resolved version: 0.14.0
Compile Swift Module 'Reflection' (23 sources)
Compile Swift Module 'Main' (1 sources)
Linking ./.build/debug/Main
$ .build/debug/Main
Person(firstName: "James")
Person(firstName: "James")
Person(firstName: "James")
Person(firstName: "James")
------
Person(firstName: "James")
Person(firstName: "pb?\0\0\0\0\0a")
Person(firstName: "\u{10}\u{10}\0a")
Segmentation fault

Related to #195.
Thanks for the bug report. We're already tracking this and hope to resolve it soon. For now, you can implement init(map:) manually.

there are some special characters printed out,please resolve it together,tks

Oh, this is in a non-venice environment, I didn't see that initially. This changes things @bradhilton

Got a different error message running in arch linux :
Hello: /tmp/yaourt-tmp-hike/aur-swift/src/swift/include/swift/Runtime/../../../stdlib/public/SwiftShims/RefCount.h:252: bool StrongRefCount::doDecrementShouldDeallocate() [ClearPinnedFlag = false]: Assertion `newval + quantum >= RC_ONE && "releasing reference with a refcount of zero"' failed.
Person(firstName: Aborted (core dumped)

@hikelee Can you try running it again using Reflection 0.14.1? I just issued a fix to #195, which may also fix this issue.

@bradhilton ,thanks for tracking, but the bug still exists. Below is my test result:
Arch Linux test
$swift build
Cloning https://github.com/Zewo/Reflection.git
HEAD is now at e75ca32 Remove @testable from PublicTests
Resolved version: 0.14.1
Compile Swift Module 'Reflection' (24 sources)
Compile Swift Module 'Main' (1 sources)
Linking ./.build/debug/Main
$ .build/debug/Main
Person(firstName: "James")
Person(firstName: "James")
Person(firstName: "James")
Person(firstName: "James")
------
Person(firstName: "James")
Main: /tmp/yaourt-tmp-hike/aur-swift/src/swift/include/swift/Runtime/../../../stdlib/public/SwiftShims/RefCount.h:252: bool StrongRefCount::doDecrementShouldDeallocate() [ClearPinnedFlag = false]: Assertion `newval + quantum >= RC_ONE && "releasing reference with a refcount of zero"' failed.
Person(firstName: Aborted (core dumped)
Ubuntu 16.04 test:
$swift build
Cloning https://github.com/Zewo/Reflection.git
HEAD is now at e75ca32 Remove @testable from PublicTests
Resolved version: 0.14.1
Compile Swift Module 'Reflection' (24 sources)
Compile Swift Module 'Main' (1 sources)
Linking ./.build/debug/Main
$ .build/debug/Main
Person(firstName: "James")
Person(firstName: "James")
Person(firstName: "James")
Person(firstName: "James")
------
Person(firstName: "James")
Person(firstName: "pâÜ\u{01}\0\0\0\0a")
Person(firstName: "\u{10}\u{10}\0a")
Segmentation fault

There is no error in macOS, seems it's only appears in linux environments

Thanks @hikelee, I'll have to try debugging it in linux then.


Add chat implementation

Signed-off-by: Jean Pierre Dudey<EMAIL_ADDRESS>

Not needed anymore, new implementation is on master.


[New Feature] CUTLASS kernels for w4a8 quantization

We plan to add QAT for LLMs to torchao (as mentioned in the original RFC here https://github.com/pytorch-labs/ao/issues/47)
For this to run efficiently on the GPU we'd need kernel support for W4A8 quantization (int4 weights, int8 activations).
Other places where this has been raised before
https://github.com/NVIDIA/cutlass/issues/1316,
https://github.com/NVIDIA/cutlass/issues/1370
cc @andrewor14

cc @alexsamardzic @cpuhrsch

Working on this: https://github.com/NVIDIA/cutlass/issues/1413.

@alexsamardzic
Great work so far on integrating w4a8 GEMM in Cutlass!
Do you have plans on re-implementing this functionality in pre-Hopper architectures using Cutlass 3.x / CuTe rather the Cutlass 2.x apis that seem to be deprecated?
The 3.x interface has some convenient sub-byte primitives for slicing 4b tensors but warp-level shuffling would still be needed for efficient tensor core loading and mma.
Would be happy to help adapt 4b mixed type gemm using CuTe for Ampere.

Do you have plans on re-implementing this functionality in pre-Hopper architectures using Cutlass 3.x / CuTe rather the Cutlass 2.x apis that seem to be deprecated?

(Please send further comments to the PR mentioned above - I think it makes most sense to discuss CUTLASS features on CUTLASS GitHub pages.)
As it could be seen from my PR, this feature is implemented the same way as F16/S8, and alike.  For my purpose, and that is adding support for this operation into PyTorch, for Ampere architecture and for both eager and compiled mode, this is good enough.  I'm not sure in which way my changes could be made more 3.x-y, as the functionality is implemented on the warp level, but if you have any suggestions, please post them either into this, or in separate PR.


superagent.agent().use()

We currently don't support setting up of plugins and settings for all superagent requests (#635).
I worry that allowing shared mutable configuration on the "singleton" returned by require('superagent') could be problematic, because this object is shared by libraries depending on superagent, and in an application where two libraries reconfigure global superagent, one could break the other.
But we already have a solution to mutability of cookies via superagent.agent(), which returns a "clone" of the "singleton".
I suggest adding .use() to the agent, which would affect all requests created by the agent instance (but not global requests from require('superagent')).

Done in #1302


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_1a_ea2andl/clone/recipe/meta.yaml:15: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_1a_ea2andl/clone/recipe/meta.yaml:22: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_1a_ea2andl/clone/recipe/meta.yaml:22: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_1a_ea2andl/clone/recipe/meta.yaml:29: missing_pip_check: For pypi packages, pip check should be present in the test commands
WARNING: /tmp/abs_1a_ea2andl/clone/recipe/meta.yaml:38: missing_description: The recipe is missing a description
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_0a7n1d84o3/clone/recipe/meta.yaml:15: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_0a7n1d84o3/clone/recipe/meta.yaml:22: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_0a7n1d84o3/clone/recipe/meta.yaml:22: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_0a7n1d84o3/clone/recipe/meta.yaml:29: missing_pip_check: For pypi packages, pip check should be present in the test commands
WARNING: /tmp/abs_0a7n1d84o3/clone/recipe/meta.yaml:38: missing_description: The recipe is missing a description
Errors were found


Bug/parallel identity deployment

Codecov Report

Merging #256 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #256   +/-   ##
=======================================
  Coverage   61.63%   61.63%
=======================================
  Files          18       18
  Lines        1092     1092
  Branches      213      213
=======================================
  Hits          673      673
  Misses        359      359
  Partials       60       60

Flag
Coverage Δ

#integration
33.24% <ø> (ø)
:arrow_up:

#unit
61.44% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Interaction latency API considerations

Currently an interaction result includes the start and end event.
We should consider simply associating a list of events instead. We'll end up with a single event when start & finish are called on the same event, 2 events for normal delayed interactions, 2 events for normal canceled interactions (but 1 for timed out interactions). We could support more than 3 by having a way to pull a running interaction & associate it to the current event, whether that interaction is running or finishing.
There's separately a question of whether even having an interaction type at all is useful. Since the rules are event based and the events carry all the context needed, an interaction could be defined as a list of events with maybe a name.
To do this we'd likely also need to provide access to all past events associated with a given running interactions, so that you could look them up and find the ones with start ids related to the id of the current event.
One consistent feedback is that cancelRunningInteractions() sounds like it would cancel all interactions when in fact it's all interactions local to the rule.

An interaction can be thought of as a stream of events. The part that's a bit awkward is converting that stream of events into something that's meaningful and loggable to analytics. If we don't include this part and just report streams of events then consumers still need to have code that recognizes those streams and turn that into something meaningful. Ideally that code would be defined next to where we define which events we care about.

Maybe the running and finishing interactions should have recordEvent() to associate the current event to a stream.
It's a bit confusing that start() is called from the scope and captures the current event, finish() is called from the interaction and also captures the current event, but everything else you have to call recordEvent()
If we start looking at a stream then the interaction type can still be on the rule, and it's something that converts a list of events into an object (also, note, maybe we should have exposed list instead of sequence since we're doing a copy anyway)


Feature/pai 292 card modal changes

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #
author instance
https://author-p131512-e1282665.adobeaemcloud.com/ui#/@pricefx/aem/universal-editor/canvas/author-p131512-e1282665.adobeaemcloud.com/content/pricefx/style-guide/components/card.html?ref=feature-pai-292-card-modal-changes
Test URLs:

Before: https://main--pricefx-eds--pricefx.hlx.live/
After: https://feature-pai-292-card-modal-changes--pricefx-eds--pricefx.hlx.page/style-guide/components/card

Dint create with content model changes branch so closing this PR and creating new one


Added new visible 'Create tenants option' info

Within 'User settings' in the Azure Active Directory portal is the 'Tenant creation' section. A toggle switch option for 'Users can create Azure AD tenants' is visible with a Yes and No option. I have added some information for this option in this proposed change.

Learn Build status updates of commit 532f412:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/active-directory/fundamentals/users-default-permissions.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@barclayn

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Documentation has been updated very similarly to my PR modifications by a Microsoft employee and has already been merged, this PR is no longer required.


[BEAM-8806] Integration test for SqsIO using Localstack (AWS Sdk v1)

Integration test for SqsIO using Localstack on AWS SDK v1.
Note: This depends on https://github.com/apache/beam/pull/16480 and will fail until rebased ...

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

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

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

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

R: @aromanenko-dev

Run Java PreCommit


Add missing C code for unpacking 3pdm/4pdm. Fix #1

why are the functions for BLOCK removed?

because these functions require libicmpspt2 which is an external
dependency ... my understanding is that the default installation of dmrg
therefore fails because of trying to load libunpack
On Wed, Jun 30, 2021 at 10:42 AM Xing Zhang @.***>
wrote:

why are the functions for BLOCK removed?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/pyscf/dmrgscf/pull/2#issuecomment-871603615, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN5NREJGWUYR2OICFJGJQLTVNJQ5ANCNFSM47O5YTZQ
.

Copy the code is not quite necessary. We can simply add dependency of icmpspt. I'm gonna close this PR and reopen one.

I agree that adding dependency is better than copying.
For this specific problem, icmpspt actually depends on dmrgscf (rather than the reverse), see, for example:
https://github.com/pyscf/icmpspt/blob/master/pyscf/icmpspt/icmpspt.py#L41-L42
Another thing is that the unpacking functions for 3PDM and 4PDM are never used in icmpspt.

I see, we can make icmpspt dependent on dmrgscf then.

I can confirm that unpacking functions for 3PDM and 4PDM are used in icmpspt only by calling dmrgscf and schiscf solvers. It is the best to move the  libunpack to dmrgscf keeping the _BLOCK functions, and make  icmpspt and schiscf dependent on dmrgscf.


Prevent accidental user overwrites

Fixes #21

fixes #21, https://github.com/Awesome-Technologies/synapse-admin/issues/176, https://github.com/Awesome-Technologies/synapse-admin/issues/467
relates to https://github.com/matrix-org/synapse/issues/8165


psfzf: Add version 2.4.0

[x] I have read the Contributing Guide.

PSFzf has a hard dependency on fzf (the module does not even load if fzf is not found on PATH).
So a depends or suggest for 'fzf' should be added


initial hours more than a day don't show

Starting a new countimer with options set as:
$('#clock').countimer({autoStart : false,leadingZeros: 2,initHours : 139,initMinutes : 03,initSeconds: 34})
The initial display shows the hours of 139 as only 19 (ie. it's excluding the fact that 139 includes 5 days (24hrs * 5)

+1

I've added a new version that fix this issue, please feel free to open again if it is necessary.


From instance for f64 and f32

It would be lovely to be able to convert floating points to rational numbers.

I missed this somehow. Thanks!


fixed jsii maven target

investigating #10
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

Waiting on word from sonatype that all is well with the 1.3.4 release...

published to the public repo 🙌
closes #10


Add sort option to ParametrizedSchedule

Summary
ParametrizedSchedule should keep given arg ordering, but there are some exceptions. The critical issue is when we build CircuitInstructionMap because FC instruction is not ordered by parameter names. In this PR, ParametrizedSchedule takes sort option to reorder parameters only when sort=True to cope with exceptional cases shown above. By default, it keeps given arg order.
fix #3609
Details and comments
To keep arg order, buit-in set function is replaced because it is not order sensitive.

Why would we ever sort the parameter list?

I think the problem is that parameterized pulse defs do not have a proper signature, we have to manually find the parameters as they come and they may be out of order. I'm not sure if the best place is to solve them here or elsewhere such as when construction the parameterized schedule in the defaults and sorting them there.

yes. the pulse parser analyzes backend inst map with ast but frame change instructions are not ordered with its parameter name.
Command(
name='u3', qubits=[0],
sequence=[
PulseQobjInstruction(ch='d0', name='fc', phase='-(P2)', t0=0),
PulseQobjInstruction(ch='u1', name='fc', phase='-(P2)', t0=0),
PulseQobjInstruction(ch='d0', name='X90p_d0_10c8', t0=0),
PulseQobjInstruction(ch='d0', name='fc', phase='-(P0)', t0=160),
PulseQobjInstruction(ch='u1', name='fc', phase='-(P0)', t0=160),
PulseQobjInstruction(ch='d0', name='X90m_d0_f926', t0=160),
PulseQobjInstruction(ch='d0', name='fc', phase='-(P1)', t0=320),
PulseQobjInstruction(ch='u1', name='fc', phase='-(P1)', t0=320)])

Then the parser returns parameters (P2, P0, P1) and ParametrizedSchedule receive this as a parameter list. Parameter order is not problem iff ParametrizedSchedule.bind_parameters() receives only kwargs, but this is not true. usually it receives *args and the method internally links the order of its parameter list and given *args. usually, user expects *args = (a, b, c) is (P0, P1, P2) and this is why parameter list is sorted.

Sorry, maybe I'm wrong.
https://github.com/Qiskit/qiskit-terra/blob/19f59c0a5537d6ca8cf6f9dd92104c23abb71120/qiskit/pulse/parser.py#L94-L96
parser sort the parameter list before passing it to ParametrizedSchedule. It means ParametrizedSchedule.parameters of u3 is always [P0, P1, P2] and we just need to remove sort from ParametrizedSchedule.

So did this fix things?

I tested above mentioned, but failed. Parser returns parameters in alphabetical order, but it sorts parameters contained in a single PulseQobjInstruction. In cmd_def case, multiple instruction with a single parameter P* compose ParametrizedPulse and thus parameter reorder at ParametrizedPulse level is still needed. I added unittest to ensure this.
https://github.com/Qiskit/qiskit-terra/blob/cc22c36bb0347a775f5f5bb3a5baab4a0a594d81/test/python/pulse/test_schedule.py#L368-L394
I keep the code unchanged and add this unittest and docstring for the constructor arguments.

Could this sorting be done at the building time (in defaults) rather than in ParameterizedSchedule itself.

I believe after my latest comment is addressed and conflicts are resolved we can move forward on this now.

@taalexander parameter order issue has been fixed by #3385 and now ParametrizedSchedule is only used when schedules are generated from Qobj. I think this PR can be closed because there is parameter sort for all inst maps (this PR is created for turning off the force sort to use the class for user defined schedule generators). how do you think?
https://github.com/Qiskit/qiskit-terra/blob/d710f2e4e2b16c80a5cbecd5b0125c9c6bd8d2e9/qiskit/pulse/schedule.py#L562


Develop

Before merge TODOs

Update PointCloudDataset and PointCloudInMemoryDataset to return a dictionary as done in ContactMapDataset.
Update aae.py training script to work with new SaveEmbeddingsCallback interface.
Update example_aae.py to work with new SaveEmbeddingsCallback and PointCloud Datasets.

Before merge TODOs

Update PointCloudDataset and PointCloudInMemoryDataset to return a dictionary as done in ContactMapDataset.
Update aae.py training script to work with new SaveEmbeddingsCallback interface.
Update example_aae.py to work with new SaveEmbeddingsCallback and PointCloud Datasets.


Hal serial

Add HAL serial implementation to the f3 crate.

@brandonedens @japaric
I tested your pull request and it works fine. I also refactored the examples to work (cf pull request #85).
Question: I noticed you have slightly changed the signature of the serial.init() function compared to the bluepill reference implementation. I found the second parameter missing which is usually p.AFIO. Is this intentional? Shouldn't be the signatures the same for all boards?


Implement tool for reading shares from YAML file

This PR implements SharesReader - the tool for reading the Share instances from the YAML file. This is needed because of an idea to store shares that will be used in the application, in a file which is more convenient in usage than simple static storage.

Codecov Report

Merging #26 (548861c) into master (d4aec5c) will increase coverage by 94.52%.
The diff coverage is 97.56%.

:exclamation: Current head 548861c differs from pull request most recent head dca09c1. Consider uploading reports for the commit dca09c1 to get more accurate results

Additional details and impacted files
@@              Coverage Diff              @@
##             master      #26       +/-   ##
=============================================
+ Coverage          0   94.52%   +94.52%
- Complexity        0      180      +180
=============================================
  Files             0       28       +28
  Lines             0      749      +749
  Branches          0       11       +11
=============================================
+ Hits              0      708      +708
- Misses            0       35       +35
- Partials          0        6        +6


Why scallop produce same transcript but with different gene id

Hi mingfu,
When I checking scallop output result, I found some transcript with all exon is same,but with different gene id. I don't know why produce duplicate transcript. For this case, how should I treat this case?
All best wishes,
xu

Hi Xu,
Is your sample strand-specific?
Could you show me the command line you run Scallop, and, if you saved the standard output , its first few lines (the preview line)?
Thanks,
Mingfu

Hi Mingfu,
My sample is strand-specific. This is my command line for assemble scallop -i R115Aligned.sortedByCoord.out.bam -o R115Aligned.sortedByCoord.out.bam_scallop.gtf --min_router_count 10

Also, please check reads with junctions in your .bam file: do they contain XS tag? And what aligner was used to generate the .bam file?

I check the bam file, they don't contain XS tag, I use STAR aligner to generate the bam file

If the bam file does not contain XS tag, scallop cannot infer the library type. In this case, you need to specify the library type in the command line. Please check the README::Usage, where there is a note about library type (I copied it below). Please try to rerun it with library_type specified.
===
--library_type is highly recommended to provide. The unstranded, first, and second correspond to fr-unstranded, fr-firststrand, and fr-secondstrand used in standard Illumina sequencing libraries. If none of them is given, i.e., it is empty by default, then Scallop will try to infer the library_type by itself (see --preview). Notice that such inference is based on the XS tag stored in the input bam file. If the input bam file do not contain XS tag, then it is essential to provide the library_type to Scallop. You can try --preview to see the inferred library_type.

Thank you very much, I will have a try

Please let us know whether that works. BTW, does the rnaseqtools::gtfformat solve the transcript-length issue?

Oh,sorry Mingfu
I forget tell you the questions about the length of transcript, I look at the gtfformat software, I found it can't solve my problem, the software select transcript length according to the here length is defined as the sum of the lengths of all exons in the transcript. My question is  artifactual fusion/chimeric transcripts that chain together multiple genes. Like below, three gene are assembled together, but the total exon length not very long

Hi Xu,
The current version of Scallop does not use the reference annotation, i.e., exons and junctions are exclusively extracted from reads. The 3 transcripts you show in the figure seems reasonable for me; they might be novel transcripts.
Thanks,
Mingfu

--library_type

Hi，mingfu
I want to know how to select the type.  I found some reverse complement sequence in the scallop result. I don't know how to solve it
Thanks
xizhe

Thank you for help.
1, Does your bam file contain XS tag (for reads with junctions)?
my bam file don't have XStag.(see attached) And my library type is unstrand.
2, The first 10 lines of scallop standard output, which contains the
inferred library_type by Scallop.
Scallop v0.10.3 (c) 2017 Mingfu Shao, Carl Kingsford, and Carnegie Mellon
University
command line: scallop -i fo-AF2_1filtered_sorted.bam -o fo-AF2_1.gtf
preview: reads = 379528, single = 0, paired = 379528, spliced reads =
40178, first = 40290, second = 40066, inferred library_type = unstranded,
given library_type = empty
Bundle 0: tid = 0, #hits = 21, #partial-exons = 1, range = 1:35172-35693,
orient = . (21, 0, 0)
process splice graph gene.0.0 type = 0, vertices =  it was also attched
below.3, edges = 2, phasing paths = 0
Bundle 1: tid = 0, #hits = 21, #partial-exons = 1, range = 1:35762-36075,
orient = . (21, 0, 0)
process splice graph gene.1.0 type = 0, vertices = 3, edges = 2, phasing
paths = 0
Bundle 2: tid = 0, #hits = 27, #partial-exons = 1, range = 1:36680-37608,
orient = . (27, 0, 0)
process splice graph gene.2.0 type = 0, vertices = 3, edges = 2, phasing
paths = 0
Bundle 3: tid = 0, #hits = 121, #partial-exons = 12, range = 1:35172-37984,
orient = - (79, 0, 42)
process splice graph gene.3.0 type = 0, vertices = 12, edges = 12, phasing
paths = 5
process splice graph gene.3.1 type = 1, vertices = 3, edges = 0, phasing
paths = 0
3, The assembled transcripts by Scallop which you have concern with.
see the attached
Best regards,
Xizhe
On Wed, Aug 28, 2019 at 12:35 AM Mingfu Shao<EMAIL_ADDRESS>wrote:

Hi Xizhe,
Could you provide me some more information:
1, Does your bam file contain XS tag (for reads with junctions)?
2, The first 10 lines of scallop standard output, which contains the
inferred library_type by Scallop.
3, The assembled transcripts by Scallop which you have concern with.
Thanks,
Mingfu
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Kingsford-Group/scallop/issues/20?email_source=notifications&email_token=ABARXUNH3EBXOHBBBRJHWALQGU3UVA5CNFSM4HYDZIKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5H6QPI#issuecomment-525330493,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABARXUIMJAUR6XU4UB3DLSDQGU3UVANCNFSM4HYDZIKA
.

fo-AF2_1filtered_sorted.bam
https://drive.google.com/file/d/1gJa-ogvMQWu_NXhpripGGEiZil2smn1k/view?usp=drive_web


Release process

Do you have any release process for generalimport? My guess is that it would be somehow coordinated with the rest of the ecosystem, so I'm curious how it works, if you have regular releases, and so on.
For us is relevant to decide when we can introduce generalimport to Haystack and how quickly we can expect bugfixes to be shipped, for example.

Simply put the current setup is pushing to master with a bumped version in metadata.json, which will upload to pypi and tag a new commit on github here
Magic happens here
So it should be quick to ship updates! I'm just a bit swamped atm but once I'll get to it, the workflow should be up and running and I'll keep the master branches clean from now on


fix(commands): add -root-dir flag

Seems like root was part of the config (at least in your nvim setup blog post) but it wasn't read and used in gnols. The change adds it as a field of BinManager so it can populate the -root-dir flag.
Also fix code-lens output commands, which were prefixed by the gno binary location, which is useless because it's already handled in gnols.test, and also erronous because it's used as an argument of gno test command.

Hey @jdkato can you have a look at this ?


[Synchronization] Fix Wasm mutex build

This change fixes the following build error happening on Wasm:
error: referencing instance method '_wait(expected:)' on 'Atomic' requires the types '_MutexHandle.State' and 'UInt32' be equivalent

@swift-ci test WebAssembly

@swift-ci smoke test

No problem at all :) Thank you for porting it to Wasm!


Security review PR - Collection of all "team project" feature related changes

Jira Ticket: VADC-951
New Features

"team project" based authorization, integrating with Gen3 Arborist. See also https://github.com/vinci-ohdsi/AtlasRoleConf/blob/601bd3c361dd38186d8246d8bd870146788480c2/README.md

Breaking Changes

none. The feature is activated through a new (optional) configuration option.

Bug Fixes

fixes an issue where sessions where unnecessarily stopped (https://github.com/uc-cdis/WebAPI/pull/107/commits/32e90bc0df31ab692c3167ec9c17ba500780821a)

Improvements

improves logging in various places by adding many .debug() calls (for DEBUG log level)

Dependency updates

the new feature depends on Arborist

Some comments will receive follow-up in new tickets.
The PR will be merged as part of https://github.com/uc-cdis/WebAPI/pull/101

@pieterlukasse  - I am done with my code review. Please note that I am not a security expert and I recommend that you have a security expert/group review the code after revision and perform the recommended security testing.

@rkboyce thanks for the review! I'm merging this PR into the pre_release/dev branch. New/extra changes will be made in follow-up PRs. I think the current PR is fine now, since remaining open comments are mostly about config options, default roles or reminder notes regarding future features like shared artifact owner/reader permissions. Let's revisit these in the next PR (if they are still applicable by then).


Hi CPU usage whilst coding with version 2.0.0

After upgrading .ignore plugin to version 2.0.0 I have found PHPStorm to be very sluggish.
As I type, the CPU spikes and there's a delay typing every character and a delay with autocomplete options being populated.
Disabling the .ignore plugin solves the issue.
These are my PHPStorm About details.
PhpStorm 2017.2
Build #PS-172.3317.83, built on July 18, 2017
JRE: 1.8.0_152-release-915-b5 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.8.0-58-generic

Let me know if there's more information I can provide.

Same on MacOS. I just uninstall because it makes intellij unusable.

@hsz same on 2.0.3, both PHPStorm and Gogland

Same for me, phpstorm is very laggy. Cpu hogs even if I don't type, it happens on some constant interval.

@vcraescu @radutopala @b1rdex  and this happens during the working with IDE (not for example indexing), right?

@hsz yes, there is problem after indexing finished.

@hsz yes, even after indexing finished. Not even touching the IDE and the CPU stays at ~120%.

Same problem on linux after last update. IDE became unusable. Uninstalled.

@courtney-miles @vcraescu @radutopala @b1rdex @alpham8 @BramDriesen
Can you please check if following build's stability is better?
idea-gitignore-2.0.3.zip

@hsz looks like problem fixed

I had the same issue using PyCharm: https://youtrack.jetbrains.com/issue/PY-25432
Tested the last build now works! :)


[card-pictogram]: screen reader output

Summary
On desktop when reading card-pictogram with VO. Tabbing will read just the heading text and then using down arrow key will read the copy, but when using left and right arrow keys it still will not read the copy.
On mobile with VO the heading and copy are all read at once.
Also, not seeing it read the pictogram label at all.
Browserstack screenreader only reads both heading and copy.
Wondering what info a user using VO should recieve from card-pictogram since it's slightly different from our other cards?
Relevant information
Previously, Ram has complained about cards being over verbose when reading heading and copy all at once
Name and organization
Carbon for IBM.com
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

Ask Michael Gower from A11y team for help with this one.

Met with a11y guild on May 5, 2022:
notes from guild:

Pictogram card shows a title, and then when hovered will expose more text/content
VO on mobile reads the title and the extra copy/content - Test has complained that is overly verbose
Reads as expected on desktop (heading - then arrow for more content
VO itself behaves differently (with "containers") on mobile vs desktop - so this is not a surprising interaction/response

Things to consider:

what is the pictogram providing?
how do we convey that they card should be hovered
and then if there is no pictogram at all then we wouldn’t have the hover interaction
also mobile completely remove the hover interaction and shows all info


test_hisi_hpre sing async mode performance is not stable

//async
test_hisi_hpre  rsa-sgn  --mode=crt --perf --trd_mode=async -t 1 --key_bits=2048
//sync
test_hisi_hpre  rsa-sgn  --mode=crt --perf --trd_mode=sync --key_bits=2048
sync:
23:<< sync 2 thread rsa-gen crt mode 2048 key_bits at 20899.988 ops!
45:<< sync 2 thread rsa-gen crt mode 2048 key_bits at 18341.109 ops!
67:<< sync 2 thread rsa-gen crt mode 2048 key_bits at 21087.043 ops!
89:<< sync 2 thread rsa-gen crt mode 2048 key_bits at 21136.064 ops!
111:<< sync 2 thread rsa-gen crt mode 2048 key_bits at 20772.770 ops!
async:
22:<< async 1 thread rsa-gen crt mode 2048 key_bits at 3570.233 ops!
43:<< async 1 thread rsa-gen crt mode 2048 key_bits at 58572.301 ops!
64:<< async 1 thread rsa-gen crt mode 2048 key_bits at 156542.062 ops!
85:<< async 1 thread rsa-gen crt mode 2048 key_bits at 4922.516 ops!
106:<< async 1 thread rsa-gen crt mode 2048 key_bits at 27717.783 ops!
async+bind:
numactl --cpubind=0 --membind=0 test_hisi_hpre  rsa-sgn  --mode=crt --perf --trd_mode=async -t 1 --key_bits=2048
linaro@ubuntu:~/test$ grep -rn "async 1 thread rsa-gen crt" log.2
22:<< async 1 thread rsa-gen crt mode 2048 key_bits at 6391.080 ops!
43:<< async 1 thread rsa-gen crt mode 2048 key_bits at 10102.447 ops!
64:<< async 1 thread rsa-gen crt mode 2048 key_bits at 18771.873 ops!
85:<< async 1 thread rsa-gen crt mode 2048 key_bits at 11188.066 ops!
106:<< async 1 thread rsa-gen crt mode 2048 key_bits at 8320.621 ops!
127:<< async 1 thread rsa-gen crt mode 2048 key_bits at 19878.707 ops!
148:<< async 1 thread rsa-gen crt mode 2048 key_bits at 6042.568 ops!
169:<< async 1 thread rsa-gen crt mode 2048 key_bits at 7707.399 ops!
190:<< async 1 thread rsa-gen crt mode 2048 key_bits at 1772.593 ops!
211:<< async 1 thread rsa-gen crt mode 2048 key_bits at 5408.329 ops!
232:<< async 1 thread rsa-gen crt mode 2048 key_bits at 4921.700 ops!
253:<< async 1 thread rsa-gen crt mode 2048 key_bits at 19461.562 ops!
274:<< async 1 thread rsa-gen crt mode 2048 key_bits at 17051.154 ops!
295:<< async 1 thread rsa-gen crt mode 2048 key_bits at 17449.238 ops!
316:<< async 1 thread rsa-gen crt mode 2048 key_bits at 4229.448 ops!
337:<< async 1 thread rsa-gen crt mode 2048 key_bits at 17965.992 ops!
358:<< async 1 thread rsa-gen crt mode 2048 key_bits at 19314.020 ops!
379:<< async 1 thread rsa-gen crt mode 2048 key_bits at 18230.029 ops!
400:<< async 1 thread rsa-gen crt mode 2048 key_bits at 4987.757 ops!
421:<< async 1 thread rsa-gen crt mode 2048 key_bits at 17950.393 ops!
442:<< async 1 thread rsa-gen crt mode 2048 key_bits at 18874.283 ops!
463:<< async 1 thread rsa-gen crt mode 2048 key_bits at 3388.029 ops!
484:<< async 1 thread rsa-gen crt mode 2048 key_bits at 120603.016 ops!
505:<< async 1 thread rsa-gen crt mode 2048 key_bits at 16211.062 ops!
526:<< async 1 thread rsa-gen crt mode 2048 key_bits at 21487.039 ops!
547:<< async 1 thread rsa-gen crt mode 2048 key_bits at 58381.984 ops!
568:<< async 1 thread rsa-gen crt mode 2048 key_bits at 10157.367 ops!
589:<< async 1 thread rsa-gen crt mode 2048 key_bits at 15453.960 ops!
610:<< async 1 thread rsa-gen crt mode 2048 key_bits at 5289.558 ops!
631:<< async 1 thread rsa-gen crt mode 2048 key_bits at 20218.229 ops!

https://github.com/Linaro/uadk/commit/b89d84109b3a893d05f96bbc21ecbf39bacdaa8d

Please also add versions of kernel, uadk, openssl-uadk. and hardware information like numa info

The root cause is poll thread using wd_rsa_poll_ctx trying to get any package,
which call driver->recv keep retying since -EAGAIN.
But recv fetch spin_lock, so send is impacted since competing spin_lock.
How to solve:
1, use semaphore, only calling  wd_rsa_poll_ctx after send.
This already exists in openssl-uadk, but uadk test application does not have, which we do not consider now.

Even after send, there is still some time required before receive.
Move spin_lock from rsa to  qm, make it smaller.

commit fa9ef2400cc2998ec60747f4f64a94b2ff5a49a3
Author: Zhangfei Gao<EMAIL_ADDRESS>Date:   Mon Apr 19 09:35:46 2021 +0000
wd_rsa: remove spin_lock since qm already has lock

In async mode, polling thread call wd_rsa_poll_ctx, which keeps
trying driver->recv, but always fail with -WD_EAGAIN, performance
may impacted if lock is hold at this time.

Signed-off-by: Haojian Zhuang<EMAIL_ADDRESS>Signed-off-by: Zhangfei Gao<EMAIL_ADDRESS>
commit 48d8d167949c0d16d4125a127f08ad89bf915975
Author: Haojian Zhuang<EMAIL_ADDRESS>Date:   Thu Apr 1 15:12:52 2021 +0800
hisi: qm: fix the lock in receiving operation

The lock actually need to protect more resources. Since there's another
lock in algorithm for synchronization mode, these resources are always
protected by lock in algorithm. Now fix it.

Signed-off-by: Haojian Zhuang<EMAIL_ADDRESS>


[stdlib] Add documentation for ===

This behavior is documented in Equatable, but it would help to have it documented here as well.

@gribozavr I've amended this to add the backticks. Thanks for reviewing

Ah ok, first time I've seen this. Thanks!


Upgrading from 417 > 418+ breaks proxy host for the NPM+ web panel

For a few months I hosted NPM on an RPi5, and recently I have been migrating all of my containers over to my x86 server PC. When I did so, I accidentally updated NPM+ to latest, up from v417 on Dockerhub. The only thing that appears to have broken is that previously I had a proxy host that went from https://npm.mydomain.tld/ to https://<IP_ADDRESS>:81, so that I could remotely access the webUI.
I use Cloudflare's tunnels and SSL, and my setup was working in v417, but updating to v418 irreversibly breaks it. Navigating to https://npm.mydomain.tld/ enters an infinite redirect loop. I can also confirm that the "Force HTTPS" option is disabled.
Even if I tear the container down and rebuild on v417, npmplus throws an error in the logs, which implies that the breaking change lives somewhere in my persistent data:
npmplus  | nginx: [emerg] open() "/usr/local/nginx/conf/conf.d/include/tls-ciphers-no-stapling.conf" failed (2: No such file or directory) in /data/nginx/default.conf:19 npmplus  | nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed
The only way I have gotten this to work again is by reverting to my original backup on v417.

yes downgrading is not supported. Can you please share the config file of the host redirecting in loop?


Scenes stay attached to an Act when the dropdown is changed

When I change the dropdown on the Scene page, to move it to a different Act, it moves to the new Act, but also mantains the relationship with the original Act.  So the Scene ends up in more than one Act.
If I close and reopen Obsidian, the extra links go away.
Carnivalle GA 1 - The Poster on the Tree.md
data.txt

Hi @vpaladino
Thanks for the report. I will look into it and write a fix

Hello!
Version 4.0 of RPG Manager has just been released. This is a complete re-writing of the plugin, and will impact all opened issues.
I am therefore closing this issue as it was related to v3.4 (now unsupported), but please feel free to re-open the task if the issue persists in the new version.
Ciao
Carlo


Not Working with react navigation 3

I am trying to use this drawer inside my application but i am using react-navigation version 3 and your drawer is no longer supported on v3

I think it is not related to react-navigation v3. I am using with v3 too, but I am not facing any problem.

This is what I'm getting while clicked on open drawer text

I think it is not related to react-navigation v3. I am using with v3 too, but I am not facing any problem.

could you please check the screenshot shared

Unfortunately I do not remember error like that and this screenshot is not enough to understand the error. Sharing your code would be better. Btw, I followed examples supplied in repo and used it similar to this code below.
import React, { Component } from 'react';
import { TouchableOpacity, View, Text } from 'react-native';
import ScalingDrawer from 'react-native-scaling-drawer';

let defaultScalingDrawerConfig = {
  scalingFactor: 0.6,
  minimizeFactor: 0.35,
  swipeOffset: 20
};

export default class Example extends Component {

  componentWillReceiveProps(nextProps) {
    /** Active Drawer Swipe **/
    if (nextProps.navigation.state.index === 0)
      this._drawer.blockSwipeAbleDrawer(false);

    if (nextProps.navigation.state.index === 0 && this.props.navigation.state.index === 0) {
      this._drawer.blockSwipeAbleDrawer(false);
      this._drawer.close();
    }

    /** Block Drawer Swipe **/
    if (nextProps.navigation.state.index > 0) {
      this._drawer.blockSwipeAbleDrawer(true);
    }
  }

  _openDrawer = () => {
    this._drawer.open()
   }

  render() {
    return (
      <ScalingDrawer
          ref={ref => this._drawer = ref}
          content={<YourCustomMenuPage />}
          {...defaultScalingDrawerConfig}
          position="right"
          frontStyle={{
            flex: 1
          }}
          >
           <View style={{ flex:1, alignContent: 'center', justifyContent: 'center' }}>
                 <TouchableOpacity onPress={() => this._openDrawer()} >
                      <Text>Open Drawer</Text>
                 </TouchableOpacity>
           </View>
       </ScalingDrawer>
    )
  }
}

import React, { Component } from 'react';
import { View, StyleSheet, TouchableOpacity, Text } from 'react-native';
import { drawer } from "../App";
class Home extends Component {
render() {
return (

<TouchableOpacity style={{flex:1}} onPress={() => drawer.current.open()}>
OPEN DRAWER

);
}
}
export default Home;
const styles = StyleSheet.create({
container: {
flex: 1,
backgroundColor: 'red'
}
});

import React, { Component, createRef } from 'react';
import { createStackNavigator,createAppContainer } from 'react-navigation';
import ScalingDrawer from 'react-native-scaling-drawer';
import NavigationService from './NavigationService';
import Home from './screens/Home';import Profile from './screens/Profile';import LeftMenu from './LeftMenu';
const AppStack = createStackNavigator({
Home: {
screen: Home
},
Profile: {
screen: Profile
}
});
export const drawer = createRef();
const defaultScalingDrawerConfig = {
scalingFactor: 0.7,
minimizeFactor: 0.4,
swipeOffset: 20
};
class AppNavigation extends Component {
render() {
return (
<ScalingDrawer
ref={drawer}
content={}
{...defaultScalingDrawerConfig}
onClose={() => console.log('close')}
onOpen={() => console.log('open')}
>
<AppStack
ref={navigatorRef => {
NavigationService.setTopLevelNavigator(navigatorRef);
}}
/>

);
}
}
export default createAppContainer(AppStack);

Unfortunately I do not remember error like that and this screenshot is not enough to understand the error. Sharing your code would be better. Btw, I followed examples supplied in repo and used it similar to this code below.
import React, { Component } from 'react';
import { TouchableOpacity, View, Text } from 'react-native';
import ScalingDrawer from 'react-native-scaling-drawer';

let defaultScalingDrawerConfig = {
  scalingFactor: 0.6,
  minimizeFactor: 0.35,
  swipeOffset: 20
};

export default class Example extends Component {

  componentWillReceiveProps(nextProps) {
    /** Active Drawer Swipe **/
    if (nextProps.navigation.state.index === 0)
      this._drawer.blockSwipeAbleDrawer(false);

    if (nextProps.navigation.state.index === 0 && this.props.navigation.state.index === 0) {
      this._drawer.blockSwipeAbleDrawer(false);
      this._drawer.close();
    }

    /** Block Drawer Swipe **/
    if (nextProps.navigation.state.index > 0) {
      this._drawer.blockSwipeAbleDrawer(true);
    }
  }

  _openDrawer = () => {
    this._drawer.open()
   }

  render() {
    return (
      <ScalingDrawer
          ref={ref => this._drawer = ref}
          content={<YourCustomMenuPage />}
          {...defaultScalingDrawerConfig}
          position="right"
          frontStyle={{
            flex: 1
          }}
          >
           <View style={{ flex:1, alignContent: 'center', justifyContent: 'center' }}>
                 <TouchableOpacity onPress={() => this._openDrawer()} >
                      <Text>Open Drawer</Text>
                 </TouchableOpacity>
           </View>
       </ScalingDrawer>
    )
  }
}

Could you please check where I'm going wrong

Unfortunately I do not remember error like that and this screenshot is not enough to understand the error. Sharing your code would be better. Btw, I followed examples supplied in repo and used it similar to this code below.
import React, { Component } from 'react';
import { TouchableOpacity, View, Text } from 'react-native';
import ScalingDrawer from 'react-native-scaling-drawer';

let defaultScalingDrawerConfig = {
  scalingFactor: 0.6,
  minimizeFactor: 0.35,
  swipeOffset: 20
};

export default class Example extends Component {

  componentWillReceiveProps(nextProps) {
    /** Active Drawer Swipe **/
    if (nextProps.navigation.state.index === 0)
      this._drawer.blockSwipeAbleDrawer(false);

    if (nextProps.navigation.state.index === 0 && this.props.navigation.state.index === 0) {
      this._drawer.blockSwipeAbleDrawer(false);
      this._drawer.close();
    }

    /** Block Drawer Swipe **/
    if (nextProps.navigation.state.index > 0) {
      this._drawer.blockSwipeAbleDrawer(true);
    }
  }

  _openDrawer = () => {
    this._drawer.open()
   }

  render() {
    return (
      <ScalingDrawer
          ref={ref => this._drawer = ref}
          content={<YourCustomMenuPage />}
          {...defaultScalingDrawerConfig}
          position="right"
          frontStyle={{
            flex: 1
          }}
          >
           <View style={{ flex:1, alignContent: 'center', justifyContent: 'center' }}>
                 <TouchableOpacity onPress={() => this._openDrawer()} >
                      <Text>Open Drawer</Text>
                 </TouchableOpacity>
           </View>
       </ScalingDrawer>
    )
  }
}

Could you please check where I'm going wrong

Your settings are good, but there is no page data you want to show. So the price is null.


UI: project overview

See Issue #48.
Todo
Setup

[x] Create React Project
[x] Add basic login form with some interactivity (for learning)
[x] Add basic routing
[x] Create Docker image for deployment

Create Project Overview page

[ ] Create Menubar as react component
[ ] Create Project Card as react component
[ ] Dynamically display project Cards based on some mock data.
[ ] Add API client to retrieve project data
[ ] Populate project overview using data retrieved from the API

Mounting the frontend dir does not work without yarn setup.
Issue described (here)[https://stackoverflow.com/questions/30043872/docker-compose-node-modules-not-present-in-a-volume-after-npm-install-succeeds], none of the described solutions work for me though.


Kansas - UP Migration - Move to Production

User Story:
As a developer, I want to move the Kansas settings to production after getting approval from the STLT, so that they can start receiving live data.
Description/Use Case
Kansas is already receiving data from the covid pipeline they will be onboarded to the UP where they will be receiving data from SimpleReport including Covid, Flu and RSV. We need to make sure the message we generate from the UP passes the STLTs validation. We can use SimpleReport to submit test messages to the STLT.
Risks/Impacts/Considerations
Dev Notes:

[ ] Upload the staging receiver settings to Production
[ ] Copy the receiver's secret key with the new receiver name in Azure's production environment
[ ] Verify we can connect to the newly created receiver
[ ] Monitor the UP data for the conditions the receiver is interested in and notify them when reports are routed to them
[ ] Send a test message through Simple Report and make sure it gets routed to the STLT
[ ] Send test messages according to the STLT needs

Acceptance Criteria

[ ] Receiver UP settings are pushed to production
[ ] ReportStream can connect to STLT in production
[ ] Notify Kansas when reports are routed to them for each condition they are receiving

Done


[help] Ping errors

Thanks for your effort and the code.
A few days ago I set up the bot and run it successfully. Everything was working correctly.
A few moments earlier I noticed that the bot is not working. I tried to run the code but it seems that something is not working correctly.
Let's see what happens after running the code, I see this:
✅ Connected to session for UID: xxxxxxx
Then, I see Ping errors. You can see one of them here:
❌ Ping error: Ping request failed 2024-11-29T16:32:23.475Z [error]: Ping error {"error":"Ping request failed"}
Please advise me.

same here, all finw till around 1 hour ago

Same


Remove Java 7 dependency for application runtime (not for asset pre-processing)

Not sure if this is issue should be in grails-asset-pipeline or  asset-pipeline-core.
See there: https://github.com/bertramdev/asset-pipeline/issues/79

file scanning needs this for glob patterns


Remove cached property and chain tests

This fixes the existing tests in https://github.com/napari/napari/pull/6536 by making _is_diagonal a property rather than a cached_property.
It also adds some tests to cover the cache invalidation logic for transform chains.
And fixes a few typos.

FYI, I can't merge on your fork, so feel free to do that or copy some of the changes here into https://github.com/napari/napari/pull/6536