Bug when using JOIN with WHERE clause

CrateDB version:
4.2.4
Environment description:
tarball
Problem description:
When doing a JOIN with a WHERE clause, the WHERE clause was optimised into the first JOIN, this lead to the expected results not being returned.
However, when running the same query as a subselect, the expected results are returned.
Steps to reproduce:
cr8 run-crate latest-stable -- @crash --hosts {node.http_url} <<EOF

CREATE TABLE subscriptions (
  id TEXT PRIMARY KEY,
  ref TEXT,
  offer TEXT
);

CREATE TABLE reports (
  id TEXT PRIMARY KEY,
  subscription_ref TEXT,
  cluster_id TEXT
);

CREATE TABLE clusters (
  id TEXT PRIMARY KEY,
  subscription_id TEXT,
  plan TEXT
);

INSERT INTO subscriptions (id, ref, offer) VALUES ('subs-1', 'ref-1', 'offer-1');
REFRESH TABLE subscriptions;

INSERT INTO reports (id, subscription_ref, cluster_id) VALUES ('rep-1', 'ref-1', 'cluster-1'), ('rep-2', 'ref-1', 'cluster-1'), ('rep-3', 'ref-1', 'cluster-2');
REFRESH TABLE reports;

INSERT INTO clusters (id, subscription_id, plan) VALUES ('cluster-1', 'subs-1', 'plan-1'), ('cluster-2', 'subs-1', 'plan-2');
REFRESH TABLE clusters;

-- expected: 6 rows
-- actual: 6 rows
SELECT *
FROM subscriptions
JOIN reports ON subscriptions.ref = reports.subscription_ref
JOIN clusters ON subscriptions.id = clusters.subscription_id
;

-- expected: 3 rows
-- actual: 0 rows
SELECT *
FROM subscriptions
JOIN reports ON subscriptions.ref = reports.subscription_ref
JOIN clusters ON subscriptions.id = clusters.subscription_id
WHERE clusters.id = reports.cluster_id
;

EXPLAIN
SELECT *
FROM subscriptions
JOIN reports ON subscriptions.ref = reports.subscription_ref
JOIN clusters ON subscriptions.id = clusters.subscription_id
WHERE clusters.id = reports.cluster_id
;

-- expected: 3 rows
-- actual: 3 rows
SELECT *
FROM (
  SELECT *, clusters.id AS a, reports.cluster_id AS b
  FROM subscriptions
  JOIN reports ON subscriptions.ref = reports.subscription_ref
  JOIN clusters ON subscriptions.id = clusters.subscription_id
) t
WHERE t.a = t.b
;

EXPLAIN
SELECT *
FROM (
  SELECT *, clusters.id AS a, reports.cluster_id AS b
  FROM subscriptions
  JOIN reports ON subscriptions.ref = reports.subscription_ref
  JOIN clusters ON subscriptions.id = clusters.subscription_id
) t
WHERE t.a = t.b
;

EOF

# run-crate
===========

Skipping download, tarball alrady extracted at /Users/fabian/.cache/cr8/crates/crate-4.2.4
Starting Crate process
CrateDB launching:
    PID: 18241
    Logs: /Users/fabian/.cache/cr8/crates/crate-4.2.4/logs/cr8-crate-run734582502.log
    Data: /var/folders/lt/tflbzl250nqdn3pmx1m7cdy80000gn/T/tmpuieaqtdx (removed on stop)

Psql      : <IP_ADDRESS>:5433
Http      : <IP_ADDRESS>:4201
Transport : <IP_ADDRESS>:4301
Cluster ready to process requests

# @crash
========

CONNECT OK
CREATE OK, 1 row affected  (0.677 sec)
CREATE OK, 1 row affected  (0.530 sec)
CREATE OK, 1 row affected  (0.574 sec)
INSERT OK, 1 row affected  (0.106 sec)
REFRESH OK, 1 row affected  (0.075 sec)
INSERT OK, 3 rows affected  (0.042 sec)
REFRESH OK, 1 row affected  (0.030 sec)
INSERT OK, 2 rows affected  (0.038 sec)
REFRESH OK, 1 row affected  (0.018 sec)
+--------+-------+---------+-------+------------------+------------+-----------+-----------------+--------+
| id     | ref   | offer   | id    | subscription_ref | cluster_id | id        | subscription_id | plan   |
+--------+-------+---------+-------+------------------+------------+-----------+-----------------+--------+
| subs-1 | ref-1 | offer-1 | rep-1 | ref-1            | cluster-1  | cluster-2 | subs-1          | plan-2 |
| subs-1 | ref-1 | offer-1 | rep-3 | ref-1            | cluster-2  | cluster-2 | subs-1          | plan-2 |
| subs-1 | ref-1 | offer-1 | rep-2 | ref-1            | cluster-1  | cluster-2 | subs-1          | plan-2 |
| subs-1 | ref-1 | offer-1 | rep-1 | ref-1            | cluster-1  | cluster-1 | subs-1          | plan-1 |
| subs-1 | ref-1 | offer-1 | rep-3 | ref-1            | cluster-2  | cluster-1 | subs-1          | plan-1 |
| subs-1 | ref-1 | offer-1 | rep-2 | ref-1            | cluster-1  | cluster-1 | subs-1          | plan-1 |
+--------+-------+---------+-------+------------------+------------+-----------+-----------------+--------+
SELECT 6 rows in set (0.052 sec)
+----+-----+-------+----+------------------+------------+----+-----------------+------+
| id | ref | offer | id | subscription_ref | cluster_id | id | subscription_id | plan |
+----+-----+-------+----+------------------+------------+----+-----------------+------+
+----+-----+-------+----+------------------+------------+----+-----------------+------+
SELECT 0 rows in set (0.009 sec)
+-------------------------------------------------------------------------+
| EXPLAIN                                                                 |
+-------------------------------------------------------------------------+
| HashJoin[((id = subscription_id) AND (id = cluster_id))]                |
|   ├ HashJoin[(ref = subscription_ref)]                                  |
|   │  ├ Collect[doc.subscriptions | [id, ref, offer] | true]             |
|   │  └ Collect[doc.reports | [id, subscription_ref, cluster_id] | true] |
|   └ Collect[doc.clusters | [id, subscription_id, plan] | true]          |
+-------------------------------------------------------------------------+
EXPLAIN 1 row in set (0.110 sec)
+--------+-------+---------+-------+------------------+------------+-----------+-----------------+--------+-----------+-----------+
| id     | ref   | offer   | id    | subscription_ref | cluster_id | id        | subscription_id | plan   | a         | b         |
+--------+-------+---------+-------+------------------+------------+-----------+-----------------+--------+-----------+-----------+
| subs-1 | ref-1 | offer-1 | rep-3 | ref-1            | cluster-2  | cluster-2 | subs-1          | plan-2 | cluster-2 | cluster-2 |
| subs-1 | ref-1 | offer-1 | rep-1 | ref-1            | cluster-1  | cluster-1 | subs-1          | plan-1 | cluster-1 | cluster-1 |
| subs-1 | ref-1 | offer-1 | rep-2 | ref-1            | cluster-1  | cluster-1 | subs-1          | plan-1 | cluster-1 | cluster-1 |
+--------+-------+---------+-------+------------------+------------+-----------+-----------------+--------+-----------+-----------+
SELECT 3 rows in set (0.012 sec)
+-----------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                |
+-----------------------------------------------------------------------------------------------------------------+
| Rename[id, ref, offer, id, subscription_ref, cluster_id, id, subscription_id, plan, a, b] AS t                  |
|   └ Eval[id, ref, offer, id, subscription_ref, cluster_id, id, subscription_id, plan, id AS a, cluster_id AS b] |
|     └ Filter[(id AS a = cluster_id AS b)]                                                                       |
|       └ HashJoin[(id = subscription_id)]                                                                        |
|         ├ HashJoin[(ref = subscription_ref)]                                                                    |
|         │  ├ Collect[doc.subscriptions | [id, ref, offer] | true]                                               |
|         │  └ Collect[doc.reports | [id, subscription_ref, cluster_id] | true]                                   |
|         └ Collect[doc.clusters | [id, subscription_id, plan] | true]                                            |
+-----------------------------------------------------------------------------------------------------------------+
EXPLAIN 1 row in set (0.004 sec)

@Taliik thank you for the report. The fix will be available in 4.2.5.


Doesn't properly freeze when there is a context menu

When there's something like this on screen(shown is bottles, but other gtk apps should work too), hyprpicker doesn't freeze the screen paired with the -r flag

And when actually using it as a color picker, it doesn't work(I'm not clicking nothing)
❯ sleep 5 && hyprpicker
#FFFFFF


