For the 2.0 release we moved the examples to a `V1` syntax folder. We should eventually adapt these to the new syntax. https://github.com/zarr-developers/VirtualiZarr/issues/638 Good first issue if someone wants to get some experience working with VirtualiZarr.

Created: 6/30/2025

We would like `compute_cut` to optionally support QPU-level constraints, such as: - **Maximum number of logical qubits per partition** (e.g., 3 qubits per QPU) - **Device-specific capacity constraints** (e.g., one QPU with 2 qubits, another with 5) - **Weighted preference to minimize splitting logical qubits across partitions** ## Current Behavior `compute_cut` currently partitions HDH nodes by minimizing hyperedge cuts using METIS, but: - It does **not track or enforce logical qubit grouping** - It treats HDH nodes independently, leading to qubit fragmentation across partitions - There is **no capacity awareness** of target devices (QPUs) ## Desired Behavior `compute_cut` should accept an optional constraint like: ```python compute_cut(hdh, num_parts=2, max_qubits_per_partition=3)

Created: 6/30/2025

Currently there is a table of contents that links to sections of the page on the [AuthPolicy](https://docs.kuadrant.io/1.2.x/kuadrant-operator/doc/reference/authpolicy/), [TLSPolicy](https://docs.kuadrant.io/1.2.x/kuadrant-operator/doc/reference/tlspolicy/) and [DNSPolicy](https://docs.kuadrant.io/1.2.x/kuadrant-operator/doc/reference/dnspolicy/). I think it might be a good idea to add a similar table of contents to the [RLP page](https://docs.kuadrant.io/1.2.x/kuadrant-operator/doc/reference/ratelimitpolicy/) for the sake of consistency across pages.

Created: 6/30/2025

Is your feature request related to a problem? Please describe. Yes. In the Enatega Main App, the filter section currently spans three lines, and the Cuisines filter tabs appear on the third line. However, the second line has visible unused space on the right side. It's frustrating to see filters unnecessarily spread across multiple lines when better space optimization could enhance the user interface. Describe the solution you'd like I suggest repositioning the Cuisines filter tabs to fit on the right side of the second line where there is already empty space. This change would reduce the visual clutter, condense the filter area, and improve the overall layout without compromising readability or accessibility. Describe alternatives you've considered An alternative could be reducing the spacing or font size to fit all filters in fewer lines, but simply utilizing the available space on the second line is the most straightforward and elegant solution. Additional context This minor layout adjustment would significantly improve the UI, especially on mobile and smaller screens, by keeping the filter section compact and visually clean. It’s a small tweak with noticeable usability benefits.

Created: 6/30/2025

Update the text to `Manage pets, people, adoptions, and fosters with ease, for free.` on the application root page. <img width="530" alt="Image" src="https://github.com/user-attachments/assets/ffa0087d-8d83-4a49-bbfd-67ee814d4fff" />

Created: 6/30/2025

ADTs are built out of `defstruct` in release mode. The getters can be inlined at the Lisp level by codegenning some `cl:inline` declaims. h/t @cdegroot

Created: 6/30/2025

The idea here is return in yearly summary total planned, total expended, and total income for each month and create a chart to to be easy understand in which month the user waste more than planned or even more than earned. We need to search for a free library to help with this chart.

Created: 6/30/2025

The *Add to Cart + Options* block should be available as one of the *Transform to* blocks offered from the non-blockified *Add to Cart with Options* block. ## **To Reproduce** 1. Go to *Appearance* > *Editor* > *Templates* > *Single Product*. 2. Select the *Add to Cart with Options* block and click on its icon. 3. Notice the blockified *Add to Cart + Options* block is not available in the *Transform to* menu. <img src="https://uploads.linear.app/f629fcde-6f9b-48e8-8af3-60eed8823bff/838ca0f0-39f0-438b-94cf-7bdd33e54bf2/48ecaf95-692c-4d39-8328-6af9de61aaea?signature=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXRoIjoiL2Y2MjlmY2RlLTZmOWItNDhlOC04YWYzLTYwZWVkODgyM2JmZi84MzhjYTBmMC0zOWYwLTQzOGItOTRjZi03YmRkMzNlNTRiZjIvNDhlY2FmOTUtNjkyYy00ZDM5LTgzMjgtNmFmOWRlNjFhYWVhIiwiaWF0IjoxNzUxMjk2MjY4LCJleHAiOjMzMzIxODU2MjY4fQ.y88NXk9GQX2lFUJ1pwYQrZxZXH03m7-K5IRSbC5KBR0 " alt="imatge.png" width="969" data-linear-height="612" /> ## **Expected behavior** The *Add to Cart + Options* block should be available in the *Transform to* list of the non-blockified *Add to Cart with Options* block.

Created: 6/30/2025

The generated classes for various metadata were generated once and dumped into the `src/main/java/fr/progilone/pgcn/domain/jaxb` folder. Making the updating of said classes in case of a new specification version rather combersome. Fix Plan: - Add the jaxb2-maven-plugin to the build. With the `xjc` plugin. - Get all the xsd files corresponding to the classes. - Refactor the classes in the `src` folder by the generated at build time classes. Note: If the right versions of the xsd are found you would only need to update the import paths for the jaxb generated classes.

Created: 6/30/2025

To finalize, a few things need to be done: 1) `main` branch should be renamed It's probably wrong to out-right delete the branch. Uncertain of a good name; `sc101-v2`? `22`? 2) `legacy` branch should be renamed It's probably wrong to out-right delete the branch. Uncertain of a good name; `sc101-v1`? `20`? 3) `24` branch should be made the default As this is the current variant. 4) A new `main` branch should be created It should be based on `24` and should be where active development happens (making changes for core26, mostly).

