Fail to short circuit an undefined private class field with optional chaining

TypeScript Version:  3.8.3

Search Terms:

private method
private class field
short circuit
optional chaining
typeerror
cannot get property of

Code
     /** Truncated for brevity */
33   // this.#callback?.(this.#list, this); /** Fails to short-circuit with ?. */
34   if (this.#callback) this.#callback(this.#list, this); /** This works fine */
     /** Truncated for brevity */

Expected behavior:
Expected this.#callback?.(this.#list, this) to not execute when this.#callback is nullish.
Actual behavior:
/**
 * Fail to short-circuit with ?. and produces TypeError.
 * Expected it to behave just like:
 *
 *   if (this.#callback) this.#callback(this.#list, this);
 *
 */
this.#callback?.(this.#list, this);

Uncaught TypeError: Cannot read property 'call' of undefined
    at A.add (eval at <anonymous> (main-3.js:1239), <anonymous>:42:62)
    at eval (eval at <anonymous> (main-3.js:1239), <anonymous>:54:3)
    at main-3.js:1239

Playground Link:
Run the reduced test case in TypeScript playground and see the result in DevTools.
Comment and uncomment L33 and L34 to see the different results when they should behave the same.
Related Issues:
Tried to look up but could not find one.

Simplified repro:
class C {
    #a;
    b() {
        this.#a?.();
    }
}
new C().b();

Playground Link


CI: Include cluster name in initial "deploying" comment.

This ensures the initial comment is discovered by the find-comment step. See line 114.
This should prevent duplicate comments if the deployment fails, as seen in this PR https://github.com/backstage/backstage/pull/22260#issuecomment-1896258320

@axisofentropy we could use an invisible html comment instead too.
Like these who have a <!-- changeset-feedback --> at the bottom


In game dialogue are not being displayed correctly in FAF SC(supreme commander 1) coop missions.

There seems to be two issues with this:
1.The cutscenes don't show up in dialogue box(only factions logo are appearing).
2.secondly,the dialogues are not being displayed in correct order(for example you can hear four dialogues at once).
This problem only seems to with SC and Custom coop missions.
SCFA coop missions are fine.

Here's a hacky solution: https://forums.faforever.com/viewtopic.php?f=78&t=16674&p=167547&hilit=unpack#p167547
Did you download the voice files via downlords client? If so then they prolly didnt get unpacked properly. Check if the files are where they should be as I described in the forum post.
Another issue could be a badly generated init file which doesn't load the the files...
Let us know

It works,both issues are solved.
Thank you

@speed2CZ is that the thing with unpack /movies to some differnent folder?

hm, yes?

You told me when i did tutorials that all /movies need to be unpacked to some folder and i implemented this however this is still not merged

Yeah, thats the thing, same system as for coop, much needed.

I will try to push tutorials again. @micheljung @Geosearchef can one of you deploy tutorial featured mod I can help you do it I already did it on the test server....

it is fixed in 1.0.1RC2, if the RC would launch XD

I would a RC5 now u can test if it works there


Use print() function in both Python 2 and Python 3

Legacy print statements are syntax errors in Python 3 but print() function works as expected in both Python 2 and Python 3.  These changes will work on Python 2 but will simplify the migration to Python 3.

Bump on this one.

if im using python 3 how do i make this work

if im using python 3 how do i make this work

if im using python 3 how do i make this work

The original project is abandoned, but there are several forks available now, choose the one you like best.

if im using python 3 how do i make this work

The original project is abandoned, but there are several forks available now, choose the one you like best.


Exception caught by animation library

I'm getting this error when I swipe my images.  Using version 0.0.2+2, Dart 2.10.4, Flutter 1.22.4.
 ════════ Exception caught by animation library ═════════════════════════════════ The method 'call' was called on null. Receiver: null Tried calling: call()

@abhlabs
Thank you for teaching me!
I fixed this issue. You can try it on master branch.


blue noise

supersedes #1219
TODO:

[ ] shorter code?
[ ] test more (dimensions of the noise, etc)

By the way, I changed the license to ISC: https://observablehq.com/@jobleonard/pseudo-blue-noise


[BEAM-2439] Dynamic sizing of Datastore write RPCs.

This implements the same behaviour recently added to Java SDK:

start at 200 entities per RPC;
size subsequent requests based on observed latency of previous requests.
Includes a MovingSum class to track recent latency.
Report RPC success & failure counts as metrics (again, as in the Java SDK).

R: @vikkyrk
R: @ssisk

LGTM, thanks. R: @chamikaramj for merging.


[BUG] add --serializable-deferrable to pg_dump in export

Describe the bug
when dumping the DB find a clean point in the transaction stream.
Optional: find the transaction id and the last timestamp without locking the database for write.

implemented with pg_export_snapshot(). use dump transaction id and dump transaction timestamp as osmosis_replication_sequence_number and osmosis_replication_timestamp respectively


Added experimental background job queue

ref ???

added background job queue behind config flags
when enabled, is only used for the member email analytics updates in order to speed up the parent job, and take load off of the main process that is serving requests

Need to add a couple integration tests then we ought to be ok. Not sure what the failure for Ghost-CLI is.

It looks like there's an error that's preventing the persisted logs from being printed 🙃 Here's the culprint:

Ghost was able to start, but errored during boot with: Cannot find module 'workerpool'

Looking at the lockfile changes, I'm not sure if they're intentional - there are a lot of new dependencies, which I think might stem from an older version of @tryghost/errors
Also, the real issue is that it looks like workerpool wasn't added as a dependency?

Ok, clearly there's some kind of race condition with the config mocks and initializing the service. I will have to look into that when I can reprioritize this.

@vikaspotluri123 Hey, it seems like the ghost-cli tests are hanging on restart with this. Do you have any suggestions on how to repro/troubleshoot that? Only thing I can guess is that the job queue service is hanging. It doesn't do that to me locally.

Note to self: need to update migration to new version before merging.

It took me a minute, but taking a look 👀
https://github.com/vikaspotluri123/Ghost/actions/runs/11393243539/job/31701108553?pr=14

diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index eec2c09aeda..d68f13ce3a2 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -861,7 +861,8 @@ jobs:

       - name: Update from v4
         run: |
-          ghost update -f -d $V4_DIR --archive $(pwd)/ghost/core/ghost.tgz
+          ghost update -f -d $V4_DIR --archive $(pwd)/ghost/core/ghost.tgz --no-restart
+          ghost run -d $V4_DIR -D

       - name: Save Ghost CLI Debug Logs
         if: failure()
@@ -879,7 +880,8 @@ jobs:
         run: |
           DIR=$(mktemp -d)
           ghost install local -d $DIR
-          ghost update -d $DIR --archive $(pwd)/ghost/core/ghost.tgz
+          ghost update -d $DIR --archive $(pwd)/ghost/core/ghost.tgz --no-restart
+          ghost run -d $DIR -D

       - name: Print debug logs
         if: failure()

I hacked the job like that and found this
[2024-10-18 00:32:03] ERROR Unhandled rejection: insert into `jobs` (`created_at`, `finished_at`, `id`, `metadata`, `name`, `queue_entry`, `started_at`, `status`, `updated_at`) values ('2024-10-18 00:32:03', NULL, '6711ac8389d4880ed0fcad4e', NULL, 'members-migrations', NULL, NULL, 'queued', '2024-10-18 00:32:03') - SQLITE_ERROR: table jobs has no column named metadata

insert into `jobs` (`created_at`, `finished_at`, `id`, `metadata`, `name`, `queue_entry`, `started_at`, `status`, `updated_at`) values ('2024-10-18 00:32:03', NULL, '6711ac8389d4880ed0fcad4e', NULL, 'members-migrations', NULL, NULL, 'queued', '2024-10-18 00:32:03') - SQLITE_ERROR: table jobs has no column named metadata
Error Code:
    SQLITE_ERROR
----------------------------------------
Error: insert into `jobs` (`created_at`, `finished_at`, `id`, `metadata`, `name`, `queue_entry`, `started_at`, `status`, `updated_at`) values ('2024-10-18 00:32:03', NULL, '6711ac8389d4880ed0fcad4e', NULL, 'members-migrations', NULL, NULL, 'queued', '2024-10-18 00:32:03') - SQLITE_ERROR: table jobs has no column named metadata

[2024-10-18 00:32:03] INFO Ghost URL Service Ready in 3.509s

Ah awesome, thank you. I suppose that's a good thing! I knew the migration needed updating but it's nice to know that it'll fail in CI. Should've thought of that.


⚠ Bofrost.fr has degraded performance

In 33ad7e0, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1361 ms

Resolved: Bofrost.fr performance has improved in a6aad59.


WIP : Show "selection" for selected board-view item.

Fixes #1303  #1271
@nimishamukherjee @sanbornsen @vikram-raj I have added css property for selected item in board view.
I would like to confirm the color=#bee1f4 and border width=3px. (Hence WIP :smile: )
Also, when I close the item detail pop over, the WI box still remains selected. I found this same in list view too.
Issue created for de-selection on close of deatil-box.

.card-pf .card-pf-view .card-pf-view-select .card-pf-view-single-select can do the hover functionality. also .active class can make selection css

@nimishamukherjee @SMahil thank you for review. I am now using patternfly classes for hover over board item here - https://github.com/fabric8io/fabric8-planner/pull/1552/commits/d9bbb9b3c5b2f93df3e5a60f5f1f41e082099156
@SMahil I had to keep my custom class for selection board-card-selected. Could not use active. we can talk about it.

Thanks @SMahil for helping me in css things.
Now PR is work complete.


Added Attribute Selectors

Attribute selectors added with example.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

@RayonD Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝


Fixing flakes in ring hash tests where RPCs are distributed

We need to increase the error tolerance slightly for the ring hash
tests; increasing only the tolerance will cause less RPCs to be sent via
ComputeIdealNumRpcs method which assumes normal distribution and uses the
99.99% standard diviation.
It is likely the ring hash distribution is not the normal distribution
and may have higher standard deviation.
Adding a parameter to ComputeIdealNumRpcs to allow standard deviation
value to be passed in and allow a higher computed RPC number to be
calculated.
Retested all flaky tests 1000x and no longer see the flake.

Why is the distribution not random?  I think it should be.  My guess is that what we're seeing here is a real bug uncovered by the test in the way we're computing the random hash.
Right now, we're generating a 32-bit random number with rand(), writing it to a string, and then passing it to the hash function.  But that may not be the right approach; the hash function probably won't necessarily distribute a bunch of different 32-bit numeric strings to random parts of the 64-bit hash space.  Instead, how about we call rand() twice, once for the high-order 32 bits and then again for the low-order 32 bits?

Also, in addition to these test changes, I think we should also change the XdsConfigSelector code to generate the random hash by calling rand() twice, once for the high-order 32 bits and then again for the low-order 32 bits.  I think that is both more efficient than what we're doing now and will yield better randomness.


Update Posts “road”

Automatically generated by Netlify CMS

👷 Deploy Preview for eloquent-chandrasekhar-302983 processing.
🔨 Explore the source changes: 7f0bfa4cb8fce1b066e24673e741a66c3c96d633
🔍 Inspect the deploy log: https://app.netlify.com/sites/eloquent-chandrasekhar-302983/deploys/61ae26d7367d790007622e9f


feature request : feilds default value

the option of add default values in the collection feilds !

This was previously discussed in https://github.com/pocketbase/pocketbase/issues/42 and https://github.com/pocketbase/pocketbase/issues/206.
In short, this is not planned because of the uncertainties when the default will be applied (PocketBase doesn't have null values).


Add FAQ

Signed-off-by: Maxime Soulé<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build 168

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.678%

Totals

Change from base Build 165:
0.0%

Covered Lines:
4337

Relevant Lines:
4351

💛  - Coveralls


Add a single file compilation fuzzer

What was wrong?
Single file compilation fuzzer was missing.
How was it fixed?
Adding a fuzzer harness.
To-Do

[ ] Fix build: Currently building a fuzzer library, what we need is a binary

[ ] Add entry to the release notes (may forgo for trivial changes)

[ ] Clean up commit history

@bshastry The build process and fuzzer both seem to work fine without the changes you made to Cargo.toml. I'm doing
cargo +nightly fuzz run single_file_fuzzer (with the latest nightly). Is there something else that isn't working that required the Cargo.toml changes?

When I build this locally, the following changes are automatically applied to the Cargo.lock file. This is presumably the Cargo.lock file that the CI is expecting to see. I'm not sure why the Cargo.lock file isn't being modified in the same way on your machine. Maybe delete Cargo.lock (and maybe run cargo clean), build again, and see what's generated?
diff --git a/Cargo.lock b/Cargo.lock
index fe0e8426..bd61b124 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -87,12 +87,6 @@ dependencies = [
  "syn 2.0.39",
 ]

-[[package]]
-name = "arbitrary"
-version = "1.3.2"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "7d5a26814d8dcb93b0e5a0ff3c6d80a8843bafb21b39e8e18a6f05471870e110"
-
 [[package]]
 name = "ark-ff"
 version = "0.3.0"
@@ -440,7 +434,6 @@ version = "1.0.83"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "f1174fb0b6ec23863f8b971027804a42614e347eafb0a95bf0b12cdae21fc4d0"
 dependencies = [
- "jobserver",
  "libc",
 ]

@@ -1213,16 +1206,6 @@ dependencies = [
  "vfs",
 ]

-[[package]]
-name = "fe-fuzzers"
-version = "0.26.0"
-dependencies = [
- "dir-test",
- "fe-common",
- "fe-driver",
- "libfuzzer-sys",
-]
-
 [[package]]
 name = "fe-library"
 version = "0.26.0"
@@ -1824,15 +1807,6 @@ version = "1.0.9"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "af150ab688ff2122fcef229be89cb50dd66af9e01a4ff320cc137eecc9bacc38"

-[[package]]
-name = "jobserver"
-version = "0.1.27"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "8c37f63953c4c63420ed5fd3d6d398c719489b9f872b9fa683262f8edd363c7d"
-dependencies = [
- "libc",
-]
-
 [[package]]
 name = "js-sys"
 version = "0.3.66"
@@ -1885,17 +1859,6 @@ version = "0.2.150"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "89d92a4743f9a61002fae18374ed11e7973f530cb3a3255fb354818118b2203c"

-[[package]]
-name = "libfuzzer-sys"
-version = "0.4.7"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "a96cfd5557eb82f2b83fed4955246c988d331975a002961b07c81584d107e7f7"
-dependencies = [
- "arbitrary",
- "cc",
- "once_cell",
-]
-
 [[package]]
 name = "libloading"
 version = "0.7.4"

@bshastry I should have mentioned earlier that most of the compiler is in the process of being rewritten, on the fe-v2 branch. It would be more useful to add the fuzzer to that branch. The fe-v2 branch is expected to be ready for use in a few months, and we likely won't fix minor issues on the master branch.
However, the fe-v2 branch driver crate (currently called driver2) doesn't have a simple entry point. You could add one to start fuzzing the new parser at least. The other components are maybe not quite ready for fuzzing, but some major changes should be merged into the fe-v2 branch someday soon.

When I build this locally, the following changes are automatically applied to the Cargo.lock file. This is presumably the Cargo.lock file that the CI is expecting to see. I'm not sure why the Cargo.lock file isn't being modified in the same way on your machine. Maybe delete Cargo.lock (and maybe run cargo clean), build again, and see what's generated?
diff --git a/Cargo.lock b/Cargo.lock
index fe0e8426..bd61b124 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -87,12 +87,6 @@ dependencies = [
  "syn 2.0.39",
 ]

-[[package]]
-name = "arbitrary"
-version = "1.3.2"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "7d5a26814d8dcb93b0e5a0ff3c6d80a8843bafb21b39e8e18a6f05471870e110"
-
 [[package]]
 name = "ark-ff"
 version = "0.3.0"
@@ -440,7 +434,6 @@ version = "1.0.83"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "f1174fb0b6ec23863f8b971027804a42614e347eafb0a95bf0b12cdae21fc4d0"
 dependencies = [
- "jobserver",
  "libc",
 ]

@@ -1213,16 +1206,6 @@ dependencies = [
  "vfs",
 ]

-[[package]]
-name = "fe-fuzzers"
-version = "0.26.0"
-dependencies = [
- "dir-test",
- "fe-common",
- "fe-driver",
- "libfuzzer-sys",
-]
-
 [[package]]
 name = "fe-library"
 version = "0.26.0"
@@ -1824,15 +1807,6 @@ version = "1.0.9"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "af150ab688ff2122fcef229be89cb50dd66af9e01a4ff320cc137eecc9bacc38"

-[[package]]
-name = "jobserver"
-version = "0.1.27"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "8c37f63953c4c63420ed5fd3d6d398c719489b9f872b9fa683262f8edd363c7d"
-dependencies = [
- "libc",
-]
-
 [[package]]
 name = "js-sys"
 version = "0.3.66"
@@ -1885,17 +1859,6 @@ version = "0.2.150"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "89d92a4743f9a61002fae18374ed11e7973f530cb3a3255fb354818118b2203c"

-[[package]]
-name = "libfuzzer-sys"
-version = "0.4.7"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "a96cfd5557eb82f2b83fed4955246c988d331975a002961b07c81584d107e7f7"
-dependencies = [
- "arbitrary",
- "cc",
- "once_cell",
-]
-
 [[package]]
 name = "libloading"
 version = "0.7.4"

I applied this patch locally and force pushed to the source branch. Now there are failing tests in the macOS CI. So definitely progress :-)
I hope the failing tests have nothing to do with the changes in this PR, at least that's what I feel after taking a cursory look at the failures in that CI.

@bshastry I should have mentioned earlier that most of the compiler is in the process of being rewritten, on the fe-v2 branch. It would be more useful to add the fuzzer to that branch. The fe-v2 branch is expected to be ready for use in a few months, and we likely won't fix minor issues on the master branch. (That said, it would be useful to add any bugs you find to our test suite, to ensure that the same problems don't exist on the fe-v2 branch)
However, the fe-v2 branch driver crate (currently called driver2) doesn't have a simple entry point. You could add one to start fuzzing the new parser at least. The other components are maybe not quite ready for fuzzing, but some major changes should be merged into the fe-v2 branch someday soon.

