Eliminate Observer Cursor Reset Manual Intervention for TestNet Resets

What problem does your feature solve?
Whenever testnet is reset, the Anchor Platform requires that the Observer database cursor be reset.  This feature request is to either address this issue or provide some automated process to do this and eliminate manual intervention required.  This issue is tracked internally against ANCHOR-583
What would you like to see?
Either resolve this issue or provide some way to automate it without manual intervention. eg. startup parameter or configuration value.
What alternatives are there?
use the manual work-around steps whenever there is a testnet reset.

For context, Polaris has a testnet reset command that clears cursors and any other related state.


Change real-time request test to use ctx.Time in milliseconds

Signed-off-by: Arsen Akishev<EMAIL_ADDRESS>

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@arsenakishev It looks like the adjustments you made are causing the tests to fail, can you please fix? You can run make test to test locally and verify before committing.

Sorry about that. Got a little carried. Will attempt to fix it as soon as possible.

@jranson  I reverted one of the changes that I made and it fixed the tests.


Incremental view maintenance

The heart of this PR is a new UDTF, called file_dependencies. This UDTF takes in an identifier for a materialized view and spits out a "build plan" that lists "build targets" for the materialized view, which are Hive directories in object storage, and then lists the "dependencies" (existing files in object storage) for each target. For example:
CREATE EXTERNAL TABLE t1 (column0 TEXT, date DATE)
STORED AS PARQUET
PARTITIONED BY (date)
LOCATION 's3://t1/';

INSERT INTO t1 VALUES
('a', '2021-01-01'),
('b', '2022-02-02'),
('c', '2022-02-03'),
('d', '2023-03-03');

-- Pretend we can create materialized views in SQL
CREATE MATERIALIZED VIEW m1 AS SELECT
    COUNT(*) AS count,
   date_part('YEAR', date) AS year
PARTITIONED BY (year)
LOCATION 's3://m1/';

SELECT * FROM file_dependencies('m1');

+--------------------+----------------------+---------------------+-------------------+--------------------------------------+----------------------+
| target             | source_table_catalog | source_table_schema | source_table_name | source_uri                           | source_last_modified |
+--------------------+----------------------+---------------------+-------------------+--------------------------------------+----------------------+
| s3://m1/year=2021/ | datafusion           | public              | t1                | s3://t1/date=2021-01-01/data.parquet | 2023-07-11T16:29:26  |
| s3://m1/year=2022/ | datafusion           | public              | t1                | s3://t1/date=2022-02-02/data.parquet | 2023-07-11T16:45:22  |
| s3://m1/year=2022/ | datafusion           | public              | t1                | s3://t1/date=2022-02-03/data.parquet | 2023-07-11T16:45:44  |
| s3://m1/year=2023/ | datafusion           | public              | t1                | s3://t1/date=2023-03-03/data.parquet | 2023-07-11T16:45:44  |
+--------------------+----------------------+---------------------+-------------------+--------------------------------------+----------------------+

The build plan is computed by analyzing the fragment of the materialized view's query containing the partition columns. This carries the restriction that the partition columns of the materialized view must only reference partition columns of other tables, directly or indirectly. (There are ways to lift this restriction in special cases, such as computing some of the partition columns at runtime, but this has not been implemented yet).
After this PR I plan to add a new UDTF, stale_files, that shows which files in a materialized view have been invalidated by newer dependencies. Then I plan to write some examples on how to use the IVM code + detailed documentation on how it works.

Hey @alamb, I just thought I would request your review since I thought you might be curious about what's going on with the project, but don't feel obligated to leave a review, and please let me know if it's distracting you 😅

Hey @alamb, I just thought I would request your review since I thought you might be curious about what's going on with the project, but don't feel obligated to leave a review, and please let me know if it's distracting you 😅

Not distracting at all! I will likely not have time to review in detail but I'll take a quick look

One thing I suggest, while you still have all this context in your head, would be to take the descripton / example of this PR and adapt it to the main README in this repo -- so that people can quickly evaluate what code is here and if it works for them
https://github.com/datafusion-contrib/datafusion-materialized-views/blob/main/README.md

Thanks for tagging me @suremarc -- I didn't read / understand all of this PR but given what I did read was well commented and tested I think this codebase would be relatively easy to pick up and figure out how to modify.
Really really cool to see this

I added a README including the example, as well as some background on the problems this repo currently aims to solve. Let me know what you think 👍


tikv is crash after ebs volumerestore

Bug Report

What version of TiKV are you using?

What operating system and CPU are you using?

Steps to reproduce

create cluster
do full restore
do ebs volumebackup before full restore completed
when volumebackup completed, do ebs volume restore

What did you expect?

restore success

What did happened?

tikv is crash

/assign @YuJuncen

It's duplicated with https://github.com/pingcap/tidb/issues/46850

duplicate


Add elasticsearch to the benchmark (NDCG and MAP)

I think that adding elasticsearch's (with default configuration) benchmark to the results table is a good point for comparasion reasons as a lot of people uses the framework and don't know how much better (or worse) are the deeplearning models performing.

elastic is developed for IR purpose, while neural information retrieval (NEU-IR) is part of our objective (see readme). It's worth to discuss through.


segmentation fault 11 when using recover + destructive read

using ponyc 0.2.1 on osx 10.11.1 (old core 2 duo processor)
actor Main
  new create(env: Env) =>
    var buffer = Array[U8].create()
    let buffer1 = recover val buffer = Array[U8].create() end

I cannot reproduce this using current HEAD, although I haven't tried on OS X yet.
Does anyone else see this using 0.2.1 and/or OS X?

I get a proper compiler error on HEAD: (clang-3.6 osx)
Building builtin -> /usr/local/lib/pony/0.2.1-529-g593bcdd/packages/builtin
Building gh544/ -> /usr/src/p2/pony/ponyc/gh544
Error:
/usr/src/p2/pony/ponyc/gh544/main.pony:4:31: can't access a non-sendable local defined outside of a recover expression from within that recover expression
    let buffer1 = recover val buffer = Array[U8].create() end
                              ^
Error:
/usr/src/p2/pony/ponyc/gh544/main.pony:4:38: left side must be something that can be assigned to
    let buffer1 = recover val buffer = Array[U8].create() end
                                     ^

with 2.1.0 and debug I can repro the SEGV:
Building gh544 -> /usr/src/p2/pony/ponyc/gh544
Building builtin -> /usr/src/p2/pony/ponyc/packages/builtin
Assertion failed: (l_type != NULL), function expr_assign, file src/libponyc/expr/operator.c, line 397.
Illegal instruction: 4

too lazy to bisect, as it is fixed already.

Closing, since this is already fixed on HEAD.


Configure Azure Pipelines

This pipeline configuration builds the application and produces a build for the Release configuration

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: GeekDotNet sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Update slick.css

The CSS cursor property does not have a hand value. Instead, it has been updated to the grab value.

@ahmadalfy if changed in sass and less this could be merged.
Hand is not a valid value:
https://developer.mozilla.org/en-US/docs/Web/CSS/cursor
If merged this should also be changed in:
https://github.com/kenwheeler/slick/blob/549ab0e87409fa6bfa40d53f149e6e3aec3e64c8/slick/slick.less#L30C1-L31C1
https://github.com/kenwheeler/slick/blob/549ab0e87409fa6bfa40d53f149e6e3aec3e64c8/slick/slick.scss#L30C1-L31C1


Change  hierarchy structure in the RootNode property after first publication

Please have a look at stackoverflow:
https://stackoverflow.com/questions/61428921/reload-treeview-with-new-root-nodes-and-new-item-source
Thanks much for answering

Dokumentdetails
⚠ Bearbeiten Sie diesen Abschnitt nicht. Er ist für die Verknüpfung von docs.microsoft.com zum GitHub-Artikel erforderlich.

ID: b245536a-3179-ff1e-dfd5-76898d07381b
Version Independent ID: 145609fa-8e77-5878-3402-7bcc69df8ccc
Content: Strukturansicht - UWP applications
Content Source: windows-apps-src/design/controls-and-patterns/tree-view.md
Product: uwp
Technology: design
GitHub Login: @jwmsft
Microsoft Alias: jimwalk

This issue is solved. Dynamic building of the tree through binding data source by the item source property in the tree view control, without node operations.

Glad your issue got resolved! If there are any suggestions you'd like to make to our documentation, feel free to contribute to our public docs.


Move Formik endpoint to a serverless function to secure the key

Fixed here https://github.com/smakosh/gatsby-portfolio-dev/pull/48


Add linux compability

Hello, thanks for this code. I check, and if the code is good, I post it

That's checking! It's publishing


Older browsers don't support just column-count, need to add the -moz …

…and -webkit variations
Another hard one to test...
column-count works on the current Chrome/FF, but not older browsers.
Adding -moz & -webkit versions appear to fix the column layout for Usage / System requirements, so they are displayed in two columns instead of one.

:+1: looks fine from here.

:+1: works on browsers I'm able to test with


Remove no-longer used dynamic configs

What changed?
Removed replication related no longer used dynamic configs.

Why?
No longer used.

How did you test it?

Potential risks

Release notes

Documentation Changes

Pull Request Test Coverage Report for Build 0180f4f3-0418-4c34-ad5d-74a5a2b725b8

4 of 4 (100.0%)  changed or added relevant lines in 1 file are covered.
45 unchanged lines in 8 files lost coverage.
Overall coverage increased (+0.02%) to 56.852%

Files with Coverage Reduction
New Missed Lines
%

service/history/queue/timer_queue_processor_base.go
1
77.92%

common/task/fifoTaskScheduler.go
2
85.57%

common/task/weightedRoundRobinTaskScheduler.go
2
88.6%

service/history/queue/timer_queue_processor.go
2
58.37%

common/persistence/nosql/nosqlplugin/cassandra/workflow.go
3
55.04%

service/history/task/fetcher.go
4
86.15%

common/persistence/nosql/nosqlplugin/cassandra/workflowUtils.go
12
76.62%