Created: 6/30/2025

# Describe the bug The IBKRBroker builds an incomplete contract when placing equity orders: the exchange field is left blank and the contract is not qualified. When the order is submitted to a paper TWS / IB Gateway the server answers: ```bash Error 321, reqId X: Error validating request.-'bF' : cause - Missing order exchange. ``` IB immediately cancels the order, leaving it in PendingSubmit → Cancelled. As a result market orders never fill, limit orders never reach Submitted, and higher-level logic (tests, live trading) time out or mis-report status. # To Reproduce 1. Start IB Gateway or TWS in paper mode (port 7497). 2. Export credentials and run StrateQueue or the integration test: ```python from StrateQueue.brokers.IBKR.ibkr_broker import IBKRBroker from StrateQueue.brokers.broker_base import OrderSide, OrderType cfg = type("Cfg", (), {"credentials": {}, "paper_trading": True}) bk = IBKRBroker(cfg) bk.connect() res = bk.place_order("SPY", OrderType.MARKET, OrderSide.BUY, quantity=1) print(res.success, res.message) status = bk.get_order_status(res.order_id) print(status) ``` 3. Observe log / TWS “Order Cancelled – Reason 321: Missing order exchange”. # Expected behavior IBKRBroker should build a fully-qualified contract (exchange="SMART", currency="USD", optionally primaryExchange) and call ib.qualifyContracts(). Market orders should transition to Filled; limit orders to Submitted and remain cancelable. # Screenshots <img width="1065" alt="Image" src="https://github.com/user-attachments/assets/7362c174-540c-44ed-a8ea-1c5b295c857a" />

Created: 6/30/2025

Created: 6/30/2025