Sure, would targeting this parser API be a good start (and targeting a different PR to fe-v2 instead of the master branch)?

Minor update: I created a fe-v2 fuzzer and a draft PR here #969


Deactivate Objects

Implement deactivating service on detail page by admin. Block the applications and make credits back.

Deactivation is done and requirements are also written.


Release/v1.116.12

Peter also approved this, but it was not good enough for some reason:

I think we need to re-evaluate our pulls request strategy on hotfixes, since there is now not really a PR to review before it goes to production. Furthermore when you make PRs to main before you create the release/tag you risk that we accidentally update it with main
Maybe we can do something like:

Create a new release branch from the previous tag. (e.g from tag v1.116.11 create  branch release/v1.116.12)
Push this to github
Checkout locally to a new fix. branch. do any fixes you want in a fix. branch
Create a PR from you fix. branch to the release/.. branch
Have someone review an merge it
Create tag and release using github actions
Create PR from release branch to main (this does not seem great because than someone has to review it again..)

This flow does seem a bit over-complicated tough, so maybe we can come up with something easier?
@aberonni Do you have suggestions?

@RubenGeo tbh, addressing the release process is high on my list of "things I wanna look at" right after "how we do git". Maybe your comments will push it higher up the list :)
If I broaden the scope a bit towards "how we do releases", I would like to challenge the current process and suggest we move to CI/CD rather than make our lives harder with hotfixes and per-instance versioning. It is not a good practice to code according to the idea that "we should release a hotfix because we can't trust what is on main", and this concept is at the core of how we currently treat hotfixes. A shift towards CI/CD would make any conversation on "how we do hotfixes according to the current process" redundant. But I'm sure there are intricacies I'm not aware of so we probably can't just make that change overnight.
It would probably be good for me to get a better grasp of how we currently operate and do things before making any drastic suggestions, though. Maybe it would be easier for me to jump on a call and let you explain that to me if you have the time for it :)
PS I'd be happy to approve this based on trust if that helps unblock you in the short term, but the conflict on CHANGELOG.md needs to be resolved first (because my review will be dismissed if you make significant changes to the branch).

