Backstage Auth (Microsoft) Error: Failed to sign-in, unable to resolve user identity

📜 Description
I'm trying to setup Azure AD Auth (Microsoft) for backstage, though after countless hours reading thru docs and experimenting, I'm still unable to get it to work. The error that I'm running into is:
Failed to sign-in, unable to resolve user identity

👍 Expected behavior
From the debug logs the msgraghorg is finding the group.
Committed 0 msgraph users and 2 msgraph groups in 0.0 seconds.
If might be that its not pulling the members from it.
I'm using a Security group called Backstage Users in Azure which the the user is apart of. And following the docs have ensure that app registration has correct permissions.
https://backstage.io/docs/auth/microsoft/provider/#configure-app-registration-on-azure
https://backstage.io/docs/integrations/azure/org/#app-registration
👎 Actual Behavior with Screenshots

👟 Reproduction steps
# app-config.local.yaml
auth:
  environment: development
  providers:
    microsoft:
      development:
        clientId: **REDACTED**
        clientSecret: **REDACTED**
        tenantId: **REDACTED**
        domainHint: **REDACTED**
        signIn:
          resolvers:
            - resolver: emailMatchingUserEntityAnnotation
            - resolver: emailMatchingUserEntityProfileEmail
            - resolver: emailLocalPartMatchingUserEntityName

catalog:
  providers:
    microsoftGraphOrg:
      default:
          clientId: **REDACTED**
          clientSecret: **REDACTED**
          tenantId: **REDACTED**
          user:
            filter: accountEnabled eq true and userType eq 'member'
          group:
            filter: >
              displayName eq '**REDACTED**'
          schedule:
            frequency: PT1H
            timeout: PT50M
            retry: PT5M

# Backstage/sec/index.ts
// ...
backend.add(import('@backstage/plugin-app-backend/alpha'));
backend.add(import('@backstage/plugin-proxy-backend/alpha'));
backend.add(import('@backstage/plugin-scaffolder-backend/alpha'));
backend.add(import('@backstage/plugin-techdocs-backend/alpha'));

// auth plugin
backend.add(import('@backstage/plugin-auth-backend'));
// See https://backstage.io/docs/backend-system/building-backends/migrating#the-auth-plugin
backend.add(import('@backstage/plugin-auth-backend-module-guest-provider'));
backend.add(import('@backstage/plugin-auth-backend-module-microsoft-provider'));
// See https://backstage.io/docs/auth/guest/provider

// catalog plugin
backend.add(import('@backstage/plugin-catalog-backend-module-msgraph/alpha'));
backend.add(import('@backstage/plugin-catalog-backend/alpha'));
backend.add(
  import('@backstage/plugin-catalog-backend-module-scaffolder-entity-model'),
);

// permission plugin
backend.add(import('@backstage/plugin-permission-backend/alpha'));
backend.add(import('@backstage/plugin-permission-backend-module-allow-all-policy'));

// search plugin
backend.add(import('@backstage/plugin-search-backend/alpha'));
backend.add(import('@backstage/plugin-search-backend-module-catalog/alpha'));
backend.add(import('@backstage/plugin-search-backend-module-techdocs/alpha'));
// ...

All other configs are set and default and has not been changed.
Following -
https://backstage.io/docs/backend-system/building-backends/migrating/
https://backstage.io/docs/integrations/azure/org
📃 Provide the context for the Bug.
Any Help would be great as the docs are still a bit confusing with the backend migration causing a bit of a mess. I understand that the team is still working on perfecting the docs and pouring and sweat and tears with the community on updating them.  Happy to assist with updating the docs to make a more clear path with authentication and azure integration.
🖥 Your Environment
No response
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

I am sure that you are not interested in disabling the authentication but just to check that its just an authentication issue, you can disable the authentication like documented here, https://backstage.io/docs/tutorials/auth-service-migration#disabling-the-default-auth-policy
I think your issue is related to this one https://github.com/backstage/backstage/issues/24569

It looks like there's no users being ingested which would probably lead to this issue that you're seeing.

Committed 0 msgraph users and 2 msgraph groups in 0.0 seconds.

@GuptaNavdeep1983  Yes that does work. I can also use guest access with no issues.
  components: {
    SignInPage: props => (
      <SignInPage
        {...props}
        providers={[
          'guest',
          {
            id: 'microsoft-auth-provider',
            title: 'Microsoft',
            message: 'Sign in using Microsoft',
            apiRef: microsoftAuthApiRef,
          }
        ]}
      />
    ),
  },

Yeah you might be right with it not pulling any users @benjdlambert. Though I'm following whats the docs are saying to use
https://backstage.io/docs/integrations/azure/org/#customizing-transformation
and if even I query the users directly it doesn't work.
         user:
           filter: displayName eq 'Backstage'

Confirmed that it works fine though on msgragh explorer
https://developer.microsoft.com/en-us/graph/graph-explorer
Any ideas if I'm doing the query wrong in the yaml configs?

We are experiencing the same problem, and currently only getting this to work with a custom resolver also.
But, doing so without the isUserInBackstageGroup step aswell.
Would much rather use the builtin resolver and msgraph integration

So to clarify you should be able to use the built-in resolvers if the users are in the catalog, so it looks like there's something gone wrong here and the users aren't in the catalog. Have the users been in the catalog before and then on upgrading they're no longer being populated? I think we're going to need some help from the community here to understand what's going on with msgraph and why it's not ingesting users properly, if it's something that's been broken in the code we own, or if something else has changed.

I am experiencing the same issue.

@pjungermann can you take a look at some of the config here and maybe help troubleshoot why we can't get any users in the catalog from the msgraphProvider :pray:

We have it in place with built-in resolvers on the latest release version, and it works just fine. Ingestion of users as well as sign in.
I agree with @benjdlambert that the underlying issue is that no user gets ingested. At least for the author of this issue and based on the details and logs shared above.
The easiest way without debugging the code is to try calling the Graph API directly using the same credentials and query. Also, ensure that you use the same query mode, etc.
I see that you use query mode basic. E.g., our user.filter requires query mode advanced.
You could also check with the yaml reader like yq whether the value is as you intended.
I'm not sure whether the user.filter is the same in your actual setup.
It doesn't seem like you have a custom transformer that might cause user entities to get invalid, etc.

I DID IT!!!!
Soooo for everyone facing the issue, after a couple of hours of debugging here's what you need to do. @pjungermann was right with there technically not being anything wrong with the code. It's more of a config issue that isn't very well documented, which is understandable with the team trying to update all the docs for the new backend.
Basically the defaultUserTransformer() Function needs three parameters from a users in msgragh to be enter in as a catalog user in backstage, which is: ID, DisplayName, & Mail. Mail is the key point that you need to add to your select config, that is missing from the docs.
[...]
        queryMode: advanced
        user:
          filter: displayName eq '**User***'
          loadPhotos: true
          select: ['id', 'displayName', 'mail']
        schedule:
          frequency: PT1H
          timeout: PT3M
[...]

You also need to make sure that in azure that your user has the Email Parameter set. Which if your creating a cloud user usually has to be done manually and isn't auto populated like the User principal name. The reason why backstage doesn't pull the User principal name instead of the email parameter is bc the User principal name isn't always going to a email in some rare cases. You can change this manually function to use the User principal name instead of the email. We could also make a PR to add to the function to pickup if the email if Null and the User principal name is a email to use User principal name instead.

Amazing @guppyfish123! 👏
Closing the issue, feel free to re-open it in case more help is needed. 🙏

Just to clarify here:
It is only necessary to make changes in the app-config.yaml?
My app-config.yaml
    catalog:
      providers:
        microsoftGraphOrg:
          providerId:
              target: https://graph.microsoft.com/v1.0
              authority: https://login.microsoftonline.com
              clientId: ${AZURE_CLIENT_ID}
              clientSecret: ${AZURE_CLIENT_SECRET}
              tenantId: ${AZURE_TENANT_ID}
              queryMode: advanced
              user:
                filter: displayName eq '**Users**'
                loadPhotos: true
                select: ['id', 'displayName', 'mail']
              schedule:
                frequency: PT1H
                timeout: PT3M

Or are there also changes needed in the backend?