common/persistence/nosql/nosqlplugin/cassandra/workflowParsingUtils.go
19
82.11%

Totals

Change from base Build 0180f4d6-2414-4ac3-bc47-e3b3193e3c50:
0.02%

Covered Lines:
83742

Relevant Lines:
147299

💛  - Coveralls


Repo file search

Would it be possible to add in a search option like github so that I can put in a string and any file in the selected repo will show, maybe even with a little preview of that part of the file with that string?

:+1:  very useful feature

There's an open issue for this :smiley:  It has a nice link to https://github.com/etsy/hound that I've been looking at integrating. though I'm sorta busy on the plugin-thingie first :stuck_out_tongue:

Anyway Is a good feature and also. I not understand why is not implemented front the start of the project

#13

#13

Looks as interesting task for me.
@unknwon before I'll create PR please watch the recording and guess, what I can forget:

It's allready has that features:

search file within revision (branch or tag)
keyboard navigation on search results (Up, Down, Enter)
simple results ranging based on distance between search symbols (I mean that search "dock" will show you "docker/file" upper than "do/../cker/file")

@zhukovra Wow 🤯 The GIF looks amazing!


Revert "Feature 117 fv3 physics"

Reverts dtcenter/METplotpy#258
This should go into the develop branch not main_v1.1

closing and reopening another PR to push to develop

It looks like this PR was closed instead of merged. The changes that were meant for develop are still in main_v1.1 and is breaking the METplus use case tests for METplus main_v4.1 which is needed to issue a bugfix release. Reopening and merging this PR.


After order

You shouldn't need material-ui only to use the CircularProgress component as it is overkill and will create more code the browser needs to render - which is not good. Other than that, the code is good. I will manually merge with the codebase


As a registered user I want to log in using email and password

Registered user should have possibility to log in using email and password by clicking on "Sign in/Register" button in the header and entering correct email and corresponding password to the fields of form in pop-up.

When user enters password characters should be replaced with asterisks ("*").

If user enters wrong email or password, message "Invalid email or password" should appear, email and password fields should be cleared.

When user enters the right credentials and clicks on "Sign in" button, or "Enter" button on keyboard, pop-up should disappear and User's photo, first name and second name should be displayed on the right side of the header.

AC:

Pop-up with sign-in form appears by clicking on "Sign in/Register" button.
When user enters passwords, characters are replaced with asterisks ("*").
If user enters the right credentials and clicks on "Sign in" button, or "Enter" button on keyboard, pop-up disappears and User's photo, first name and second name are displayed on the right side of the header.
If user enters wrong email or password, message "Invalid email or password" appears, email and password fields are cleared.

The possibility of registrations on the site should be closed for a while.
Only pre-registered users could sign in.
Show on FE short form for log in according to the mockup.

AC:

Login field
text field accepts 40 symbols Latin alphabet, numbers, special symbols, accept uppercase as lowercase
Password field
text field accepts 40 symbols Latin alphabet, numbers, special symbols, uppercase, lowercase


🥑🤖 v1.16.4 release

Co-authored-by: ec2-bot 🤖<EMAIL_ADDRESS>Testing release trigger

🥑🤖 Release v1.16.4 was verified successfully. 🤖🥑

🥑🤖 TektonBot: Release v1.16.4 was verified successfully. 🤖🥑

🥑🤖 TektonBot: Release v1.16.4 was verified successfully. 🤖🥑

🥑🤖 TektonBot: Release v1.16.4 was verified successfully. 🤖🥑


Wrong index in Fig on page 384?

Hi Sebastian.
On page 384 in the MLP figure there might be a typo? In the 2nd layer for the last activation unit I would have expected the sub-index to be "d", not "h". That would fit also with the (m x d) dimension of W(h) as mentioned on page 389 (first section).

Good catch, you are right! I am just fixing this for the 3rd edition. Many thanks!

No worries, I am glad I could help. When should we expect the third edition to be published?

We are currently aiming for ~mid October. Vahid and I have been working on a bunch of new content (mainly rewriting everything after Ch 12 wrt Tf 2.0 and adding a GAN and reinforcement learning chapter) -- currently, we are going over it a few more times to make sure everything is in good shape. Shouldn't be too long from now on.

Excellent! Looking forward to it. Keep on the good work!


Filter.ByIncludingOnly in sub-logger does not work for project namespace

Hello.
I have following code snippet.
Log.Logger = new LoggerConfiguration()
                .Enrich.FromLogContext()
                .WriteTo.Logger(lc => lc
                        .WriteTo.File("web_all_.log", rollingInterval: RollingInterval.Day))
                .WriteTo.Logger(lc => lc
                    .Filter.ByIncludingOnly(Matching.FromSource("Project.NameSpace"))
                        .WriteTo.File("web_.log", rollingInterval: RollingInterval.Day))
                .CreateLogger()

In this case, the file web_.log is not even created.
If I delete Filter.ByIncludingOnly(Matching.FromSource("My.project.namespace")) or change it to Filter.ByExcluding(Matching.FromSource("Microsoft")), then it works as expected.

Hi! This isn't the right repository for this functionality (the repo is just string-based expression support); this one should get a quick answer on Stack Overflow 👍

Hi! This isn't the right repository for this functionality (the repo is just string-based expression support); this one should get a quick answer on Stack Overflow 👍


Bad indent of multi-line call expression arguments

All of these combinations are improperly indented:
// CallExpression with one ArrayExpression an one ObjectExpression arguments
x([
  a
], {
  b: 0
});

// CallExpression with two ObjectExpression arguments
x({
  a: 1
}, {
  b: 0
});

// CallExpression with one ArrayExpression and one FunctionExpression arguments
// works fine when ArrayExpression is on one line
x([
  bar
], function() {
  y();
});

// CallExpression with one ObjectExpression and one ArrayExpression arguments
x({
  a: 1
}, [
  b
]);

Result:
// CallExpression with one ArrayExpression an one ObjectExpression arguments
x([
  a
], {
    b: 0
  });

// CallExpression with two ObjectExpression arguments
x({
  a: 1
}, {
    b: 0
  });

// CallExpression with one ArrayExpression and one FunctionExpression arguments
// works fine when ArrayExpression is on one line
x([
  bar
], function() {
    y();
  });

// CallExpression with one ObjectExpression and one ArrayExpression arguments
x({
  a: 1
}, [
    b
  ]);

These were previously reported as #227 and #217. I've taken the tests reported there and simplified them. #201 might be related as well, but since it doesn't involve a call expression, I can't yet tell.
Might have been cause by 4736c146e32aaf7103700c0141db2e02a6ff7f07.

@millermedeiros I've debugged this one multiple times, but still haven't gotten anywhere. I suspect the issue to be in either lib/hooks/CallExpression.js or in lib/indent.js. Since the latter remains cryptic to me, I can't really tell.
This is one of the few remaining blockers for me. I hope you can look into this some time soon.

I think this can be fixed by changing the way the CallExpression.getIndentEdges work to only indent the arguments if the first argument starts on a different line, eg:
// don't indent
foo({ a: b });
foo({
  a: b
});

// indent
foo(
  {a : b}
);
foo(
  {
    a: b
  }
);

so basically return false if there is no line break between openingParentheses and the node.arguments[0].startToken.

I don't really know why I added the indent3 test to CallExpression this behavior is really weird and I couldn't map it to any issue.. I think we should change the way the code behaves on this case.
I'm going to provide a patch in the next 30min that fixes this problem.

indent3 test does actually make sense.. the implementation that is wrong. we can keep both behaviors.


phpExtensions.imagick: upgrade to ImageMagick 7

Motivation for this change
We use the imagick extension for conversion of PDFs to images, among other things. ImageMagick 6 invokes Ghostscript with -sDEVICE=pamcmyk32, which results in a lot of breakage, specifically large portions of text missing in the output. This appears to have been fixed in ImageMagick 7.
Note: I'm unclear about the impact of simply upgrading ImageMagick here. I assume the imagick API stays the same, but there are obviously behavioural changes going on here. How do we deal with this?
Things done

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

[x] NixOS
[x] macOS
[ ] other Linux distributions

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

The imagick extension for PHP is an extension and not a package, so the commit message should be phpExtensions.imagick: message because that's actual attribute name of the derivation.
I would say that I'm in favor of this change, we won't backport it to stable of course, so it ends up in the next stable.
@ofborg build phpExtensions.imagick

Whoops! Typo'd it. I amended the commit with just the change in message.

Hmm, just realised, URLs to GitHub PRs like that are not necessarily stable, at least not while they are open. I may have to make changes to the upstream PR because of feedback. So it may not be wise to merge this yet. 😕

@stephank You could use https://github.com/Imagick/imagick/commit/09551fbf38c16cdaf4ade7c08744501cd82d2747.patch which is stable at least.

Missed some versions before :)
@ofborg build php73Extensions.imagick php74Extensions.imagick php80Extensions.imagick

Result of nixpkgs-review pr 106905 1

I tried building on darwin, but it fails due to the anticipated hash mismatch on the patch.

@talyz Ah, sorry. I just updated the upstream PR, you're quick. :)
I rebased this and updated it with the fixed URL.

Great! Now it builds fine on darwin :)
@ofborg build php73Extensions.imagick php74Extensions.imagick php80Extensions.imagick

@ofborg eval


Mistake in output_dir and overwrite parameters validation

This assert only lets in the following combination of parameter values:

output_dir must exist and overwrite=False

https://github.com/fumihwh/onnx-pytorch/blob/2902b4d7cfb0470e2a91e29595ba2dfb8dcee50f/onnx_pytorch/code_gen.py#L317-L319
From the context is seems that other combinations of parameter values should also be valid, such as:

output_dir doesn't exist an overwrite is whatever
output_dir exist and overwrite=True

I think the fix is to change the clause to:
assert not os.path.exists(
     output_dir
 ) or overwrite, f"{output_dir} is not empty and overwrite is not True."

@Aivean Sorry for late reply.
Some PR will resolve this issue.


Add more datasets

Added some invertebrates test data