Sure call me anytime ;)

The changes from this branch are already in #5212


Resolved issue BUG: Changing the colour of navbar while in dark mode. #643

Description
Solved  the issue #643:I have resolved the problem of displaying the active link for the genre.
Fixes:  #643
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] I have made this from my own
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] My changes generate no new warnings

ATTACH SCREEN-SHOTS

Thank you @huamanraj  for assigning me this issue. I have completed it, and you can review and merge it.

Thank you @huamanraj  for assigning me this issue. I have completed it, and you can review and merge it.

good work 👏


Remove the JS requirement from radios/checkboxes

I’d originally done this work (but left unmerged) on govuk_elements: https://github.com/alphagov/govuk_elements/tree/radios-without-js

Update the markup to match the new style
Remove the setup call and wrapper from init
Update the specs to expect the new markup
Remove the selection button JS and tests

LGTM! Thanks @robinwhittleton, I'll merge when green.


Mobile digi?

Could a mobile digi option be added to pull the gps from the module to use as the digi's location. For instance a digi/tracker located in car.

sorry i am not understanding your question, can you please describe your idea a little bit better? thanks!

sorry i am not understanding your question, can you please describe your idea a little bit better? thanks!

I attached a diagram to help describe the option requested.

I attached a diagram to help describe the option requested.