Hello,
I dont know it is the best way to solve, but in my case, the users in the Azure does not have the  mail field filed, so I  used transformer (https://backstage.io/docs/integrations/azure/org#using-custom-transformers) and i added the line below:
graphUser.mail = graphUser.mail || graphUser.userPrincipalName;

The final code block:
export async function myUserTransformer(

  graphUser: MicrosoftGraph.User,
  userPhoto?: string,
): Promise<UserEntity | undefined> {

  graphUser.mail = graphUser.mail || graphUser.userPrincipalName;

  const backstageUser = await defaultUserTransformer(graphUser, userPhoto);

  if (backstageUser) {
    backstageUser.metadata.description = 'Loaded from Microsoft Entra ID';

  }

  return backstageUser;
}

The solution was based in the @guppyfish123 post about defaultUserTransformer parameters. Thank you all


Added notes for Jan 2021 API design review.

This PR adds notes from the January 7, 2021 Q# API Review meeting.

/azp run

/azp run

/azp run

/azp run


Add support for renaming a property/attribute

Doing this right, for properties at least, will involve integrating with a javascript static analyzer.

Re-opening because this original issue is now transferred and canonical again.


segfault on intel mac

bash-3.2$ kubexporter
Segmentation fault: 11
Darwin ShaneStarcher 22.6.0 Darwin Kernel Version 22.6.0: Fri Sep 15 13:39:52 PDT 2023; root:xnu-87<IP_ADDRESS>0.8~1/RELEASE_X86_64 x86_64 i386 Darwin
Ran from https://github.com/bakito/kubexporter/releases/download/v0.5.2/kubexporter_0.5.2_darwin_amd64.tar.gz

I built from source and it works fine

@sstarcher the reason for this could be that the binary is compressed with https://github.com/upx/upx
I'll make a new, uncompressed release.

can you check with https://github.com/bakito/kubexporter/releases/tag/v0.5.3 ?

That version works for me


ci: automated jira issue creation workflow

Summary
Sets up automated jira tickets creation for new issues to help triage system.

Nice! Thanks John!

@jooohhn We've been getting a significant amount of issues filed that are just related to not following the installing steps correctly.  Do we care about creating a jira ticket for tickets that don't require any work other than commenting?  Is it possible to change this action to only occour when a certain label is added?

@kelsonpw SDK has a weekly oncall person, for simple tickets they'll close them out. I think because we prefer the oncall closing easier tickets rather than letting an important one slip unnonticed

@jooohhn makes sense, this is good to go!


Dead project?

Just wanted to get someone to reply here as to whether or not the project is simply on hold or has shut down.
Whatever the case, this program still works great on both my Win7-86 and Win10-64 machines despite some minor issues (some detailed here on Github).  I love it, I've donated in the past, and would certainly donate in the future.

Not dead - just an extended rest. I don't have time to work on it. But i'd like to - I still use the program at work. Perhaps in a few months I'd like to at least clean up the issues.

Just want to add that I completely understand time limitations, and if you can't do it you can't do it, but I also would like to say that AutoVer is the only program I've been able to find, searching here and there for the past several years, that does what it does, so it would be great if you were able to keep working on it. I wouldn't doubt you could even make money off of licensing it if that's what it took. It basically does what Windows' File History should do, and it could be so much better with some additional options and tweaks.

Just want to add that I completely understand time limitations, and if you can't do it you can't do it, but I also would like to say that AutoVer is the only program I've been able to find, searching here and there for the past several years, that does what it does, so it would be great if you were able to keep working on it. I wouldn't doubt you could even make money off of licensing it if that's what it took. It basically does what Windows' File History should do, and it could be so much better with some additional options and tweaks.


audio: Better calculation for buffer size on browsers

audio/buffersize_js.go

Oto fixed this (see https://github.com/hajimehoshi/oto/issues/32)


Buildroot update: UX review and polish

overview
This ticket is for tracking a UX review of the buildroot update front-end flow once we have an MVP implemented.
flows

[x] Migration from Balena to buildroot via automatic app download
[x] Migration from Balena to buildroot via manual file upload
[x] Regular buildroot upgrade
[x] Regular buildroot downgrade
[x] Regular buildroot re-install
[x] Re-evaluation of app update available logic

Closed via meeting/discussion between stakeholders.
TODO: unify all restart flows within wizards in the run app.


gocryptfs: 1.6.1 -> 1.7

Notes for a future gocryptfs updates

Delete fix-unix2syscall_darwin.go-build-failure.patch
Delete patches within default.nix

Motivation for this change
Just a minor package version update.
By the way, I haven't worked with go packages before.
This thing with deps2nix is for a noob as me a bit complicated to just update a package.
Not jet tested, as I still have not a practicable workflow for this here on my side.
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

@worldofpeace: Hello, as you're the one who have merged the last gocryptfs update,
I kindly ask if you wanna have a look on my PR.

@GrahamcOfBorg build gocryptfs

@GrahamcOfBorg build gocryptfs
building again for darwin

I'm generating a different deps.nix locally.
The process I've done to do this was
1. checkout `gocryptfs` repo locally

2. `$ git checkout v1.7`

3. `$ dep2nix`

Here's a gist of the diff
Additionally the build fails on darwin.
This patch upstream should fix this rfjakob/gocryptfs@b1468a7 (please use fetchpatch in patches)

Thx.
About the deps.nix I did it on the latest commit (forgot checking out v1.7).
And I'm not sure if the thing with the patches I did now is right?

@GrahamcOfBorg build gocryptfs

@GrahamcOfBorg build gocryptfs

I'm exited. There was a lot I've learned until now in this little update.
@worldofpeace: Thank you very much for your assistance.

I'm exited. There was a lot I've learned until now in this little update.
@worldofpeace: Thank you very much for your assistance.

I'm glad you're excited. It's a secret that most nixpkgs reviewers are little mentors :smile:
In the push I fixed a little tricky thing where we have to manually update the sys module
to have that fix, since the bug came from there.

This pull request has been mentioned on Nix community. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/33

@cw789 I can merge this is just needs to be squashed into one commit

@cw789 I think the best way to deal with "on next update do xyz" type of comments is to put them on the version line. People are unlikely to read all comments in a file on every update, but its hard to miss the one one the version line. Even if the updater misses it, it will show up in the diff for the reviewer.
Doesn't matter in this case, since the patch will fail to apply on update anyway. Just general advice for the future.

@timokau: Thank you, for this advice.
@worldofpeace: I think I've made it.

@cw789 Thanks for doing this :sparkles:


Profile Panel Thingy broken with Vencord's Toggle Game Activity plugin

Would a fix for this be possible?
Thanks!

Fixed, thanks!


Unable to Edit or Remove Custom Tile

Per the instructions on this page to Edit or Delete a Custom Tile, I should
"On the Organization profile page, next to Add custom tiles for your organization, select Edit."
I do not see Edit option, I only see Add Custom Tile.
Also, do not see where I have the ability to delete a custom tile.
Thank you!

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

ID: 9488caf7-b791-3002-8749-7fdc4b2ec8b3
Version Independent ID: 08e61eb0-7bcd-f449-46ef-17e209138a8e
Content: Add custom tiles to the app launcher - Microsoft 365 admin
Content Source: microsoft-365/admin/manage/customize-the-app-launcher.md
Service: o365-administration
GitHub Login: @twernermsft
Microsoft Alias: twerner

@tnordin Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/7036
The Edit custom tile option is available when you select Custom app launcher tiles-->Click on the three dots next to the tile that you want to edit.

Thanks
Sri

@msbemba Thank you very much for the contribution and updating the documentation with PR. @tnordin Hope this update is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


enable acpi.ec_no_wakeup in Thinkpad T14 AMD Gen 5

Description of changes
This PR should remove constant battery drain specific to this device (and others, but I only have this one to test) as suggested in e.g.

https://bbs.archlinux.org/viewtopic.php?id=298895
https://bbs.archlinux.org/viewtopic.php?id=234913

Things done

[x] Tested the changes in your own NixOS Configuration (https://github.com/kowale/homelab/commit/a46e5dea72e70b5d65e9956993947a5c624040c0#diff-37d03cb9538bb32044b321a8a2cad7aafe9ec114d6b9f83e1d40e917edcc14f4R46 is working on my machine. Before this commit, I had to keep my laptop charging at all times, as it would drain in a few hours, even on suspend, unless fully shutdown. After this commit, I can leave my laptop with its lid closed for 10 hours at the expense of about 4% of battery!)
[x] Tested the changes end-to-end by using your fork of nixos-hardware (I was already using this nixos-hardware input in my config, so counting this as done, as it should be identical, right?)

I see the tests are failing for

x86_64-linux.nixos-stable-focus-m2-gen1
x86_64-linux.nixos-unstable-focus-m2-gen1

but these don't seem related. Flaky tests?


completes quiz but did not have time to test

5/6
Great job. You'll get more of a feel for what these Activerecord methods return as we dive more into rails


feat: Storage overlay

Closes #1106
Introduces the ability to define a second fallback storage driver via a configurable circuit breaker pattern:
storage:
  driver: "overlay"
  overlay:
    baseDriver: postgres
    fallbackDriver: disk
    fallbackErrorThreshold: 1 # number of errors allowed within the fallbackErrorWindow before failover occurs
    fallbackErrorWindow: 1s # the rolling window in which errors are aggregated
  disk:
    directory: policies
    watchForChanges: true
  postgres:
    url: "postgres://${PG_USER}:${PG_PASSWORD}@localhost:5432/postgres?sslmode=disable&search_path=cerbos"

I wasn't sure if this was a feat or an enhancement - can change.

Realised whilst raising PR that I need to add documentation - I'll get this done tomorrow morning.

Aaah, I was getting a bit muddled about how updates to the underlying SourceStores would propagate to the PolicyLoaders (e.g. polling for updates to git/blob storage etc), but on further reading, it seems that this'll all be handled per store in the background via subscriptions, and therefore GetPolicySet will always reflect up to date store state? If so, that all makes sense!
On that, would it not still make sense to implement the Reloadable interface? We don't support mutable ops, but if we already support updates via polling, it doesn't seem unreasonable to expose this manual trigger?

Therefore, you only need to have two struct fields of type BinaryStore instead of the four that it has now.

I think we'll still need to maintain the four struct fields (two Stores and two PolicyLoaders), because there's a chicken-egg situation whereby the schemaMgr expects a Store implementation, but then is required by the compilation.Manager to build the PolicyLoader. I'm not sure how to solve that tidily without separately instantiating the stores and the policy loaders in two stages.

I've addressed most of the smaller review items but I've left the Reloadable interface in there for now until the need is clarified.


Enable WalletConnect on EWC

WalletConnect supports EWC and Volta thanks to Nico: https://github.com/WalletConnect/walletconnect-monorepo/commit/2da7703616b40d5d9421267c51c18dc5aa3834d7
We have WalletConnect enabled on Volta, but not on EWC.
-> Please enable WalletConnect also on EWC/

@matextrem @tschubotz double check if this is really working on Volta, first.
In case it doesn't work, please add the reason here, but let's not spend much time on this yet.

@matextrem I just tested with Metamask mobile and I could create a Safe and make a Safe tx: https://volta.gnosis-safe.io/app/#/safes/0xba132fe57Af98d4B426Ae5A408aa99e9965589a4/transactions
So seems to work.
Volta RPC can be found here: https://energyweb.atlassian.net/wiki/spaces/EWF/pages/703201459/Volta+Connecting+to+Remote+RPC+and+Metamask
fyi @dasanra


Add elm-community/linear-algebra to native whitelist.

This is a new name for elm-community/elm-linear-algebra which we will soon mark as "deprecated".
See https://github.com/elm-community/elm-linear-algebra/issues/12

@evancz, it would be nice to have this merged and live, so that the elm-community stuff can move forward.


Local Pessimistic Proofs and Cross-Chain Consistency Checks

[DRAFT]
I'd like to propose a change to how we calculate the pessimistic proof (this was largely inspired by Carlos Matallana's idea to generate local pessimistic proofs) that is designed to achieve the following:

Allow each chain to compute the pessimistic proof entirely locally.
Make computing the pessimistic proof more efficient.
Effectively get asynchronous cross-chain interop checks for free, and synchronous with a small change to the bridge smart contract and zkEVM prover.

(1) is very important because it removes complexity from the agglayer. The agglayer no longer needs to compute local balance trees for all chains at each epoch. We can calculate pessimistic proofs per chain and simplify the recursive aggregation step to combine these proofs before settlement to Ethereum. Generating per-chain pessimistic proofs without relying on global state also makes individually settling / force-including chains on L1 much simpler
The proposed scheme was described in more detail here: https://hackmd.io/YZ-AeAR2QXS4e_wOYD6NBQ but the basic intuition is that right now we're proving the statement: for each chain X, the pessimistic proof guarantees that after applying every asset transfer in every LET to X, its token balances are {b_i} where b_i are (token_address, balance) pairs.
This is actually a stronger statement than we need to prove. It suffices to show that for all chains X_j the balances b_{j,i} are non-negative after applying some subset of all asset transfers with destination chain X_j.
To give an example, suppose that there's some shitchain spamming tokens and making giant LETs depositing to many chains. Right now, the pessimistic proof needs to calculate the impact on every single chain, even when these tokens won't be claimed on nearly any of these chains, because the spammer cannot pay tx fees. Instead, the pessimistic proof should only apply asset transfers to destination chains when those transfers are claimed. Since each destination chain has the claim data available, pessimistic proofs can be computed entirely locally.
Here's some pseudo-code for the local version of the pessimistic proof (forgive me, I haven't written code in like 3 years, please don't hesitate to change while implementing):
pub struct Claim {
  pub sending_chain: ChainId
  pub local_exit_root: LocalExitRoot
  pub merkle_path: LocalExitTreePath /// Inclusion proof in a LocalExitTree
  pub token_info: TokenInfo
  pub token_amount: u256
}

pub struct NullifierSet<Hasher> { /// Hasher should be AFH, though maybe keccak for prototyping
  pub chain: ChainId /// The chain that is maintaining this nullifier set
  pub claim_bit_mask: HashMap<ChainId, ClaimBitMask> /// The claim bit mask is a data structure that maps each index of an external LocalExitTree to 1 if an asset transfer has been claimed at that position, and 0 otherwise.

  pub root: NullifierSetRoot /// Really just a u256 or vec of field elements I believe
}

/// I know that we're implementing this differently w/ FullProofOutput as a generic - this is just to illustrate
pub struct PessimisticProof {
  /// Private/Non-Deterministic inputs
  pub claims: Vec<Claim>
  pub withdrawals: Vec<Withdrawal>
  pub local_balance_tree: LocalBalanceTree<Hasher>
  pub nullifier_set: NullifierSet<Hasher>

  ///Public Inputs
  pub batch: Batch
  pub local_exit_root: LocalExitRoot /// This is the local exit root for the chain generating the pessimistic proof (PP chain), generated after the latest batch
  pub local_balance_tree_root: BalanceTreeRoot /// The local balance tree root for the PP chain
  pub nullifier_set_root: NullifierSetRoot /// The nullifier set root for the PP chain
  pub claimed_local_exit_roots: Vec<LocalExitRoot> /// Vec of all LocalExitRoots included in claims
}

Going to clean this up later, but for now, the idea is that the pessimistic proof first applies all claims that are provided by the PP chain (the chain generating the proof) to the Local Balance Tree. Ie something like (I've forgotten how to write Rust):
claims.iter().map(|claim|
  /// Need to verify that:
  /// - each asset transfer is currently unclaimed in the nullifier set
  /// - that the claim's merkle path is correct and matches the claim's LocalExitRoot
  /// - that the claim's destination chain ID matches the PP Chain's Chain ID
  local_balance_tree.apply_claim(claim) /// Adds the amount of tokens in the claim to the local balance tree
  /// Then we update the nullifier set to record each claim
)

/// We verify that the calculated Nullfier Set Root is consistent with nullifier_set_root included as a public input

/// We map claims to a vector of local_exit_roots included in each claim and then verify that this vector matches the public input
/// claimed_local_exit_roots

From here, we can infer from the batch the previous frontier of the PP chain's local exit tree, and then extract all new asset_transfers included in the PP chains local exit tree. We then deduct each asset transfer from the chain's local balance tree.
/// Need to first verify that the set of withdrawals is consistent with the updated LocalExitRoot included as a public input
withdrawals.iter().map(|withdrawal|
  local_balance_tree.apply_withdrawal(withdrawal) /// Deducts the withdrawal from the local balance tree
)
/// Alternatively we could calculate aggregate withdrawals for each token and apply them to the local balance tree
/// We verify that the calculated LocalBalanceRoot matches local_balance_root

Now we have a locally-generated pessimistic proof, but we still have to verify that claimed_local_exit_roots are valid. This can be done by the agglayer. The Agglayer can recursively aggregate all locally-generated pessimistic proofs and merge the set of claimed_local_exit_roots, before verifying that each is valid as part of the final proof step.
The nice thing is that this is the cross-chain consistency / interop proof. We allow chains to cryptographically guarantee that they cannot depend on invalid or inconsistent LERs. To guarantee this property for synchronous message passing, we can modify the bridge contract, as described here: https://hackmd.io/Cn5NqzC2TJ6dVg9AtmFOUw

Great writeup and this meets my intuitions based upon the discussions with Carlos, Jesus, and shared sequencing teams.
Question: what DA guarantees do we need for the agglayer to verify that the claimed_local_exit_roots are valid?

PP pseudo-code

I have written a pseudo-code of the steps that the PP needs to do --> https://hackmd.io/eJUpSKhkQHudBS48BEXrow?view#Pseudo-code

Seems pretty much aligned with yours @bpfarmer , expect for the claimed_local_exit_roots or the selectedGER.

There is a glossary at the beginning of the doc, https://hackmd.io/eJUpSKhkQHudBS48BEXrow?view#Glossary, just if any naming is different xD

pseudo-code:

// public inputs
const oldLER
const oldLBR
const oldNullifierRoot

const hashBridgeExits
const hashImportedBridgeExits
const selectedGER
const networkID

// public outputs
const newLER
const newLBR
const newNullifierRoot

// Section A: Verify `hashbBridgeExits`
const bridgeExits = [bridgeExit_0, bridgeExit_1, ..., bridgeExit_N-1]; // private input
assert(keccak256(bridgeExits), hashBridgeExits);

// Section B: Apply `bridgeExits` to `oldLER`
let currentLER = oldLER;
for (let i = 0; i < bridgeExits.length; i++) {
    currentLER = smt.add(currentLER, bridgeExits[i]); // returns the new root
}
assert(newLER, currentLER);

// Section C: apply bridgeExits to LBR and store balance to check at the very end
const checkBalances = []; // unique identified by originTokenAddress & originTokenNetworkID
let currentLBR = oldLBR;
for (let i = 0; i < bridgeExits.length; i++) {
    const singleBridgeExit = bridgeExits[i];
    if (singleBridgeExit.originNetworkID == networkID) {
        continue; // skip since asset it is originally from this chain
    }

    if (singleBridgeExit.leafType == MESSAGE_TYPE) {
        continue; // skip since it is message type, not asset type
    }

    // add pair originTokenAddress & originTokenNetworkID
    checkBalances.push(singleBridgeExit.originTokenAddress & singleBridgeExit.originTokenNetworkID;
    // extract value from the LBR
    currentLBR = smt.updateLeafBridgeExits(currentLBR, singleBridgeExit); // this function decrease token balance base on (originNetworkID, originAddress, amount)
}

// Section D: Verify `hashImportedBridgeExits`
const importedBridgeExits = [importedBridgeExit_0, importedBridgeExit_1, ..., importedBridgeExit_N-1]; // private input
assert(keccak256(importedBridgeExits), hashImportedBridgeExits)

// Section E: group importedBridges by its originNetworkID
const mappingIBByNetworkID = {}; // IB --> Imported Bridges
for (let i = 0; i < importedBridgeExits.lenght; i++) {
    const singleImportedBridgeExit = importedBridgeExits[i];
    if (mappingIBByNetworkID[singleImportedBridgeExit.originNetworkID] == undefined) {
        mappingIBByNetworkID[singleImportedBridgeExit.originNetworkID] = [];
    }
    mappingIBByNetworkID[singleImportedBridgeExit.originNetworkID].push(singleImportedBridgeExit);
}

// section F: for each networkID, verify the LER that is going to be used against the selectedGER
const networkIDLERMap = { // private input
      "0": "0xAA...BB",
      "1": "0xCC...DD",
      ...
      "N-1": "0xEE...FF",
};

for (let i = 0; i < Object.keys(mappingIBByNetworkID).length; i++) {
    const networkID = Object.keys(mappingIBByNetworkID)[i];
    const singleLER = networkIDLERMap[networkID];
    const smtProof = [0x00...01, 0x00...02, ...]; // private input
    const isIncluded = verifySMTProof(selectedGER, singleLER, smtProof); // return true/false
    assert(isIncluded, true);
}

// section G: verify importedBridges exists on its corresponding LER
for (let i = 0; i < Object.keys(mappingIBByNetworkID).length; i++) {
    const networkID = Object.keys(mappingIBByNetworkID)[i];
    const LERNetworkID = networkIDLERMap[networkID];

    // get all importedBirdges for that networkID and verify them
    for (let j = 0; j < mappingIBByNetworkID[networkID].lenght; j++) {
         const singleImportedBridgeExit = mappingIBByNetworkID[networkID][j];
         const smtProof = [0x00...01, 0x00...02, ...]; // private input
         const isIncluded = verifySMTProof(LERNetworkID, singleImportedBridgeExit, smtProof); // return true/false
         assert(isIncluded, true)
    }
}

// section H: add importedBridges on the LBR
const currentNullifierRoot = oldNullifierRoot;
for (let i = 0; i < importedBridgeExits.length; i++) {
    const singleImportedBridgeExit = importedBridgeExits[i];

    if (singleImportedBridgeExit.leafType == MESSAGE_TYPE) {
        continue; // skip since it is message type, not asset type
    }

    if (singleImportedBridgeExit.destinationNetworkID != networkID) {
        continue; // skip since it does not affect this networkID
    }

    // verify it has not been nullified
    const isClaimed = smt.readValue(oldNullifierRoot, singleImportedBridgeExit); // uses index & networkID from the bridgeExit
    if (isClaimed == true) {
        continue; // jump to the next one, since it has been claimed
    }

    // add it to the LBR
    // extract value from the LBR
    currentLBR = smt.updateLeafBridgeExits(currentLBR, singleImportedBridgeExit); // this function adds token balance base on (originNetworkID, originAddress, amount)
    // update nullifierRoot
    currentNullifierRoot = smt.updateNullifierTree(currentNullifierRoot, singleImportedBridgeExit); // uses index & networkID from the bridgeExit
}

assert(newLBR, currentLBR);
assert(newNullifierRoot, currentNullifierRoot);

// section I: verify there is not negative value for all the decreasing balances in the LBR
for (let i = 0; i < checkBalances.length; i++) {
     const balance = smt.readValue(currentLBR, checkBalances[i]); // gets value from a certain originAddress # originNetworkID
     assert (balance > 0);
}

claimed_local_exit_roots

Now we have a locally-generated pessimistic proof, but we still have to verify that claimed_local_exit_roots are valid. This can be done by the agglayer. The Agglayer can recursively aggregate all locally-generated pessimistic proofs and merge the set of claimed_local_exit_roots, before verifying that each is valid as part of the final proof step

There are several options to do that verification, each one with its trade-offs. I will try to summarize all three approaches that I can think of:
aggLayer to verify at top level proof the claimed_local_exit_roots

this is your approach

this implies the aggLayer to make a proof of every LER present claimed_local_exit_roots (used when importing the bridges)
The aggLayer then can settle each PP on-chain by proving at higher level two proofs: the PP & the claimed_local_exit_roots inclusion
This implies to have a single input on-chain with all the previous GER, so you can prove all the claimed_local_exit_roots

Pros

PP locally does not care about proving the claimed_local_exit_roots
reuse data that has been used in your chain: LER for each claim & merkle_path

Cons

join two proofs into a top level proof
the chain cannot submit the PP by themselves

selectedGER

this is what is written in my pseudo-code

selectedGER is a GER that exist on L1
all the pub struct Claim are not checked against its own LER, but all of them are checked against the selectedGER.

if a claim has been done in GER_i...the GER_i+1 also has that claim

Therefore, you know all the claims that has been done in your chain (call them importedBridgeExits)

you can query the bridge-service to give you the merkle_path against the selectedGER so you can prove them

Pros

fully PP generated locally
simplifies aggLayer at first stage
easy to add like forcedPP on the mid-term

Cons

depends on the bridge-service (although I can imagine the aggLayer to provide that data)

L1InfoTree

kind of an hybrid

Turns out that we have a data structure on L1 that holds all historical GER. It is the L1InfoTree
It is an append-only MT of fixed 32 levels (same tree as the GER) that contains:

key: index
value: GER_i (more data inside, but for simplicity, just consider the GER)

So we can validate all the claimed_local_exit_roots inside the PP built by the chain

Pros

reuse data that has been used in your chain: LER for each claim & merkle_path
fully PP generated locally
simplifies aggLayer at first stage

Cons

it may add complexity since it uses the L1InfoRoot

Great writeup and this meets my intuitions based upon the discussions with Carlos, Jesus, and shared sequencing teams.
Question: what DA guarantees do we need for the agglayer to verify that the claimed_local_exit_roots are valid?

There's no DA guarantee required - "claimed_local_exit_root = valid" <=> the local exit root included in a previous GET or the current GET being built.

Nice writeup @krlosMata !

There are several options to do that verification, each one with its trade-offs. I will try to summarize all three approaches that I can think of:

What I would propose is a mixture of the first and the third approaches. For the happy path, where the chain doesn't need to force-include on L1, it can submit a vector of claimed_local_exit_roots to the AL, and the AL can prove inclusion in previous GERs or the current GER.
This point (proving inclusion in the current GER) is really important, as it's what allows us to have low-latency interop (we can allow chains to claim from LETs before they're even included in a GET by the AL).
The force-include path would be allowing chains to submit another proof to L1 showing that the claimed LERs are consistent with the L1InfoRoot.

Let me write down all the necessary steps taking account your 1-3 approach:

Step 1: chain_A to get from itself: bridgeExits and importedBridgeExits
Step 2: Send them to aggLayer
Step 3: aggLayer to have L1InfoRoot data (so it can prove all used claimed_local_exit_root)
Step 4: aggLayer to build PP
Step 5: aggLayer to send PP to L1

sequenceDiagram
    participant chain_A
    participant aggLayer
    participant L1
    Note over chain_A: All bridgeExits
 from oldLER to newLER
    chain_A->>chain_A: Sign bridgeExits
    Note over chain_A: All claims (importedBridgeExits)
 from oldLER to newLER
    chain_A->>chain_A: Sign importedBridgeExits
    chain_A->>aggLayer: Certificate (data needed to build the PP)
    note over aggLayer: Build PP
 check PP consistency
    aggLayer->>L1: PP

As far as I understood this would be the data flow. Let me know if I'm missing something.
Some comments:

aggLayer to maintain the LBT and the nullifierTree for each chain

each chain could also have a copy or live just in the chain (and the chain send merkle paths necessary to the aggLayer)

It will allow low-latency interoperability. I think this feature should not be taken into account in the very first stage of the PP since it adds complexity to the aggLayer. The design takes into account that, but I would say that it is for future aggLayer versions

If this is not taken into account in the first version, the approach 3 also will satisfy the needs for the very first version of the PP and maybe simplifies even more the aggLayer since all the work is done at chain level

Thanks @krlosMata - few thoughts on this.

aggLayer to maintain the LBT and the nullifierTree for each chain

I would actually argue that the chain should maintain the LBT and NullifierSet. In this mode, we have a clean separation of what the agglayer does (maintains the L1InfoRoot and proves validity of LERs) and what's required for each chain to generate a PP.
It's not strictly required that the chain itself will generate a PP - it could be a service that we expose, but I think that it makes sense to separate this from the AL itself, as we can remove the requirement that AL nodes store LBT and NullifierSets.

It will allow low-latency interoperability. I think this feature should not be taken into account in the very first stage of the PP since it adds complexity to the aggLayer.

The nice thing is that it doesn't need to add any complexity. If we use the approach where PPs don't specify a GER, but the LER -> GER inclusion is proved at the final step, then we get the cross-chain consistency check for free. There are further protocol changes (allowing claims on the EVM with just LERs, not the GER) but all that's required by the AL for cross-chain consistency is to prove that LERs are valid.

I would actually argue that the chain should maintain the LBT and NullifierSet.

100% agree. Just with the bridgeExits and the importedBridgeExits you can build the LBT and the nullifierTree, so both the chain and the aggLayer could store them.
If the aggLayer is totally agnostic to those trees, the chain must submit the merke-paths to the aggLayer to build the PP

I would say that it simplifies the data flow, in this first stage, if the aggLayer is the one that has all the LBT and the nulifierTree for every chain

It's not strictly required that the chain itself will generate a PP

I think it is a "nice to have" feature at this first stage xD
It futures stages I can see

each chain to build its own PP, chain_A_pp
sends to the aggLayer (it receives from multiples chains, chain_A_pp, chain_B_pp, ..., chain_Z_pp)
aggLayer build a proof of multiples LER inclusion in the L1InfoTree, proof_inclusion_LERs
aggLayer to build a proof that proves proof_inclusion_LERs & chain_A_pp & ... & chain_Z_pp

The nice thing is that it doesn't need to add any complexity

somehow the chain needs to know the other chain LER, so some sort of communication is needed and if we split the proofs it kinda add more complexity at this first stage

Cool, I think that we mainly agree on everything

I would say that it simplifies the data flow, in this first stage, if the aggLayer is the one that has all the LBT and the nulifierTree for every chain

I'm just wondering if we can separate this from the main agglayer repo, as it's functionality that we don't strictly need. We could have a separate PP-generator service that could be run by the chain itself or by some other party.

somehow the chain needs to know the other chain LER, so some sort of communication is needed and if we split the proofs it kinda add more complexity at this first stage

The chain will have all of the LERs though - they'll be provided by users or builders during the claims process. The chain doesn't really care if the LER is old or new (for fast interop) - it can handle them all the same.
The main changes for fast interop would be in the zkEVM proof - instead of accepting a GER, chains could specify a set of LERs to process claims on.

I think it would make sense to split this out into a library with go, rust bindings as well as a service that can run as a sidecar for EVM chains.
We can then ask other folks to port this to svm, movevm etc.

a library with go, rust bindings as well as a service that can run as a sidecar for EVM chains...port this to svm, movevm, etc

I don't think that any contract or VM changes should be required for this. We should be able to have a single implementation of a service written in Rust that can query or receive local LET and claim/deposit data to generate the proof. The LBT and Nullifier Set are generated entirely from the LET and claims/deposits.

I'm just wondering if we can separate this from the main agglayer repo, as it's functionality that we don't strictly need. We could have a separate PP-generator service that could be run by the chain itself or by some other party

yep, it can be separated. This is convenient to compute proofs in a stateless server (the service does not know anything about the LBT and the nullifierTree). This will imply high amount of data to be transferred to the service (merkle-paths basically) so it could have a delay associated with data transfer.

The chain will have all of the LERs though - they'll be provided by users or builders during the claims process. The chain doesn't really care if the LER is old or new (for fast interop) - it can handle them all the same

true. chain_A can read chain_B LERs produced by inspecting the bridge SC or provided by users.

The main changes for fast interop would be in the zkEVM proof - instead of accepting a GER, chains could specify a set of LERs to process claims on.

That is a huge change in the zkEVM proofs as well as in the Bridge L2 SC. It would need every chain to update its SC and its Verifier (forkID) (all chains do not need to update at the same time though...which is good).
I'm just thinking another viable solution. Make the update of the GER deterministic in L1. Say chain_A wants to update its LER_A. It chooses from which GER (mainnetExitRoot & rollupExitRoot) the LER_A is updated.
This will not imply updating all zkEVM chains and its Verifier...but only the rollupManager.sol and how the new GER is computed.
thoughts on this topic @invocamanman ?


[P0] Can't finish games on desktop client

Summary
The desktop client builds are now succeeding, but I can't get into SP or MP games. I don't see anything in the logs regarding connections aside from the HTTP/101 Changing Protocols on the WebSocket to Firebase. I don't see any WebSocket connections to game servers.
This may be related to window.location things (see notes in #110 comments).

Logs:
NetworkManager: connecting to game server wss://:8000

Definitely window.location sadness.

Fixed in #141, but games are failing to conclude. This may be due to missing resources.


Issues with asynchronous functions (await not working)

Hi,
I am trying to set annotations and then immediately zoom to those annotations. However, the await doesn't work for me properly.
Here's an example:
https://stackblitz.com/edit/js-f2v3uc?file=index.js
If I use timeout, it works good, but it's not a preferred solution.
Any idea about what could be happening here?

I think I've come across this before. It looks like there's not much that can be done about out right now (given the way the zoom function currently works). Timeout might currently be your only workaround.
Some background: setAnnotations is not an async function. The effect you're seeing is that setAnnotations completes immediately, but the DOM update itself takes a while to process in the browser. The problem, now, is that fitAnnotations fetches the annotation from the DOM, and then fits the viewport.
The only way to resolve this cleanly inside Annotorious would be to rewrite fitAnnotations, to make it independent from the DOM. This way, zooming would work even before the annotation is actually rendered to the DOM. I'll leave that issue open, for the case that I get the chance to look into this soon-ish.

Alright, I see. Thanks for the quick response. :)


Add B4 Submission

confirmed:B4
address:3R1JDpWS1Z8Y43ky5LeGKLWX62FzRwpkiGbm4UV4if5ZTNsNyG
baker:581

confirmed:B4
address:3R1JDpWS1Z8Y43ky5LeGKLWX62FzRwpkiGbm4UV4if5ZTNsNyG
baker:581

rejected:B5
address:3R1JDpWS1Z8Y43ky5LeGKLWX62FzRwpkiGbm4UV4if5ZTNsNyG
reason: no 'update baker account' or 'update baker key' transactions found on-chain


Cannot debug a webextension that depends on another extension

Issue Type: Bug
This bug occurs in normal desktop Linux version of VS Code, but only for webextensions.

Check out the source of any webextension, for example the sample helloworld-web-sample (here is the commit I used).
I also tried this with the boilerplate extension you get by using yo code as suggested in the guide, with the same result.

Add an extensionDependencies field to package.json. For example, I added
 "extensionDependencies": ["ms-python.python"],

I also tried this with gregoire.dance or ms-python.vscode-pylance instead of Python, with the same result.

Run npm install in that directory, open VS Code in it, make sure the Python extension is installed.

Debug the extension with F5. Try to activate the extension, e.g. by pressing Ctrl+Shift+P and running the Hello, World command the extension provides.

Expected result:
The command works. (This is what happens if you started with a normal extension such as helloworld-sample, or if you skip step 2).
Actual result:
You get two error messages "command helloworld-web-sample-helloWorld not found" and "Cannot activate the 'helloworld-web-sample' extension because it depends on the 'Pylance' extension which is not loaded." The latter message has a "Reload Window" button, but it doesn't help.

VS Code version: Code - Insiders 1.69.0-insider (ab6ba241145bb81c8bc0f323453bbec45fd66109, 2022-06-10T06:23:32.996Z)
OS version: Linux x64 5.10.110-15808-ge5740beba59b
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i3-10110U CPU @ 2.10GHz (4 x 2591)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offopengl: enabled_onrasterization: disabled_softwareraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: disabled_softwarevideo_encode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
3, 1, 1

Memory (System)
6.45GB (6.43GB free)

Process Argv
. --crash-reporter-id 3cc33ccb-4c87-49cf-90e4-69944c0c944e

Screen Reader
no

VM
100%

DESKTOP_SESSION
undefined

XDG_CURRENT_DESKTOP
undefined

XDG_SESSION_DESKTOP
undefined

XDG_SESSION_TYPE
undefined

Extensions (2)

Extension
Author (truncated)
Version

python
ms-
2022.8.0

vscode-pylance
ms-
2022.6.10

A/B Experiments
vsliv695:30137379
vsins829:30139715
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30422396
pythontb:30258533
vsc_aa:30263845
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805:30301674
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30404738
wslgetstarted:30449409
vscscmwlcmt:30465136
cppdebug:30492333
pylanb8912:30496796
vsclangdf:30492506

@sandy081 Is it possible to have a web extension depend on a regular extension (here: "ms-python.python")?

As far as I understand, ms-python.python is both a normal extension and a webextension. It should have both main and browser entrypoints in package.json. This is certainly the case for gregoire.dance, you can try others.

Thank you very much for the suggestions! For future readers, it took me a second to figure out that  extension files live in ~/.vscode/extensions and can be edited or copied from there.
Your second suggestion -- of a custom runner path -- seemed to work for me. In fact, I didn't even need to copy the files. On Linux, adding following to launch.json worked for me (though, this approach might be less robust than copying the files as you suggested):
{
	"name": "Run Web Extension With Web dependencies",
	"type": "pwa-extensionHost",
	"debugWebWorkerHost": true,
	"request": "launch",
	"args": [
		"--extensionDevelopmentPath=${workspaceFolder}",
		"--extensionDevelopmentPath=${userHome}/.vscode/extensions/gregoire.dance-0.5.11",
		"--extensionDevelopmentKind=web"
	],
	"outFiles": [
		"${workspaceFolder}/dist/web/**/*.js"
	],
	"preLaunchTask": "npm: watch-web"
}

Strangely, the suggestion of editing package.json to remove the main entry only worked half the time. It worked for the Python extension, but did not work for gregoire.dance. Confusingly, after removing main, VS Code still seemed to try to load it as a normal extension according to the "Extensions Running" page. The extension ended up broken as VS code could no longer find the JS files for the Dance extension.
I'm not sure why the behavior of the two extensions differs. I do know Dance works on github.dev, so it does function as a web extension. Also, the first approach did seem to work for it.


fix(substrait): consuming AggregateRel as last node

Which issue does this PR close?
Closes #12869.
Rationale for this change
consumer bakes in plan names into last Aggregate, but only handled metrics expressions before. This PR splits schema fields into grouping and metrics fields and renames each accordingly.
Are these changes tested?
yes
Are there any user-facing changes?
yes

🚀


sick/healthy organism

Hi,

I am trying to define "healthy organism" and "sick organism" in the context
of the Influenza Ontology, and I believe those should belong in OGMS.

Current definition of disease reads "A disposition (i) to undergo
pathological processes that (ii) exists in an organism because of one or
more disorders in that organism." As per its definition, it is asserted
under bfo:disposition.

The explanation in the
http://ontology.buffalo.edu/medo/Disease_and_Diagnosis.pdf paper reads:
A disposition is an attribute of an organism in virtue of which it will
initiate certain specific sorts of processes when certain conditions are
satisfied.
Examples are: our disposition to crave liquid following dehydration; the
disposition of an epithelial cell in the G2 phase of the cell cycle to
become diploid following mitosis. In any organism there is a wide variety
of dispositions, some associated with health, others with disease.
We use ‘realization’ to refer to the process through which a disposition is
realized, and we shall identify diseases as dispositions realized in
pathological processes.

Based on this, it seems that "health" would be an other disposition. I am
not sure how to define "health": I would intuitively say health = free from
disease, however talking bout dispositions organisms always bear both, they
are just realized or not. In any case we would need a process equivalent to
disease course, something similar to "health/free from disease course
process" in which the health disposition is realized.

Any suggestion on how to add this term?

I am then unsure how to proceed for "sick organism": it is neither input_of
nor output_of a disease course process (def: The totality of all processes
through which a given disease instance is realized.), it is undergoing the
process. Similarly, a healthy organism is an organism not currently
participating in a disease course process. Is has_agent (def: As for
has_participant, but with the additional condition that the component
instance is causally active in the relevant process) the appropriate
relation to use, then saying disease course process has_agent sick organism
and health course process has_agent healthy organism?

Thanks,
Melanie

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 9 Mar 2010 at 12:42

Closed ticket because issue has not been acted upon in reasonable amount of time.


[MOB-927] Add inboxSessionId

Locally ran through all the unit tests and they all passed.

Few suggestions/observations

We should look into removing inboxSessionId from IterableInAppMessage class and add this to InAppMessageContext.
I don't see anywhere that IterableInAppMessage.inboxSessionId value is being set.
We should probably write or change unit tests to make sure that inboxSessionId is being passed for calls other than trackInboxSession.

At this point, just two tasks remain:

unit tests
converting the internal use of inAppConsume to track inboxSessionId

Clarified that the current addition of inboxSessionId to inAppConsume is fine since it's meant to be used internally, so unit tests remain.


Ready for public release

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/di-graph/terraform-config-validator?version=dev:27f03d9210dad369a5f0efdff357a4cddfab0db6

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/di-graph/terraform-config-validator?version=dev:45f129caaa4bae5dd291bfb73999a955b30cdbc3

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/di-graph/terraform-config-validator?version=dev:45f129caaa4bae5dd291bfb73999a955b30cdbc3


Add "seedable" feature flag and functionality

Feature Addition

Adds the ability to have seeded randomness for stochastic processes.
Links to and Closes #85 (see more detail there)

Please let me know if there is any extra documentation you would like to have included. I did include a test to make sure that the seed works properly.

I realized that it may be good to bump the patch version in this and post to crates.io as well.

Hey there, just pinging you all again.
I was just using your crate over the last few days and was debugging a simulation where having reproducibility via a seed would have been nice.
Anything I can do to help get this merged in?

@avhz no worries at all! Hope you had enjoyable holidays! Thanks for merging in.
I may have more to contribute soon enough.


Clicking Refresh is not updating Blob Containers

Environment
OS - Windows
Plugin Version - 0.1.212
IDE - Intellij Idea Ultimate 14.1.3 , Android Studio <IP_ADDRESS> , JRE 1.8
Authentication - Publish Settings file
Steps
Click Azure.
Click storage.
Expand a particular Storage.
Expand Blobs.
Select a particular Blob Containers.
Add few file to the Container from plugin .
Now add some more files to that same Blob containers from other way such as azure portal or through plugin in different IDE .
Now come back to the plugin , and click Refresh for that Blob Containers , It is not updating the Blob container .

Note -

The oval marked refresh is not working , whereas Square marked is working fine .
The issue also extends to queues and table too .

The refresh button is now working fine for blob Containers , queues and tables too ..


redirect is not working in initController()

Hello why is this not working.
I created a child Controller trying to check if constant is defined on the parent controller. if not redirect as the general option but not working both on construct function and inicontroller.

 public function initController(RequestInterface $request, ResponseInterface $response, LoggerInterface $logger)
    {
        parent::initController($request, $response, $logger);

        if (!defined('ADMINPATH')) {

            return redirect()->to(site_url());
        }
    }

the redirect is not working

We use GitHub issues to track BUGS and to track approved DEVELOPMENT work packages. We use our forum to provide SUPPORT and to discuss FEATURE REQUESTS.
https://github.com/codeigniter4/CodeIgniter4#repository-management

why is this not working.

initController() is kind of constructor.
It can't return anything.


dynamically changing filetype?

curently while working on a vue file, no matter where am I, the filetype is always vue which isn't ideal, because when I pass to script it should switch to javascript so that we can disable emmet

When changing the filetype from vue to e.g. javascript when you're in a script tag, the contents of the surrounding template and style tags would lose their syntax highlighting, which is undesirable.
Using context_filetype.vim you could detect if the current section of the file is javascript, html or css. This doesn't change the filetype setting in vim, so context_filetype.vim should be manually implemented in plugins that benefit from it.


Fix a bunch of reflection tests to be correct for Ubuntu

These tests had Darwin-specific code in them, mostly unnecessary, that caused them to break on non-Darwin platforms.  In particular, they break on Ubuntu 22.10 aarch64.
Only one (reflect_Enum_SingleCaseCFPayload.swift) was actually specific to Darwin.  That one has been disabled on non-Darwin.  For the rest, just delete the unnecessary import Darwin and similar.

@swift-ci Please test


Feature/s4 85 update content

Description
Update content on wait-for-others-to-sign page and define-signatory-information page
Coding Standards
Code Style Guide: https://github.com/companieshouse/dissolution-web/wiki/Code-Style-Guide
Checklist

[x] 3 Amigos
[x] Acceptance Criteria met
[x] Branch named {feature|hotfix|task}/{S4-*}
[x] Commit messages are meaningful
[x] Manually tested
[x] All unit tests passing
[x] WAVE accessibility testing tool ran on new or updated pages
[x] Pulled latest master into feature branch
[x] Code reviewed
[x] New Docker environment variables are consistent with those on the Rebel1 environment
[ ] If your pull request depends on any other, please link them in the description

Screenshots of new or updated views

@mateuszc-kainos changes pushed, new screenshot of wait-for-others-to-sign page below


Dharman: Watch (?-i:JaClA57ChVI)(?#YouTube)

Dharman requests the watch of the watch_keyword (?-i:JaClA57ChVI)(?#YouTube). See the MS search here and the Stack Exchange search in text, in URLs, and in code.

(?-i:JaClA57ChVI)(?#YouTube) has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ

Approved by tripleee in Charcoal HQ


Stroke Color till source with different color

this wants to give a different line color to the source.
eg: I'm using status to handle line color so right now if node D has error able to change stroke color of node C to Node D but want this line color till the node T(this will happens only if any Node has error status)

Conditionally changing the stroke of a link is easy.

Conditionally changing a link stroke color is possible. How you want to conditionally change the color is up to you. In the code snippet below if the index is 2 the stroke is blue, else it's red.
<Tree>
  {(tree) => {
    return tree.links().map((link, i) => {
      return (
        <LinkComponent
          key={i}
          data={link}
          stroke={i === 2 ? "blue" : "red"}
          strokeWidth="1"
          fill="none"
        />
      );
    });
  }}
</Tree>

Hope this helps!

Thanks but my question was different sorry that I didn't explain it better before. And conditionally changing line stroke I already able to do. What I am trying to do take this example:

with this snippet, line stroke b/w Node B & Node C is red as Node C has error status and this is working fine.
    data={link}
    percent={+stepPercent}
    stroke={link.target.data.status}
    strokeWidth="1"
    fill="none"
    key={i}
/>

But I want if any node has error status like in this case Node C has then not only line stroke of Node B & C has a red line but Node A & B also i.e till source has same line stroke.

@Im10Anish You can use d3-hierarchy's ancestors or path to make this determination on color.
If you look at some of the d3-hierarchy examples here, and specifically the handling of highlight in their examples, it should get you what you are looking for.


Name of the Payload GraphQL type created does not take parent into account

When nesting a mutation, and having the lib handle django errors (handle_django_errors=True), the Payload type created is named using only the direct field name. If another different mutation has the same name elsewhere, it will use the first created one.
Describe the Bug
# settings.py
STRAWBERRY_DJANGO = {
  "MUTATIONS_DEFAULT_HANDLE_ERRORS": True,
}

# schema.py

import strawberry
import strawberry_django

from .models import Project, Task

@strawberry_django.type(Project)
class ProjectType:
    id: strawberry.auto
    name: strawberry.auto

@strawberry_django.type(Task)
class TaskType:
    id: strawberry.auto
    name: strawberry.auto
    project: ProjectType

@strawberry_django.input(Project)
class ProjectInputType:
    id: strawberry.auto
    name: strawberry.auto

@strawberry_django.input(Task)
class TaskInputType:
    id: strawberry.auto
    name: strawberry.auto
    project: ProjectType

@strawberry.type
class ProjectMutation:
    create: ProjectType = strawberry_django.mutations.create(ProjectInputType)

@strawberry.type
class TaskMutation:
    create: TaskType = strawberry_django.mutations.create(TaskInputType)

@strawberry.type
class Mutation:

    @strawberry.field
    def project(self) -> ProjectMutation:
        return ProjectMutation()

    @strawberry.field
    def task(self) -> TaskMutation:
        return TaskMutation()

schema = strawberry.Schema(
    query=Query,
    mutation=Mutation,
    extensions=[DjangoOptimizerExtension],
)

Both project.create and task.create mutations return a CreatePayload. Since the project mutation is the first created, the payload contain ProjectType.
System Information

Operating system:
Strawberry version: 0.242.0
Strawberry django version: 0.48.0

Upvote & Fund

We're using Polar.sh so you can upvote and help fund this issue.
We receive the funding once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog.

This is related to namespacing, a feature which we Strawberry itself doesn't support that well yet.
To properly support this we would need to understand that the type being returned is actually a mutation.
I think it is worth to start a discussion about this on discord about namespacing queries and mutations  to see what the other devs and the community thinks about and to try to come with a general solution for this.


chore: Remove unused boolean return values from stores

LMDB operations return a false boolean if an insert or delete operation fails due to a failed version check, which we are not using. So we just turn every return value to void.
Context here.

Benchmark results
No metrics with a significant change found.

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit ef446747 and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
64 txs

l1_rollup_calldata_size_in_bytes
676
676
676

l1_rollup_calldata_gas
6,412
6,424
6,412

l1_rollup_execution_gas
585,745
585,757
585,745

l2_block_processing_time_in_ms
1,316 (+1%)
4,909 (+1%)
9,394

note_successful_decrypting_time_in_ms
182 (-28%)
532 (-9%)
987 (+3%)

note_trial_decrypting_time_in_ms
91.2 (+51%)
62.5 (-39%)
151 (+74%)

l2_block_building_time_in_ms
13,595
50,199
99,730 (+1%)

l2_block_rollup_simulation_time_in_ms
7,859
27,400
54,518

l2_block_public_tx_process_time_in_ms
5,716
22,747 (+1%)
45,111 (+1%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
14,057 (-4%)
26,573 (-1%)

note_history_successful_decrypting_time_in_ms
1,269 (-8%)
2,493 (-2%)

note_history_trial_decrypting_time_in_ms
145 (+5%)
229 (+18%)

node_database_size_in_bytes
18,665,552
34,836,560 (-1%)

pxe_database_size_in_bytes
29,859
59,414

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
228
44,379
28,214

private-kernel-ordering
203 (+1%)
52,880
14,296

base-parity
3,551
128
311

root-parity
1,254 (-3%)
1,244
311

base-rollup
16,229 (-1%)
165,760
861

root-rollup
49.6
4,359
725

private-kernel-inner
295 (+1%)
73,795
28,214

public-kernel-app-logic
121 (+1%)
35,252
28,217

public-kernel-tail
166 (+1%)
40,928
28,217

merge-rollup
9.51 (+14%)
2,568
861

public-kernel-teardown
117 (-1%)
35,252
28,217

public-kernel-setup
116 (-1%)
35,252
28,217

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
512 leaves
1024 leaves
2048 leaves
4096 leaves
32 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.2
16.0 (-1%)
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.8
31.6
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.592
0.495 (-1%)
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
46.9 (-1%)
72.1
233 (+1%)
445 (-1%)
877
1,730
N/A

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
96.0
159
543
1,055
2,079
4,127
N/A

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.481 (-1%)
0.445
0.424 (+1%)
0.416
0.416
0.414
N/A

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
56.8 (+3%)
107
340 (-1%)
662
1,311
2,736 (+5%)
N/A

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
105
207
691
1,363
2,707
5,395
N/A

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.501 (+4%)
0.481
0.461
0.456
0.454
0.479 (+6%)
N/A

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
61.4 (-1%)

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
109

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0.537 (-1%)

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
14,968
495,320

Transaction size based on fee payment method

Metric
none fee payment method
native fee payment method
fpc_public fee payment method
fpc_private fee payment method

tx_with_fee_size_in_bytes
773
905
1,161
1,377

Transaction processing duration by data writes.

Metric
0 new note hashes
1 new note hashes
2 new note hashes

tx_pxe_processing_time_ms
2,085
1,368
4,742

Metric
0 public data writes
1 public data writes
2 public data writes
3 public data writes
4 public data writes
5 public data writes
8 public data writes

tx_sequencer_processing_time_ms
12.8 (-2%)
702
527 (+1%)
1,450
588
2,511
675

@alexghr ready for re-review!


Parsing unencrypted PKCS#12 private key process idiopathically demanding import password

The issue materializes on the current Debian Sid (testing/unstable), OpenSSL version 3.0.5-4.
When using OpenVPN:
$ openvpn config.ovpn
2022-10-27 19:36:25 OpenVPN 2.6_git x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
2022-10-27 19:36:25 library versions: OpenSSL 3.0.5 5 Jul 2022, LZO 2.10
Enter Auth Username: username
Enter Auth Password: password
Enter Private Key Password: // There is none.
2022-10-27 19:36:49 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2022-10-27 19:36:49 OpenSSL: error:0308010C:digital envelope routines::unsupported
2022-10-27 19:36:49 OpenSSL: error:0308010C:digital envelope routines::unsupported
2022-10-27 19:36:49 Decoding PKCS12 failed. Probably wrong password or unsupported/legacy encryption
2022-10-27 19:36:49 Error: private key password verification failed
2022-10-27 19:36:49 Exiting due to fatal error

Trying to parse the culprit key:
$ openssl pkcs12 -in key.p12
Enter Import Password: // There is none.
Error outputting keys and certificates
40C79A67FA7F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:373:Global default library context, Algorithm (RC2-40-CBC : 0), Properties ()

Everything works fine on Debian Bullseye (stable).
Thanks.

After a bit more searching around, I found an answer to my problem.


Update dropbox to 20.4.19

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

As in #29169 and #29613, outdated appcast left in hoping that it'll get updated eventually.


Failed to write in file

Try just putting the image on the SD card

Try just putting the image on the SD card

I have the same problem.

I think you need to do it in termux
Pada Jum, 6 Sep 2024 16.44, solomyster @.***> menulis:

I have the same problem.
image.png (view on web)
https://github.com/user-attachments/assets/047a0de0-d20d-4a5c-9a88-ee734cf7b484
—
Reply to this email directly, view it on GitHub
https://github.com/Whomrx666/exploit-X/issues/1#issuecomment-2333681097,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCWRBMJF3H77FSE73QM62ILZVF2Q3AVCNFSM6AAAAABM6SIMYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZTGY4DCMBZG4
.
You are receiving this because you commented.Message ID:
@.***>


library share to get started

Hi AsFaBw, are there any libraries you would recommend to get started with Erica? I've got some PCBs coming and want to get a head start getting my brain around writing code for the GreatFet.
Much obliged
PIM

Hi, there is nothing what I can share, except some sample code.
Can you send me an email to<EMAIL_ADDRESS>?

Hi, there is nothing what I can share, except some sample code. Can you send me an email to<EMAIL_ADDRESS>?

Emailed, thank you
PIM


[WIP] Destroy DHCP Server before PowerVS Cloud Instance deletion

What this PR does / why we need it:
This PR adds functionality to delete DHCP server created in PowerVS Cloud Instance before the actual instance deletion.
We need it, so that we do not rely on PowerVS Cloud Instance's recursive delete functionality to delete all other dependent resources.
Checklist

Subject and description added to both, commit and PR.
This PR was tested locally.

/assign @dharaneeshvrd  @srivastav-abhishek


Fix docker package

Changes
Addresses the issue https://github.com/ALT-F4-LLC/kickstart.nix/issues/52

LGTM, running workflows...

Thanks for the PR! Much appreciated :)


Account not deployed.

Hey i updated remote 2 and add the routine node and entered the proxy

This IP
port: 3456
auto init: on
events: on
service Host: layla.amazon.de
page: amazon.de
language: de-DE

but i get always a failure after saving the changes.
I have the same issues with the cookie.
Before updating it was working fine

Anyone who know whats wrong?
Thank you
Miguel

The notification you get does not have anything to do with authentification. It just means that the account you selected in the routine node does not (yet) exist and because of that it couldn't load the routines for you to select in the Execute Routine option.
What do you see in the node status? Is there a problem with the authentification? If so what do you see in the debug log?
You can manually trigger an authentification with the Alexa Init to get an error.

I got it similar, but overcome it and ignored, but than this other issue I have opened now appears.


Remove dependency on chef-server: secret management (vault)

Move away from chef server vault (oh, brain dumping: etcd or other cluster formation that doesn't rely on chef server? push-to-deploy)

bye bye Chef!


improved functions

Hi....
sorry it's not an issue but don't know how to contact you.....
i've forked your streamdeck and add some good capabilities if you want to include in your :

in gcode preview, now , we see machine position on gcode picture like in cncjs interface

added function to move cnc position at clic position grid and  can now show machine size

added messagebox information

may be some bugs but if you want to test it :
https://github.com/metropolicon/cncjs-pendant-streamdeck
Sorry i'm french, so , some labels  are in french.......
anyway thanks for your great job ! ;)

Looks neat! I'm not going to add the 'click to move' feature, because I'd like to keep feature compatibility between the web and stream deck versions, but the current machine position is a good idea. Thanks!


docs: ui system specs

🤖 Generated by Copilot at 0d37bb4
Summary
📝🎼🖥

This pull request adds two new documents to the docs/docs/specs/v0 folder: composer.md and ui-system.md. They describe the vision, design, and organization of Composer and the UI system for DXOS apps. They are part of the documentation effort for Composer v0 and v1.

Composer vision
Peer-to-peer knowledge sharing
New docs in autumn

Walkthrough

Add new documents for Composer and UI system specs (link, link)

Some notes for discussion:
It’s critically important that we bring together the Composer and Kai parallel development efforts. We need to support three priorities: Dogfooding Composer to drive stability and end-user engagement; Directly supporting alpha-level third-party development by extending modular front-end components (Kai frames) and Bots (long-running processes); Further enabling internal experiments that push forward the framework.
I propose we use/evolve/throw-away the current Kai frame approach (minimally: modular component container, host app hooks, module metadata) in a manner that supports:

current Composer
Composer V2 (i.e., Stacks)
existing Kai frames
static combination of frames (i.e., Kai)
considers the modular roadmap for modular components via schema/bot dependencies tracked by DMG

We already have the majority of this core functionality developed — in a rudimentary but usable (and “daily use”) form — in the @dxos/mosaic library, and as a standalone (i.e., single Stack-only frame) implementation within Kai (with both build and runtime options). We should evaluate what minimal clean-up (if any) would be required to serve Composer v2’s immediate needs. Furthermore, Kai frames are already independent of the main “shell” — and of each other.
This envisions a fast path towards a Kai-Stacks like extension of Composer — which is the right short-term goal. Composer would then be a supported single-frame app that would:

Continue to be used to prove the stack and operations via dogfooding.
Continue to evolve the critical development work re text surfaces (plain, rich, markdown) and synchronization (e.g., new information re AST expression and sync).
Continue to evolve (and mitigate) mobile requirement (e.g., recoverability, storage).
Start to evolve the modularity APIs (initially Stack frames, then broader container/event/configuration concerns.
Be an exemplar to showcase Composer a supported production form of the framework with a great end-user experience.
Absorb successful experiments from Kai — and push framework/API innovation into Kai.

We have anecdotal evidence that developers already want to extend or develop Kai-like frames and bots. We currently have over a dozen distinct frames, many of which are Dogfoodable in their current form (either standalone or in combination). Kai should be reconceptualized (and renamed — e.g., as “labs”) to be the minimal starting point for building experimental apps (e.g., use of vault/OS panels, route handling, sidebar, etc.)

Apps could be started via the DX CLI template-driven app creation mechanism. Developers would develop single-frame apps that would benefit from framework updates (rather than being permanently forked experiments).
Third-party apps would be self-hosted, but this would leave open the ability to have developer publish the app/frame module metadata so that: a) the frame can be hosted (in demo form) via a community portal/sandbox; b) the frame could be “installed” on and operated via a user’s (or third-party provided) KUBE.

Summary

KUBE stability should be prioritized:

Gravity (see note)
First-party hosting of composer and vault
Dogfood of Composer should be prioritized to drive KUBE stability
Bots to drive ECHO stability

Prioritize Kai on:

Modularity API for composer V2
Self-hosting to drive adoption
Bots to drive adoption via experimentation (service integration to third-party data)


Increase the batch size of rows during the database backup

Questions
Answers

Description?
Following an ugprade attempt made on a production like shop, we discovered the database backup takes too much time. It did not complete after a whole day of work while a save of the same database via PhpMyAdmin takes a couple of minutes. This PRs tries some changes to see the impact on the process.

Type?
improvement

BC breaks?
Nope

Deprecations?
Nope

Fixed ticket?
/

Sponsor company
@PrestaShopCorp

How to test?
Backups are faster

Replaced by https://github.com/PrestaShop/autoupgrade/pull/894


Linux .desktop file / vector icon?

Linux distros use .desktop files to add applications in a menu.
Default .ico file was a bit tiny for Ubuntu menu, so I made SVG version for it, no blur enabled.
I'll attach icon file I'm using.
lite.svg.zip
There is a .desktop file I am using:
[Desktop Entry]
Version=1.06
Type=Application
Terminal=false
Name=Lite
Exec=/home/grid/tools/lite/lite
GenericName=Lite text editor
Comment=A lightweight text editor written in Lua
Icon=/home/grid/tools/lite/lite.svg
Categories=programming
Name[en_US]=Lite

Would it be useful to have a script, which adds Lite in a menu by creating a Lite.desktop file in ~.local/share/applications?

Question- When I do this, Lite then launches in it's build direqctory. How do you launch it via .desktop and open another code folder?

@StarrKiss, please try something like this:
Path=/home/StarrKiss/lite


http > https redirect

Hi there,
First let me thank you for this great package. solved me some dev issues i was having.
But i was wondering something, i have been browsing the wiki and also found the url redirect part.
But i can't get http to redirect to https when using --https.
When running several tests, my tests (not written by myself) will run by the "will it redirect to https" part, and in that part the test crashes/errors out when http does not redirect (unfortunately).
So is there any info on how to acheive this with lws, or am i just missing it completely?

hi!
If you have an HTTPS server running (at https://<IP_ADDRESS>:8000, for example) then any HTTP requests to http://<IP_ADDRESS>:8000 will fail (as it's a different protocol).
HTTP and HTTPS servers are two different things. If you want to respond to both HTTP and HTTPS requests you need both HTTP and HTTPS servers running.
So, launch your HTTPS server as normal. Then launch a separate HTTP server (on a different port of your choice) that hosts the same directory. Configure a blanket rewrite rule to redirect all HTTP traffic to the HTTPS server.
For example, with your HTTPS server already running, launch your HTTP server like this (insert your own specific port numbers):
$ ws --port 7000 --rewrite '/* -> https://<IP_ADDRESS>:8000/$1'

Thanks allot for the support and information!


[Documentation] Classes within the $.net.http API

Add documentation in the www.xsk.io site, API section for the classes Destination, Client and Request inside $.net.http API, based on the Wiki.
Related issue: #403

This issue is resolved in https://github.com/SAP/xsk/commit/d4e3b1bdbabfd69e1057e9a8752aca09b78306ca


(package! nano-theme) not installing correctly

Opening doom results in the following error:
Error (after-init-hook): Error running hook "nano-light" because: (file-missing Cannot open load file No such file or directory nano-theme) Disable showing Disable logging
The package is available in elpa (https://elpa.gnu.org/packages/nano-theme.html) and it was updated fairly recently in nix (https://github.com/NixOS/nixpkgs/pull/158374/files)
Here is my doom config:
https://github.com/shaunsingh/nix-darwin-dotfiles/tree/main/configs/doom-emacs
Here is my flake: https://github.com/shaunsingh/nix-darwin-dotfiles/blob/main/flake.nix
Relevent parts are https://github.com/shaunsingh/nix-darwin-dotfiles/blob/5dd081659d51e51306cbf4f22333cc26630764b7/flake.nix#L45, https://github.com/shaunsingh/nix-darwin-dotfiles/blob/5dd081659d51e51306cbf4f22333cc26630764b7/flake.nix#L108, and https://github.com/shaunsingh/nix-darwin-dotfiles/blob/5dd081659d51e51306cbf4f22333cc26630764b7/modules/home.nix#L23. emacs-mac is my own overlay for emacs, found https://github.com/shaunsingh/nix-darwin-dotfiles/blob/5dd081659d51e51306cbf4f22333cc26630764b7/flake.nix#L174 if that makes any difference

apparently its both https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/emacs/elisp-packages/elpa-generated.nix and https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/emacs/elisp-packages/nano-theme/default.nix, maybe its installing the outdated version from manual elpa .nix?

We're using emacs-overlay, check that?

https://github.com/nix-community/emacs-overlay/blob/1a2382410521ef30343c5e7fca090517691883c4/repos/elpa/elpa-generated.nix#L2795 looks fine

Look at the directory from SPC h v load-path RET?

What does SPC h v run? I can't use any SPC bindings because doom is broken as its failing to load the missing package. I can only execute commands with M-x sorry for the trouble

Found it!

Each element is a string (directory file name) or nil (meaning
default-directory).
This list is consulted by the require function.
Initialized during startup as described in Info node (elisp)Library Search.
Use directory-file-name when adding items to this path.  However, Lisp
programs that process this list should tolerate directories both with
and without trailing slashes.

View in manual

References
Finding references in a .c file is not supported.

Find all references

Source Code
// Defined in /nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/src/lread.c
  DEFVAR_LISP ("load-path", Vload_path,
	       doc: /* List of directories to search for files to load.
Each element is a string (directory file name) or nil (meaning
`default-directory').
This list is consulted by the `require' function.
Initialized during startup as described in Info node `(elisp)Library Search'.
Use `directory-file-name' when adding items to this path.  However, Lisp
programs that process this list should tolerate directories both with
and without trailing slashes.  */);

Symbol Properties
initial-value
  ("/nix/store/hg2rcwrplb1xvpyysf5zki1nc6izjipg-doom-emacs/core/" "/Users/shauryasingh/.nix-profile/share/emacs/site-lisp/" "/etc/profiles/per-user/shauryasingh/share/emacs/site-lisp/" "/run/current-system/sw/share/emacs/site-lisp/" "/nix/var/nix/profiles/default/share/emacs/site-lisp/" "/nix/store/dijqfdjh754m0i3yl5jfdqfc9h4802kb-emacs-packages-deps/share/emacs/site-lisp" "/nix/store/z7qi68392cvs4plwci9iji9nz6r4ypcr-emacs-packages-deps/share/emacs/site-lisp" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/site-lisp" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/site-lisp" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/vc" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/url" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/textmodes" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/progmodes" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/play" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/org" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/nxml" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/net" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/mh-e" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/mail" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/leim" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/language" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/international" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/image" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/gnus" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/eshell" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/erc" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/emulation" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/emacs-lisp" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/cedet" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/calendar" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/calc" "/nix/store/zdlyk02gv3i9raigj1p54dn4jlkk4hqf-emacs-29.0.50/share/emacs/29.0.50/lisp/obsolete")
risky-local-variable
  t
variable-documentation
  731832

The weird thing is, [nix-shell:/nix/store/cmwg8j2y1xjkk6fjjm0wzii6avad5khc-straight-emacs-env/straight/build-29.0.50]$ rg nano-theme returns nothing. So although it's added the path for nano-theme, no repo exists under /nix/store/cmwg8j2y1xjkk6fjjm0wzii6avad5khc-straight-emacs-env/straight/build-29.0.50/nano-theme. Weird

emacs-overlay builds nano-theme fine so I think this may be nix-straight.el getting confused. Maybe play with the emacsPackagesOverlay argument to NDE.

Closing this issue in favor of https://github.com/nix-community/nix-doom-emacs/issues/252.
If you need more support visit https://matrix.to/#/#doom-emacs:nixos.org.


Refactor Storage classes, there is a lot of repeated code

For instance, this piece:
async getReadableStream(): Promise<StorageReadable> {
    const input = this.getDownloadUrl()

    const response = await axios({
      method: 'get',
      url: input,
      responseType: 'stream'
    })

    return {
      httpStatus: response.status,
      stream: response.data,
      headers: response.headers as any
    }
  }

is repeated on every storage class, exact same lines of code, 3 times
and there are other functions that basically have pretty much the same code like
async fetchSpecificFileMetadata(fileObject: IpfsFileObject): Promise<FileInfoResponse> {

closed on https://github.com/oceanprotocol/ocean-node/pull/299


Add Storage => Domain already exists

Similar to #1845
Describe the bug
I have Auth, Function and Api services in place.
I added Storage service and pushed.
The error on Cloudwatch has this messages:

message: Domain already exists. , code: AccessDeniedException
message: User XXXXX is not authorised to perform: cognito-idp:DeleteUserPoolDomain on resource: XXXXX code: InvalidParameterException
same as n.2
same as n.2

But the bucket on S3 is created
Expected behavior
successful s3 storage creation and use on the project
Additional context
amplify version: 1.8.5

I noticed that every time a add a custom attribute to my Cognito users then I have this error when I add storage

@AlessandroVol23 I suspect what's happening is that, when you're modifying/adding a custom attribute (which are immutable and shouldn't be updated after creation), Cloudformation is creating a new user-pool for you (with the new custom attributes), retaining the old one and trying to spin up a new hosted UI (with the same domain) as the previous user-pools hosted UI domain which still exists.
To get around this, you might want to delete the old cognito user-pool and remove the hosted UI endpoint using the AWS console to make the push succeed.

I see, thanks for the explanation @kaustavghosh06 , where exactly can I remove the hosted UI endpoint?

@AlessandroAnnini From your AWS cognito console.