Describe the bug The concrete AlpacaBroker implementation does not behave as advertised in two key areas: 1. get_orders(symbol=…) forwards an unsupported symbol kw-arg to TradingClient.get_orders(), raising TypeError. 2. replace_order_by_id() succeeds on the Alpaca API, but the broker keeps referencing the original order-id. Subsequent calls to get_order_status() and cancel_order() therefore act on a non-existent order and fail. These gaps surface in the live integration-test suite but can also hit production code that relies on per-symbol order queries or order amendment flows. To Reproduce 1. Activate a venv with Python 3.10 and pydantic<2.6 (compatible with alpaca-py). 2. Export paper-trading creds (ALPACA_API_KEY, ALPACA_SECRET_KEY). 3. Run the live integration test (or execute the snippet below): ``` from StrateQueue.brokers.Alpaca.alpaca_broker import AlpacaBroker bk = AlpacaBroker(paper=True) bk.connect() # succeeds # --- BUG 1: symbol filter --- bk.get_orders(symbol="AAPL") # raises TypeError # --- BUG 2: replace / cancel bookkeeping --- order_id = bk.place_limit_order("AAPL", 1, 150, "buy") # returns 1st id new_id = bk.replace_order_by_id(order_id, 149) # API returns 2nd id assert new_id != order_id # ID actually changes bk.get_order_status(new_id)["limit_price"] == 149 # ⇒ KeyError bk.cancel_order(new_id) # ⇒ fails, id unknown ``` 4. Observe the exceptions / failed assertions. Expected behavior get_orders(symbol="AAPL") should return only AAPL orders without error. After a successful replace_order_by_id, all subsequent helper methods must use the new order-id and expose updated limit_price / stop_price fields. cancel_order() should be idempotent and succeed even if the order is already filled/cancelled upstream. Additional context - Root cause for bug #1 is passing symbol= directly to TradingClient.get_orders(), which only accepts a filter: GetOrdersRequest object. - Bug #2 stems from not tracking the new order-id returned by Alpaca’s PATCH /orders/{id} endpoint; the broker continues to cache the stale id in pending_orders. - A small patch that (a) filters orders client-side, (b) maps old→new ids, and (c) enriches order dicts with limit_price/stop_price fixes the failing integration tests (see PR #xxx for reference).

Created: 6/30/2025

please add a css doc with some styles

Created: 6/30/2025