I think what @drtechga meant was this:
Add an option to fetch the iGates' location not only from the Config, but also doing a live-update and fetch the location from the built in GPS-module.
String lat = create_lat_aprs(Config.beacon.positionLatitude);
String lng = create_long_aprs(Config.beacon.positionLongitude);

would then be something like: (shown only for Lat, for Lon it's the same)
double lat = Config.beacon.positionLatitude;
if(Config.beacon.doLivePositionUpdate)
    lat = fetchPosFromGPSModule_lat();
String lat = create_lat_aprs(lat);

I think what @drtechga meant was this:
Add an option to fetch the iGates' location not only from the Config, but also doing a live-update and fetch the location from the built in GPS-module.
String lat = create_lat_aprs(Config.beacon.positionLatitude);
String lng = create_long_aprs(Config.beacon.positionLongitude);

would then be something like: (shown only for Lat, for Lon it's the same)
double lat = Config.beacon.positionLatitude;
if(Config.beacon.doLivePositionUpdate)
    lat = fetchPosFromGPSModule_lat();
String lat = create_lat_aprs(lat);

Quark While i have been wanting to do what you just showed in code i don't think that is what drtech means.
I think he is asking for something the system already does as part of digipeater. He means can the tracker in the car relay data to the igate for the dog and the person.
As far as I know this already happens is digipete is set to true

Quark While i have been wanting to do what you just showed in code i don't think that is what drtech means.
I think he is asking for something the system already does as part of digipeater. He means can the tracker in the car relay data to the igate for the dog and the person.
As far as I know this already happens is digipete is set to true

now i am understanding what you mean! the iGate should have a static location and no gps tracking etc. should happen. This ticket is better in the Tracker repository.


API and implementation separation for Java libraries

This epic covers all work required to support API and implementation separation for Java libraries. It's worth noting that it's a follow up to the first milestone, which was the introduction of the Java Library Plugin and more specifically separation of API and implementation dependencies.
This epic is about separation of API and implementation of the library itself. In particular, we will want to support declaring which classes belong to the API of a library.
This is not about supporting Jigsaw modules, nor the module-info.java format: this should work
whatever version of the JDK is used.

Work is now tracked through the in:api-impl-separation label.


Add Tools to the Sidekick tutorial.

Adding a Tools section to the Sidekick tutorial.
Also fixed the Quickstart.

@mdwelsh i think you can prob close this PR unless there were any tweaks in the QS that you wanted to bring over. i pulled in the big addition you made for the jq example and also brought over the entire tools section.

@benlower Ben already merged this with his PR


Drop 0.3 support

You need to change this in REQUIRE, that's the only place that actually matters.

You need to change this in REQUIRE, that's the only place that actually matters.

Right, sorry. I forgot about that.


Strange Out Of Memory error when trying example Colab

When I try to run the officially provided Colab
not changing any row, everything goes fine until the training model = question_answer.create(train_data, model_spec=spec)
As soon as training process started, after a while it begins to consume memory with big chunks (e.g. memory consumption increases by 2GB per 2-3 seconds) and shortly it crashes the Colab environment as it throws Out of Memory error. I think this is some sort of a bug, because otherwise this will not be official example, or it would be documented somewhere in the example that the free Colab environment with 16GB ram is not enough to run this example.
I also tried to run the example with much smaller dataset, but the same problem in the same way is being reproduced. So I am almost sure that this is a bug in the library.

@ando0689
We see that the issue template has not been filled, could you please do so as it helps us analyse the issue [tf version, steps followed before you ran into this error or stand alone code to reproduce the issue faced]
Van you share your colab gist where the error is present.

Hi. I am sorry for that, but actually I don't know what to fill there.
I opened this issue under the "Other" tag, as I guess it's not relevant what OS I use etc, because I just run the Official Tensorflow Lite Model Maker example Colab  without changing anything, just running each cell one by one, and on the cell called "Customize the TensorFlow Model" I get out of memory error.
Is it relevant who runs the example or on what machine etc. if I just run it in Google Colab?

I didn't provide enough information in this issue, so I close this and provided the full information here: https://github.com/tensorflow/tensorflow/issues/45541


Help

How to use tool named as re4sym?

You're meant to just be able to drag+drop a sym file to it, but looks like that doesn't work... If you make an ida and a ghidra folder next to the re4sym it should work fine though hopefully.

I fixed the tools, I will post them later with the tools for OpenMT(ツ)


Update base image, rust, python deps, rust crates

Including transformers 4.39.1
Protobuf can't be updated since grpc doesn't support the latest version yet.

Latest transformers doesn't work due to what I think is a bug, have opened this PR to fix in the transformers repo: https://github.com/huggingface/transformers/pull/29821

I have excluded transformers for now so that we can do the other updates.


Test PostgreSQL optimization of CSV generator

See also #20.
Some things that would need addressed:

translation of category ids to names
state abbrs to full names (or not?)
sensible translation of array fields to lists
on-the-fly CSV generation for searches.

It would be easier to do the first 3 via Django.
Search: you'd want to make the search result queryset available to the next function which would generate the CSV.

Streaming dl works fine for the near future.


Strange behavior in showTimePicker dialog in keyboard input mode

A user of my app who has a Samsung Galaxy S20 FE (Android 11) is reporting that the showTimePicker input dialog is behaving strangely. The locale is English (United Kingdom). In keyboard entry mode, the input dialog is not accepting what should be a valid 24-hour time. A validation error message "Enter a valid time" is shown when pressing OK button for hours 13 to 23 (pm time). For am hours though, the input was accepted. Dial time picker entry mode seems to be working correctly.

I have asked the user to download the Flutter Gallery app and try out the demo time picker. The results were the same i.e. validation failed for hours 13 to 23 in keyboard mode.
The issue is not reproducible on the Android 11 emulator and on my Android 10 Mi A2 phone. I wonder if this issue only affects certain Android 11 devices (e.g. Samsung Galaxy S20 FE), or if there is a conflicting setting on the device.
Steps to Reproduce

Language on device is set to English (United Kingdom).
Launch Flutter Gallery app.
Navigate to Material > Pickers > Time Picker.
Open the time picker.
Dial the time to a pm time e.g. 20:00. Tap the keyboard icon to switch to keyboard input mode.
The keyboard entry dialog appears, showing 20:00; Tap OK without touching the time boxes.

Expected results:
Time accepted on pressing OK. Dialog is closed.
Actual results:
Enter a valid time validation error message in red appears (even though 20:00 is a valid 24-hour time). Dialog remains opened. Tapping on the input text box to edit causes the app to crash/close.
Note: In the case of my app, the time picker did not crash the app (probably due to different Flutter SDK version?). My app in production is running on Flutter 1.22.3 stable.

@jongkb
Is there a way to confirm if this is only happening in Flutter Gallery app and on S20 ?
Although I don't have the said device and on Emulator 11 didn't see the issue:

Is it possible to reach out to the user with below sample code (demo app) and ask them to try it to see if issue persists ?

code sample
@override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: GestureDetector(
            onTap: () async {
              TimeOfDay picked = await showTimePicker(
                context: context,
                initialTime: TimeOfDay.now(),
                builder: (BuildContext context, Widget child) {
                  return MediaQuery(
                    data: MediaQuery.of(context)
                        .copyWith(alwaysUse24HourFormat: true),
                    child: child,
                  );
                },);
            },
            child: Text("SetTime",textAlign: TextAlign.center,))
      ),
    );
  }