NoMethodError: undefined method `maxmind' for #Geocoder::ConfigurationHash:0x007f85611dc890

View details in Rollbar: https://rollbar.com/trystant/BOW/items/327/

NoMethodError: undefined method `maxmind' for #<Geocoder::ConfigurationHash:0x007f85611dc890>
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/geocoder-1.2.8/lib/geocoder/configuration_hash.rb", line 8, in method_missing
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/geocoder-1.2.8/lib/geocoder/results/maxmind.rb", line 75, in service_name
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/geocoder-1.2.8/lib/geocoder/results/maxmind.rb", line 79, in field_names
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/geocoder-1.2.8/lib/geocoder/results/maxmind.rb", line 128, in respond_to?
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.6.rc1/lib/active_support/core_ext/object/try.rb", line 63, in try
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/ahoy_matey-1.1.1/lib/ahoy/deckhands/location_deckhand.rb", line 10, in country
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/ahoy_matey-1.1.1/lib/ahoy/visit_properties.rb", line 16, in country
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/ahoy_matey-1.1.1/lib/ahoy/visit_properties.rb", line 24, in []
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/ahoy_matey-1.1.1/lib/ahoy/stores/base_store.rb", line 71, in block in set_visit_properties
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/ahoy_matey-1.1.1/lib/ahoy/stores/base_store.rb", line 70, in each
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/ahoy_matey-1.1.1/lib/ahoy/stores/base_store.rb", line 70, in set_visit_properties
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/ahoy_matey-1.1.1/lib/ahoy/stores/active_record_store.rb", line 14, in track_visit
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/ahoy_matey-1.1.1/lib/ahoy/tracker.rb", line 35, in track_visit
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/ahoy_matey-1.1.1/app/controllers/ahoy/visits_controller.rb", line 5, in create
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_controller/metal/implicit_render.rb", line 4, in send_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/abstract_controller/base.rb", line 198, in process_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_controller/metal/rendering.rb", line 10, in process_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/abstract_controller/callbacks.rb", line 20, in block in process_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.6.rc1/lib/active_support/callbacks.rb", line 88, in __run_callbacks__
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.6.rc1/lib/active_support/callbacks.rb", line 778, in _run_process_action_callbacks
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.6.rc1/lib/active_support/callbacks.rb", line 81, in run_callbacks
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/abstract_controller/callbacks.rb", line 19, in process_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_controller/metal/rescue.rb", line 29, in process_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_controller/metal/instrumentation.rb", line 32, in block in process_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.6.rc1/lib/active_support/notifications.rb", line 164, in block in instrument
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.6.rc1/lib/active_support/notifications/instrumenter.rb", line 20, in instrument
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activesupport-4.2.6.rc1/lib/active_support/notifications.rb", line 164, in instrument
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_controller/metal/instrumentation.rb", line 30, in process_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_controller/metal/params_wrapper.rb", line 250, in process_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/searchkick-0.8.7/lib/searchkick/logging.rb", line 107, in process_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/activerecord-4.2.6.rc1/lib/active_record/railties/controller_runtime.rb", line 18, in process_action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/abstract_controller/base.rb", line 137, in process
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionview-4.2.6.rc1/lib/action_view/rendering.rb", line 30, in process
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_controller/metal.rb", line 196, in dispatch
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_controller/metal/rack_delegation.rb", line 13, in dispatch
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_controller/metal.rb", line 237, in block in action
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_dispatch/routing/route_set.rb", line 74, in call
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_dispatch/routing/route_set.rb", line 74, in dispatch
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_dispatch/routing/route_set.rb", line 43, in serve
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_dispatch/journey/router.rb", line 43, in block in serve
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_dispatch/journey/router.rb", line 30, in each
  File "/Users/dariusgoore/development/blackops/.bundle/gems/ruby/2.2.0/gems/actionpack-4.2.6.rc1/lib/action_dispatch/journey/router.rb", line 30, in serve
  File "/Users/dariusgoore/development/

This is a development issue that's occurring due to a resource copied from production without all the required information needed. This is a dupe and can be closed.


SwaggerGenOptions does not contain a definition for SwaggerDoc and no extension method...

SwaggerDoc will not resolve. Is this a known issue?
using Swashbuckle.Swagger.Model; isn't enough apparently.
services.AddSwaggerGen(c =>             {                 c.SwaggerDoc("v1", new Info { Title = "PayrollPredict API", Version = "v1" });             });

My apologies. I didn't use the proper PM command per the MD - Install-Package Swashbuckle.AspNetCore -Pre
I had installed 6.0.0.beta902.


Run rubocop

Wait until #22 is being merged. From the commit message:
OK, the diff is hard to understand, here's what I did:
1. Update the supported ruby version in `threema.gemspec` to `> =2.4`
2. Remove trailing comma in literal cop from `rubocop_todo.yml`, as it was outdated and not supported anymore.
3. Run `bundle exec rubocop -A`
4. Fix one cop manually by adding`_` underscore to unused variable in `lib/threema/receive/image.rb`
5. For the remaining cops, I decided to do:
  * `rm .rubocop_todo.yml`
  * `bundle exec rubocop --auto-gen-config`
  To recreate the config file

Hi @roschaefer - this PR is marked as a draft. Are you planning to add more changes? Personally I liked the aligned hash parameters. Better readability IMHO but I'm good with changing it to community defaults.

@thorsteneckel the only reason why this is marked as draft is that I wanted to rebase this PR on origin/master once #22 is merged. It's not so easy with forks to have:
master <-- PR1 <-- PR2

I sometimes do that in order to make it easier for the maintainer (you) to review my PRs.

Here you go.

Would you mind resolving the conflict? Happily merging afterwards.

@thorsteneckel do you know what needs to be done to enable reviews?

Merged and invited you to become a collaborator on this repository 💌


Improve tile lifecycle determinism

Addresses some observed behavior in the lifetime of tiles that wasn't initially expected. This PR makes some minor changes to how GeometryTiles update their pending status, to better reflect what the tile is actually doing. One of the more interesting observations is how a tile pyramid's call to setLayers() can dispatch a task on the worker thread before the tile has even loaded.
This PR should address #2807

Looks like it will also fix #2826!


Implement Cursor-Based Pagination for Recent Circuits Using activerecord_cursor_paginate.

What This PR Does:

Fixes #5195
Replaces OFFSET-based pagination for recent circuits on the home page with cursor-based pagination using the activerecord_cursor_paginate gem.
Removes dependency on will_paginate for recent circuits.
Updates the "Next" and "Previous" pagination links to match the production styling (using Bootstrap’s pagination classes).

Why:

OFFSET-based pagination is inefficient and not performant for large datasets.
Cursor-based pagination provides consistent and reliable pagination that adjusts gracefully to data changes.
Ensures the pagination UI aligns with the existing style guide and user expectations.

Key Changes:

circuitverse_controller.rb:

Uses cursor_paginate(after: ..., before: ...) and fetch to get paginated results.
Sets @projects_page and @projects = @projects_page.records to handle pagination data cleanly.

app/views/circuitverse/index.html.erb:

Removes calls to will_paginate.
Introduces the new pagination links styled with
 and .

Testing Done:

Manually tested by creating multiple circuits locally.
Verified pagination forward and backward using the new cursor parameters.
Ensured no JavaScript errors or layout issues occur.
Checked behavior with no data, small datasets, and larger datasets.

Additional Notes:

No changes made outside the scope of pagination and styling.
This update is intended to improve performance and maintain a consistent UX.

Screenshots (If Applicable):

Summary by CodeRabbit

New Features

Introduced cursor-based pagination for project listings, enhancing navigation and data retrieval.

Bug Fixes

Updated caching mechanism for recent projects to align with the new pagination method.

Documentation

Improved clarity on pagination logic in the user interface, providing intuitive navigation links for previous and next pages.

@tachyons pls review

@tachyons,
I think the vet OSS check failed due to a policy trigger on the yarn.lock file rather than an actual vulnerability.
The scan didn't find any issues; i think it's a policy-based fail that pops up when yarn.lock is altered.

@abhisek Error from vet
There are 102 more libraries that should be upgraded to reduce risk
Run vet with `--report-markdown=/path/to/report.md` for details

  ** 1305 libraries are exempted from analysis through exception rules

Run with `vet --filter="..."` for custom filters to identify risky libraries
For more details https://github.com/safedep/vet

scan failed due to error: CEL Filter Suite analyzer raised an event to fail with: failed due to filter suite match on yarn.lock
Generated vet markdown report at /home/runner/work/_temp/vet-tmp-0.ww83jtpsw6
Adding vet report as a comment in the PR
Warning: Unable to add a comment to the PR: Resource not accessible by integration - https://docs.github.com/rest/issues/comments#create-an-issue-comment
Error: One or more policy violation was detected!
Error: The process '/home/runner/work/_temp/e4b2eab2-1f59-415d-bfb6-1dd06ac7abee/vet' failed with exit code 255

@tachyons Thankyou for the approval, I enjoyed working on this issue, learned quite a bit of new things :)

@tachyons The vet failure happened due to bunch of low popular packages being introduced.
Assuming this is the failed run:
https://github.com/CircuitVerse/CircuitVerse/actions/runs/12197951311
It found the following packages violating policy

The failure is due to policy violation. The warning with issue comment is expected because this was a PR from a forked repo and GitHub Actions do not have the permissions in the GITHUB_TOKEN to write issue by default when the PR is from forked repo.

We are working to improve the experience using a GitHub App which should provide better integration and interaction with the PR workflow.

Suspect Issues
This pull request was deployed and Sentry observed the following issues:

‼ ActiveRecordCursorPaginate::InvalidCursorError: The given cursor MTQ3NjQzNw' could not be decoded (ActiveRecordCursorPaginate::InvalidCursorError) CircuitverseController#index View Issue

Did you find this useful? React with a 👍 or 👎

recent circuits seems to be working fine in prod with no issues...

That was already suggested by coderabbit, right ? Could you add that ?
On Fri, 6 Dec, 2024, 11:48 pm Aditya Singh, @.***>
wrote:

Suspect Issues
This pull request was deployed and Sentry observed the following issues:

‼ ActiveRecordCursorPaginate::InvalidCursorError: The given cursor
MTQ3NjQzNw' could not be decoded
(ActiveRecordCursorPaginate::InvalidCursorError)
CircuitverseController#index View Issue
https://circuitverse.sentry.io/issues/13648150/?referrer=github-pr-bot

Did you find this useful? React with a 👍 or 👎
recent circuits seems to be working fine in prod with no issues...
if i can get more details on this invalid cursor error i can add some
error handling for this @tachyons https://github.com/tachyons
—
Reply to this email directly, view it on GitHub
https://github.com/CircuitVerse/CircuitVerse/pull/5199#issuecomment-2523896027,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXYAECQOJOZ64D55OTKMQD2EHS57AVCNFSM6AAAAABTEO36XGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRTHA4TMMBSG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

@tachyons
This issue is a common challenge with cursor-based pagination, especially because I think we are handling user-modifiable parameters. By adding validation, error handling, and logging, this can be improved... If I can get the exact issue which is i guess only accessible to the members in circuitverse sentry ( I tried clicking on view issue ) I will get this error of invalid cursor edge case handled gracefully.

That was already suggested by coderabbit, right ? Could you add that ?
…
On Fri, 6 Dec, 2024, 11:48 pm Aditya Singh, @.> wrote: Suspect Issues This pull request was deployed and Sentry observed the following issues: - ‼ ActiveRecordCursorPaginate::InvalidCursorError: The given cursor MTQ3NjQzNw' could not be decoded (ActiveRecordCursorPaginate::InvalidCursorError) CircuitverseController#index View Issue https://circuitverse.sentry.io/issues/13648150/?referrer=github-pr-bot Did you find this useful? React with a 👍 or 👎 recent circuits seems to be working fine in prod with no issues... if i can get more details on this invalid cursor error i can add some error handling for this @tachyons https://github.com/tachyons — Reply to this email directly, view it on GitHub <#5199 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXYAECQOJOZ64D55OTKMQD2EHS57AVCNFSM6AAAAABTEO36XGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRTHA4TMMBSG4 . You are receiving this because you were mentioned.Message ID: @.>

sure let me do that right away


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-main" workflow

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