Note sure how to structure it. Some of the data should go into PickLists and some into regular tables such as Storage. Any ideas? @jmenglund


Suggested a more explicit "device"

Explicitly mentioned which device the device registration refers to.

@amang2205 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Related to issue #37157

Made an edit to your PR.

Which edit besides closing the PR?

One of the prerequisites to create this new strong credential, is that the device, where the Microsoft Authenticator app is installed, must also be registered within the Azure AD tenant to an individual user. Due to current device registration restrictions, a device can only be registered in a single tenant. This limit means that only one work or school account in the Microsoft Authenticator app can be enabled for phone sign-in.

OK, understood. Thanks.
I'm completely confused as the PR was not merged.

I tried to edit yours but just ended up publishing via a PR (https://github.com/MicrosoftDocs/azure-docs-pr/pull/86008) from the private repo we use internally.


Fix invalid port assignment in HttpUrl.Builder.effectivePort and authority

Throw IllegalArgumentException if invalid port is used in HttpUrl.Builder.effectivePort() and authority

Can you give more context? What are you hitting, why will this fix it?
Is it that some clients you don't control are hitting bad URLs, crashing your process?


 Resources: 0 added, 0 changed, 4 destroyed.

Can only happen when main.tf has less or different resources than the ones on terraform.tfstate

But look this
iterative_task.task2: Still destroying... [id=tpi-tpi-fashion-mnist-bb-121-bozu0s-1ldyl63-pl48tt-1md6j4n

Looks like the id generator is not working in the destroy

resource "iterative_task" "task2" {
  cloud     = "aws"
  name      = "tpi-fashion_mnist-bb-121-bozu0s-1ldyl63"

  script = ""
}

Im using the full bucket name with the magical feature

No, you aren't: the name contains an underscore.

The name argument is supposed to contain either the original name or the “bucket” name, not a mix of both.

Well, so I do not fully understand it yet. The underscore here only applies if I use the partial name, however if I specify the full tpi- I have to write it as the bucket says

Quoting https://github.com/iterative/terraform-provider-iterative/issues/317#issuecomment-982548401
name = "tpi-fashion_mnist-bb-121-bozu0s-1ldyl63"
                   ^ THIS

here I was clariying

https://github.com/iterative/terraform-provider-iterative/issues/298#issuecomment-979292602
You can either use:

The original name used to create the task, with any Unicode string.
The exact bucket/resource name, with only hyphens and alphanumeric characters; not underscores.

For a task created with the name Example Name for the first time:
Valid

Example Name
tpi-example-name-a1b2-c3d4

Invalid

example-name
tpi_example_name_a1b2_c3d4

@casperdcl, maybe worth a mention in the documentation after #298 and #317?

Please do draft a PR, yes :pray:


dev(narugo): regenerate yolov8's benchmark

Codecov Report

Merging #37 (2cc3613) into main (9b269f8) will decrease coverage by 0.99%.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main      #37      +/-   ##
==========================================
- Coverage   98.79%   97.80%   -0.99%
==========================================
  Files          50       50
  Lines        1324     1324
==========================================
- Hits         1308     1295      -13
- Misses         16       29      +13

Flag
Coverage Δ

unittests
97.80% <ø> (-0.99%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 2 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Fix Windows bugs by bumping rollup-plugin-polyfill-node to 0.7.0

Changes
Before, when nodePolyfill: true is set in the snowpack config, the files _snowpack/pkg/common/_polyfill-node:XXX.js were not created due to : being an illegal character in Windows filenames. This would exhibit itself as an empty _polyfill-node file being created, and all polyfill imports failing in the application. I fixed this in PR snowpackjs/rollup-plugin-polyfill-node#24 by switching the : to a .
After fixing this issue, I noticed that relative imports in the polyfills -- for example, anything that needed the http-lib polyfills, were failing on Windows. This was because we were using \\ as a path separator in JS imports. I fixed this in PR snowpackjs/rollup-plugin-polyfill-node#26 by using POSIX separators here.
Those PRs were both merged and included in the new release of version 0.7.0 of https://github.com/snowpackjs/rollup-plugin-polyfill-node.
This PR aims to finally:

Close #3385
Close #3545

By bumping to this release of rollup-plugin-polyfill-node!

Testing

I've been using snowpack on Windows for the last few months by manually applying the changes I made to rollup-plugin-polyfill-node, without a hitch. I also made sure to run the tests included in https://github.com/snowpackjs/rollup-plugin-polyfill-node.
For a more detailed testing setup:

Set nodePolyfill: true in your snowpack config
Run snowpack build and ensure that _snowpack/pkg/common/_polyfill-node.XXX.js file(s) are created and are non-empty
Repeat the above for a project that actually uses polyfills and check that they work
Repeat the above for a project that uses polyfills from http-lib, and ensure that it actually builds without crashing

Docs

Please let me know if you want me to add documentation, though I think this is just a pretty simple bugfix.

@drwpow @rpadaki  This hasn't fixed the problem for me.
If I upgrade my snowpack to 3.8.8, it still depends on esinstall ^1.1.7. The 1.1.7 available in npm still depends on
        "rollup-plugin-polyfill-node": "^0.6.2",

I'm not really a Node developer, but I think to fix this for folks someone will need to:

[ ] Bump the version number of esinstall, and release a new version to npm.
[ ] Bump Snowpack's dependency on esinstall to require that new version.
[ ] Publish a new version of snowpack w/ that updated dependency.

Is there a workaround I can use in the meantime?
I tried adding
"rollup-plugin-polyfill-node": "^0.7.0"

to my main package.json, and running an npm install but now I have two versions of it installed instead of upgrading the one esinstall uses.  🤦♂

Oh!   I see why I can't install 0.7.0.  It's actually a major/breaking change from a ^0.6.2 semver. At least according to https://semver.npmjs.com/

@drwpow @rpadaki  This hasn't fixed the problem for me.
If I upgrade my snowpack to 3.8.8, it still depends on esinstall ^1.1.7. The 1.1.7 available in npm still depends on
        "rollup-plugin-polyfill-node": "^0.6.2",

I'm not really a Node developer, but I think to fix this for folks someone will need to:

[ ] Bump the version number of esinstall, and release a new version to npm.
[ ] Bump Snowpack's dependency on esinstall to require that new version.
[ ] Publish a new version of snowpack w/ that updated dependency.

Is there a workaround I can use in the meantime?
I tried adding
"rollup-plugin-polyfill-node": "^0.7.0"

to my main package.json, and running an npm install but now I have two versions of it installed instead of upgrading the one esinstall uses.  🤦♂

Hey @NfNitLoop! I'm not really a node dev either, but I'm happy to help you figure out a workaround at the very least.
Is there a particular repo/project I should try running? Is there a slack/discord/irc/etc where it would be convenient to chat?

I have this issue aswell with socket.io-client 4.2.0 and Snowpack 3.8.8

I have the same issue aswell

Same issue here...


Improve README.md

Add

portfolio
badges
gifs

Can  work on this plss

Please assign this to me @boradesanket13

@boradesanket13 what i have to add in portfolio, and there are already lots of badges present in read me

sanketborade.me
Just add this

I didn't get what I have to change

https://sanketborade.me/
Add this link the 'Links' Section in readme.md. That will do.
@itz-deepak

@boradesanket13 can I work on this?

Is the issue resolved?


[qos] use flow label to identify Very High priority IP6 packets

When there are different company's devices in the same Thread Network. Some company may always set their traffic priority to High, which causes some critical traffics from other company are blocked. This feature allows the Thread device to use the flow label to identify Very High priority IP6 packets. If the devices of the same company use the same flow label, the IP6 packets with the same flow label will be set to Very High priority.

Closing stale PR. Can reopen if we decide to pursue this again.


Native PowerShell Core task execution support

Enhancement request
We need a native PowerShell Core task execution. Is it possible to add new PowerShell6 execution handler to support this?
Expected behaviour
Updated task.json schema and underlying API to support PowerShell Core execution:
    "execution": {
      "type": "object",
      "additionalProperties": false,
      "description": "Execution options for this task",
      "properties": {
        "PowerShellCore": {
          "$ref": "#/definitions/executionObject"
        }
      }
    },

To be clear, is this the same issue as #314? If so, I'd rather keep the conversation there - I recognize it had gone stale, but tried to respond now and will try to be more responsive.
There's a lot of context there that I'd prefer we not lose/better to address one problem in one place.

Thanks for looking into this @damccorm ! Yes, this is quite similar to #314 , however our concern is Windows agents only at this stage - not sure if this makes it any easier for you.

Ok. I think the answer is more or less the same - its not currently high priority for us right now so we don't have an eta. I also think if we add one it will be for all 3 platforms (I don't see any reason not to do this), so I'd probably rather just track in #314 - does that seem fair?

Yep that's fine with me @damccorm . Just one more question - what does it take to make it a priority for you guys? We could push it through our official channels with MS, if needed.
Just some background: we got a lot of custom Azure DevOps tasks running our custom Azure deployment mechanism. All of those tasks are currently using AzureRM on PowerShell 5, which is fine. However, we can't update to Az module (as we want new Az features) because we'll need to run PowerShell 6 which is not currently supported by the task. We could hack it as a workaround, but I would prefer a native execution handler to address this. Also, we're running custom Windows agents, so agents pre-requisites for PowerShell Core is not a problem for us.

Ok. I think the answer is more or less the same - its not currently high priority for us right now so we don't have an eta. I also think if we add one it will be for all 3 platforms (I don't see any reason not to do this), so I'd probably rather just track in #314 - does that seem fair?

This is really frustrating.  We could push it through our official channels with MS, if needed.

@dmitryserbin to be honest I'm not sure what the best path is. Official channels might be your best bet, our team is pretty much full to capacity at the moment though so I'm not sure what the response will be.
Sorry, I know that's not the most satisfying response, our hands are just somewhat tied

Note that it's not a blocker.  You can write the task in typescript and use the ToolRunner class to call pswh against a script you write for your task.  There's nothing preventing a task from carrying a powershell core script and running it.

Thanks @bryanmacfarlane this might be a good workaround until pswh is natively supported.

Cant this help (and potentially speedup) with the implementation of the Powershel Core handler?

Note that it's not a blocker. You can write the task in typescript and use the ToolRunner class to call pswh against a script you write for your task. There's nothing preventing a task from carrying a powershell core script and running it.

Can you give an example please?

Is there any update on this? We can't really use Invoke-VstsTool or typescript tool runner because this method creates a new PowerShell session, which makes task parameters unacceptable in new scope - i.e. things like Get-VstsInput or Get-VstsEndpoint will not work. Not to mention task modules from ps_modules directory will not be available by default either.

+1

Thanks for the discussion.
We're not planning to add any new PowerShell-based handlers, even PowerShell Core. Additional handlers complicate the story for other features like running inside containers. Every container would have to carry pwsh on the off-chance that a task written in PowerShell gets used in a pipeline.
The handler is just infrastructure. It doesn't have to be where the bulk of your work occurs. You can write a small amount of JavaScript to grab the task inputs, invoke your script with them as arguments, and handle exit codes. This has the benefit of working for any language you want to bring along: PowerShell, but also Python, Ruby, or a native executable (if you know which platforms your task needs to run on).
I haven't tested this code, but it would look something like:
import tl = require('azure-pipelines-task-lib/task');
import tr = require('azure-pipelines-task-lib/toolrunner');

const firstVar = tl.getInput('firstVar');
const secondVar = tl.getInput('secondVar');

async function run() {
  let pwshPath: string = tl.which('pwsh', true);
  let pwsh = tl.tool(pwshPath);
  pwsh.arg('path/to/script.ps1');
  pwsh.arg(firstVar);
  pwsh.arg(secondVar);

  let options = <tr.IExecOptions> {
    failOnStdErr: false,
    // Direct all output to STDOUT due to Node's buffering strategy
    errStream: process.stdout,
    outStream: process.stdout,
    ignoreReturnCode: true
  };

  let exitCode: number = await pwsh.exec(options);

  let result = tl.TaskResult.Succeeded;

  // Fail on exit code.
  if (exitCode !== 0) {
    tl.error(`Failed with exit code {exitCode}`);
    result = tl.TaskResult.Failed;
  }

  tl.setResult(result, null, true);
}

There must be a miscommunication of the requirements @vtbassmatt: we don't really ask for out-of-the-box pwsh support on all type of agents. All we need is support for task API to execute pwsh.exe (same as powershell.exe) - that's all. Let your customers worry about prerequisites and pwsh availability on the agents.
We are having A LOT of troubles running PWSH via JS or PowerShell 5 (I could easily bore you to death with details).  This may work for very basic PowerShell scripts, but not even close when we're dealing with complex solutions.
You guys already have PowerShell and PowerShell3 handlers in the task.json schema and I do not believe that one more handler type will give you so much troubles.

Please share details. If there are problems executing PowerShell from a Node-based task, then there are likely problems with other languages and systems as well. I can fix those.
The lack of desire to do another PowerShell handler is based on our experiences building the first two. Handlers come with higher expectations - it's very weird for a customer to download a task from the Marketplace only to encounter infrastructure errors trying to run it. The handler has to run on the agent host, on a same-OS container, and recently, on a different-OS container. We have to bring along the handler runtime with the agent, or know without a doubt it'll be there.

Thanks for getting back to me @vtbassmatt.
We're using self-hosted agents in our enterprise environment - same, as I believe, many other Microsoft customers. There's a lot of corporate bs why we're forced to do so - it's a topic for another conversation. For this reason, pre-installed PowerShell is not a problem for us (even if we use microsoft-agents, installing prerequisites is a separate concern).
In our case, we're successfully building in-house extensions and tasks to help with CI/CD in Azure DevOps. Most of our tasks are PowerShell-based running bespoke deployment framework module (50k+ lines of code) based on Az PowerShell modules to deal with Azure deployments.
Since Azure DevOps is our one and only CI/CD platform, we're basically stuck with PowerShell 5 technology and blocked from migrating out codebase to use PowerShell 6 or even 7 - just because pwsh handlers aren't supported.
We have managed to use JS/PowerShell 5 invoke method to run our deployment framework in pwsh instance, however it's not going to cut it and as there are some significant (for us at least) problems with this approach. So far we have discovered the following:

Complexity. Instead of simply running our code in task.ps1 we now have to split it in chunks. Separately initializing task parameters and service connections using VstsTaskSdk features in native PowerShell 5 session, then passing it through to pwsh runner to start another PowerShell 6 session. In some cases addressing this may require significant amount of code refactoring - often in a very hacky and ugly way. Not to mention backward comparability we still need to worry about - this adds another complexity layer. Simple things become very complicated.

Prerequisites. Basically, we loose ability to bring some modules with the task. Having another PowerShell session means that we need to worry about wiring and re-loading prerequisite modules as task instance with ps_modules isn't available. Also, some native things like pipeline variables and tokens are no longer available from new pwsh session - for some solutions this might be a blocker.

Exception handling. We're forced to parse output from & pwsh 2>&1 line by line under PowerShell 5 session, reading [System.Management.Automation.ErrorRecord] types and formatting $_.Exception.Message using Write-VstsTaskError. Also rely on LASTEXITCODE - which is waaay too many assumptions. Basically, same as you guys do in AzurePowerShellV4 task. It's not for me to judge, but I would let go the person who came up with this solution.

Stdout handling. Since we're using pipe to run pwsh and parse errors, using Write-Output to print console output in our modules/scripts is no longer an option - we're forced to use Write-Host instead. We also loose ability to see anything external apps we execute using & (which we do a lot), for example & nunit3-console.exe app.dll or anything similar (unless we output it in a variable and then print with Write-Host - loosing ability to see live output from the app). On top of this, things like Write-Warning do not get recognized by pipelines anymore and displayed as plain text. We have to add some string parsing and output to Write-Host which extremely inconvenient (also doesn't work well with Write-Progress).

I am confident there's another 100+ issues we don't know about just yet. It's one thing after another. Bottomline, nothing can replace native PowerShell handler. We have to build a bicycle with crutches every time we wan't to use or do something very simple. Pwsh invoke method do work for simple script, but doesn't when you have more complex PowerShell solution - which is pretty much any enterprise organization.

With regards to 3, have you tried issuing the formatted log commands directly from your own powershell libraries?
The magic strings are explained here:
https://github.com/microsoft/azure-pipelines-tasks/blob/master/docs/authoring/commands.md
But all the issues you are presenting are exactly why creating new powershell handlers are hard to make and hard to maintain.
A workaround I've seen used, albeit pretty ugly too, is to call cmd /c pwsh script.ps1, funnily enough, cmd will normalize everything.
You can also initialize the current task like inside of the pwsh session. Since all communication with the host happens through environment variables, most functions will just work.  There is no direct communication between the lib and the agent through API connections.
Some things, like requesting a ClientOM may fail on powershell core, as these rely on the presence of the TFS/AzDevOps client object mobile binaries for your platform.
Not trying to discourage creation of a new handler, just trying to help in the interim.

Thanks for enumerating the difficulties, and I understand this isn't intended to be a complete list. The complexity angle definitely resonates.
It's a long shot but, could you by chance share the source of one of these tasks with me? Especially one that illuminates problems 2, 3, or 4. I have a few ideas in mind but am not sure if they'll hold up against the scope of your issues. My email is<EMAIL_ADDRESS>

Thanks for your reply @jessehouwing, here's my comments:

With regards to 3, have you tried issuing the formatted log commands directly from your own powershell libraries?

This might be a good workaround, however we develop platform-agnostic code (i.e. out PowerShell-based framework), so it can be run locally on a Windows machine or in any other system. Everything related to Azure DevOps is decoupled and sits in the task.ps1. We could add extra condition logic into the core logger to do this stuff in Azure DevOps environment only, but this will introduce unnecessary complexity we're tying to avoid.

But all the issues you are presenting are exactly why creating new powershell handlers are hard to make and hard to maintain.

I understand that, however you guys already have two PowerShell handlers. It's difficult for me to judge without looking into the implementation, but it feels like new PWSH handler would be very similar to existing PowerShell3, which means, if done right, there will be a lot of re-usable features/code.

A workaround I've seen used, albeit pretty ugly too, is to call cmd /c pwsh script.ps1, funnily enough, cmd will normalize everything.

Will try that just for curiosity, thanks.

You can also initialize the current task like inside of the pwsh session. Since all communication with the host happens through environment variables, most functions will just work. There is no direct communication between the lib and the agent through API connections.

This is where we're struggling as well when using integrated or user-specific service connections (for example task's connectedService:AzureRM and Get-VstsEndpoint -Name SystemVssConnection in PowerShell session). With proposed approach we have to initialize Azure endpoint in PowerShell session and pass it to PWSH as a parameter.

It's a long shot but, could you by chance share the source of one of these tasks with me? Especially one that illuminates problems 2, 3, or 4. I have a few ideas in mind but am not sure if they'll hold up against the scope of your issues. My email is<EMAIL_ADDRESS>
Sorry for taking ages to reply, I just came back from holiday and will send you some details as you asked within the next few days.

@dmitryserbin no worries, and that would be amazing. I had just sat down to play with this yesterday, but without a real-world example of some PowerShell someone wants to move, it feels like a toy. I'll be taking some time off over the holidays, but if you email me anything, I may log in and take a look anyhow.

Official channels might be your best bet, our team is pretty much full to capacity at the moment though so I'm not sure what the response will be.

Are there any existing requests on the official channels? Tied to find but the search functionality on https://developercommunity.visualstudio.com/ is really limited.

it's very weird for a customer to download a task from the Marketplace only to encounter infrastructure errors trying to run it.

So true. I'm tired to see the following error messages after setting up tasks that are wrappers around the existing PowerShell Core code base:

##[error]The current operating system is not capable of running this task. That typically means the task was written for Windows only. For example, written for Windows Desktop PowerShell.

The error message should be changed because most of the failing tasks I've used are PowerShell Core and the limitation comes from the task executor.


Errors with large AAXC

I have trouble converting several files that are >2GB:
Traceback (most recent call last):
  File "/opt/homebrew/bin/snowcrypt", line 8, in <module>
    sys.exit(main())
  File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/main.py", line 43, in main
    decrypt_aaxc(
  File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 205, in decrypt_aaxc
    _decrypt(src, dest, key, iv)
  File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 189, in _decrypt
    _atomizer(inStream, outStream, path.getsize(inStream.name), key, iv)
  File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 176, in _atomizer
    func(
  File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 93, in _just_copy_it
    outStream.write(inStream.read(length))
ValueError: read length must be non-negative or -1

For a bit of debugging, I added these 2 statements:
def _just_copy_it(inStream, outStream, length, t, **_):
    print("LENGTH1: ", length)
    length -= t.write(outStream)
    print("LENGTH2: ", length)
    outStream.write(inStream.read(length))

These are the details for 3 example files:

Result for file 1 (3.140.467.300 bytes, resulting broken m4a size: 2.918.641.456 bytes)
LENGTH1:  108
LENGTH2:  100
LENGTH1:  92
LENGTH2:  84
LENGTH1:  36
LENGTH2:  28
LENGTH1:  20
LENGTH2:  12
LENGTH1:  44
LENGTH2:  36
LENGTH1:  58
LENGTH2:  50
LENGTH1:  16
LENGTH2:  8
LENGTH1:  36
LENGTH2:  28
LENGTH1:  24
LENGTH2:  16
LENGTH1:  15304
LENGTH2:  15296
LENGTH1:  33589244
LENGTH2:  33589236
LENGTH1:  1528052
LENGTH2:  1528044
LENGTH1:  92
LENGTH2:  84
LENGTH1:  36
LENGTH2:  28
LENGTH1:  32
LENGTH2:  24
LENGTH1:  57
LENGTH2:  49
LENGTH1:  76
LENGTH2:  68
LENGTH1:  36
LENGTH2:  28
LENGTH1:  59
LENGTH2:  51
LENGTH1:  720
LENGTH2:  712
LENGTH1:  28
LENGTH2:  20
LENGTH1:  372
LENGTH2:  364
LENGTH1:  368
LENGTH2:  360
LENGTH1:  33
LENGTH2:  25
LENGTH1:  6256
LENGTH2:  6248
LENGTH1:  33
LENGTH2:  25
LENGTH1:  54199
LENGTH2:  54191
LENGTH1:<PHONE_NUMBER>
LENGTH2:<PHONE_NUMBER>
LENGTH1:<PHONE_NUMBER>
LENGTH2:<PHONE_NUMBER>
LENGTH1:  -1937235809
LENGTH2:  -1937235817
Traceback (most recent call last):
File "/opt/homebrew/bin/snowcrypt", line 8, in
sys.exit(main())
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/main.py", line 43, in main
decrypt_aaxc(
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 205, in decrypt_aaxc
_decrypt(src, dest, key, iv)
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 189, in _decrypt
_atomizer(inStream, outStream, path.getsize(inStream.name), key, iv)
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 176, in _atomizer
func(
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 93, in _just_copy_it
outStream.write(inStream.read(length))
ValueError: read length must be non-negative or -1

Result for file 2 (<IP_ADDRESS> bytes, resulting broken m4a size: 1.031.548.124 bytes):
LENGTH1:  108
LENGTH2:  100
LENGTH1:  92
LENGTH2:  84
LENGTH1:  36
LENGTH2:  28
LENGTH1:  20
LENGTH2:  12
LENGTH1:  44
LENGTH2:  36
LENGTH1:  58
LENGTH2:  50
LENGTH1:  16
LENGTH2:  8
LENGTH1:  36
LENGTH2:  28
LENGTH1:  24
LENGTH2:  16
LENGTH1:  5296
LENGTH2:  5288
LENGTH1:  32184532
LENGTH2:  32184524
LENGTH1:  1463376
LENGTH2:  1463368
LENGTH1:  92
LENGTH2:  84
LENGTH1:  36
LENGTH2:  28
LENGTH1:  32
LENGTH2:  24
LENGTH1:  57
LENGTH2:  49
LENGTH1:  76
LENGTH2:  68
LENGTH1:  36
LENGTH2:  28
LENGTH1:  59
LENGTH2:  51
LENGTH1:  2184
LENGTH2:  2176
LENGTH1:  28
LENGTH2:  20
LENGTH1:  1104
LENGTH2:  1096
LENGTH1:  1100
LENGTH2:  1092
LENGTH1:  33
LENGTH2:  25
LENGTH1:  16896
LENGTH2:  16888
LENGTH1:  33
LENGTH2:  25
LENGTH1:  32884
LENGTH2:  32876
LENGTH1:  997839281
LENGTH2:  997839273
LENGTH1:  -1698701940
LENGTH2:  -1698701948
Traceback (most recent call last):
File "/opt/homebrew/bin/snowcrypt", line 8, in
sys.exit(main())
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/main.py", line 43, in main
decrypt_aaxc(
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 205, in decrypt_aaxc
_decrypt(src, dest, key, iv)
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 189, in _decrypt
_atomizer(inStream, outStream, path.getsize(inStream.name), key, iv)
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 176, in _atomizer
func(
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 93, in _just_copy_it
outStream.write(inStream.read(length))
ValueError: read length must be non-negative or -1

Result for file 3 (3.928.237.809 bytes, resulting broken m4a size: 43.980.806 bytes):
LENGTH1:  108
LENGTH2:  100
LENGTH1:  92
LENGTH2:  84
LENGTH1:  36
LENGTH2:  28
LENGTH1:  20
LENGTH2:  12
LENGTH1:  44
LENGTH2:  36
LENGTH1:  58
LENGTH2:  50
LENGTH1:  16
LENGTH2:  8
LENGTH1:  36
LENGTH2:  28
LENGTH1:  24
LENGTH2:  16
LENGTH1:  2848
LENGTH2:  2840
LENGTH1:  42015516
LENGTH2:  42015508
LENGTH1:  1910060
LENGTH2:  1910052
LENGTH1:  92
LENGTH2:  84
LENGTH1:  36
LENGTH2:  28
LENGTH1:  32
LENGTH2:  24
LENGTH1:  57
LENGTH2:  49
LENGTH1:  76
LENGTH2:  68
LENGTH1:  36
LENGTH2:  28
LENGTH1:  59
LENGTH2:  51
LENGTH1:  976
LENGTH2:  968
LENGTH1:  28
LENGTH2:  20
LENGTH1:  500
LENGTH2:  492
LENGTH1:  496
LENGTH2:  488
LENGTH1:  33
LENGTH2:  25
LENGTH1:  8192
LENGTH2:  8184
LENGTH1:  33
LENGTH2:  25
LENGTH1:  40747
LENGTH2:  40739
LENGTH1:  -987100931
LENGTH2:  -987100939
Traceback (most recent call last):
File "/opt/homebrew/bin/snowcrypt", line 8, in
sys.exit(main())
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/main.py", line 43, in main
decrypt_aaxc(
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 205, in decrypt_aaxc
_decrypt(src, dest, key, iv)
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 189, in _decrypt
_atomizer(inStream, outStream, path.getsize(inStream.name), key, iv)
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 176, in _atomizer
func(
File "/opt/homebrew/lib/python3.10/site-packages/snowcrypt/snowcrypt.py", line 93, in _just_copy_it
outStream.write(inStream.read(length))
ValueError: read length must be non-negative or -1

Until this can be fixed, I will be using (latest) ffmpeg to decrypt, via
ffmpeg -audible_key key_from_voucher_file -audible_iv iv_from_voucher_file -i input.aaxc -c copy output.m4b

Howdy!
This is a strange bug indeed. The only size limitation I'm aware of in the code is line 19 of src/snowcrypt/snowcrypt.py, but that's a 4GB limit, which you're inside of.
What books do you have that get so big? And what did you use to download them? The largest I have in my library is only 2GB at around 70hr long (and it decrypts just fine).
Does FFMPEG correctly decrypt these large files?

They were downloaded just the same way as the other ones I was able to decrypt with successfully with snowcrypt, via https://github.com/mkb79/audible-cli
The books are in the range you mention, 50-70 hours, (Sherlock Holmes Complete Collection for instance). ffmpeg had no problem. I did find some reports though on 44kHz AAXC giving trouble, and all of the ones that we are looking at are not only large (but <4GB), they are also 44kHz. ¯_(ツ)_/¯


React to prop changes

This PR makes SeatsioSeatingChart and SeatsioEventManager react to prop changes and rerender the chart. The Vue test page is also updated with a language dropdown to test the behaviour.

 [seatsio-vue]: Not able to change language

Fixed for designer as well after latest seatsio-ui release.

Fixed for designer as well after latest seatsio-ui release.

Nice 👍


No backpressure when converting to publisher and back

I'm setting up backpressure-enabled streams over grpc and I would like to expose the streams in the public api using standard reactive streams types (i.e. Publisher[T]).
In order to do so I'm converting my stream Observable using toReactivePublisher(), and then in my client/test environment consuming that once again with monix by converting it back to an Observable using Observable.fromReactivePublisher().
However, I'm observing a different behavior in terms of backpressure compared to the fully native monix version: going through this reactive streams "bridge" seems to make it eager, and it consumes all the stream even though I'm using delay operators down the line. Any idea what could cause it to ignore backpressure and this difference in behavior? Thanks

@jchapuis converting into a reactive publisher or from a reactive publisher involves buffering.
So what happens is that a fixed size buffer gets created and the source is free to push events for as long as that buffer has room in it. And then back-pressuring happens after the buffer gets full.

@alexandru thanks! any specific reason for the buffering? is there any way to configure the size of that buffer?

Currently the ReactiveObservable (the implementation that converts org.reactivestreams.Publisher into Observable is doing subscriber.toReactive, which initiates a SubscriberAsReactiveSubscriber using a buffer size set by the Scheduler's execution model, see: https://monix.io/docs/2x/execution/scheduler.html#execution-model
For now, if you really, really want this, you can configure the scheduler passed when building that publisher. I don't recommend that though.
You could also do your own helper:
def convertToObservable[A](publisher: Publisher[A], bufferSize: Int): Publisher[A] =
  new Observable[A] {
    def unsafeSubscribeFn(subscriber: Subscriber[A]): Cancelable = {
      val sub = subscriber.toReactive(bufferSize)
      val subscription = SingleAssignmentSubscription()

      publisher.subscribe(new reactivestreams.Subscriber[A] {
        def onNext(t: A): Unit = sub.onNext(t)
        def onComplete(): Unit = sub.onComplete()
        def onError(t: Throwable): Unit = sub.onError(t)

        def onSubscribe(s: Subscription): Unit = {
          subscription := s
          sub.onSubscribe(s)
        }
      })

      subscription
    }
  }

So it's all in that created Subscriber. We have a buffer size parameter there, but we don't have it on Observable.fromReactivePublisher.
A PR for an overload accepting a buffer size is is welcome.

Ok thanks! I actually did try exactly what you are proposing earlier, with my own helper because I had spotted that toReactive overload that accepts a buffer size. However it didn't seem to change the behavior. I could try again if it works do a PR indeed.
Btw. turning the publisher created with Monix into a RxJava2 Flowable works like a charm in Java, with backpressure.

Ok it doesn't seem to work. However I've spotted a possible reason for this in SubscriberAsReactiveSubscriber:
private[this] val buffer: RSubscriber[T] =
    SyncSubscriberAsReactiveSubscriber(
      BufferedSubscriber.synchronous(subscriber, Unbounded),
      requestCount = requestCount
    )

Notice the Unbounded parameter here, would that be it?

@jchapuis sorry for the silence, I've been busy and couldn't investigate if this works as designed or not.
I'm planning to cut a new 2.3.0 release ASAP, sometime this week, however I promise to have this issue sorted out until then.

@alexandru, thanks for your reply, no problem, good to know!
On 2 May 2017, at 21:15, Alexandru Nedelcu <notifications<EMAIL_ADDRESS>wrote:
@jchapuishttps://github.com/jchapuis sorry for the silence, I've been busy and couldn't investigate if this works as designed or not.
I'm planning to cut a new 2.3.0 release ASAP, sometime this week, however I promise to have this issue sorted out until then.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/monix/monix/issues/352#issuecomment-298733068, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHJ6oW3lGpGj30QIwGMJ7qwIOeTR_Nz5ks5r14DcgaJpZM4NKajt.

@jchapuis there's indeed a problem with that unbounded buffer. Well, it's not the unbounded-ness that's the issue, but how we keep requesting for stuff.
I'm working on a new implementation. Stay tuned.

Fix is on master.

Is this issue actually fixed ? It seems like it is still there for 3.0.0-RC1. I set requestCount = 1, yet yourkit showed the memory taken by the process kept growing until it died with OOM.


WIP: Basic pluggable cache mechanism

Description of proposed changes
New PR to continue the prototype that Joe Hamman started at https://github.com/xarray-contrib/xbatcher/pull/115. Current draft is almost identical to Joe's.

Fixes #

Codecov Report

Merging #167 (d1afdc2) into main (4c63119) will decrease coverage by 3.26%.
The diff coverage is 42.85%.

@@            Coverage Diff             @@
##             main     #167      +/-   ##
==========================================
- Coverage   96.04%   92.79%   -3.26%
==========================================
  Files           6        6
  Lines         329      347      +18
  Branches       70       74       +4
==========================================
+ Hits          316      322       +6
- Misses          8       17       +9
- Partials        5        8       +3

Impacted Files
Coverage Δ

xbatcher/generators.py
88.77% <42.85%> (-5.91%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Is the failing codecov CI expected?

Thanks for catching that! It related to a missing dependency - fixed now


Update documentation

Description of Changes

Replaced 'MDRectangleFlatButton' with 'MDRectangleFlatIconButton' on line 213.

@jarp0l Thanks for PR!
Please make your commits clearer. Your commit doesn't tell what exactly you did.

@HeaTTheatR Thanks for the heads up! I updated the description, I hope it's clear now.

@jarp0l You understood me wrong. I meant the text of the commit, not the description of the pull request.

I could only change the title; I think I messed up by foolishly deleting my fork already. And I could not find a way to change the commit message/text. Really sorry for not being able to understand properly. I was going through the documentation, found that minor error and decided to edit it.

@jarp0l Close this PR and make a new one.


compile Error

./rebar3 compile
===> Verifying dependencies...
===> Plugin rebar3_eqc does not export init/1. It will not be used.

mkdir -p _build/cmake
cd _build/cmake
type cmake3
CMAKE=cmake
cmake -DWITH_BUNDLE_SNAPPY=ON -DWITH_BUNDLE_LZ4=ON ../../c_src
-- LZ4 library: /home/secer/helium/blockchain-node/_build/default/lib/rocksdb/_build/cmake/lz4/lib/liblz4.a
-- LZ4 includes: /home/secer/helium/blockchain-node/_build/default/lib/rocksdb/_build/cmake/lz4/include
-- Snappy library: /home/secer/helium/blockchain-node/_build/default/lib/rocksdb/_build/cmake/snappy/lib/libsnappy.a
-- Snappy includes: /home/secer/helium/blockchain-node/_build/default/lib/rocksdb/_build/cmake/snappy/include
-- cmake args -DCMAKE_POSITION_INDEPENDENT_CODE=ON;-DCMAKE_CXX_COMPILER=/usr/bin/c++;-DCMAKE_AR=/usr/bin/ar;-DCMAKE_BUILD_TYPE=Release;-DFAIL_ON_WARNINGS=OFF;-DPORTABLE=ON;-DUSE_RTTI=1;-DWITH_TOOLS=OFF;-DWITH_TESTS=OFF;-DWITH_GFLAGS=OFF;-DWITH_JEMALLOC=OFF;-DWITH_TBB=;-DWITH_SNAPPY=TRUE;-DWITH_LZ4=TRUE;-DWITH_ZLIB=;-DWITH_BZ2=;-DWITH_ZSTD=;-Dsnappy_ROOT_DIR=/home/secer/helium/blockchain-node/_build/default/lib/rocksdb/_build/cmake/snappy;-Dlz4_ROOT_DIR=/home/secer/helium/blockchain-node/_build/default/lib/rocksdb/_build/cmake/lz4
-- Found RocksDB library: /home/secer/helium/blockchain-node/_build/default/lib/rocksdb/_build/cmake/rocksdb-prefix/src/rocksdb-build/librocksdb.a
-- Found RocksDB includes: /home/secer/helium/blockchain-node/_build/default/lib/rocksdb/c_src/../deps/rocksdb/include
-- Using OTP lib: /usr/lib/erlang/lib - found
-- Using erl_interface version: erl_interface-5.3
-- Using erts version: erts-13.0
-- Configuring done
-- Generating done
-- Build files have been written to: /home/secer/helium/blockchain-node/_build/default/lib/rocksdb/_build/cmake
echo done.
done.
HEAD is now at 659b1d9 version 2.2.0
make[1]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/erlang_stats/c_src'
make[1]: '/home/secer/helium/blockchain-node/_build/default/lib/erlang_stats/c_src/../priv/erlang_stats.so' is up to date.
make[1]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/erlang_stats/c_src'
Compiling multihash v0.0.1 (/home/secer/helium/blockchain-node/_build/default/lib/multihash)
Finished release [optimized] target(s) in 0.50s
===> Compiling c_src/aead.c
===> Compiling c_src/enacl.c
===> Compiling c_src/enacl_ext.c
===> Compiling c_src/enacl_nif.c
===> Compiling c_src/generichash.c
===> Compiling c_src/hash.c
===> Compiling c_src/kdf.c
===> Compiling c_src/kx.c
===> Compiling c_src/public.c
===> Compiling c_src/pwhash.c
===> Compiling c_src/randombytes.c
===> Compiling c_src/secret.c
===> Compiling c_src/secretstream.c
===> Compiling c_src/sign.c
make[1]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/ecc_compact/c_src'
make[1]: '/home/secer/helium/blockchain-node/_build/default/lib/ecc_compact/c_src/../priv/ecc_compact.so' is up to date.
make[1]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/ecc_compact/c_src'
make[1]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/inert/c_src'
make[1]: '/home/secer/helium/blockchain-node/_build/default/lib/inert/c_src/../priv/inert_drv.so' is up to date.
make[1]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/inert/c_src'
make[1]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/procket/c_src'
make -f /home/secer/helium/blockchain-node/_build/default/lib/procket/c_src/Makefile.ancillary
make[2]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/procket/c_src'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/procket/c_src'
cc -m64 -DHAVE_SETNS -g -Wall -o /home/secer/helium/blockchain-node/_build/default/lib/procket/priv/procket -L/home/secer/helium/blockchain-node/_build/default/lib/procket/c_src procket_cmd.c -lancillary
cc /home/secer/helium/blockchain-node/_build/default/lib/procket/c_src/procket.o -shared -L/home/secer/helium/blockchain-node/_build/default/lib/procket/c_src -lancillary -o /home/secer/helium/blockchain-node/_build/default/lib/procket/c_src/../priv/procket.so
make[1]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/procket/c_src'
make[1]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/splicer/c_src'
make[1]: '/home/secer/helium/blockchain-node/_build/default/lib/splicer/c_src/../priv/splicer.so' is up to date.
make[1]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/splicer/c_src'
Finished release [optimized] target(s) in 0.01s
===> The erlang version 25.0 is newer then the latest version known to rebar_erl_vsn (21). Features introduced between after 21 will not have flags.
make[1]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/xxhash/c_src'
make[1]: '/home/secer/helium/blockchain-node/_build/default/lib/xxhash/c_src/../priv/xxhash.so' is up to date.
make[1]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/xxhash/c_src'
-- Using upstream h3 tag v3.6.4 based on local tag v3.6.4-37-g90e1b6e
-- Configuring done
-- Generating done
-- Build files have been written to: /home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src
make[1]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src'
make[2]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src'
make[3]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src'
make[3]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src'
make[3]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src'
[  9%] Performing update step for 'external-h3'
[ 18%] Performing configure step for 'external-h3'
CMake Warning at CMakeLists.txt:261 (message):
clang-format was not detected, so automatic source code reformatting is
disabled

CMake Warning at CMakeLists.txt:273 (message):
clang-tidy was not detected, so source code linting is disabled
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build
[ 27%] Performing build step for 'external-h3'
make[4]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build'
make[5]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build'
make[6]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build'
make[6]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build'
[100%] Built target h3
make[5]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build'
make[4]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build'
[ 36%] Performing install step for 'external-h3'
make[4]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build'
make[5]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build'
make[6]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build'
make[6]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build'
[100%] Built target h3
make[5]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build'
Install the project...
-- Install configuration: ""
-- Up-to-date: /home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/lib/libh3.a
-- Up-to-date: /home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/include/h3/h3api.h
-- Up-to-date: /home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/lib/cmake/h3/h3Config.cmake
-- Up-to-date: /home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/lib/cmake/h3/h3ConfigVersion.cmake
-- Up-to-date: /home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/lib/cmake/h3/h3Targets.cmake
-- Installing: /home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/lib/cmake/h3/h3Targets-noconfig.cmake
make[4]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src/external-h3/src/external-h3-build'
[ 45%] Completed 'external-h3'
make[3]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src'
[ 72%] Built target external-h3
make[3]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src'
make[3]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src'
[100%] Built target h3
make[2]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src'
Install the project...
-- Install configuration: "Release"
-- Up-to-date: /home/secer/helium/blockchain-node/_build/default/lib/h3/c_src/../priv/libh3.so
make[1]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/h3/_build/c_src'
Finished release [optimized] target(s) in 0.01s
make[1]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/exor_filter/c_src'
make[1]: '/home/secer/helium/blockchain-node/_build/default/lib/exor_filter/c_src/../priv/exor_filter.so' is up to date.
make[1]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/exor_filter/c_src'
Finished release [optimized] target(s) in 0.02s
make[1]: Entering directory '/home/secer/helium/blockchain-node/_build/default/lib/blockchain'
blockchain core grpc service directory  does not exist
./rebar3 get-deps
=ERROR REPORT==== 8-Jun-2022::09:04:36.319386 ===
beam/beam_load.c(148): Error loading module rebar3:
please re-compile this module with an Erlang/OTP 25 compiler
escript: exception error: undefined function rebar3:main/1
in function  escript:run/2 (escript.erl, line 750)
in call from escript:start/1 (escript.erl, line 277)
in call from init:start_em/1
in call from init:do_boot/3
make[1]: *** [GNUmakefile:44: src/grpc/autogen] Error 127
make[1]: Leaving directory '/home/secer/helium/blockchain-node/_build/default/lib/blockchain'
===> Hook for compile failed!
make: *** [Makefile:18: compile] Error 1

Erlang 25 was recently released and is not supported yet. Please use erlang 24


Additional Chip size; The BGA32!

While messing about with the Circuit Designer I reasonably quickly found that I actually wanted a few more IO pins. Trying out some things I found you could actually cram 17 pins on a single circuit design. Rounding that down to a power of two brings that to a neat 16 pins.
I'm not entirely sure about what the actual block would look like but initially I was thinking about a full black top (the BGA chip) with two layers of socket in and out on all sides of the block giving a total of 32 sockets IO followed by one layer of power in socket. Pretty much making it a full block (or nearly a full block if you want to inset the BGA a little bit). You could actually put the power sockets on the bottom making the chip a layer lower.
Trying out all the pins in the debugger seems to work like a charm so I suspect technically it should be quite possible:

The above isn't really a good example or a reason for a 32 socket chip however I can already envision the fun I'd have with a BGA32 ;)
You could actually do a BGA16 as well with all the sockets at the bottom like a real BGA chip and the power sockets on the sides.
Either way love the mod and I think the addition of these BGA variants would make for more fun!

i Think it woud be a good year Because complexer circuits Need that kind of I/O

If your I/O mainly uses On/Off logic signals you can expand using Binary Signal Splitters/Combiners giving you a total of 256 (DIP8) or 384 (QFP12) "effective pins".
But when using numeric signals, I see that more actual pins would indeed be useful.
My current implementation actually has a limit of 31 outputs (no limit on inputs) but I'm currently not sure if I enforced that limit or if things just break then. At least the limited space in the editor prevents you from ever reaching that number ;)
The BGA16 (back side filled with pins) sounds most reasonable to me, it would then also have the same pin setup as the Signal IO Controller (OpenComputers bridge).
Another Idea that I recently got is some kind of "Integrated Control Panel":
Modules placed on the panel won't be directly connected to ports on the back but instead go through a custom internal circuit first. But I'm not fully sure yet how assembly and internal wiring would be done.
Maybe have IOs in the editor named like [13] be connected to the Input/Output of the module placed to the module placed on first cell from the left of third row from bottom, etc.


Bulk deletion Request

A bulk deletion facility is required. Because thousands of Excercises/Games are hard to delete.

Now available from the context menu when you right click on any game in the Chapters view ("Delete Games...")

I should also note that I have implemented "undo" for this feature too (the usual CTRL-Z).


Opening a popup window set form's object to null

I have three radio buttons (input type radio) in my popup window.
When I submit the form to the server (without opening the popup window), everything works fine and I get retrieve my radio buttons value with Request.Form.GetValues("RadioBtnName")(0).
When I submit the form to the server (after opening the popup window), I get this error on the same line of code (above):

System.NullReferenceException: Object reference not set to an instance of an object.

It seems like the opening of the popup window affect the form's controls... Any idea why?

Here's the HTML code of the page:
myText

MyProdName

SomeText

	  <input type='radio' name='radio1' value='1' checked>Option No 1

	  <input type='radio' name='radio1' value='2'>Option No 2

	  <input type='radio' name='radio1' value='3'>Option No 3

And in the bottom of the page:

Hi, I also experienced the same issue. Any idea?

Nevermind, I have found the solution here: https://github.com/sandywalker/webui-popover/blob/master/demo/test-issue193.html
Thank you :)


⚠ Spryr has degraded performance

In 11ed052, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 4446 ms

Resolved: Spryr performance has improved in 8690d8b after 37 minutes.


fix(deps): PG version sync

This PR syncs the postgresql versions for the docker-compose files as per the current infrastructure/

@dolcalmi Can you re-review?


Update response classes

It looks like Toggl has updated their docs with better nullability types and field descriptions

Nevermind, docs haven't actually changed.


sndio: 1.8.0 -> 1.8.1

Motivation for this change
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 133547 at 71d4f8d7 run on x86_64-linux 1

2 packages skipped due to time constraints:

lutris
lutris-free

6 packages built successfully:

aucatctl
ryujinx
sndio
waybar
yuzu-ea
yuzu-mainline


ci: add lint

Coverage remained the same at 56.612% when pulling b435c714fbc843c060af1418f7928c9b12397dfa on add_lint into ea19b2ac78a918ae1ac576ca0eaa44ae22c0f3fd on main.


Rethink service group health status and its filters

Current definition of the service group health status
In the table view, the status reported for a service group will reflect the “most critical” status reported by any individual instance of that service (e.g. if one instance is in “critical” status, the entire group is in “critical” status). By default, the table rows are sorted by the percentage of OK services from the smallest to the largest. The sidebar cards are sorted by criticality, from the “most critical” status to the “least critical” status (“critical,” “warning,” “unknown”,  and “OK”).
A picture with examples illustrating the hierarchical relationship among the health status and how the individual instance status affect the group status:

Problems
As we follow the current model of the service group health status, there are a few problems we observed so far:

If a service group contains any service instance that is in "critical" status, the "warning" or "unknown"  status for other instances in the group get lost when transforming into the group status, which is only the most critical status of the instance in the group. This makes it impossible to filter on "warning" or "unknown" status for services in the group even when they exist. When asking users what they expect to see when the "warning" filter is applied, they said:

When I click on “warning” I expect to see all the apps that are showing the warning.

This indicates that users expect all service groups that contain any instances that are in a "warning" status should show up when the "warning" filter is applied. However, the current rule will only show all service groups that have the most critical status as "warning", meaning they couldn't contain any service instance that is "critical".

We started to realize that it is unnecessary to assign a single status to a group. Instead, the group status should be a status spectrum: reflecting the status of the instances in it, which spans from a range of "critical", "warning", "unknown" and "OK". If a service group has 90 service instances, and only one of them is "critical" while the rest are "OK", it is not worth rendering the entire group as "critical". But if 80 of the 90 services are in a "warning" status while the rest 10 are "OK", it might worth more attention from the user than the former scenario.  We heard them saying:

... I would prefer it (service group "warning" filter) to not only filter on that (the service group), but the ones over here (service instance panel)  that are warning. I would expect to filter on this (table) and this (side panel). If I have a service group that has a warning, and there are 90 of them. I don’t want to have to go here (side panel) and click on warning again. I’m clearly trying to find which system is under warning.

This indicates that not only the group status is unnecessary, so are the group status filters. From an efficiency standpoint, we should focus on helping users narrow down to the worrisome service instances (either "warning" or "critical") quickly. This could mean less click in the interface, and filters that efficiently narrow down the problem areas.

Solutions
We've done some design exploration around the above problem, the current solution is to:

remove the rules and construct for the service group status, leave it be the donut chart that visualizing the individual service instance status within it.
remove the "OK" filter, since it is not the area that users care about. They come to the view to figure out what went wrong. But it's good to keep the count somewhere in the interface.
redefine the target for the status filter, for both the filters above the service group table and within the sidebar.
...

@apriofrost is working on getting more feedback and inspirations to not only address the problems identified here but also play harmoniously with other status filters in Automate for infrastructure and compliance.
Feel free to post your comments and feedback below! 😃

this has been deprioritized.


WIP: V4

Codecov Report

Merging #1111 (6462553) into master (7e41691) will not change coverage.
The diff coverage is 100.00%.

Additional details and impacted files
@@            Coverage Diff             @@
##            master     #1111    +/-   ##
==========================================
  Coverage   100.00%   100.00%
==========================================
  Files           36        35     -1
  Lines         2450      2635   +185
==========================================
+ Hits          2450      2635   +185

The register/unregister in NeuriteType neum in this branch is quite fragile because it tries to bend the immutability of the python enums:
    @classmethod
    def register(cls, name, value):
        """Register a new value in the Enum class."""
        value = _int_or_tuple(value)

        if hasattr(cls, name):
            existing = getattr(cls, name)
            raise ValueError(f"NeuriteType '{name}' is already registered as {repr(existing)}")

        try:
            existing = cls(value)
        except ValueError:
            existing = None

        if existing:
            raise ValueError(f"NeuriteType '{name}' is already registered as {repr(existing)}")

        obj = _create_neurite_type(cls, value, name=name)

        cls._value2member_map_[value] = obj
        cls._member_map_[name] = obj
        cls._member_names_.append(name)

        return obj

    @classmethod
    def unregister(cls, name):
        """Unregister a value in the Enum class."""
        if name not in cls._member_names_:
            raise ValueError(
                f"The NeuriteType '{name}' is not registered so it can not be unregistered"
            )

        value = cls._member_map_[name].value
        del cls._value2member_map_[value]
        del cls._member_map_[name]
        cls._member_names_.remove(name)

Therefore, it is no surprise that some of the functionality we relied upon is now broken in 3.12 because they tried to make them safer:
https://docs.python.org/3/whatsnew/3.12.html#enum
In addition, we rely on protected variables to make it work, which is also not great.
In the end, the use cases for which registration is needed are not so many. To make an int type usable, it has to also exist in MorphiIO as a SectionType and all section types are already available as neurite types.
That leaves us with registering new composite types that combine existing section types. As we don't have use cases where other type combinations are needed apart from axon-on-dendrite, which is already defined in NeuriteType, I suggest we remove the registration of neurite types and revisit them in the future when solid cases for this functionality appear.


openai issue

so "manual" says:
micro-agent config set MODEL=GPT-4o
that needs to be
micro-agent config set MODEL=gpt-4o
or it throws errors at you all day long :D

doh! ty


Possible mistakes in Connection Resiliency example

In the section "Option 3 - Add state verification", the code block uses verifySucceeded to check if a Blog exists with aBlogId equal to blogToAdd.BlogId. Due to acceptAllChangesOnSuccess being set to false, I believe the store-generated blogToAdd.BlogId will still be 0 at this point and this check will always fail, or at least will be the wrong check to make. There could be a few ways to improve the example but one might be to use db.Entry(blogToAdd).CurrentValues[nameof(Blog.BlogId)] as I think this will have the store-generated value in it.
Also, if my understanding is correct, AsNoTracking() is redundant here as no entity is returned by the query. Would it be best to remove this, not just for brevity but so as to avoid any confusion about its function?

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

ID: 876c88d4-2972-d905-28d7-56f9e589f309
Version Independent ID: 29002343-fa42-2f49-3362-53592039b26d
Content: Connection Resiliency - EF Core
Content Source: entity-framework/core/miscellaneous/connection-resiliency.md
Product: entity-framework
Technology: entity-framework-core
GitHub Login: @AndriySvyryd
Microsoft Alias: avickers

While on the topic, is there any mechanism by which I can simulate a transient error during a commit to see verifySucceeded in action, to check it's working as expected? With reflection I'm able to build a transient error exception, which I can thrown in place of calls to SaveChanges to ensure my code works as expected on a retry, but the commit scenario seems difficult.
This is one reason why I think it could be worth reworking the example in your documentation - some may have copied the approach and been unable to truly test it themselves, leaving them open to a (very small!) chance of data corruption.

@stevendarby It does look like something is amiss here. We will take a look, and potentially also add a sample that causes this code to execute, like you suggest. You might also want to take a look at some of the tests we have for this. For example, https://github.com/dotnet/efcore/blob/main/test/EFCore.SqlServer.FunctionalTests/ExecutionStrategyTest.cs#L37


It would be nice to have a homebrew tap with formula for this tool, to be able to install it via HOmebrew.

Here's a quick head only formula if someone wants to push it to a tap or something:
class BitcodeRetriever < Formula
  desc "URL extractor/launcher"
  homepage "https://github.com/AlexDenisov/bitcode_retriever"
  head "https://github.com/AlexDenisov/bitcode_retriever.git"

  depends_on "libxml2"

  def install
    system "make"
    bin.install "build/bitcode_retriever"
  end
end


Add Contributing file

We're starting to get some interest in adding / submitting to the repo, etc. We should add a Contributing.md file, that outlines preferred mechanisms to do so, as well as a CodeOfConduct (I think this can be a copy of some standard one that basically covers 'don't be an ass').

npm install -g covgen will install the Contributor Covenant, which is the standard for a lot of open software codes of conduct. Afterward, running covgen<EMAIL_ADDRESS>will install it into the project and embed the appropriate contact email. Additions and modifications specific to the Voytek Lab are encouraged.
For Contributing.md, I always like to refer to the Mozilla Working Open Workshop materials. Full disclosure: I interact a lot with Mozilla, so I'm definitely biased.

Thanks for the notes @GrantRVD
Code of Conduct and Contributing Guide added.


Generate crossplane-runtime methodsets

Description of your changes

This PR uses https://github.com/negz/angryjet to generate the crossplane-runtime method sets for all Crossplane managed resources and non-portable resource classes, i.e. resource.Managed and resource.NonPortableClass. I've made it a draft to discuss how we feel about using a project from my personal Github org to generate Crossplane code. I'm happy to donate the code to the crossplaneio org if this is functionality we'd like.
This PR intends to demonstrate what this pattern looks like for an infrastructure stack - I'm going to hold off on raising AWS and Azure equivalents until we're sure whether (and how) we want to do this. See https://github.com/crossplaneio/crossplane/pull/856 for the equivalent change to Crossplane core.
Checklist

I have:

[x] Run make reviewable to ensure this PR is ready for review.
[x] Ensured this PR contains a neat, self documenting set of commits.
[ ] Updated any relevant documentation, examples, or release notes.
[ ] Updated the RBAC permissions in clusterrole.yaml to include any new types.

We've had some debate amongst Crossplane maintainers around whether what we call "client" or "helper" functions for API types should live in the same package as the API definition, typically as OOP style methods on the type itself, or in a separate package. These functions typically translate a cloud provider struct into a Crossplane struct, or vice versa. CloudSqlInstance is an example of the OOP style pattern, and CloudMemorystoreInstance is an example of the separate package pattern.
My own inclination has been to avoid the OOP style pattern, preferring that the translation code be slightly less tightly coupled to the API type definitions. Switching to generated crossplane-runtime methods put me further into this camp because I encountered some pain migrating thedatabase/v1alpha1 package to generated crossplane-runtime methods. Many code generation tools use Go's type checking library rather than lower level AST parsing to analyse a package. Type checking requires the package to compile, which the database/v1alpha1 does not without its crossplane-runtime methods, because it contains several OOP style helper methods that expect the crossplane-runtime methods to exist.

How does the generator know that it should generate the methods for the given struct?

 This automatic detection can be disabled using the // +crossplane:generate:methods=false marker.


Pointer speed setting doesn't work macOS 15 public beta

OS
macOS 15.0 (Build 24A5289h)
LinearMouse
v0.10.0
Describe the bug
Pointer > Pointer speed setting doesn't work macOS 15 public beta
To reproduce
MacBook Pro 14 M1 Pro, using internal trackpad the pointer speed setting doesn't work. Have not tested external mice. Pointer acceleration does work.
Expected behavior
The setting pointer speed to work again
Anything else?
No response

Having the same issue.

Me too, the internal trackpad is not working as excepted. but external mice works well.  My device is Macbook air, apple silicon M1 ,2020. macOS 15.1 beta

Here's the solution temporary. set Pointer acceleration 's value to 0.1，pointer speed to 0.21. then the pointer will not moving so slow.

Not stale, issue still not fixed.

Problem is not fixed.


<EMAIL_ADDRESS>decompress error

May relate to #13444.
With scoop v0.5.0+:
scoop bucket add versions
scoop install versions/innounp-unicode

as workaround.


Add voluptuous to binary template sensor

Description:
This adds voluptuous to the binary template sensor.
Related issue (if applicable): fixes #
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#
Example entry for configuration.yaml (if applicable):

Checklist:
If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.io

If code communicates with devices, web services, or a:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] Tests have been added to verify that the new code works.

@pavoni if you can get @fabaff's comments fixed we can get this merged in time for 0.27 :)

@robbiet480 should have commented - both done a while back.

Sorry must have lost a commit when I rebased. Now traveling without my laptop - so won't be able to fix until Friday.

@pavoni I can get it fixed up since you put the branch on the official repos :)

Fantastic - thanks!


[New OS Validation] RHEL 9.1

Confirm this OS is functional using v1.26

Validated as per new OS validation list on k3s version v1.26.3-rc2+k3s1

Conformance test
Cluster-reset functionality
Snapshot and Restore functionality
Manual Upgrade and SUC upgrade
Upgrade using rancher


Package is not stateless, not concurrency-safe

It looks like it is not possible to use this package in several places with different values for MaxRetries. Also it is not concurrency safe to mutate this value if package is used from multiple goroutines - e.g. one might be setting MaxRetries value and another one will be reading without any synchronization.

That's true - would you like to submit a fix?
Sent from my iPhone

On 26 Apr 2017, at 21:30, Mikhail Mazurskiy<EMAIL_ADDRESS>wrote:
It looks like it is not possible to use this package in several places with different values for MaxRetries. Also it is not concurrency safe to mutate this value if package is used from multiple goroutines - e.g. one might be setting MaxRetries value and another one will be reading without any synchronization.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.