@jongkb
Is there a way to confirm if this is only happening in Flutter Gallery app and on S20 ?
Although I don't have the said device and on Emulator 11 didn't see the issue:

Is it possible to reach out to the user with below sample code (demo app) and ask them to try it to see if issue persists ?

code sample
@override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: GestureDetector(
            onTap: () async {
              TimeOfDay picked = await showTimePicker(
                context: context,
                initialTime: TimeOfDay.now(),
                builder: (BuildContext context, Widget child) {
                  return MediaQuery(
                    data: MediaQuery.of(context)
                        .copyWith(alwaysUse24HourFormat: true),
                    child: child,
                  );
                },);
            },
            child: Text("SetTime",textAlign: TextAlign.center,))
      ),
    );
  }

@darshankawar
I'm finally able to reproduce the odd behavior in the time picker on the Android 11 emulator and my own phone. This doesn't look like a Galaxy S20 FE specific issue after all.
The issue can be reproduced under the following conditions:

Language settings set to a locale which inherently uses 24-hour time format (e.g. English (United Kingdom) - en_GB)
Set the Use locale default and Use 24-hour format options to off in the Date & time settings of the device.

This essentially sets the alwaysUse24HourFormat property of Flutter's MediaQuery to false.

The sample code workaround fixes the validation issue. Hopefully this can be addressed at the framework level but with that said, there seems to be a more fundamental issue.
To confirm what should be the "standard" UI behavior, I noticed that when setting alarm in the native Clock app, the clock indeed switches to 12-hour format when 24-hour format is turned off in Settings.

@darshankawar
I'm finally able to reproduce the odd behavior in the time picker on the Android 11 emulator and my own phone. This doesn't look like a Galaxy S20 FE specific issue after all.
The issue can be reproduced under the following conditions:

Language settings set to a locale which inherently uses 24-hour time format (e.g. English (United Kingdom) - en_GB)
Set the Use locale default and Use 24-hour format options to off in the Date & time settings of the device.

This essentially sets the alwaysUse24HourFormat property of Flutter's MediaQuery to false.

The sample code workaround fixes the validation issue. Hopefully this can be addressed at the framework level but with that said, there seems to be a more fundamental issue.
To confirm what should be the "standard" UI behavior, I noticed that when setting alarm in the native Clock app, the clock indeed switches to 12-hour format when 24-hour format is turned off in Settings.

@jongkb
Thanks for digging deep into this issue. I tried the suggested settings in emulator and sample code.

Keeping this issue open for further analysis.

stable flutter doctor -v
[✓] Flutter (Channel stable, 1.22.5, on Mac OS X 10.15.4 19E2269 darwin-x64,
    locale en-IN)
    • Flutter version 1.22.5 at /Users/dhs/documents/Fluttersdk/flutter
    • Framework revision<PHONE_NUMBER> (5 weeks ago), 2020-12-10 11:54:40 -0800
    • Engine revision ae90085a84
    • Dart version 2.10.4

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
    • Android SDK at /Users/dhs/Library/Android/sdk
    • Platform android-30, build-tools 30.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    • CocoaPods version 1.9.3

[!] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.52.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.16.0

[✓] Connected device (1 available)
    • sdk gphone x86 64 arm64 (mobile) • emulator-5554 • android-x64 • Android
      11 (API 30) (emulator)

! Doctor found issues in 1 category.

@jongkb
Thanks for digging deep into this issue. I tried the suggested settings in emulator and sample code.

Keeping this issue open for further analysis.

stable flutter doctor -v
[✓] Flutter (Channel stable, 1.22.5, on Mac OS X 10.15.4 19E2269 darwin-x64,
    locale en-IN)
    • Flutter version 1.22.5 at /Users/dhs/documents/Fluttersdk/flutter
    • Framework revision<PHONE_NUMBER> (5 weeks ago), 2020-12-10 11:54:40 -0800
    • Engine revision ae90085a84
    • Dart version 2.10.4

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
    • Android SDK at /Users/dhs/Library/Android/sdk
    • Platform android-30, build-tools 30.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    • CocoaPods version 1.9.3

[!] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.52.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.16.0

[✓] Connected device (1 available)
    • sdk gphone x86 64 arm64 (mobile) • emulator-5554 • android-x64 • Android
      11 (API 30) (emulator)

! Doctor found issues in 1 category.

I have the same bug, I'm on the latest flutter version.
do I need to provide more data?

This bug still continues. Apparently Flutter should get the time format information to use in the time picker using the OS configuration and not the app's location. Because we can have people who are in a location that the default is 24hrs, however, they set it as the default to be used as 12hrs.

same bug also here on web

This is still happening.
Adding TimeOfDay.now() as initial time will display the time in 24h format in the input mode of the time picker, but renders it invalid from the start.
Input validation doesn't check for 24 hour setting in devices, but the formatting does check it.

by the way, this is also happening on the ios simulator when using the material showTimePicker


Argument Completers for FailoverClusters module

Failover Clustering argument completion for parameters

Cluster (-Cluster, -Name)
Cluster Resource (Name, VMId)
Cluster Resource Type
Cluster Group (Name, VMId)
Cluster Node (Name)
Cluster Shared Volume (Name)
Cluster Storage
Cluster Network (Name)
Cluster Network Interface (Name)
Cluster Virtual Machine Role (Name, VMId)

Thanks for all the contributions.
Can you make sure to do a few things in any more PRs you send:

Name the file .ArgumentCompleters.ps1 (this PR looks fine, but you didn't do that in others)
Add the file that you're adding to Install.ps1
Let me know if any of the completions are slow e.g. > 250ms - sometimes it's better to return w/ no completions but build a cache the first time so we don't block editing.

Hi Jason,
No problem.
This module indeed has some slow completers:

All registrations using function FailoverClusters_ClusterResourceNameArgumentCompletion
Example: Get-ClusterResource -Name
All registrations using function FailoverClusters_ClusterResourceVMIdArgumentCompletion
Example: Get-ClusterResource -VMId

Does that helps?
Question: How do you build a cache first?
Kurt

Hi Jason,
Is there soms info you are missing from me?
Thans,
Kurt

Hi Jason,
I believe all requested information is there.
Could you have a look?
Thanks,
Kurt


Cocoapods badges are not fetched

Are you experiencing an issue with...
shields.io
🐞 Description
some of the badges can be fetched for instance:

Is it because of the cocoapods? Orr it can be resolved on your side?
🔗 Link to the badge

💡 Possible Solution
No response

We could use the tag but it doesnt seem like to have a correct sort order:

While the latest one is 2.21.0

Is it because of the cocoapods?

Ultimately yes, in combination with some GitHub behavior. For whatever reason, the CocoaPods API is running brutally slow right now, for example:
$ time curl https://trunk.cocoapods.org/api/v1/pods/Pendo/specs/latest

real	0m14.615s
user	0m0.116s
sys	0m0.026s

GitHub refuses to render any static content that takes more than 3-4 seconds to respond, which is what is happening here. Our badge server is stuck waiting to get the response from the upstream CocoaPods API and by the time those 15+ seconds (I tested with a few other targets, some taking 20 and 30 seconds) have past and we have a badge ready, GitHub has already long ago decided to not render.
If you try using the badge url outside the GitHub markdown rendering process you'll notice it'll eventually return.
Given how extremely slow the API is I don't think there's really anything we can do on our end; increasing cache duration isn't going to help much and isn't a resolution for a functionally non-responsive API. Someone should try reaching out to the CocoaPods team to see if they can figure out what's going on.

We could use the tag but it doesnt seem like to have a correct sort order:

No, it's correct, but I suspect you may have specified the wrong repo. The badge url you used was https://img.shields.io/github/v/tag/MikePendo/pendo-mobile-ios (btw it's helpful to include the actual badge link in addition to the embeds, even more so when reporting badges that aren't rendering. to that end, i've edited some of your comments to include the url). If you look at GitHub, you'll see your fork's latest tag is indeed v2.12.0
https://github.com/MikePendo/pendo-mobile-ios/tags

I suspect you may have been trying to use the badge for the upstream repo:

Hi
Thanks a lot, I totally forgot that I forked it (long time ago).
The swiftui  is a beta branch and should not be used in official SDK
last question will the following format
https://img.shields.io/github/v/tag/pendo-io/pendo-mobile-ios?color=brightgreen&label=version&sort=semver

Will assure that no prefixes will be used?


could you mention the difference with well-known and used dua ?

https://github.com/Byron/dua-cli

Hello. Thank you for pointing out, never seen dua-cli
Dropped some observations here


"Unit Testing" Lecture

Not done yet.

Title: Packages, Testing, and Continuous-Integration
Walkthrough of creating an example package for your own use

Create the basic project
After it is created, immediately show people how to get it into a new repo online using GitHub desktop
Show how to run the code, activate, etc.
Check in the Manifest/Project so it is reproducible

How to create:

Try https://github.com/invenia/PkgTemplates.jl
If it works, add it to QEALP
Set the name, license, and

julia> t = Template(;
           license="ISC",
           plugins=[
               TravisCI(),
               CodeCov(),
               Coveralls(),
               AppVeyor()
           ],
       )

Call the example package: ExamplePackage.jl  use the qeuser account

Setup Travis now or later?  Link to the travis setup.

Tell people the basic structure of the tree of files.
Code writing workflow

What is the workflow to write code?  Startup you go activate, where to write code, etc.
Tell people to work in the the tests, and put the reusable functions in the src.
Tell people to create a jupyter notebook in the main directory.  Could be tracked or not.  Show people you to do the using in that notebook.  Then you can play around with the plotting/etc. and call reusable functions

How does someone else get the project

] dev http://////
Then add it to github desktop by drag/drop

Unit tests

Explain where to put them.
Show calling a foo function in the src and testing the output.
Explain the ] test to run
Point out testsets and other features

Continuous Integration

Show them how to setup travis.  You might need to point them towards signing up for Travis.
Skip appveyor setup for now
Skip code coverage setup.
Show a screenshot of a build in process (and maybe a link to the existing one)
Show how to put the badge up.
Show how to 1 == 2 assertion in the test, and what it does in the build

The more I think about it, the more I want to introduce code coverage here.  Lets remove  Coveralls(), just to keep things simple.  And perhaps even AppVeyor is not work the trouble if we don't introduce it.  So it would be
plugins=[TravisCI(), CodeCov()],

Then, I think we should have in the indstuctions of code coverage for people to:

Sign in with their GitHub account, and ensure they have already applied for the Student Developer Pack, etc.
Then  codecov.io  to sign up for CodeCov with it.
I cannot do this myself since I don't have a student developer account, but if you could do it yourself and then detail the setup steps, it would help a lot.

One of the steps will be to five CodeCov access permissions to your repo.

After that, in the CI setup section, we can

Turn on code coverage for your repo (assuming the setup steps above work)
Add a code coverage badge
Show people an example with imperfect code coverage.  The best thing to do is to have a bar() function in the example package that we don't call in our first unit test.  Then we get a snapshot of the code coverage perfect, then add a test to call bar(), etc.

Sounds like we can tell people to sign up for CodeCov

Most projects I suspect will be public so no need for the Student Developer Pack... CodeCov is free for public / open-source projects. Code coverage last time I check still had some issues being worked on for Julia 1.0.

Not a chance.  Most students are going to want to do their work in private repos because they are ashamed of the code, and because they don't want anyone "stealing their stuff".  Only later would they get enough confidence to work in the open.  We are not talking about writing open-source packages here, just user projects.
If the CodeCov output is imperfect, that is fine, just as long as the setup instructions are solid.

As part of the workflow, you may need to click "Settings/Integrations & services" on the github webpage for the project.  Also, the badges aren't working and I am not sure why.... there must be a missing step.

Merging ahead of lecture tomorrow.


Question about unimplemented image type