Methods like `DeleteTo` do multiple deletions underneath that have to be done atomically. This is currently done via Batching, however, Batches [do not guarantee](https://github.com/ipfs/go-datastore/blob/bee84ceeb277b14249d1ac4297860fa7e52556f4/datastore.go#L97-L103) atomicity while transactions do. Basically, the issue is to identify other places like above where the transaction should be used instead and make it so

Created: 6/30/2025

## Description This is a feature request to add SHA-512 hash algorithm support to Trivy's SBOM parsing capabilities. Currently, Trivy only supports SHA-1, SHA-256, and MD5 hash algorithms when processing SBOM files. Some tools, particularly NPM's SBOM generation (`npm sbom`), use SHA-512 hashes for package integrity verification. Adding SHA-512 support would enable Trivy to fully process these SBOMs and preserve important security metadata. ### Current limitations: - **CycloneDX**: SHA-512 hashes are ignored and the hashes field becomes `null` - **SPDX**: SHA-512 checksums are completely omitted from the output ## Current Behavior ### CycloneDX In `pkg/sbom/cyclonedx/unmarshal.go:251-268`, the `unmarshalHashes` function only supports: - SHA1 - SHA256 - MD5 Any other algorithm (including SHA-512) logs a warning but still creates a digest with an empty algorithm prefix (e.g., `:hashvalue` instead of `sha512:hashvalue`), resulting in malformed digest strings. ### SPDX In `pkg/sbom/spdx/marshal.go:501-522`, the `spdxChecksums` function has the same limitation, returning `nil` for unsupported algorithms. ## Root Cause The limitation stems from `pkg/digest/digest.go` which only defines three algorithms: ```go const ( SHA1 Algorithm = "sha1" SHA256 Algorithm = "sha256" MD5 Algorithm = "md5" ) ``` ## Desired Behavior Trivy should support SHA-512 hash algorithm alongside the existing SHA-1, SHA-256, and MD5 support. This would enable Trivy to: - Preserve SHA-512 hashes when processing SBOMs from NPM and other tools - Generate SBOMs with SHA-512 hashes when appropriate - Maintain full compatibility with CycloneDX and SPDX specifications ## Impact - Loss of package integrity verification data - Generated SBOMs may be invalid or incomplete - Affects tools that rely on SHA-512 for security validation ## Proposed Solution 1. Add SHA512 constant to `pkg/digest/digest.go`: ```go const ( SHA1 Algorithm = "sha1" SHA256 Algorithm = "sha256" SHA512 Algorithm = "sha512" MD5 Algorithm = "md5" ) ``` 2. Add SHA-512 calculation support in the digest package 3. Update `unmarshalHashes` in CycloneDX: ```go case cdx.HashAlgoSHA512: alg = digest.SHA512 ``` 4. Update `spdxChecksums` in SPDX: ```go case digest.SHA512: alg = spdx.SHA512 ``` ## References - NPM SBOM documentation: https://docs.npmjs.com/cli/v10/commands/npm-sbom - CycloneDX hash algorithm specification: https://cyclonedx.org/docs/1.6/json/#components_items_hashes - SPDX checksum specification: https://spdx.github.io/spdx-spec/v2.3/package-information/#79-package-checksum-field ## Test Data ### CycloneDX Example ```json { "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json", "bomFormat": "CycloneDX", "specVersion": "1.5", "components": [ { "bom-ref": "lodash@4.17.21", "type": "library", "name": "lodash", "version": "4.17.21", "hashes": [ { "alg": "SHA-512", "content": "bf690311ee7b95e713ba568322e3533f2dd1cb880b189e99d4edef13592b81764daec43e2c54c61d5c558dc5cfb35ecb85b65519e74026ff17675b6f8f916f4a" } ] } ] } ``` ### SPDX Example ```json { "spdxVersion": "SPDX-2.3", "packages": [ { "name": "lodash", "SPDXID": "SPDXRef-Package-lodash-4.17.21", "checksums": [ { "algorithm": "SHA512", "checksumValue": "bf690311ee7b95e713ba568322e3533f2dd1cb880b189e99d4edef13592b81764daec43e2c54c61d5c558dc5cfb35ecb85b65519e74026ff17675b6f8f916f4a" } ] } ] } ``` ### Discussed in https://github.com/aquasecurity/trivy/discussions/9082

Created: 6/30/2025

In the `ICommonBridge.sol` interface, and hence `CommonBridge.sol` contract, we have a wrapper function `getPendingDepositLogs()(bytes32[])` (renamed to `getPendingTransactionHashes` after #3392) that just return the value of `pendingDepositLogs`. We should call `pendingDepositLogs()(bytes32[])` directly and remove `getPendingDepositLogs` to simplify the contracts

Created: 6/30/2025

### **Description 📹** Currently, the `leafIndex` used to store `commitment_hash_to_index` in `append_withdrawal_hash` relies on `leaf_count`, but this becomes inaccurate starting from the 3rd leaf. The actual index of the 3rd leaf jumps to 4 (while `leafCount` is 3), due to how the Merkle Mountain Range (MMR) structures nodes. This mismatch leads to off-chain verification failure when using the stored index, as it's no longer referencing the correct leaf position. The [Herodotus MMR playground](https://mmr.herodotus.dev/) allows you view how mmr trees are generated. Create a helper function to properly assign the index of the leaf. Reference: Checkout the `leafCountToMmrIndex` function in the L1 MerkleManager contract ### 📁 **File** `l2/src/core/ZeroXBridgeL2.cairio` ### 📋 **Required Guidelines** * Submit a PR only if assigned * Include `Close #[issue_id]` in your PR * Ensure successful build/test run * Keep logic minimal and clearly documented

Created: 6/30/2025 • 2 comments

[Zotero](https://www.zotero.org/) Export -> BibTeX:  Usage in Typst: ```typst #let my_bib = "Typst_Documentations.bib" #import "@preview/citegeist:0.1.0": load-bibliography #let bib = load-bibliography(read(my_bib)) #bib.noauthor_typst_nodate.fields.file #bibliography(my_bib, title: none, style: "ieee", full: true) Text @noauthor_typst_nodate ``` https://typst.app/universe/package/citegeist/ Integrating this logic directly into the template would save a lot of time and reduce complexity when writing a thesis.

Created: 6/30/2025

This standalone RewardShopModule enables users to spend earned points to claim virtual items from a reward shop. It handles item storage, purchase tracking, redemption validation, and provides a user-friendly API to browse and filter available rewards. **Tasks:** * [ ] Define `ShopItem` and `Purchase` entities to represent available items and user transactions * [ ] Implement redemption logic to validate point balances and process purchases * [ ] Create an API for listing available items with filtering options (e.g., category, price range, availability) **Note:** This module must be fully **independent** and should **not rely on any other modules** in the codebase.

Created: 6/30/2025 • 1 comments