Comparison is base (a6eca89) 95.69% compared to head (e2440c9) 95.69%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #830   +/-   ##
=======================================
  Coverage   95.69%   95.69%
=======================================
  Files           1        1
  Lines         395      395
  Branches       53       53
=======================================
  Hits          378      378
  Misses         17       17

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


"The security token included in the request is invalid" for my AWS credentials

Hi there; I've checked my AWS credentials and start the service like this:
# dynamodb-cli -k AKXXXXXXX -s i1EXXXXXX -r eu-west-1
But then:
dynamodb> SHOW TABLES;
{ UnrecognizedClientException: The security token included in the request is invalid.

Any idea what I might be doing wrong? These are the same credentials I can use AWS command line with OK, and they have full DynamoDB access.
PS - this looks like an awesome resource and I'm surprised there aren't more stars and downloads on github

Sorry for late response!
Unfortunately this repository is unmaintained and missing the most important part
of a cli ... a solid IO piping ... that could be used in backups / restores etc.
Try maybe wrapping your credentials in double quotes or use environment credentials.
-adrian


Create node.js.yml

Can some check this out: https://github.com/skhalife/calculator/pull/16/checks?check_run_id=1365591901#step:6:79


Rework integration tests script

Is your feature request related to a problem? Please describe.
The integration test script should be re-worked to include the ability to run new DAP tests, and should be renamed to follow the test_<test type> scheme that most Cyberark projects follow.
That is, instead of having a separate test_enterprise script, we should have one single test_integration script that can be toggled to run tests against either oss or enterprise, and this single script can be invoked in the project pipeline.
As part of this card, we can also review the naming of the utility scripts to make sure that the exact behavior that each script does is clear from the name alone, and that we follow the convention of having bin/test_unit, bin/test_integration, bin/test_e2e, and bin/dev (as needed) so that it's easy for devs starting work on this project to get started. The docs on them will be cleaned up in #164.
Currently the script runs the Python integration tests by default, this should be changed so that users are required to specify a specific set of integration tests.
AC:

[ ] The test scripts use the common convention of being named bin/test_X, and are consolidated
[ ] Utility script names are clear
[ ] The integration test script doesn't have a default language that it runs, but requires a language to be passed in

Additionally I would like to see the way we run a given clients tests change. We currently use a -l <language> flag on the generated client and --<language> on the integration test script. We should bring these in line and add an extra flag to the integration tests script which allows passing a specific test to run.
So running just the secrets tests in Python would be: ./bin/integration_tests -l python --tests test_secrets_api


Get rid of NMS and reflection

Use of /tellraw command. Tested (https://www.spigotmc.org/resources/custommessagesplus-1-10-support.6443/).

Looks good – thanks for contributing!


No @generated/type-graphql folder in node_modules

Describe the Bug
I have followed your guide https://prisma.typegraphql.com/docs/basics/installation
No @generated/type-graphql folder in node_modules was generated
To Reproduce
Following your guide here on node 18.16.0?
Environment (please complete the following information):

OS:  Windows 10
Node  18.16.0

{
"devDependencies": {
"prisma": "^5.0.0",
"typegraphql-prisma": "^0.27.0"
},
"scripts": {
"preinstall": "nvm install && nvm use"
},
"dependencies": {
"@apollo/server": "^4.8.1",
"@prisma/client": "^5.0.0",
"@types/graphql-fields": "^1.3.5",
"graphql": "^15.0.0",
"graphql-fields": "^2.0.3",
"graphql-scalars": "^1.22.2",
"tslib": "^2.6.0",
"type-graphql": "^1.1.1"
}
}
Additional Context

I got the same issue, setting emitTranspiledCode = false does output the generated code correctly but with the transpilation turned on nothing is emitted. Still investigating so will get back here if I find anything else

Faced the same issue, but only while building a docker container. Can confirm, that emitTranspiledCode = false fixes my problem.
base is node:18.16-alpine.
package versions are: "@prisma/client": "^5.4.2","prisma": "^5.4.2", "reflect-metadata": "^0.1.13", "type-graphql": "2.0.0-beta.3", "typegraphql-prisma": "^0.27.0", "typescript": "5.2.2".
Same setup locally on MacOS it works fine. I'm trying to pin point the difference and create a repo.

@ivankhm amazing investigation. If it helps, ts-morph (https://ts-morph.com/setup/) is the package used to emit the transpiled code.  What's your node version locally? Thinking this might be some Node issue? 🤔

@MichalLytek without spending too much time on your end - do you happen to have an example repo I can quickly clone and debug this issue in? 🙏

My debug repo is the experiments folder in this repo - I test there all fixes and develop all the features 😉

Brilliant, will have a look and get back to you 🙏


ParseError import error

In file etree.py
from lxml import etree, ParseError

should be
from lxml import etree
from lxml.etree import ParserError

Fixed in https://github.com/geopython/OWSLib/commit/6f40078e0624079e266e00181b09e76c7956e733


Fix #8 by upgrading datauri to <0.8

This change adds support for Node v4.0+.
The rationale for choosing <0.8 is that v0.8 of datauri breaks
compatibility with Node v0.8, which grunt-datauri-variables supports.

Released on npm as 0.4.1 @jsepia :)

Thanks!


Tuple with struct incorrectly parsed - always errors

Description
Struct tuple incorrectly parsed, never passes validation:

Example tuple: (whitespace here for legibility)
[
  [{ "token": "0xSomeActualAddress", "id": "1000" }],
  [{ "token": "0xSomeActualAddress", "id": "4000" }]
]

contract tuple:
StructType {
  address token;
  uint256 id;
}

function someContractFn(
        string memory stringParam,
        uint256[] calldata _unit256ArrayParam,
        StructType[][] calldata _tupleParam
    ) external { ... }

Running this on etherscan works fine. I checked the tests written in this PR, which addresses the original issue opened, but I don't see any tests for struct tuples
Environment

Browser: Brave
Wallet: Brave wallet
Safe:
Environment:

production (goerli)

Steps to reproduce
For reasons of security on our side I don't want to give our contract, but any other contract requiring a struct tuple as a param will encounter this problem.
Expected result
Passes validation
Obtained result
Invalidated with: format error. details: typeerror: cannot read properties of undefined (reading 'length')
Screenshots

Also hi to the Safe team!

I have met the following error:

Hi @bradyjoestar for that _batchHeader struct defined in this contract 0x91A5D806BA73d0AA4bFA9B318126dDE60582e92a:
you can use a value like this:
[123,"0xAAAAFF", 1234, 1234, "0xAAAAFF", "0xAAAAFF"]

Hi @W3stside sorry for the late response.
For this tuple
StructType {
  address token;
  uint256 id;
}

You can use a value like this:
["0x57CB13cbef735FbDD65f5f2866638c546464E45F",1]

but in the method someContractFn  expects a matrix param likeStructType[][] calldata _tupleParam
A basic example of a valid value for that matrix is:
[
 [
    ["0x57CB13cbef735FbDD65f5f2866638c546464E45F", 1]
 ]
]

Could you provide me the contract address and the method that you want to use?

@DaniSomoza will give it a go, thanks!

[123,"0xAAAAFF", 1234, 1234, "0xAAAAFF", "0xAAAAFF"]

It worked ! Thank you for your help.

Hellow, in the case when the tuple is more complex, is there a way to match the format?
In my case this is the format:

Hello @DaniSomoza!
I'm facing a similar issue with the array of tuples: tuple(int64,tuple(string,uint256)[])[], while this test succeed after replacing the abi fragment and expected result with next values:

ABI fragment for input:

{
   "name":"s",
   "type":"tuple[]",
   "internalType":"struct Period[]",
   "components":[
      {
         "internalType":"int64",
         "name":"length",
         "type":"int64"
      },
      {
         "name":"c",
         "type":"tuple[]",
         "internalType":"struct Coin[]",
         "components":[
            {
               "internalType":"string",
               "name":"denom",
               "type":"string"
            },
            {
               "internalType":"uint256",
               "name":"amount",
               "type":"uint256"
            }
         ]
      }
   ]
}

input value: [[5000,[["random",100]]]]

During interacting with tx-builder the error is thrown at this line. And it looks like the issue is on web3-eth-abi side (https://github.com/web3/web3.js/issues/6307).
Do you have any advice how to use such structures as an argument?
Thanks in advance!

Given this struct:
StructType {
  address token;
  uint256 id;
}

Block explorers like Etherscan accept the format below for an array of tuples for that struct:
[{ "token": "0x0000000000000000000000000000000000000000", "id": 1 }]
Could we leverage this thread/issue for supporting this format?

I’m not sure if this issue is still relevant, but it looks like updating to the latest version of web3.js should resolve it. The fix was merged in September 2023. See https://github.com/web3/web3.js/issues/6307


Add SimpleRNN layer

This pull request adds SimpleRNN layer to lwtnn following the style of other recurrent layers.
Please let me know if there are any needed changes.

I created #151 to keep track of the unit test we'd like to have


Add additional About page accomplishments cards

Summary

[ ] Add card describing Global Hack 1.0 win
[ ] Add card describing Hack Quarantine win
[ ] Add card describing feature in Decrypt

Motivation
We want to share that we're succeeding!

I'll take this


Allow usages of closures for ffi callbacks.

Right now ffi callbacks have to be top-level functions. This creates major inconveniences, as the callback may need to access some state in dart. Which means that that state also has to be global state - which is not nice for encapsulation, testing, etc.
As part of the async callback implementation we use now dynamically allocated ffi trampolines. This opens up the possibility to remove the restriction that the callback has to be a top-level function. Instead we can allow closures:

main() async {
  final (a, b) = await invokeAsyncNativeOperation();
}

Future<(int, int)> invokeAsyncNativeOperation() async {
  final completer = Completer<(int, int)>();

  late RawNativeCallback callback;
  callback = RawNativeCallbacks<Void Function(Int64, Int8)>((int arg0, int arg1) {
    completer.complete((arg0, arg1));
    callback.close();
  });
  processAsynchronously(callback.nativeFunction);

  return completer.future;
}

@Native<Void Function(Pointer<...>)>()
void processAsynchronously(Pointer<...> callback);

(Compare this with how the code would need to be written if we only allow a top-level function)
The only requirement is that the closure given to the RawNativeCallbacks constructor has to have a static type (void Function(int, int) in this example) that is compatible with the native type function type (Void Function(Int64, Int8) in this example).
When the metadata is allocated it can then put a Dart_PersistentHandle referring to the closure into the metadata. When closing the callback the persistent handle could be freed.

/cc @liamappelbe @dcharkes

We could then extend the API to have a RawNativeCallback(<function>, {bool isSync: ...}) parameter, thereby allowing closures in synchronous callbacks as well.

Would be a definite usability win. Do it!
Having to use a top-level function just begs for a pattern like: late int Function(int, int) _actualFunction; int delegatingFunction(int a, int b) => _actualFunction(a, b);, where you set the function to actually call, globally, and then passes the delegating function to the native code. (Or some core function plus dynamic data stored on the side.)
That pattern doesn't scale. You need either a static function+state variable per native function to call, which means no creating native callbacks in loops.
Or you need to multiplex/trampoline by having the static function take an extra argument, which is used to look up dynamic state in a map, and passing the (key) value of the argument to the native code too. Which also complicates the native code.
And it would allow zone-aware callbacks, if you can do Zone.current.bind(callback) before wrapping it.
In fact, if possible, I think all native callbacks should be zone-bound by default, just like Dart async callbacks. It's far too easy to forget it, and you get weird errors when code runs in a different zone than expected. (There could be a "no zone" version as well, for when performance is the only thing that matters.)

I like everything in this thread! 👍

As part of the async callback implementation we use now dynamically allocated ffi trampolines. This opens up the possibility to remove the restriction that the callback has to be a top-level function.

Yes! Using an extra int argument and a map to find the right function as we have been recommending is not pretty at all.

{bool isSync: ...}

Should we consider an enum CallbackType instead? With values sync, asyncVoid, that enables us to have the same API for other types of callbacks if we want to in the future. From Liams doc:

block and wait to enter until isolate is free (with return value)
(the others we already have or are not callback types)

So then that CallbackType would get a third option blocking.

Doesn't that end up with the same problems we talked about here https://github.com/dart-lang/sdk/issues/51350? The sync and async constructors should probably be different, in case the APIs diverge as we add more optional params. For example, the sync callbacks will need an exceptional return.
The eventual goal of unifying them in one type sounds good to me though.

@liamappelbe I'm not seeing how this design would be different from the proposed RawVoidCallback, other than accepting more functions as argument to the constructor.
Which means that if we support function values as non-synchronous native callbacks, we should not introduce a new class, but just accept more arguments to RawVoidCallback.
A function which can return a value to massive code would be different, and maybe need a new class to support it, or maybe it should just be different constructors on the same class.

without it being a breaking change

The only question for a breaking change would be what the bool isSync or CallbackType callbackType would default to. If we now introduce RawNativeCallback for only async, making sync also use that API later and defaulting it to sync would be a breaking change.
My preference would be to introduce RawNativeCallback, but mark it as experimental. That way we can still decide to make the sync one the default when switching Pointer.fromFunction over. @mit-mit any opinions on whether async callbacks should be marked as experimental for the first release they will be in?

Let's consider all the functionalities we expect to eventually want, so we don't have to redesign the APIs later.
We already have "synchronous" Dart functions, which can only call back into Dart, into the same isolate, during a call out to native code. They can return a value immediately. They also need to, so the Dart function can't meaningfully return a future.
Then we have these fire-and-forget "event" Dart functions, where any native code can call them, at any time, and eventually they're executed in the originating Dart isolate. There is no return value, and no way to pass a value back.
There is no way to know whether anyone is still listening at the other end of the call, since there is no return channel at all.
There is a need to close down the listening end, since it may keep the isolate alive. (It would be great if ports had a flag that kept them from keeping an isolate alive, and this callback handler could have a similar flag, then you could choose to have a callback that only responds while something else keeps the isolate alive.)
This doesn't cover the following use-cases for native function pointes to Dart functions:

A Dart function which can be called back during a single native call, but which performs an async computation.
A Dart function which can be called from anywhere, but still return a value. (This function can be async too, we'.)

The former case might just be unacceptable, since it would allow asynchronous events to happend during an otherwise synchronous Dart execution. It's a way to get waitFor using native code.
So, maybe just not allow that. Which narrows the problems we need to solve to calling a Dart function, possibly async, from anywhere, and get a result back later somehow
The two immediate approaches would be:

Blocking until a result comes back.
Passing a native callback function as an argument in the call, and call that when the Dart result is ready. The native code has to handle its own asynchrony.

Blocking is bad. If I do a native call from Dart code, that native call does an "event" callback to the same isolate, then it can't block, because that would prevent control coming back to the isolate, so the event would never be handled. Houston, we have a deadlock.
The more approachable approach is to pass the native value callback as a native function pointer (or whatever works, in case we want to pass a C++ method pointer?), and then let the Dart side call the callback when it has a value.
That's something we can do with the VoidCallback already, just do:
var cb = RawVoidCallback<Void Function(Int32, Pointer<NativeFunction<Void Function(Int32)>>)>(
   void (int arg, resultCallback) async {
      var result = await asyncFibonnaci(arg);
      resultCallback(result); // or how we call a native function pointer.
   });

We can provide helpers, but since we can't abstract over argument lists, we can only do that for a certain set
of argument lists.
  /// Creates a native pointer which calls the [function] from native code.
  ///
  /// The native pointer takes an extra argument, which will be called with the result of [function]
  /// when the computation is done.
  /// If [maxCalls] is greater than zero, the native function stops working after [maxCalls] calls
  /// have been received.
  Pointer<NativeFunction<Void Function(T1, Pointer<NativeFunction<Void Function<R>>>)>>
    asyncFunction<R extends NativeType, T extends NativeTYpe>(
        @CorrespondingDartAsyncOrType<R Function(T1)>() FutureOr<Object?> Function(Never) function,
        {final int maxCalls = -1}) {
     var calls = 0;
     late RawVoidCallback<Void Function(T1, Pointer<NativeFunction<Void Function(Int32)>>)> cb;
     cb = RawVoidCallback((v1, callback) {
          if (maxCalls > 0 && ++calls >= maxCalls) cb.close();
          var result = await function(arg); // not actually type-sound, we need to know the Dart type corresponding to R.
          callback(result);
     });
    return cb.nativeFunction;
  }

(I'm sure we need to be much trickier than that, but that's the idea).
If so, I think the RawVoidCallback might be the only thing we really need, the rest can be built on top of that, and then it's just a matter of figuring out how to thread the static typing constraints through the calls.

Not quite sure what you're referring to here. The fact that exceptionalReturn was made a positional instead of a named parameter was a mistake. We're not making this mistake in the new class.

We have 2 distinct kinds of functions with 2 very different semantics (blocking vs non-blocking). They already require different constructor args, and it's very possible that we'll add more. Eg, as Lasse suggests, we could have a version of async callbacks that doesn't keep the isolate alive, which we'd probably do as a constructor flag that would only be applicable to async callbacks.
We'd have to document this constructor well, to capture all the combinations of args that are allowed, as well as documenting the behaviour differences. All these docs would be of the form "[blah blah] when isSync is true." or "When isSync is false [blah blah].". So I think it would be clearer and less error prone to just make them separate APIs (separate named constructors/static functions on the same class is fine). That way these differences would be self documenting.
This is the conclusion we came to in https://github.com/dart-lang/sdk/issues/51350. Rather than adding a flag to Pointer.fromFunction, we opted to add Pointer.asyncFromFunction.
I also like the idea of starting with RawVoidCallback and adding this abstraction later (probably by adding a RawNativeCallback interface that both the async void and sync classes implement). This would let users check what sort of callback they have with an is check. I can include that interface in the current CL if adding it later would be a breaking change somehow. We can still have constructors/static functions on the RawNativeCallback that delegate to the implementation class's constructors.

If so, I think the RawVoidCallback might be the only thing we really need, the rest can be built on top of that, and then it's just a matter of figuring out how to thread the static typing constraints through the calls.

Let me expand on that a bit:
Once we allow closures in callbacks (this issue) our synchronous callbacks that allow return values need to be allocated / freed. i.e. they become a resource. Using a class with the name RawVoidCallback isn't appropriate as it's not actually returning void.
Regarding the async callbacks with actual return values: One may execute the dart function in a temporary isolate (by invoking a closure with state) and return the result. (Some other solutions that we are unlikely to implement, but never say no: async callback that block, async callback that doesn't execute in event-loop cycle). Again here the name RawVoidCallback isn't appropriate.
So the question is whether we should then introduce more classes, or we choose a different name - e.g. RawCallback. On the surface it seems all scenarios can be covered with the same interface: Constructor (allocate resources), Pointer get nativePointer , close() method.
(In other parts of language we prefer single classes, e.g. List to cover const, immutable, growable, non-growable implementations)

So I think it would be clearer and less error prone to just make them separate APIs (separate named constructors/static functions on the same class is fine).
This would let users check what sort of callback they have with an is check.

It would certainly be different constructors. But the question is whether it should be separate classes. One can start with a RawNativeCallback with different factory constructors, and in the future make more classes and make the constructors return different classes. One cannot go the other way around (once RawVoidCallback, RawSyncCallback, RawSyncTempIsolateCallback, ... are out there, there's no going back)
I'm not too opinionated, but I lean on having a single class except if we have an actual need for having separate ones (e.g. if classes need different properties/methods, realistic reason a user may need to use is check on them, ...).
@lrhn you still think RawVoidCallback is the right choice? If so, we can also stick with that.

So the question is whether we should then introduce more classes, or we choose a different name - e.g. RawNativeCallback. On the surface it seems all scenarios can be covered with the same interface: Constructor (allocate resources), Pointer get nativePointer , close() method.

+1 I believe we should have different constructors but a single class.
The constructor we add now should then probably be asyncVoid or voidAsync on RawNativeCallback.

I still think it should be (expected future) use-case driven, so if the expected use-cases include allocating resources for any kind of function, uniformly, then I see no problem with having a single class representing that.
As long as users can tell which constructor to use, and what it does.
The typing will be tricky, because you're abstracting over parameter lists, but if your @CorrespondingDartType(...) hack works, it should help.
I still see async callbacks as significantly different from sync callbacks, whether void or not, because you'll always want to handle the future on the Dart side, which means the behavior is not entirely defined by the Dart function itself, but also by what happens after it returns. Which means that it will need a separate constructor, but not necessarily a separate "resource class".
But again, if you can filter on the static type of the function, so that nobody passes in a Future<int> Function(int) where a native Int32 Function(Int32) is needed, it shouldn't be a problem.
Or, consider separating the resource from the function, so you don't need to vary the nativeFunction getter, and do:
/// A native callback resource which listens for calls to a native function.
///
/// Creates a native callback by using one of the [createCallback] or [createAsyncCallback]
/// functions to link the call to a Dart function, which will eventually be run with the same
/// arguments, converted to Dart values.
///
/// The result of the Dart function
abstract class NativeCallback<T extends Function> {
  /// Allocates a native callback resource to receive calls to the returned native function.
  ///
  /// The native function type must be a `void` function type, and no value is returned
  /// to the caller.
  /// The call will not happen immediately, instead the isolate which created the
  /// native callback will run the callback function as a new event loop event.
  ///
  /// Use [NativeCallback.close] to free the resource when no further calls are expected.
  external static (NativeCallback, Pointer<NativeFunction<T>>) createVoidCallback<T extends Function>
      (@CorrespondingDartType("T") Function function);

  /// Allocates a native callback resource to receive calls to the returned native function.
  ///
  /// The native aller is blocked until the function result is available, at which point it's
  /// passed back to the caller, which is then unblocked.
  /// If the native call happens during a Dart call-out to the native code from the same
  /// isolate which created the native callback, the execution may continue on the same
  /// thread. Otherwise, that isolate will also be blocked until the code has run in
  /// the isolate which did create the native callback.
  ///
  /// Use [NativeCallback.close] to free the resource when no further calls are expected.
  external static (NativeCallback, Pointer<NativeFunction<T>>) createBlockingCallback<T extends Function>
      (@CorrespondingDartType("T") Function function);

  /// Allocates a native callback resource to receive calls to the returned native function.
  ////
  /// The native caller is blocked until the function result is available, which means
  /// after the async Dart [function] has returned a future, and that future has completed
  /// with a value. If the future completes with an error, the error is reported as uncaught,
  /// and the native function call returns zero-bits at its expected type (usually NULL-pointer
  /// or zero-valued integer).
  ///
  /// The Dart function is run in a *new* isolate, on a separate thread, as if by an `Isolate.run`
  /// from the isolate which created the native callback.
  ///
  /// Use [NativeCallback.close] to free the resource when no further calls are expected.
  external static (NativeCallback, Pointer<NativeFunction<T>>) createBlockingAsyncCallback<T extends Function>
      (@CorrespondingAsyncDartType("T") Function function);

  void close();
}

Maybe it's overkill, and not a problem because the type of the native function is always T get nativeFunction.
I'm worried that constructors can't restrict the type arguments passed to them, they can't have further constraints on the type arguments like a static function can, but since we can't limit the type in the Dart type system anyway, it's probably not a problem.

Ok, sounds like I'm outvoted on separating the classes.
Does it still make sense to call it RawNativeCallback, since we're scrapping the idea of leaning into the port style API? I think the original reasoning for including Raw in the name was that it was like a RawReceivePort, and we would later add a non-raw wrapper that looks more like a ReceivePort. If we're not planning to add a separate NativeCallback wrapper class, it probably makes sense to just call this one NativeCallback.
As for naming the constructors, from Lasse's example it sounds like createFooCallback is the naming pattern. Since we'd like to avoid sync vs async (to avoid confusion with the Dart keywords, which describe a different concept), I guess the real distinction is blocking vs non-blocking, or thread-safe vs thread-unsafe.
class NativeCallback<T extends Function> {
  // Sync vs async option.
  NativeCallback.createSyncCallback(@DartRepresentationOf('T') Function callback, {Object? exceptionalReturn});
  NativeCallback.createAsyncCallback(@DartRepresentationOf('T') Function callback);

  // Blocking vs non-blocking option.
  NativeCallback.createBlockingCallback(@DartRepresentationOf('T') Function callback, {Object? exceptionalReturn});
  NativeCallback.createNonBlockingCallback(@DartRepresentationOf('T') Function callback);

  // Thread safe vs thread unsafe option.
  NativeCallback.createThreadUnsafeCallback(@DartRepresentationOf('T') Function callback, {Object? exceptionalReturn});
  NativeCallback.createThreadSafeCallback(@DartRepresentationOf('T') Function callback);

  Pointer<NativeFunction<T>> get pointer;

  void close();
}

I'm worried that constructors can't restrict the type arguments passed to them, they can't have further constraints on the type arguments like a static function can, but since we can't limit the type in the Dart type system anyway, it's probably not a problem.

We'll have custom logic for check the correspondence between Dart and C types anyway. So making that logic check for Future<int> instead of int would be easy.

If it's a constructor, I'd remove the create. My examples were suggesting static factory functions to allow restricting the type parameters allowed for each (you cannot restrict a constructor to a subset of the types allowed by the class, sadly).
That might not be practical, since the type argument is T extends Function> anyway, and we cant restrict to only Void Function(something) in the current type system. In that case using a constructor is fine.
And constructor always have an implicit create, so you don't need to write it.
Also no need to repeat Callback, the class name is part of constructor names, more than they are of static names, so
Not sure the createSyncCallback fits in here, if it doesn't have to allocate a resource that must be closed.
(In that case, if we still do want it here, I'd make it just a static function returning just a Pointer<NativeFunction<T>>, not a constructor, since it doesn't need a NativeCallback resource object allocated.)
Also not sure about the separation of the three concerns (immediate/delayed, blocking/non-blocking and must-be-same-thread/can-be-any-thread/must-not-be-same-thread), since I think they are linked, some do not make sense by themselves, and some do not make sense combined.
A native function can either be fire-and-forget or wait for a result (or even just wait for completion).
Waiting for completion/result can happen in two ways:
* Run everything on the same thread, until completed.
* Block and run everything on a separate thread, then unblock when the result is ready.
If you run everything in the same thread, you might be able to call back into the current isolate, the one which called into the native code doing the callback. You probably can't run code in other existing isolates. You may be able to synchronously spawn a new isolate, run the callback function in that, take the results back out, and shut the isolate down again, all using only the one thread.
That suggests, to me, that the main categories of callbacks could be: immediate or fire-and-forget.
An immediate function can return a result, or guarantee the code has run, and the fire-and-forget returns immediately, and something happens later in Dart code, somewhere.
The immediate can work in two ways: Blocking or non-blocking. Blocking allows waiting for other threads, but precludes using the current thread. Nonblocking means using only the current thread.
Then callbacks can be separated into whether they expect to run in their original isolate, or if we want to create/spawn a new isolate and run them in that. Which is obviously more expensive (but maybe an isolate can be created by the NativeCallback creation in anticipation of getting called into, especially if it can be reused for multiple calls. But if there are multiple calls from different threads, then it won't be thread safe.).
So, the combinations that make sense are:

Specific/other isolate callback:

Immediate, unblocking: Calls directly back into the current thread's isolate and runs Dart code on top of the stack which contains existing Dart code stacks for that isolate. Only works for callbacks created by that isolate. (Checks that it runs in the same thread as the isolate it wants to call back into, fails if not.)
Immediate, blocking: Blocks current thread, triggers event which runs Dart function in its originating isolate. May wait for async results too. Returns the result, then unblocks. (Cannot work for current isolate, since it would block handling the event.)
Fire-and-forget: Triggers event which runs Dart function in its originating isolate (what started this issue).

New isolate callback:

Immediate: Synchronously spawns a new isolate from the originating isolate, runs the function in that, gets the (non-async) result, shuts down the isolate, returns the result. All on the same stack.
Immediate blocking: Blocks. Spawns new isolate in new thread, runs function in it, wait for result (may event be async). When ready, shut down isolate with result, and unblock.
Fire-and-forget: Triggers event to later spawn a new isolate, run the Dart function in it, and shut down the isolate normally when there's nothing more for it to do.

I might go with the following combinations:
/// A native callback resource which listens for calls to a native function.
///
/// Links a native function to to a Dart function, so that calling the native function will
/// call the Dart function in some way, with the same arguments as converted to Dart values.
///
/// Some callbacks return values as well, others do not.
///
/// Some callbacks must be called on the same thread that the isolate creating it is running on,
/// others must not. Some work on any thread, either by not waiting for a result, or by blocking
/// the current thread if necessary.
///
/// The native callback allocates resources link Dart functions to native functions, and to
/// receive events from other isolates or threads. Those _must_ be disposed by calling
/// [close], when no more callbacks are expected.
/// After calling [close], no further calls to the native function will succeed.
/// Blocking calls *may block indefinitely* on a closed native callback,
/// so it's important to manage access to callbacks, and to not close the callback too early.
///
/// The [T] must be a native function type, like `Void Function(Int32)`.
class NativeCallback<T extends Function> {
  // If the first one needs to allocate resources to handle closure callbacks, just make it a constructor too.

  /// Must only be called in native code called to by the same isolate which created the callback.
  ///
  /// The return value of [callback] is directly sent back to the calling native code.
  /// Therefore the return value cannot be a future.
  ///
  /// If the Dart [callback] function throws, the error is recorded as an uncaught error
  /// and the [exceptionalReturn] value is returned instead.
  /// If [exceptionalReturn] is omitted or `null`, it defaults to a zero-value of the corresponding
  /// native type (a NULL-pointer, zero number value or false boolean).
  external static Pointer<NativeFunction<T>> immediate<T extends Function>(
      @DartRepresentationOf('T')
      Function callback,
     {@DartRepresentationOfReturnTypeOf('T')
      Object? exceptionalReturn,
     });

  /// Creates a native callback whose [nativeFunction] requests an execution of [callback].
  ///
  /// The native function type [T] must be a `void` function, like `Void Function(Int32)`.
  ///
  /// Native code on any thread can invoke the [nativeFunction], which immediately returns
  /// to the native code execution.
  /// At some later point, as an event, the isolate which originally created the native callback
  /// will execute the [callback] function. It's return value is ignored. Any errors thrown,
  /// immediately or asynchronously, become uncaught errors in that isolate.
  // TODO: run the function in the current zone? Yes, please, if possible.
  external NativeCallback.delayed(@DartRepresentationOf('T') Function callback);

  /// Creates a callback which may be called from any thread.
  ///
  /// If called from the thread of the same isolate which created the native callback,
  /// it will work like [NativeCallback.immediate], and calls directly back into the isolate.
  ///
  /// If not, the thread calling the native function will block, then trigger a later invoacation
  /// of the callback in its originating isolate with the provided arguments.
  /// When that synchronous invocation is complete, the result is sent back, and the calling
  /// thread is unblocked again with that return value.
  ///
  /// If the Dart [callback] function throws, the error is recorded as an uncaught error
  /// and the [exceptionalReturn] value is returned instead.
  /// If [exceptionalReturn] is omitted or `null`, it defaults to a zero-value of the corresponding
  /// native type (a NULL-pointer, zero number value or false boolean).
  NativeCallback.mayBlock(
      @DartRepresentationOf('T')
      Function callback,
     {@DartRepresentationOfReturnTypeOf('T')
      Object? exceptionalReturn,
     });

  /// Creates a callback which calls an async Dart function from another isolate.
  ///
  /// The callback may have a `Future` or `FutureOr` return type, and if it returns
  /// a future, that future will be awaited before the result is returned.
  ///
  /// If called on the thread of the isolate which created the native callback,
  /// the callback will fail and return the [exceptionalReturn] value.
  ///
  /// When called from another thread, the thread is blocked,
  /// and it triggers a later execution of the [callback] function in the isolate
  /// which created the native callback, with the provided arguments.
  /// When that computation completes with a result value, waiting for a future if necessary,
  /// the calling thread is unblocked with that return value.
  ///
  /// If the Dart [callback] function throws, the error is recorded as an uncaught error
  /// and the [exceptionalReturn] value is returned instead.
  /// If [exceptionalReturn] is omitted or `null`, it defaults to a zero-value of the corresponding
  /// native type (a NULL-pointer, zero number value or false boolean).
  external NativeCallback.blockingAsync(
      @DartAsyncOrRepresentationOf('T')  // Same as DartRepresentationOf, except for `FutureOr` on return.
      Function callback,
    {@DartRepresentationOfReturnTypeOf('T')
      Object? exceptionalReturn,
     });

  /// Creates a callback which calls an async Dart function in a new isolate.
  ///
  /// The callback may have a `Future` or `FutureOr` return type, and if it returns
  /// a future, that future will be awaited before the result is returned.
  ///
  /// Calling the native function will block the current thread, then
  /// *spawn a new isolate* from the isolate which created the native callback,
  /// and run the [callback] in that isolate (similarly to [Isolate.run]).
  /// When that computation completes with a result value, waiting for a future if necessary,
  /// the isolate is shut down again, and the calling thread is unblocked with that return value.
  ///
  /// If the Dart [callback] function throws, or the new isolate exits preamturely,
  /// the error is recorded as an uncaught error and the [exceptionalReturn] value is returned instead.
  /// If [exceptionalReturn] is omitted or `null`, it defaults to a zero-value of the corresponding
  /// native type (a NULL-pointer, zero number value or false boolean).
  external Native.blockingNewIsolateAsync(
      @DartAsyncOrRepresentationOf('T')
      Function callback,
    {@DartRepresentationOfReturnTypeOf('T')
      Object? exceptionalReturn,
     });

  // We can have an `blockingOtherOrNewIsolate` which runs a callback in another isolate,
  // but if trying to do it in the same isolate, it spawns a new one. Probably too confusing.

  /// The native function which can be used to invoke the `callback` passed to the constructor.
  Pointer<NativeFunction<T>> get nativeFunction;

  /// Closes the native callback for further invocations and releases its resources.
  ///
  /// Existing running invocations are not affected.
  ///
  /// The [nativeFunction] *must not* be called after the native callback has been closed.
  /// Later invocations of the [nativeFunction] may do nothing, may crash, may block its thread
  /// indefinitely, may return a default value, and may invoke a completely different function.
  void close();
}

Some of these require the native function to have some leading logic which checks whether the isolate
it wants to invoke is the same that called it (if any), or not. More precisely, it needs to ensure it doesn't block the thread which runs the event loop of the isolate it wants to send an event to.
The "block and send event if other isolate, call sync if same" one might be tricky, depending on how much control you have over the native code stubs you generate for the nativeFunction, but it's basically just the same code paths as immediate plus what you'd do for an unonditional blocking constructor, and it avoids the error-case of blocking the current isolate forever.

Also not sure about the separation of the three concerns (immediate/delayed, blocking/non-blocking and must-be-same-thread/can-be-any-thread/must-not-be-same-thread), since I think they are linked, some do not make sense by themselves, and some do not make sense combined.

It's late here, so I'll respond to the rest of this tomorrow. Just wanted to clarify that my example only has 2 constructors, but I was presenting 3 different pairs of naming options.

Ah, that makes sense. In that case I might just go with .immediate and .delayed, if those are the only two constructors we'd ever need.
But I'd consider if we want more constructors later, and make sure we can distinguish all the use-cases that we want. If we want two different "delayed" versions, we might want to name them fooDelayed and barDelayed and not have one ambiguously called just delayed.
So, prepare for everything we can imagine! :sweat_smile:

Not sure the createSyncCallback fits in here, if it doesn't have to allocate a resource that must be closed.

If we want to support closures in these callbacks (the topic of this bug), then we'll need a close method to clean up the closures. They'll also be cleaned up on isolate shutdown, but there will be cases where waiting for the isolate to shutdown will cause the number of active callbacks to grow unbounded.

Ah, that makes sense. In that case I might just go with .immediate and .delayed, if those are the only two constructors we'd ever need.

Hmmm. I like "immediate", but "delayed" makes me think of Future.delayed, so implies some sort of fixed duration delay. It's hard to find good synonyms for "async" that don't have strange implications, so maybe we should just go with "async". It's probably the most accurate, all things considered, and making the other option "immediate" rather than "sync" helps reduce confusion with the sync/async keywords.

But I'd consider if we want more constructors later, and make sure we can distinguish all the use-cases that we want.

In that case let's call include "void" in the name.
class NativeCallback<T extends Function> {
  NativeCallback.immediate(@DartRepresentationOf('T') Function callback, {Object? exceptionalReturn});
  NativeCallback.asyncVoid(@DartRepresentationOf('T') Function callback);

  Pointer<NativeFunction<T>> get pointer;

  void close();
}

Discussion w @mkustermann @mraleph @lrhn @HosseinYousefi @liamappelbe and me:

NativeCallable abstract class with factory constructors

listener
isolateLocal
("blocking" -> this one blocks if you're on a thread that has not entered the isolate. It has a fast path to isolateLocal.)

doc for isolateLocal:
/// Creates native function calling directly back into this isolate.
///
/// The native function must only be called from the same thread
/// that the isolate which created this native callback called out to native code on.

class NativeCallable<T extends Function> {
  NativeCallable.isolateLocal(@DartRepresentationOf('T') Function callback, {Object? exceptionalReturn});
  NativeCallable.listener(@DartRepresentationOf('T') Function callback);

  Pointer<NativeFunction<T>> get pointer;

  void close();
}

Make it
  Pointer<NativeFunction<T>> get nativeFunction;

and I'm happy :grinning:
(Could there be a
@DartRepresentationOfReturnTypeOf('T')

that could be applied to exceptionalReturn?)


add callout about performance of read committed isolation

Some early testers of the public preview of Read Committed isolation in 23.2 have been surprised that it does not necessarily improve throughput of their workload compared to Serializable isolation. There are at least a few specific reasons for this in 23.2:

locks acquired by FK checks, SELECT FOR UPDATE, and SELECT FOR SHARE are fully replicated under Read Committed isolation, which adds a delay for raft replication
FK checks are not performed in parallel under Read Committed isolation
SELECT FOR UPDATE and SELECT FOR SHARE statements are less optimized under Read Committed isolation

More generally, we don't guarantee improved throughput when using Read Committed isolation, but rather more predictable throughput due to fewer transaction retries and aborts. (This might change as we spend more time optimizing RC.)
Would it be possible to add a callout to the Read Committed Transactions docs to this effect? Not sure what the exact wording would be... something to set expectations, and convey the message that workloads running well under Serializable isolation should not change to Read Committed isolation unless there is a pressing reason.
(This topic was discussed at length here.)

After some discussion we're thinking it might be better to mention these three specific items in known limitations rather than adding a callout.

These three items have been added to known limitations. Thanks! Closing.


Error while downloading the document file to be converted.

I've installed owncloud, and run Docker image ONLYOFFICE
I got correct https://my.owncloud.host:docker-port/welcome/
but when I try set onlyoffice settings in owncloud panel, I got "Error while downloading the document file to be converted."
I search about 6 hours this problem, and make all advises but it still do not work
And I see that inside container I can't resolve owncloud host
wget: unable to resolve host address ‘my.owncloud.host’
I'm using one SSL Let'sEncrypt serts on both
Running docker image by
docker run -i -t -d -p 8443:443     -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data  onlyoffice/documentserver
enabled SSL3 in docker
root@d54f96f3bd8c:/# openssl s_client -ssl3 -connect <IP_ADDRESS>:443
139969868351128:error:140A90C4:SSL routines:SSL_CTX_new:null ssl method passed:ssl_lib.c:1878:

set up
'onlyoffice' => array ( 'verify_peer_off' => true, ),
in the owncloud config
and
"rejectUnauthorized": false
in /etc/onlyoffice/documentserver/default.json

Hello @RebelUkraine
First you have to make sure that the domain name of your ownCloud can be resolved from the Document Server container. As a workaround, try to add the pair IP/domain of your ownCloud to /etc/hosts in the container.

now it resolving
root@aed32e1dfcb2:/# wget https://cloud.rockwill-wealth.co.uk/
--2019-12-03 11:29:38--  https://cloud.rockwill-wealth.co.uk/
Resolving cloud.rockwill-wealth.co.uk (cloud.rockwill-wealth.co.uk)... <IP_ADDRESS>
Connecting to cloud.rockwill-wealth.co.uk (cloud.rockwill-wealth.co.uk)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://cloud.rockwill-wealth.co.uk/index.php/login [following]
--2019-12-03 11:29:38--  https://cloud.rockwill-wealth.co.uk/index.php/login
Reusing existing connection to cloud.rockwill-wealth.co.uk:443.
HTTP request sent, awaiting response... 200 OK
Length: 10565 (10K) [text/html]
Saving to: ‘index.html’

index.html          100%[===================>]  10.32K  --.-KB/s    in 0s

2019-12-03 11:29:38 (67.7 MB/s) - ‘index.html’ saved [10565/10565]

@RebelUkraine
Please check the log /var/log/onlyoffice/documentserver/converter/out.log inside the container. What errors do you see there?

[2019-12-03T11:36:37.933] [ERROR] nodeJS - error downloadFile:url=https://my.owncloud.host:8443/index.php/apps/onlyoffice/empty?doc=eyJ0eXAiOiJKV1QiL                                                                                CJhbGciOiJIUzI1NiJ9.eyJhY3Rpb24iOiJlbXB0eSJ9.ZVm9UStcfWPVJy3AdjWAB3Oo2ntLh-f7OaN                                                                                k0eJSI4U;attempt=3;code:null;connect:null;(id=conv_check_534095589_docx)
Error: Error response: statusCode:404 ;body:

Error

Cannot GET /index.php/apps/onlyoffice/empty

Holy scripts!!!!! I Think found my problem!!!
In setup of onlyoffice in owncloud panel, i set additiobal setting. But when i removed additional settings, all is start working.
Thanx for your response  @CarlOnlyoffice

@RebelUkraine
Glad you have found the reason of the issue.


Compressed API Responses

The Cumulocity API is supporting gzip compression - I think go-c8y-cli does not support that yet (at least I did not see the Accept-Encoding: gzip header in the requests sent by CLI).
Should this be supported? If yes, by default or opt-in feature via configuration?

This has been included since 2.38.0.
Compressed message are enabled by default and it occurs transparently to the user.


Why not unit tests?

@andreftavares Why didn't you write any test 😇
Are there any plans on writing?👷

The usual suspect, for both not having written and for not knowing when they'll be: time :) Feel free to create a PR!

@andreftavares I am facing few issues while integrating.
Can you integrate do some basic test /api with either Lab, Tape or Jest.
I will do the rest.


How to disable option?

Hi,
I have one option that I want to hide/make unselectable. Does this plugin allow that? I haven't seen any method for it.

https://www.zellerda.com/projects/jquery/tokenize
Section "Using the api" you can find "enable" and "disable" method

a) it does not have documentation in the API section, just in how to use section
b) that, from my understanding, disables the whole element, I just want to hide/disable a single option

Ok I understand, just access directly to the option in the select with jquery and disable it.

Neither prop('disabled', true) or attr('disabled', 'disabled') is working.

If you use AJAX that will not work, you have to filter your items on the server side
Here is my sample test:
<select class="tokenize select" multiple="multiple">
    <option selected value="Adrienne">Adrienne</option>
    <option selected value="Nevada">Nevada</option>
    <option value="Petra">Petra</option>
    <option value="Georgia">Georgia</option>
    <option value="Ashley">Ashley</option>
    <option value="Silvia">Silvia</option>
</select>
<script>
    $('.tokenize').tokenize({});
    $('.tokenize option[value=Petra]').prop('disabled', true);
</script>

I am not using ajax.
My script is:
(function($) {

  // DOM ready.
  $(function() {

    // Initialize tokenize script on all select elements with multiple
    // choices.
    // Allow elements to opt-out by using the 'skip-tokenize' class.
    $('select[multiple="multiple"]').once('tokenize').not('.skip-tokenize').each(function() {
      $(this).find('option[value="_none"]').prop('disabled', true);
      // Allow elements to provide placeholder.
      var placeholder = $(this).data('tokenize-placeholder') || false;
      // Allow elements to use custom configuration via 'data-tokenize-config' attribute.
      var default_config = { displayDropdownOnFocus: true, 'placeholder': placeholder };
      var config = $(this).data('tokenize-config') || default_config;
      $(this).tokenize(config);
    });

  });

})(jQuery);

My html is:
<select class="form-select" id="edit-tags" name="tags[]" multiple="multiple" aria-describedby="edit-tags--description" data-drupal-selector="edit-tags"><option selected="selected" value="_none">- None -</option><option value="33">Test</option></select>

Found, just correct like this
$(this).find('option[value="_none"]').prop('disabled', true).prop('selected', false);

If an element is already selected you cannot disable it

Thanks, but that just un-made it default value. The option can still be selected - it is present in the list. I do not think disable works in this case at all. Maybe removing the option completely would be a better option?

Yes removing the option will be the best solution.

Ok, thanks.

At some point in 2015 the .disable() method was added to the jquery.tokenize library.


Removes the blockscout deployment

Description
Removes all reference to blockscout in the conf
References (if applicable)

To be tested on next redeployment


Basic-Auth with embedded etcd

Hello,
It seems that using k3s v1.19.3 with embedded etcd , it is not possible to use basic-auth anymore, it is the case ?
At the moment since k3s v0.7 I was adding my user/password to the /var/lib/rancher/k3s/server/cred/passwd file and reloading k3s-server service to take it into account.
Is it still possible to keep doing that with embedded etcd , or is basic-auth no longer available ?
Regards,

Closing , as basic-auth has been remove from kubernetes, switching to token-auth


Add API that allows the parent to grab a frame from the stream being decoded

Sometimes it might be of interest to take a picture out of the video stream that is currently decoded. This pull request adds this capability to the component.
It also refactors how the elements within the component are linked with the JavaScript code: Instead of using fixed IDs, ElementRefernce is used. Doing so should prepare the component for multiple instances (yet, there are still a couple of "singletons" left in the JS code...)
The image is transferred from JS to .NET through either a marshalled or unmarshalled channel. Unmarshalled is preferred as it's lightning fast compared to marshalled (see extensive comment in Capture).
There are a couple of potential improvements left which I did not touch so far:

Currently a frame is grabbed from the video stream. Yet ImageCapture features a takePhoto call which might be able to provide even better quality still images. So it might be worth investigating in that functionality.
ImageCapture appears to be unsupported by Safari and Firefox. A browser dependent polyfill has to be added to the component in order to support those platforms.

@sabitertan this could make a potential polyfill. Yet it's Apache, not MIT license. Do you have any opinion what would be best regarding Firefox and Safari support?


review m.getInvocationNumbers() method and how it works with default and custom data providers

maybe we can specify invCount more properly for the dataproviders without unique TUID arguments

already fixed in 6.3.30 - we could detect index of the dataprovider line correctly and handle rerun failures ideally using Zafira. No more rerun of all lines in dataprovider. Fixes from all sides will be delivered as part of qps-infra 4.8 release


Require torque with github repository instead of version

@rochoa @javisantana

The problem using versioning here is, if we change something in torque.js, and we don't bump the package version, running npm install will not update anything from that dependency because it thinks it is the same.

IMO we should not use a branch for a dependency.
BTW why did you have to change those tests?/

Related with last changes in torque, testing that Map {} is present in the cartocss.
https://github.com/CartoDB/torque/commit/0e9184e02629c07a6323c8fc955e2760f6710226

If we don't use a branch, we should take care of the version, I'm ok with that, but if it has happened once, it could happen again.

I'm lost: what was the problem?

We have to publish the version to NPM.


Add support for MRC recording from the PV camera

Overview
Adds support for MRC recording from the PV camera for HoloLens 2. When recording MRC on a HoloLens, by default, the holograms render from the head while recording is taking place from the PV camera, which is slightly offset from the center of the head. With this new HoloLens 2 feature, a second HolographicCamera is spun up to render the holograms from the perspective of the PV camera to align better with the recorded video.
https://docs.microsoft.com/en-us/windows/mixed-reality/mixed-reality-capture-for-developers#render-from-the-pv-camera-opt-in
WithoutPVCameraRender

WithPVCameraRender

As part of that change, this adds a profile for the WindowsMRCameraSettings. This will also be used for https://github.com/microsoft/MixedRealityToolkit-Unity/issues/6531.
Changes

Fixes: https://github.com/microsoft/MixedRealityToolkit-Unity/issues/6694

/azp run

/azp run

@keveleigh The HoloLens 2 now has a Render from Camera option in the Mixed Reality Capture Settings via the device portal. Does this conflict with that or this an alternate path for enabling that?

@michael-house I believe the API here is required to be set in the first place, then the option in the device portal can be used to toggle it at runtime in the actual recording. I'll double check, but I don't believe the device portal setting does anything until the HolographicViewConfiguration is explicitly enabled in code.

I think that's right. If I disable this setting in MRTK, toggling this checkbox in the device portal appears to have no effect.
The reason I brought it up: it appears when HolographicViewConfiguration is set, it breaks MRC for Azure Remote Rendering.


Temporal values not being displayed correctly on x-axis on INT

When displaying temporal values on the x-axis on INT the values are (at least for one value) not shown correctly. Instead of the the expected values (e.g. year) 0NaN is shown. Also for some cubes not all the possible temporal values are shown in the bar chart and neither are only the valid values shown when in this case year is selected as a filter option (all years show up for selection instead).
Heavy Metal Soil Contamination

Another example for the airpollution along the A2 and A13
On PROD I did not encounter this issue

Hi @tboeni, thanks for reporting! This should be fixed once we merge #1025.


Where string is carried over when navigating from one collection to another

Link to reproduction
No response
Payload Version
3.0.0-beta.71
Node Version
20.16.0
Next.js Version
15.0.0-canary.53
Describe the Bug
Often  when you use filter some data using ui filter in one collection and after navigate through navbar to another collection the 'where' queryString is applied to the navigated collection.

Adapters and Plugins
No response

Going to track this in the original issue here: https://github.com/payloadcms/payload/issues/7085
@chelaru-artur if you can provide a reproduction there it would be really appreciated since I've not been able to reproduce this

Going to track this in the original issue here: #7085
@chelaru-artur if you can provide a reproduction there it would be really appreciated since I've not been able to reproduce this

Hello @paulpopus  due to corporate policy I am not able to run playwright to write an e2e test.
But repro steps that I've described in the issue are reproducing the problem. I have testes on my app, on a new blank app and also in  the app from _/test/community folder.

@chelaru-artur Did you clear your node_modules, nextjs and any other cache? This issue remains not reproducible for me on the latest beta

I was just shown a reproduction on this, will work on a fix

@paulpopus Hello, any news on this one?


"Listen to Broadcasts" odd behaviour

v0.5.1 : I've enabled "Listen to Broadcasts",  the "Update Interval" is currently set to 30s, and I've restarted the server between tests. Each Entity's "Secondary Info" is set to "Last Updated" to illustrate how often updates are occurring.
Rain Today is being updated every few seconds - what looks like the correct value of reading '14.4 mm' flickers up very briefly, but the 'held' value is being displayed as '0 mm' [sic, no decimal place]. Rain Rate is also flickering with updates but otherwise '0 mm/h'.
Wind, Wind Direction, Wind Max, Temperature, Solar, UV etc seem to update at irregular intervals of 10s of seconds to minutes.
I don't know if it is expected but the "Last Updated" values of each Entity remain static e.g. "4 seconds ago" unless a browser refresh is forced.

Rain Today is being updated every few seconds - what looks like the correct value of reading '14.4 mm' flickers up very briefly, but the 'held' value is being displayed as '0 mm' [sic, no decimal place].

Most likely this happens because the WeatherLink device, for some reason, only sends the valid value every so often and in between it explicitly sends 0. I do want to point out that the device doesn't have to, and in fact, shouldn't broadcast 0 for these measurements, but for some reason it does.
From what I can tell this only affects the rain measurements, which is why I didn't notice during testing as it simply wasn't raining at the time.
Could you send me a screenshot of the graph for these values so I can get a feel for how the 0s are distributed amongst the real values?

Wind, Wind Direction, Wind Max, Temperature, Solar, UV etc seem to update at irregular intervals of 10s of seconds to minutes.

It's important to note that state.last_updated reflects the time the value was last changed, even though there's state.last_changed which only adds to the confusion. The difference between the two is that the latter only updates if the actual state.value changes, not if any of the state.attributes do.

Thanks for the explanation.
I attach the graph of sensor.weatherlink_rainfall aka "Rain today". The solid red bits are where the zero bug is at work.
(I shutdown my RPi for an hour where there's no data - and sorry, I don't know enough about HA to change the x-axis scale and limits from the defaults!)

Unfortunately I haven't been able to reproduce this yet. I suspect this issue might be caused by your split setup. Both ISS transmitters will regularly broadcast a value for rainfall and rain rate, but since one of them doesn't actually measure the rain, it only ever sends 0.
If this is indeed the case, then this issue will be resolved by implementing #10.

I think I could test your hypothesis by temporarily disabling the other sensors. I’ll get back to you!

Unsurprisingly, I've determined removing sensors will leave just the ISS data - JSON attached - but no rain is forecast for a couple of days to observe the "live" behaviour (and I'm not intending to pour water into the gauge!). Until then...
cambmint current conditions 2021-06-22 (ISS only, not raining).txt

Some rain at last! I have determined the following:

ISS + Wind (on station 6) : display OK
ISS + Wind (6) + Greenhouse (2) : display OK
ISS + Wind (6) + Greenhouse (2) + Cellar (3) : broken
ISS + Wind (6) + Cellar (3) : display OK again
I attach the JSONs and screenshots for (2) and (3) (grabbed after a short while).
Hope this helps!
cambmint current conditions 2021-06-28 (ISS+6+2).txt
cambmint current conditions 2021-06-28 (ISS+6+2+3).txt

Hmm, that doesn't really make sense to me...
In your case channel 1, 2, 3, and 6 ALL use the "data_structure_type" 1 (ISS), which is the one I assumed to be problematic.
Because of that, I expected that any combination of these four would lead to issues, but that's not at all what happened in your case. Worse even, it's only when all 4 of them are active that it starts showing? Unfortunately I can't make sense of that.
Is it really only the rain that does this, or is the wind also affected?
Taking a look at the live broadcasts might shine some light on this, but the integration currently doesn't expose a way to do that (not even visible in the logs).

When it next rains (weekend?) I'll check out the behaviour with channels 1, 2 (or 3), 6 but add in 4 (Leaf/Soil: Temp on Port 1; Leaf Soil on Port 1) as I note that has data_structure_type 2.
I've not noticed a problem with the wind, but will double-check.
Probably irrelevant and a coincidence but on my (slow) iPad I got the impression lots of screen redraws were happening. I'll pay more attention next time, e.g. by switching tab in HA.

0.4mm rain today. I have added in station 4 (Leaf/Soil: Temp on Port 1; Leaf Soil on Port 1). All ok. (See attached files.)
Adding in the second Temp/Hum breaks display of Rain today and Rain Rate but interestingly not Rainstorm. Wind speed is still ok.
Let me know if you wish me to test out anything else!
cambmint current conditions 2021-07-03 (ISS+6+3+4).txt


[ Helm ] Proposal for better alert management and configuration

Issue
Currently the way that Helm exposes the configuration for the PrometheusRules is located in the template files "prometheusrule.yaml". The logic to fetch the default or custom rules is:
spec:
{{- if .Values.prometheusRules }}
  groups:
{{ toYaml .Values.prometheusRules | indent 4 }}
{{ else }}
{{ include "kube-state-metrics.rules.yaml.tpl" . | indent 2}}
{{ end }}

This is great because we have the option to work with the default rules or to define custom rules. But here are the downsides I've seen with this strategy:

What if I want to add one single custom rule for the exporter-kube-state Chart but at the same time keep all the default rules?
I would have to add all the rules from the kube-state-metrics.rules.yaml into my values.yaml file in order to add just one rule! The kube-state-metrics.rules.yaml file is 60 lines long. I don't want to see all those default rules in my values.yaml file.

What if I just want to tweak a single rule from the default rules?
Again, let's say I just want to tweak the for field in the DeploymentGenerationMismatch rule from 15m to 5m. Same problem as above.

Basically, modifying default rules or adding custom rules implies adding all the default rules to the values.yaml file. This means adding ~500 lines to the values.yaml file when the prometheusrule.yaml files from all the Charts are considered.
Proposal
For my proposal, we have to first divide what we consider "custom" rules from "default" rules.
These are the steps to follow:

Default rules can be turned on or off as a whole.
Nothing has to be done here. This means having a flag called useDefaultPrometheusRules with true as the default value.

Default rules can be turned off independently.
Each alert inside the default rules file would have a flag specifying if it will be turned on or off.

Custom rules can be added independently from default rules.
This means having a field customPrometheusRules per Chart.

Implementation
The logic inside the prometheusrule.yaml files would be:
spec:
{{- if or (.Values.useDefaultPrometheusRules) (.Values.customPrometheusRules) }}
  groups:
{{- end }}
{{- if .Values.useDefaultPrometheusRules | default true}}
{{ include "kube-state-metrics.rules.yaml.tpl" . | indent 2}}
{{- end }}
{{- if .Values.customPrometheusRules }}
{{ toYaml .Values.customPrometheusRules | indent 4 }}
{{ end }}

And each default rule would have a surrounding condition:
{{ define "kube-state-metrics.rules.yaml.tpl" }}
kube-state-metrics.rules: kube-state-metrics.rules
  rules:
{{- if .Values.prometheusRulesFlags.DeploymentGenerationMismatch | default true}}
  - alert: DeploymentGenerationMismatch
    expr: kube_deployment_status_observed_generation != kube_deployment_metadata_generation
    for: 15m
    labels:
      severity: warning
    annotations:
      description: Observed deployment generation does not match expected one for
        deployment {{`{{$labels.namespace}}`}}/{{`{{$labels.deployment}}`}}
      summary: Deployment is outdated
{{- end }}

Result

If I want to add a custom rule, I don't have to worry about the default rules. I can just add it under the customPrometheusRules field.

Downsides of the proposal

It would be harder to move from the Contrib rules to these rules because it isn't just a copy&paste anymore, but maybe a simple script that adds the conditions to the yaml.tpl file could help.

This adds complexity for the configuration because users would have to understand this. But, if someone is already adding custom rules or tweaking default rules, it means they are already very involved with the Chart and they'll be willing to understand this complexity. Also, they'll be grateful by knowing they don't have to copy&paste 500 lines of default rules into their configuration files.

It would make sense to add this issue to helm charts repo https://github.com/helm/charts/issues?utf8=✓&q=is%3Aissue+is%3Aopen+stable%2Fprometheus-operator+ The charts have been moved to there for some time.
And yes I agree the prometheus rules can be done a lot better.

@faheem-cliqz Thanks, I dind't know that, but could you explain to me what is the equivalent for the coreos/kube-prometheus chart in the stable Helm charts?
I deployed the coreos/prometheus-operator and the coreos/kube-prometheus, but I don't think these are the same to what exists in the Stable repository. For example, there's no Alertmanager in the stable/prometheus-operator.

Haha, apparently they already did this there. They have the flag: .Values.defaultRules.create. Nice!

The prometheus-operator helm chart is more like kube-prometheus chart in this repo, which has everything alert manager, prometheus operator, grafana and some prometheus rules for both recording and alerting. And the helm chart in this repo is deprecated. :)

It would be nice to actually say that in the readme

The helm chart is neither used nor maintained by us. Please create an issue on the upstream helm charts repo.


[DOC] Add reference to paper to FreshPRINCEClassifier

Describe the issue linked to the documentation
FreshPRINCEClassifier does not reference the paper in the documentation
https://link.springer.com/chapter/10.1007/978-3-031-09282-4_13
and it should do so
Suggest a potential alternative/fix
No response

Hello, I'd like to work on this issue.


Align SwiftlyVersion with semver prereleases

Change SwiftlyVersion to make it more conformant to the semantic version specification (https://semver.org) with respect to pre releases. Add test cases that cover typical scenarios. Update the swiftly version to a "dev" pre-release.

@swift-server-bot test this please

I've seen a few I think. I've used @gwynne's SemVer library in Penny and it's been working fine.

@swift-server-bot test this please

@swift-server-bot test this please

I've seen a few I think. I've used @gwynne's SemVer library in Penny and it's been working fine.

I'd vote for using this

@cmcgee1024 It's generally a good idea to not depend on just any package, but it applies less here, because:

Swiftly is not a library, so having a new dependency won't make other people's dependency trees bigger.
Using the library is less code you need to maintain yourself.
@gwynne is a stablished member of the community so we can feel more relaxed when depending on her libraries.
Security wise, @gwynne would know enough to try to not introduce security problems (not that the package contains anything sensitive). She has contributed a bunch of stuff like RSA to SwiftCrypto as well.
@gwynne is a member of the SemVer org.

@swift-ci test macOS

@swift-server-bot test this please

@swift-ci test macOS

@swift-ci test macOS

I'm closing this for now since there's no real urgency to aligning swiftly more with the sermver spec. We have already bumped the swiftly version to a 0.4.0 prerelease version.


Update project with username change

Seems like the maintainer's username was changed from jorgebucaran to joxji, but the installation instructions in README.md and other files in this project still reference the old username. GitHub redirects the old links, but this will break if someone else happens to register with the old username.

I'm still holding onto the old name, so that won't be a problem. Thanks for opening this up, though.  I'll keep it open until I sort things out. Also, thanks for the PR – no need to close it. I'll merge it when I'm ready.


problem in Our Mission spacing

Hi ,
The flipcards have problem in spacing they are being stick with each other which doesn't look good. as shown in the image below:

so i ll improve it.
Thanks
Honey Bhardwaj

@honeybhardwaj  reload the website. There is no problem like this.

@honeybhardwaj reload the website. There is no problem like this.

i  have tried and the problem exist. i use google chrome.

@honeybhardwaj the website is not responsive thats why it semms like this. This issue is assigned. If you want to work on this you have to make this full website responsive.