Hi and thank you for your work and support on SPIRV-Cross
I'm just wondering if you please have any information as to when this feature will be supported ?
string CompilerHLSL::image_type_hlsl_modern(const SPIRType &type)
{
...
case DimRect:
SPIRV_CROSS_THROW("Rectangle texture support is not yet implemented for HLSL"); // TODO
case DimBuffer:
// Buffer/RWBuffer.
SPIRV_CROSS_THROW("Buffer/RWBuffer support is not yet implemented for HLSL"); // TODO

No immediate plan, but if you have some test shaders you need to work it would get some priority.

This is the test shader I'm using:

Texture3D LightClusters;
Buffer LightIndices;
Buffer PointLights;
void PSMain()
{
int realLightIndex = LightIndices.Load(0);
float4 pointLight1 = PointLights.Load(realLightIndex * 2);
uint2 lightData = LightClusters.Load(int4(0, 1, 2, 3));
}

I can convert it to SPIRV using glslang
But when I convert it back from SPRIV to HLSL using SPIRV-Cross, it will throw this exception:
SPIRV_CROSS_THROW("Buffer/RWBuffer support is not yet implemented for HLSL"); // TODO
I'm using hlsl shader model 40 (--shader-model 40)
If the shader model is below 40, it will throw this exception instead:
SPIRV_CROSS_THROW("Separate image and samplers not supported in legacy HLSL.");

Awesome, thank you !


Added eq_proof and ge_proofs for presentation

Looks good to me -- but I'm not sure I'm helpful here. @mikelodder7 -- would really help to have you review this.
@aritroCoder -- much (but not all...) of the Latex is not rendering in GitHub, which may be expected, and it will work when rendered by SpecUp.  Are you concerned with that?  I tried a quick check, but couldn't see whether you were doing anything different between when it does and does not render properly in the "Rich Diff" display.

Looks good to me -- but I'm not sure I'm helpful here. @mikelodder7 -- would really help to have you review this.
@aritroCoder -- much (but not all...) of the Latex is not rendering in GitHub, which may be expected, and it will work when rendered by SpecUp. Are you concerned with that? I tried a quick check, but couldn't see whether you were doing anything different between when it does and does not render properly in the "Rich Diff" display.

I don't think I am doing anything different in any case, all of them are proper markdown latex and should be rendered properly. I guess it is a limitation by github


failed to display json stream: failed to register layer: rename: file exists

Describe the bug
I'm trying to run the Supabase Docker stack locally: https://supabase.com/docs/guides/cli/local-development (they mention OrbStack in the docs!)

I have tried manually removing the destination file, but that doesn't change anything (even when running supabase stop first).
To Reproduce
Not sure; I'd have to reproduce this in a minimal sample project.
Expected behavior
This used to work fine; I'm not sure what has changed. 🤔
Diagnostic report (REQUIRED)
OrbStack info:
Version: 1.5.1
Commit: 4cfac15e1080617c70eb163966e1cb2009dac1c2 (v1.5.1)
System info:
macOS: 14.4.1 (23E224)
CPU: arm64, 10 cores
CPU model: Apple M2 Pro
Model: Mac14,9
Memory: 16 GiB
Full report: https://orbstack.dev/_admin/diag/orbstack-diagreport_2024-04-10T00-56-57.229134Z.zip

Screenshots and additional context (optional)
I'm also checking with the Supabase team to see if it's an issue with the realtime image specifically: https://github.com/supabase/realtime/issues/837

Your Docker engine data is corrupted, likely because you ran out of disk space at some point or had an abrupt shutdown. Options:

Clear Docker data in Settings > Storage (recommended)
Attempt to fix it yourself with https://stackoverflow.com/questions/41928729/docker-failed-to-register-layer. Get a shell with docker run -it --rm --privileged --pid host alpine nsenter -m -u -n -t 1

Ha, funny that both of my submitted issues for OrbStack were both caused by me running out of disk space. 😂
I did the storage reset and haven't had the error so far.
Thanks Danny!


need to put scale info in the LayerList

e.g. grey out if out of scale

Done with https://github.com/boundlessgeo/sdk/commit/1a7b0d6c6d2553bc3b9a3a0d50a72c735d0f794e
Previously done with ArcGIS REST


Unable to install on M1 / Apple Silicon

Steps To Reproduce The Error
Try to install the package on an M1 Mac.
Expected Behaviour
Install as per normal.
Actual Behaviour
It runs into issues with node@10, as shown in this output:
Warning: node@10 has been deprecated because it is not supported upstream!
Error: node@10: no bottle available!
You can try to install from source with:
  brew install --build-from-source node@10
Please note building from source is unsupported. You will encounter build
failures with some formulae. If you experience any issues please create pull
requests instead of asking for help on Homebrew's GitHub, Twitter or any other
official channels.

Building node@10 from source does not work.
It results in this output:
==> Downloading https://ghcr.io/v2/homebrew/core/icu4c/manifests/69.1
Already downloaded: /Users/jonathan/Library/Caches/Homebrew/downloads/319330d53dab436f7e6bbe478539f29d41abb6be79788b06615f28006a82b30c--icu4c-69.1.bottle_manifest.json
==> Downloading https://ghcr.io/v2/homebrew/core/icu4c/blobs/sha256:25a1ec460d422ba5abff15dc5cb60ad36003ad021585fa7be278d1dca6fcd2c4
Already downloaded: /Users/jonathan/Library/Caches/Homebrew/downloads/ccf6b67f22944e4ef3d02f6108f71d827eb5193bfeb2a23b10a3471f43e79874--icu4c--69.1.arm64_big_sur.bottle.tar.gz
==> Downloading https://nodejs.org/dist/v10.24.1/node-v10.24.1.tar.xz
######################################################################## 100.0%
Warning: node@10 has been deprecated because it is not supported upstream!
==> Installing dependencies for node@10: icu4c
==> Installing node@10 dependency: icu4c
==> Pouring icu4c--69.1.arm64_big_sur.bottle.tar.gz
🍺  /opt/homebrew/Cellar/icu4c/69.1: 259 files, 73.3MB
==> Installing node@10
==> ./configure<EMAIL_ADDRESS>--with-intl=system-icu
Last 15 lines from<EMAIL_ADDRESS>                 'v8_no_strict_aliasing': 1,
                 'v8_optimized_debug': 0,
                 'v8_promise_internal_field_count': 1,
                 'v8_random_seed': 0,
                 'v8_trace_maps': 0,
                 'v8_typed_array_max_size_in_heap': 0,
                 'v8_use_snapshot': 'true',
                 'want_separate_host_toolset': 0,
                 'xcode_version': '12.0'}}
creating config.gypi
creating config.status
creating config.mk
running:
    python tools/gyp_node.py --no-parallel -f make-mac
Error running GYP

Do not report this issue to Homebrew/brew or Homebrew/core!

Please create pull requests instead of asking for help on Homebrew's GitHub,
Twitter or any other official channels.

Version Numbers or N/A

macOS: 11.5.2
/Applications/ImageOptim.app: 1.8.8
/Applications/ImageAlpha.app:  1.5.1
/Applications/JPEGmini.app: (not installed)

Help Needed
Is there any way around this? Is there a way to run ImageOptim-CLI on an M1 Mac?
What are the options?

@inspiredearth @matthewferry @jwryan9 @shuguenot @sebastienbarre I have updated the version of node.js which imageoptim is built with to 12.18.2, hopefully this will solve this issue.
This is in<EMAIL_ADDRESS>which has just been released, it might take some time before it appears on homebrew (I don't control that).

Thanks.
I just cloned the repo to test it out manually.

I tried the old 3.0.2, and indeed it failed at yarn install, same error as seen with Homebrew. What I didn't realize is that yarn build does work and produces a binary, but since the previous step failed, Homebrew had already given up.
I then switch to the 3.0.7 tag you just released, and yarn install now succeeds (and so does yarn build). So this is looking good for Homebrew, thanks for fixing that.

Tangential, but based on this pull request, it looks like imageoptim not being updated is blocking the homebrew formula from being updated.

What needs to be done to update the homebrew formula? Still seeing 3.0.2 and unable to install on Apple silicon https://formulae.brew.sh/formula/imageoptim-cli#default

I've not had any time to check but I suspect the package needs building for a different version of node.js than it is currently or it seems like maybe homebrew also supports linux now(?) and, if that's the case, could be related to this package being mac only.

https://formulae.brew.sh/formula/imageoptim-cli is now 3.0.7 but I still don't see support for Apple Silicon mentioned there.

get the same as above for homebrew, but I was able to install imageoptim-cli via Yarn without issue on Apple Silicon.
$ yarn global add imageoptim-cli

  yarn global v1.22.17
  [1/4] 🔍  Resolving packages...
  [2/4] 🚚  Fetching packages...
  [3/4] 🔗  Linking dependencies...
  [4/4] 🔨  Building fresh packages...
  success Installed<EMAIL_ADDRESS>with binaries:
        - imageoptim
  ✨  Done in 5.25s.

@janosh yes, runs without issue.
$ imageoptim --imagealpha --quality 0-100 --number-of-colors 32 example.PNG
i Running ImageAlpha...
i Running ImageOptim...
✓ example.PNG was: 474kB now: 47.7kB saving: 426kB (89.93%)
✓ TOTAL was: 474kB now: 47.7kB saving: 426kB (89.93%)
✓ Finished

$ which imageoptim
/Users/levi/.npm-global/bin/imageoptim

$ arch
arm64

@levibuzolic Thanks! Can you confirm that it's using Rosetta?

Yep.

Anything I need to do for this? I don't own an M1 Mac.

@Spomsoree, if you follow https://github.com/Homebrew/homebrew-core/pull/96368 then you'll see the patch isn't accepted, and is made under the assumption that you can run it through rosetta 2.
So in short, it can't be run native yet, but you can run it through rosetta 2. In order to do this, follow https://github.com/Homebrew/brew/issues/9173

Similar issues to above, but with Yarn I get:
$ imageoptim --imagealpha --quality 0-100 --number-of-colors 32 example.PNG
zsh: bad CPU type in executable: imageoptim

$ which imageoptim
/Users/jason/.yarn/bin/imageoptim

$ ls -lah /Users/jason/.yarn/bin/imageoptim
lrwxr-xr-x  1 jason  staff    54B 10 Oct 17:25 /Users/jason/.yarn/bin/imageoptim -> ../../.config/yarn/global/node_modules/.bin/imageoptim

$ arch
arm64

@sammcj, I know you're confused, but this issue is about installing on Apple Silicon, not running it natively. People above showed that it can be installed, so indeed this issue is resolved.
The comment I made is about the brew formula. The maintainer here tried to fix it, but clearly wasn't very familiar with homebrew. And technically it is an issue for homebrew, not this repo (homebrew formula are individually maintained, sometimes by the same developer of the software, most of the time not as in any other package index.)
Regarding running it natively, probably you should worry more about this issue: https://github.com/ImageOptim/ImageOptim/issues/334
Lastly, it is easy to ask for people to "just recompile for arm64". But remember this is all free softwares developed by people in their free time and volunteer to release it with an open source license. Most these licenses come with a clause saying that the software has no warranty. They have no obligation at all to do those volunteer work. So just be nice and stop thinking as a consumer.

@ickc that's a bit petty / high and mighty, I'm an OSS maintainer as well. While I appreciate what you're saying in general - I didn't like a consumer - I just stated that it's not fixed and needs to be compiled for ARM plain and simple 🤷

@sammcj, which part of the issue "Unable to install on M1 / Apple Silicon" you think is not closed/resolved?
Feel free to open a new issue if you want.
And have you visited the linked issue? It seems like you're not really reading what I wrote, nor understanding what is really the issue at hand. And given your attitude I'll refrain from commenting here further.

Friendly bump: We're ~9 months on since last activity here, but this is still an issue.
When I attempt to brew install imageoptim-cli on Apple Silicon (M2), I get the message:
$ brew install imageoptim-cli
[…snip…]
imageoptim-cli: The x86_64 architecture is required for this software.
Error: imageoptim-cli: An unsatisfied requirement failed this build.

The version pulled down by yarn seems to run fine:
$ yarn add imageoptim-cli
[…snip…]
✨  Done in 0.50s.

$ node_modules/imageoptim-cli/dist/imageoptim --version
3.0.7

What, specifically, are the blockers to updating the homebrew formula?

it looks like it is not installing the arm native artifact
  imageoptim-cli
    * Binaries built for a non-native architecture were installed into imageoptim-cli's prefix.
      The offending files are:
        /opt/homebrew/Cellar/imageoptim-cli/3.1.7/libexec/lib/node_modules/imageoptim-cli/dist/imageoptim

See this PR, https://github.com/Homebrew/homebrew-core/pull/135595

Also don't work for me:
> brew install imageoptim-cli
imageoptim-cli: The x86_64 architecture is required for this software.
Error: imageoptim-cli: An unsatisfied requirement failed this build.

Also don't work for me:
> brew install imageoptim-cli
imageoptim-cli: The x86_64 architecture is required for this software.
Error: imageoptim-cli: An unsatisfied requirement failed this build.

maybe this should be reopen?

Ask far as I've understood from the responses to this thread (started be me), it was determined (here) that since it can be installed if Homebrew is installed in Rosetta mode, the issue is resolved.
I have been using Homebrew for a few years in native Silicon mode, and having to reinstall my Homebrew and all packages seems like too much hassle just to get imageoptim-cli working.

Yeah running software in emulation is a workaround/hack especially for something that's processor or GPU intensive, but I'm aware Jamie is doing a complete rewrite of imageOptim so probably isn't investing time in the current codebase.


helm upgrade --recreate-pods flag should do a soft restart

@chancez  correctly noted here that the --recreate-pods flag does not do a soft restart. We should fix that. https://github.com/kubernetes/helm/pull/1648#issuecomment-267684171

A naive proposal would be to shove revision into the spec of deployment/daemonset/statefulset so that they gracefully do rolling upgrade if so configured. I'd go further but I still owe bacongobbler an improved wait.go before I pretend to commit to anything else.

I think it will be great if --recreate-pods flag will include which deployment/pods to recreate instead the whole application,
sometime you don't really need / want to recreate the whole chart and just need to redeploy part of it, especially in umbrella charts.

Would using an annotation on the object (like described in the docs) be a better and more declarative way to do this? I think trying to make it soft restart to meet everyone's specific use case will just lead to pain for everyone

FYI, kubectl is doing this also by adding an annotation to the owning object's pod spec, and that works perfectly, I'm using it all the time now.
check out kubectl rollout restart {deployment,statefulset,daemonset} xyz

Any official note or progress on this?  Feels like a tool revolving around deploying resources should have an option to do a seamless rollout.

@rorysavage77 That definition is correct. "Restarting" a pod is not an actual thing and is done by terminating a pod and letting a controller do the work of recreating.
@KetsuN Like I stated before, I am not entirely convinced yet that we need to add additional logic to Helm itself that is just duplicating all of the update strategy logic that Kubernetes already does for you. As I linked in the docs and in the example that @towolf gave, the way to do this declaratively is to add an annotation that changes to the pod template spec and then it will update the pods according to the defined update strategy.
As I am typing this, it gets me wondering if we should deprecate that flag 🤔

I’m in favour to deprecate the flag.
adding the annotation and using kubectl rollout restart are good enough for the job, no needs to make helm more complex

After discussion today in the dev call, we are comfortable with deprecating the flag. It will remain in Helm 3, but additional work will not be done with it. Before marking as deprecated, I will be writing documentation detailing how to use annotations to roll pods

Closed by https://github.com/helm/helm-www/pull/286 and #6463


Add https://github.com/projectdiscovery/nuclei

Add https://github.com/projectdiscovery/nuclei
update amd64

fix #77