Electron Windows 7 deprecation

how to solve this ? thanks.
Win7 ,  netron 6.8.2 and 6.8.1 release versions , " can't locate DiscardVirtualMemory function on kernel32.dll"

Windows 7 is no longer supported by Electron. See Farewell, Windows 7/8/8.1.
The browser app still works on Windows 7.


(Fix) : Put padding in facets select refs 258078

This fix is for https://taskman.eionet.europa.eu/issues/258078#change-852863. Also there is a fix in volto: https://github.com/plone/volto/pull/5305

@dobri1408 besides my comments left on the plone pull request 4px value is way too small for our design
you could easily add padding uniformly on all sides minium 8px

I have made the padding at 8px as you said, and fixed the pr in volto. Thank you!


Apply antialias reset to all elements

BODY doesn't cover input elements and their placeholders.

Should be there for you in v1.0.2

You should update the docs. I'd do it but I'm not familiar with Assemble and my writing style might be different.

Your right. The wording no longer applies.


Update AtEM

Please approve. I've updated token name and social media details.
First PR #12980
Updated PR #13147
Thank You.

squashed and merged

squashed and merged

Thank You.


Improve the checking of subscriber objects to match RxJS and zen-observable (#445)

Summary
Use object wrapping rather than the typeof check to determine if subscriber is valid. Correctly handles objects and functions and is compatible with how RxJS and zen-observable behave as they don’t distinguish between objects and functions. (issue #445)

Great thanks @far-blue!  Could you add a test here that covers the function case?


Update flyway-core to 8.2.0

Updates org.flywaydb:flyway-core from 8.0.5 to 8.2.0.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.flywaydb", artifactId = "flyway-core" } ]

labels: library-update, early-semver-minor, semver-spec-minor

Superseded by #236.


Non repeatable build / broken dependency propogation

I'm not sure exactly whats up here, but cargo2nix appears broken.
I've been building in CI, and running to successful completion. Getting hold of master and issuing nix-build pulls everything from the binary cache, which no build, as expected.
However:
echo " " >> ./crates/xrfdc/Cargo.toml
cargo clean
cargo generate-lockfile
cargo2nix -f
nix-build .

results in the error below. Cargo is presumably unhappy with the metadata within encoding_rs.
I haven't bottomed out the cause yet (otherwise there would be an accompanying PR).
The fact that this has built successfully indicates there is an ordering type bug at play here? Or that cargo is emitting metadeta which renders the build invalid
   Compiling async-graphql v2.8.2 (/build/async-graphql-2.8.2)
{
    "reason": "compiler-message",
    "package_id": "xrfdc 0.1.0 (path+file:///build/source)",
    "target": {
        "kind": [
            "lib"
        ],
        "crate_types": [
            "lib"
        ],
        "name": "xrfdc",
        "src_path": "/build/source/src/lib.rs",
        "edition": "2018",
        "doc": true,
        "doctest": true,
        "test": true
    },
    "message": {
        "rendered": "error[E0460]: found possibly newer version of crate `encoding_rs` which `async_graphql` depends on
 --> src/schema.rs:2:5
  |
2 | use async_graphql::*;
  |     ^^^^^^^^^^^^^
  |
  = note: perhaps that crate needs to be recompiled?
  = note: the following crate versions were found:
          crate `encoding_rs`: /nix/store/md0bfvsf39ch8vki443wsib7sc44vcjd-crate-encoding_rs-0.8.28/lib/libencoding_rs.rlib
          crate `async_graphql`: /nix/store/akgk0qdl4fzn32mhpg54zwjgxh7nzc9a-crate-async-graphql-2.8.1/lib/libasync_graphql.rlib

",
        "children": [
            {
                "children": [],
                "code": null,
                "level": "note",
                "message": "perhaps that crate needs to be recompiled?",
                "rendered": null,
                "spans": []
            },
            {
                "children": [],
                "code": null,
                "level": "note",
                "message": "the following crate versions were found:
crate `encoding_rs`: /nix/store/md0bfvsf39ch8vki443wsib7sc44vcjd-crate-encoding_rs-0.8.28/lib/libencoding_rs.rlib
crate `async_graphql`: /nix/store/akgk0qdl4fzn32mhpg54zwjgxh7nzc9a-crate-async-graphql-2.8.1/lib/libasync_graphql.rlib",
                "rendered": null,
                "spans": []
            }
        ],
        "code": {
            "code": "E0460",
            "explanation": null
        },
        "level": "error",
        "message": "found possibly newer version of crate `encoding_rs` which `async_graphql` depends on",
        "spans": [
            {
                "byte_end": 31,
                "byte_start": 18,
                "column_end": 18,
                "column_start": 5,
                "expansion": null,
                "file_name": "src/schema.rs",
                "is_primary": true,
                "label": null,
                "line_end": 2,
                "line_start": 2,
                "suggested_replacement": null,
                "suggestion_applicability": null,
                "text": [
                    {
                        "highlight_end": 18,
                        "highlight_start": 5,
                        "text": "use async_graphql::*;"
                    }
                ]
            }
        ]
    }
}
{
    "reason": "compiler-message",
    "package_id": "xrfdc 0.1.0 (path+file:///build/source)",
    "target": {
        "kind": [
            "lib"
        ],
        "crate_types": [
            "lib"
        ],
        "name": "xrfdc",
        "src_path": "/build/source/src/lib.rs",
        "edition": "2018",
        "doc": true,
        "doctest": true,
        "test": true
    },
    "message": {
        "rendered": "error: aborting due to previous error

",
        "children": [],
        "code": null,
        "level": "error",
        "message": "aborting due to previous error",
        "spans": []
    }
}
{
    "reason": "build-finished",
    "success": false
}

cargo generate-lockfile
cargo2nix -f

This step is expected to be non-reproducible as the package index will be consulted.  Still, the build should succeed if cargo can succeed (Definitely point out if this is not the case).
Among search results, this link seems pointing in the right direction:

It produces a crate with incompatible symbol names (a "different version"). There's a "strict version hash" derived by hashing a representation of the structure of a crate's entire external interface. That hash value is appended to every symbol name as part of the name mangling process.

A mechanism I could believe to be at work here is if Nix evaluation thinks a dependency doesn't need rebuild when it actually does.  The compiler catches our error due to the wrong interface hashes.  To simplify, we might be ignoring part of the input when writing the Nix expressions.  If this theory is correct, cleaning out the store paths should result in Nix not finding the (broken) cached rlib and being able to succeed.  Can you give this a shot?
You can find the paths that might need rebuilding using a similar workflow:
nix-store -q  --deriver /nix/store/32d9pc56axxrc2830q5cz1iwifjbar2m-crate-cargo2nix-0.9.0-bin
nix show-derivation /nix/store/ddwgw69slmx1ajdcyjrj2z53c4kfw3ml-crate-cargo2nix-0.9.0.drv | grep '/nix.*crate.*drv

  "/nix/store/ddwgw69slmx1ajdcyjrj2z53c4kfw3ml-crate-cargo2nix-0.9.0.drv": {
      "/nix/store/3inhij8bmn3qzpn1m18j2f48bvwlil2r-crate-anyhow-1.0.35.drv": [
      "/nix/store/3l1la0qrsgwyzx6nvpxlb8kz8l98jgi0-crate-semver-0.9.0.drv": [
      "/nix/store/9lid9ypd34zxyp697ajx92qwn9bkzshf-crate-tera-1.5.0.drv": [
      "/nix/store/ixv0163kk08nyjwjk22p2z990z4335wy-crate-cargo-0.48.0.drv": [
      "/nix/store/jjkvilw9283576lxysgkyrng2v5myf33-crate-tempfile-3.1.0.drv": [
      "/nix/store/js8lidv52qbdflgnjrqbv9hnhairsd66-crate-colorify-0.2.3.drv": [
      "/nix/store/l5l4anxvgpj6kxvp9h3g2dgi37glabql-crate-serde-1.0.118.drv": [
      "/nix/store/n08g1s2v3kgcir8z06f45hn2a32ybm0k-crate-toml-0.5.7.drv": [
      "/nix/store/qyivqx0j3g4gikbf7y9gn1wfan1xl0ds-crate-pathdiff-0.2.0.drv": [
      "/nix/store/vgdpa0vxdw1yh88xbgmbdvijhm2mdl95-crate-cargo-platform-0.1.1.drv": [

To confirm, the build does not succeed. I'll have a go with what you've suggested - thanks for the pointer. It'll be next week now before i get a chance.

Assuming cargo build works but nix build fails.  Please correct me if that's not the case.

Yes, cargo works fine, nix does not. I can simplify the failure case to:
git checkout master
# confirm build is as CI - everything is pulled from binary cache
nix-build .
# Invalidate build for 1 of the crates in workspace
echo " " >> ./crates/xrfdc/Cargo.toml
nix-build .

The resultant error message is then on a downstream crate:
 found possibly newer version of crate `cvt` which `xrfclk` depends on

so here, we have crate xrfdc and xrfclk which are both dependencies of a downstream binary crate. xrfdc builds correctly with the whitespace modified toml.
I can confirm that deleting all store paths, then rebuilding with nix-build . --option substitute false results in a successful build

Guessing that you've already implemented flushing the CI cache as a workaround for now.
Based on first example, there's strong evidence that the newly generated Cargo.nix did not react to the "modified" Cargo.toml.
Question is, how does the inconsequential change to the Cargo.toml result in rustc deciding that the rlib is no longer good...

Our workaround was nota subtle one - CI is ignoring all entries in the binary cache containing our crates. We warm it up by building hello-world with the cache for all cross-compilation targets, to avoid rebuilding the universe.
I'm equally baffled. I don't understand the internals of cargo sufficiently to know where to inspect the metadata.

My leading (only) candidate for this is a single binary crate, which shares a many of the dependencies of the failing ones. Its the only override aside from some fairly straightforward sys crates including build inputs on the libraries. We have
    my_bin = pkgs.rustBuilder.rustLib.makeOverride {
      name = "my_bin";
      overrideAttrs = drv: {
        # Rust flags were being ignored: this is a workaround.
        configureCargo = ''
          mkdir -p .cargo
          cargo_config=${./.cargo/config.toml}
          cp $cargo_config .cargo/$(stripHash $cargo_config)
        '';
      };
    };

This is being done to set linkage flags for static cross compilation. I'm unaware of any other way to inject these in cargo2nix - i'd love to been shown to be incorrect.
[target."aarch64-unknown-linux-musl"]
linker = "aarch64-unknown-linux-musl-ld"
rustflags = ["-C", "target-feature=+crt-static", "-C", "link-arg=-s"]

Building the dependencies for this target will have different flags than building those dependencies for other targets, which if encoded in metadata would cause what i'm seeing if those dependencies were reused. I don't have a great handle on what metadata cargo stores, but i'd believe link flags were amongst them.
Does this seem likely? If so what would be a better method for injecting these rust flags for this target and its deps?

We've come to hit this issue as well. We use crates2nix however.

@Fuuzetsu Is there a related issue in that project? Also, are you doing cross compilation?

@Fuuzetsu Is there a related issue in that project? Also, are you doing cross compilation?

No issue on cargo2nix that I know of.
w.r.t. reproduction, sadly it's a closed source project that has been working well up until recently when we hit this issue. We have a workspace with maybe like 20 crates (not at PC to check) and when we added one more, the new crate is having the problem. I found this ticket by Googling.
We are not doing cross compilation.

@Fuuzetsu Is there a related issue in that project? Also, are you doing cross compilation?

No issue on cargo2nix that I know of.
w.r.t. reproduction, sadly it's a closed source project that has been working well up until recently when we hit this issue. We have a workspace with maybe like 20 crates (not at PC to check) and when we added one more, the new crate is having the problem. I found this ticket by Googling.
We are not doing cross compilation.

Sorry, first line meant to say crate2nix, not cargo2nix

@Fuuzetsu Are you able to share how you invoke crate2nix?
My working assumption for this error is its something in the manner in which I'm setting the linkage flags not propagating correctly. However, that could be completely unrelated, and there is some more fundamental bug here.
The way this first manifested itself for us was very similar to what your describe - we've 15 or so crates in a workspace (closed source), and adding a new one caused this problem.

@Fuuzetsu Are you able to share how you invoke crate2nix?
My working assumption for this error is its something in the manner in which I'm setting the linkage flags not propagating correctly. However, that could be completely unrelated, and there is some more fundamental bug here.
The way this first manifested itself for us was very similar to what your describe - we've 15 or so crates in a workspace (closed source), and adding a new one caused this problem.

We're not doing anything strange with the crates I think: I am adding things like buildInputs to a bunch and setting some env vars to the others but once we get past that, it's fairly vanilla. I'm not messing with linking (except for a single crate where I use extraLinkFlags to deal with https://github.com/NixOS/nixpkgs/issues/119382).
I don't really think it's an issue with how we're invoking the builder nor with what you're doing. I initially was blaming non-determinism of rustc but it doesn't explain why changing the whitespace in the upstream crate makes it work sometimes... The issue happening when a crate is added is also very strange: they ought to be just separate derivations, I don't understand why they would be affecting each other.
Honestly I'm a bit lost as to how to deal with this. I was going to try and examine what's happening during the build in detail when I got some time but I haven't gotten to that point yet. If we have a way to replicate the issue then change some whitespace and have a working build, it should presumably be possible to examine what rustc is doing during the build and find the difference...

@Fuuzetsu Are you able to share how you invoke crate2nix?
My working assumption for this error is its something in the manner in which I'm setting the linkage flags not propagating correctly. However, that could be completely unrelated, and there is some more fundamental bug here.
The way this first manifested itself for us was very similar to what your describe - we've 15 or so crates in a workspace (closed source), and adding a new one caused this problem.

We're not doing anything strange with the crates I think: I am adding things like buildInputs to a bunch and setting some env vars to the others but once we get past that, it's fairly vanilla. I'm not messing with linking (except for a single crate where I use extraLinkFlags to deal with NixOS/nixpkgs#119382).
I don't really think it's an issue with how we're invoking the builder nor with what you're doing. I initially was blaming non-determinism of rustc but it doesn't explain why changing the whitespace in the upstream crate makes it work sometimes... The issue happening when a crate is added is also very strange: they ought to be just separate derivations, I don't understand why they would be affecting each other.
Honestly I'm a bit lost as to how to deal with this. I was going to try and examine what's happening during the build in detail when I got some time but I haven't gotten to that point yet. If we have a way to replicate the issue then change some whitespace and have a working build, it should presumably be possible to examine what rustc is doing during the build and find the difference...

Oh, I wanted to add something. One thing that's different on say my machine where build works vs coworker's machine where build failed vs CI where build failed is the codegen-units rustc parameter that basically comes from the environment. This parameter is very suspicious and I think easily can lead to different build results. This could explain why it builds on one machine but fails in CI. I have not yet tried tuning NIX_BUILD_CORES but I wonder if it'd work to set it to say 1 in CI or something.

I think you may have something with codegen-units. I hadn't considered this, but our errors started around the time we bumped our CI machines from 8 to 16 cores.
I'm not sure of the exact correlation, because the CI infrastructure was done out of band from our commit history. Perhaps codegen-units should be a build parameter in cargo2nix / crate2nix.

The docs suggest this is not the case though:

I'm not sure what you mean by this. The defaults aren't used in nix builds. See build-crate.nix and configure-crate.nix.

For now I'm going to send MR to nixpkgs to make codegen-units configurable. Will need changes in crates2nix and cargo2nix to make use of it of course but have to start somewhere.

The docs suggest this is not the case though:

I'm not sure what you mean by this. The defaults aren't used in nix builds. See build-crate.nix and configure-crate.nix.

Cargo2nix uses cargo to do the building

The docs suggest this is not the case though:

I'm not sure what you mean by this. The defaults aren't used in nix builds. See build-crate.nix and configure-crate.nix.

Cargo2nix uses cargo to do the building

Ah, I see. I still am not sure what you mean by "this is not the case" in this situation but as I understand, this means that probably cargo2nix is using the value of 16 as release builds are non-incremenal by default as of few rust versions ago (and nix builds aren't able to be incremental anyway so one would hope it's doing non-incremental settings anyway).
I guess the patch to nixpkgs doesn't matter for cargo2nix and for your usecase you should just either patch cargo2nix to set the flag explicitly or set it in Cargo.toml, assuming it gets honoured properly.

We started doing codegen-units=1 in our codebase recently in hopes that it'd fix the issue. Sadly, I just hit this again even with codegen-units=1 so it doesn't make the issue go away. I guess this needs some real debugging ;/

Need to look at the drv's between success & failure.  In the tree of dependencies, there's got to be some extra drv's that show up (along with old ones) or else the impurity is a non-determinism that's leaking in, meaning the intensional store winds up with multiple results at the same nix path.  It's a great help to spot the propagation of differences in the drvs

0.9.1 has fixed a behavior where trivial features were leaking down into dependencies.  This might actually help the behavior.

After reading more into Fuuzetsu's experience, it's pretty clear that this issue is with Rust, non-deterministic binary outputs.  In general, we can't protect from non-determinism.  I guess would could recommend an override workflow for the specific crate to always trigger rebuild.  A workaround is the right answer if there's unavoidable non-determinism in the Rust dependency or some rustc behavior.

Yes, rustc 1.55 seems OK and issues there lie with macro crates that produce non-deterministic output.
In rustc 1.56, there are issues with compiler (rather, LLVM) itself in general so I would wait for 1.57 where there are bunch of fixes.
There's a nix config flag that you can set to rebuild all packages multiple times and check hashes: this can help catch non-deterministic packages ahead of time, hopefully before they go into your binary caches etc. Another is to override your rust deps with preferLocalBuild or whatever it is.
For us, we are just on 1.55 for now.

so I would wait for 1.57 where there are bunch of fixes.

@Fuuzetsu   Did you see any fixes land as expected?

so I would wait for 1.57 where there are bunch of fixes.

@Fuuzetsu Did you see any fixes land as expected?

Yes, there were a bunch. We ran into another issue but it turned out to be a derive crate producing code from a macro in non-deterministic way. It's looking like we're going to be upgrading from 1.55 to 1.57, skipping the broken 1.56.
You can see some issues getting fixed in https://github.com/rust-lang/rust/issues/90301 – it's all LLVM stuff.

Then I think it's appropriate to handle this issue as errata, noting it in the common issues on the README but not attempting to hunt it down as a nix or cargo2nix issue.  With no objections, I'll include this note in my open PR and close this issue on merge.

Then I think it's appropriate to handle this issue as errata, noting it in the common issues on the README but not attempting to hunt it down as a nix or cargo2nix issue. With no objections, I'll include this note in my open PR and close this issue on merge.

Yes, there is nothing on the nix side that's broken or that one can do beyond something like "disable binary caches because binaries are randomly not compatible". Definitely nothing cargo2nix or crate2nix or anything can do (except somehing crazy like enabling preferLocalBuild or something).


Add license to package.json

yarn build reports:
warning ..\..\..\..\..\package.json: No license field
[1/5] Validating package.json...
warning<EMAIL_ADDRESS>The engine "podman-desktop" appears to be invalid.
[2/5] Resolving packages...
[3/5] Fetching packages...
[4/5] Linking dependencies...
[5/5] Building fresh packages...
Done in 50.22s.

License field is in package.json https://github.com/redhat-developer/podman-desktop-sandbox-ext/blob/c34fd4855abd492a3fed985b754a94b26d1628ee/package.json#L8
closing. cannot replicate.


openai/clip-vit-large-patch14 were not used when initializing CLIPVisionModel

I running this command
python video_chatgpt/demo/video_demo.py
--model-name Video-ChatGPT_Models/LLaVA-Lightning-7B-v1-1
--projection_path Video-ChatGPT_Models/video_chatgpt-7B.bin
It seems to work well with this, but I'm not sure if this is really okay, any advice would be appreciated.

@minuenergy
No problem, some weights in picture belong to encoder.
Don't worry

Hi
As pointed by @jhj7905, these warnings are expected. Thanks

Hi, a followup to this question can we use vit base version instead of large while inferencing and from exactly where do we get the above warning as this not in the code base as far as I saw.


-I argument: support load-path customisation

Add -I dir to look up source files in other directories.

I just added minimal support for inclusion path.
Inclusion path is populated by passing -I arguments: texpresso -I path1 -I path2 doc_dir/main.tex.
The paths should be either absolute or relative to the document directory (doc_dir in the command line above).

Working good enough for me.


Uploading images

I know this question has been asked and has been around for quite sometime.
Am making an app where users should post images to server and the image retrieved in the view.
I need a way to store maybe the images url in the db,and a mongoose shema.The backend code i have is
in the image.server.controller.js
//image upload handler
exports.imageUpload = function(req, res) {
var file = req.files.file,
path = './public/modules/images/img';
// Logic for handling missing file, wrong mimetype, no buffer, etc.

var buffer = file.buffer, //Note: buffer only populates if you set inMemory: true.
    fileName = file.name;
var stream = fs.createWriteStream(path + fileName);
stream.write(buffer);
stream.on('error', function(err) {
    console.log('Could not write file to memory.');
    res.status(400).send({
        message: 'Problem saving the file. Please try again.'
    });
});
stream.on('finish', function() {
    console.log('File saved successfully.');
    var data = {
        message: 'File saved successfully.'
    };
    res.jsonp(data);
});
stream.end();
console.log('Stream ended.');

};
I used multer to handle the upload https://github.com/expressjs/multer and i have already required it.
exports.imageUpload = function(req, res) {
var file = req.files.file,
path = './public/modules/images/img';
// Logic for handling missing file, wrong mimetype, no buffer, etc.
var buffer = file.buffer, //Note: buffer only populates if you set inMemory: true.
    fileName = file.name;
var stream = fs.createWriteStream(path + fileName);
stream.write(buffer);
stream.on('error', function(err) {
    console.log('Could not write file to memory.');
    res.status(400).send({
        message: 'Problem saving the file. Please try again.'
    });
});
stream.on('finish', function() {
    console.log('File saved successfully.');
    var data = {
        message: 'File saved successfully.'
    };
    res.jsonp(data);
});
stream.end();
console.log('Stream ended.');

};
I need to add angular controller and view in the client side.
i had a simple form with
enctype="multipart/form-data"
action="/images"
method="post">
Am stuck around here ,any help will be appreciated.

This really isn't a MEAN.js question. Please post on SO or on the Google forum before coming here.

... Or carefully look through the mean 0.4 code where you'll find all the
answers since the code is already there! 😊
On Wednesday, February 25, 2015, Ilan Biala<EMAIL_ADDRESS>wrote:

This really isn't a MEAN.js question. Please post on SO or on the Google
forum before coming here.
—
Reply to this email directly or view it on GitHub
https://github.com/meanjs/mean/issues/429#issuecomment-76010832.

@karan-kapoor90 Hey,am using mean 0.4, :( i can't see the code apart for the one of uploading user image.


smtp handler body html parse

Question
A clear and concise description of your question.
Hi @Badgerati
I have a new question, I try to parse the smtp body content, but when client sent, I cannot always ask them to change to plain text format, if they sent with html format, how I can parse them?
Thanks
Eric Xin

Hi @ericxin1982,
Have you example of what the format the body is in, or how the email is being send? I would have expected the $SmtpEvent.Email.Body to contain the plain HTML from the client - but I can see this being different if the encoding/content-type isn't as expected 🤔

Let me try again.
And I have another concern:
I sent my email from outlook 365 to this pode smtp server, outlook mail tracer showed the email has been delivered, but pode smtp server has no response, but some public email service sent, pode smtp server can receive, I am puzzled.
Thanks
Eric Xin

To be honest, I'm surprised Outlook can send email to a Pode SMTP server since it's not a public exchange! Where is the email being sent to, and how does it get to the Pode SMTP server?
If you have New-PodeLoggingMethod -Terminal | Enable-PodeErrorLogging -Levels Error, Debug set, do you see any errors on the terminal?

I am running pode smtp server in the public internet,and give this IP to mx record for one speciifc domain, then the email can be delivered, ok, I would set up the log method and share you the output.
Thanks
Eric Xin

Apart from if it's possible to so this with pode I'd recommend rethinking this setup.

Running a webserver accessible from the internet directly sounds kinda scary
What I learned whenever I was trying to parse HTML is "never parse HTML"
Just my 2 cents but maybe there's a better solution for whatever you're trying to achieve

Greetings
Mike

hi @Badgerati
I got something from exchange sent.

Can you see what that is.
Thanks
Eric Xin

Hi @Badgerati
I am new to github, so I do not know how to sumbit the change, but I have changed this bug.
This sentence below
headers.Add(match.Groups["name"].Value, match.Groups["value"].Value)
changed to the statement below.
if (headers.ContainsKey(match.Groups["name"].Value))
{
headers[match.Groups["name"].Value] = headers[match.Groups["name"].Value].ToString + ";" + match.Groups["value"].Value;
}
else
{
headers.Add(match.Groups["name"].Value, match.Groups["value"].Value);
}
And it works.
My code should not be perfect, but it works, I just share what I did.
Thanks
Eric Xin

Hi @ericxin1982,
Thanks for the code snippet 😄  I'll going to re-open this issue just so is stays on the radar and doesn't get lost for the next release 😉

Hi @ericxin1982,
I've applied a fix similar to yours above. The only difference is that when multiple headers are detected they'll be converted into a List object rather than appended as a string with ; separators - as the Received header can also contain the ; character.

@Badgerati No problem, thanks for update. When 2.9 can be released? Thanks!

@ericxin1982 I'm hoping sometime this month.

Thanks very much!


Cannot receive filenames without complete dir absolute path

After checking all the available options, I seem unable to remove dir absolute names from glob results.
For example: result /root/mydir/file.txt should be presented as plainly file.txt
Isn't there an option to obtain that?

There is an option absolute that should be defaulted to false but it doesn't work.

This is still a problem in version 7.1.3

I just noticed that it apparently depends on the globbing pattern provided.  When specifying a relative pattern without an absolute prefix it works.

The plan for 9.1 is that absolute:false will mean "always relative", absolute:true will mean "always absolute", and absolute:undefined will mean "relative if the pattern is relative, absolute if the pattern is absolute".  (Currently in 9.0, absolute:false is handled like absolute:undefined.)


Added headless selection API

@jyasskin @mikaelkindborg
This PR addresses #10 by extending requestDevice() and adding a cancelRequest() as discussed in the issue:
bluetooth.requestDevice({
    filters:[{ services:[ "heart_rate" ] }],
    // adding this function causes the Promise to resolve on timeout with no device, not reject
    deviceFound: function(bluetoothDevice) {
        addDeviceToList(bluetoothDevice);
        // for synchronous requirements returning true here can stop scanning and
        // resolve Promise of requestDevice() with current bluetoothDevice
    }
})
.then(...

var bluetoothDevices = [];
function addDeviceToList(bluetoothDevice) {
    bluetoothDevices.push(bluetoothDevice);
    // display found devices to the user
}

// event when user chooses a device
function handleUserSelect(index) {
    var bluetoothDevice = bluetoothDevices[index];

    // 'cancelRequest()' stops scanning and returns a promise
    bluetooth.cancelRequest()
    .then(() => {
        return bluetoothDevice.gatt.connect();
    })
    ...
}

The PR includes two new node examples showing continuous eddystone scanning and realtime command-line selection of a device.
What are your thoughts?

@thegecko Looking forward to experimenting with this!

@thegecko Very cool with the Eddystone example!
I don't get how/when .then(scan) is called. (I have not really got the hang on when .then is called in general, how it can be called without resolving any promise. Will study the code a bot more!)

@mikaelkindborg It's just a recursion

@beaufortfrancois @scheib @g-ortuno You may be interested in this headless Web Bluetooth "extension"

@thegecko Looked further at api-web-bluetooth.js and now better understand how the Eddystone example works! My understanding is that in the Eddystone example, .then(scan) will never be called, since handleDeviceFound does not return a truthy value or call cancelRequest. Is this correct?

.then(scan) does get called recursively once the scan timeout completes.
The requestDevice() call resolves instead of rejecting because a deviceFound function has been specified.

@thegecko Oh, I didn't consider the scan timeout! Thanks for clarifying this.

It is interesting! Will definitely look at this when addressing https://github.com/WebBluetoothCG/web-bluetooth/issues/191


Unify gate memory layout for lgpu and ltensor

Before submitting
Please complete the following checklist when submitting a PR:

[ ] All new features must include a unit test.
If you've fixed a bug or added code that should be tested, add a test to the
tests directory!

[ ] All new functions and code must be clearly commented and documented.
If you do make documentation changes, make sure that the docs build and
render correctly by running make docs.

[ ] Ensure that the test suite passes, by running make test.

[x] Add a new entry to the .github/CHANGELOG.md file, summarizing the
change, and including a link back to the PR.

[x] Ensure that code is properly formatted by running make format.

When all the above are checked, delete everything above the dashed
line and fill in the pull request template.

Context:
[sc-77874]
Excitation gates' memory layout was col-major for LGPU, while they are row-major for LTensor. This PR unify memory layout for both, which will improve the maintainability of Lightning.
Description of the Change:
Benefits:
Possible Drawbacks:
Related GitHub Issues:

Sorry @AmintorDusko I accidentally pressed to ask for re-review from you!


feat: useStateHistory

Description
Introducing hook that stores defined amount of previous state values and provides handles to travel through them
Type of change

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

Checklist

[x] Read the Contributing Guide
[x] Perform a code self-review
[x] Comment the code, particularly in hard-to-understand areas
[x] Add documentation
[x] Add hook's story at Storybook
[x] Cover changes with tests
[x] Ensure the test suite passes (yarn test)
[x] Provide 100% tests coverage
[x] Make sure code lints (yarn lint). Fix it with yarn lint:fix in case of failure.
[x] Make sure types are fine (yarn lint:types).

What do you think about calling it useStateWithHistory?

Current name is draft.
About your proposal - it would better coney meaning, but for my ears it somewhy sounds not very well.

I've been thinking about useHistoryfulState but not sure about it.

Finalized and mergable now

Reviewing...

@streamich there been some files got in PR from rebase, deleted them now.

:tada: This PR is included in version 13.10.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Make local template tests not depend on SharedFramework

Currently in order to test the templates you must first build the Shared framework with something like eng\scripts\cibuild.cmd. That takes quite a while and makes doing templating work slow and arduous. If there was a way we could not have to build the Shared framework to test locally (the CI tests should still test against the Shared framework) that would help speed things up.
It's possibly not worth it to do this if it requires a big investment, but if it's medium or small it could really help template development speed.

Let's consider doing this only if it's a small issue.

Can you please assign a cost to this issue, @ryanbrandenburg? If it'll take time to evaluate, let's postpone till 3.1. If it's S feel free to move it to preview7.

Closing as a dupe


appengine?

Where is the AppEngine module? seem to be missing.

We haven't got to it yet. Like said, we've just started and it's early stages. But you're welcome to come up with a plan.

Now that Admin API is available, this can actually be implemented!


Space and Air Echelon and Mobility

Original question came from SMDC.
They reported a bug re: assigning echelon and mobility to Air tracks. Specifically, the echelon and/or the mobility amplifiers do not line up with the friendly frame. They work as expected in hostile, neutral, and unknown frames (see below).

Responded to them that it wouldn't work, since it was never fixed. It wasn't fixed because it's not supposed to be possible. Echelon and Mobility are not valid in MIL-STD-2525D (see below).

Especially in the "a la carte" spirit of MIL-STD-2525D, this should change. It is possible to have a group of aircraft that might require an echelon (though the echelons might require additional names, like:

Element
Flight
Squadron
Group
Wing
... etc.

Additionally, we have aircraft that are ski-equipped (see below), which would match the requirement to use that mobility amplifier.

So, suggest the following course(s) of action:

Draft CPs for allowing echelon and mobility in Space and Air symbol sets
Edit SVGs to accommodate friendly air frames
Update JMSML

FYI: @ottenw, @wmcgrane, @Dbarnes1, @drdanstephens

I noticed that the Utility modifier is not quite centered on the enemy frame (along with the echelon, which as stated below, is currently not allowed).
Is there a way to get a dump of complete symbols from you (Joe). I will manually review them an adjust as needed for the next release.
Mike
From: Joe Bayles<EMAIL_ADDRESS>Sent: Wednesday, October 19, 2016 11:40 AM
To: Esri/joint-military-symbology-xml
Subject: EXT :[Esri/joint-military-symbology-xml] Space and Air Echelon and Mobility (#328)
Original question came from SMDC.
They reported a bug re: assigning echelon and mobility to Air tracks. Specifically, the echelon and/or the mobility amplifiers do not line up with the friendly frame. They work as expected in hostile, neutral, and unknown frames (see below).
[10060100151102000700]https://cloud.githubusercontent.com/assets/5016557/19525793/03e239e0-95d7-11e6-8059-135a49e3a00f.png
[10030100151102000700]https://cloud.githubusercontent.com/assets/5016557/19525805/09cd8dbe-95d7-11e6-82cc-db20893ce266.png
Responded to them that it wouldn't work, since it was never fixed. It wasn't fixed because it's not supposed to be possible. Echelon and Mobility are not valid in MIL-STD-2525D (see below).
[image]https://cloud.githubusercontent.com/assets/5016557/19525037/8b4f82b4-95d4-11e6-81d2-cd35d6b54dab.png
Especially in the "a la carte" spirit of MIL-STD-2525D, this should change. It is possible to have a group of aircraft that might require an echelon (though the echelons might require additional names, like:

Element
Flight
Squadron
Group
Wing
... etc.

Additionally, we have aircraft that are ski-equipped (see below), which would match the requirement to use that mobility amplifier.
[image]https://cloud.githubusercontent.com/assets/5016557/19525474/e5087d96-95d5-11e6-8dfd-0054226f1fc6.png
So, suggest the following course(s) of action:

Draft CPs for allowing echelon and mobility in Space and Air symbol sets
Edit SVGs to accommodate friendly air frames
Update JMSML

FYI: @ottenwhttps://github.com/ottenw, @wmcgranehttps://github.com/wmcgrane, @Dbarnes1https://github.com/Dbarnes1
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/Esri/joint-military-symbology-xml/issues/328, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AG-ghdJbysXkrcyXQ_eMeTJqCr34CGmJks5q1jmygaJpZM4KbIOa.

@mepler Sure thing Mike, latest versions are here:
https://github.com/Esri/joint-military-symbology-xml/tree/dev/svg


Add feature to navigate user input history

Add a new feature to allow users of HackNet to navigate through user input history of current session using ↑ and ↓.
UG has been updated as well.

Codecov Report

Merging #69 (0dcf6e4) into master (4d638f9) will decrease coverage by 1.68%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master      #69      +/-   ##
============================================
- Coverage     72.20%   70.51%   -1.69%
  Complexity      498      498
============================================
  Files            83       84       +1
  Lines          1547     1584      +37
  Branches        166      170       +4
============================================
  Hits           1117     1117
- Misses          376      413      +37
  Partials         54       54

Impacted Files
Coverage Δ

...n/java/seedu/address/storage/TextFieldStorage.java
0.00% <0.00%> (ø)

src/main/java/seedu/address/ui/CommandBox.java
0.00% <0.00%> (ø)

src/main/java/seedu/address/ui/PersonCard.java
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4d638f9...0dcf6e4. Read the comment docs.


Jim/63053/apply conditional rendering to improve performance

Changes:

...

Type of change

[ ] Bug fix
[ ] New feature
[ ] Update feature
[ ] Refactor code
[ ] Translation to code
[ ] Translation to crowdin
[ ] Script configuration
[X] Improve performance
[ ] Style only
[ ] Dependency update
[ ] Documentation update
[ ] Release

Shouldn't we remove ROW, UK, EU components now?
if we don't remove them now, it may cause confusion in the future.

Using the Wrapper Components like <ROW> or <EU> and the others calls the useCountryRule hook, which in my opinion is not very damaging, but also not efficient. e.g. In the screenshot below, the hook is unnecessarily called for both cases


[Bug]: The page not found error is displayed when user tries to view the app in view mode

Is there an existing issue for this?

[X] I have searched the existing issues

Description
The page not found error is displayed when user tries to view the app in view mode

Steps To Reproduce

Login to the application
inside the editor
Intially the page 1 would be a home page
Now change the home page
dont deploy the app
go back to the home page
Click on lunch button
The error displayed in the view mode is wrong

Public Sample App
No response
Issue video log
No response
Version
release

Not a issue


Issue using some container widgets

I could be totally off base but I am not able to use some container widgets like box and hsplit in a definition like box . label $ "foo",
due to this warning:
No instance for (Typeable s) arising from a use of ‘box’
I am unable to use box with any widget that I tried, aliasing the box function box' = box showed the same warning in the definition so it doesn't appear only when applying box to other widgets.
I wrote some aliases for label and box:
_label :: (Typeable s, Typeable e) => Text -> WidgetNode s e
_label = label

_box :: (Typeable s, Typeable e) => WidgetNode s e -> WidgetNode s e
_box = box

__box :: (WidgetModel s, WidgetEvent e) => WidgetNode s e -> WidgetNode s e
__box = box

_t :: (Typeable s, Typeable e) => Text -> WidgetNode s e
_t = _box . _label

And this definition of _box and __box does not show the warning itself but I am still unable to apply it to either label or _label, though the definition _t shows no warning until it is applied to some Text.
Also tried reverting from monomer-<IP_ADDRESS> to monomer-<IP_ADDRESS> but had the same issue. This may be kind of a noob Haskell problem and not related to Monomer at all so I apologize if this is not worth a ticket.

Hi @monawasensei!
If you have a complete example, even something like the default Main.hs file with enough changes to reproduce the problem, I can take a look.
Does the same happen if you use vstack, for example?

Thanks for the reply! I've been trying to reproduce this in the sample Main.hs from the tutorial but I can't. I've managed to reproduce the exact set of packages used in my project in the tutorial project but the issue is not appearing there, only in my other project. I've tried deleting my package store and re-installing everything and that did not resolve the problem. Really kind of stumped on how to reproduce this to be honest with you. I've tried using box in the Main module of my project that is seeing that issue and it works too.
Okay I've found a way to reproduce this and it probably gives a good hint as to why it's happening that I am unaware of. The issue does not appear when I use box in my Main module but I have a separate module, Node.Base where I am defining the WidgetNodes I'm using. I can provide a sample cabal project I believe should reproduce this for you. In the meantime, using Tutorial01_Basics.hs as Main.hs you might be able to see this. If you use a box in Main.hs it will work but if you have a module structure like:
app/
---- Main.hs
---- Node/
--------Base.hs
where Base.hs is
module Node.Base () where

import Monomer

t = box . label

You should be able to see this error.
app/Node/Base.hs:5:5: error:
    • No instance for (base-<IP_ADDRESS>:Data.Typeable.Internal.Typeable
                         s0)
        arising from a use of ‘box’
    • In the first argument of ‘(.)’, namely ‘box’
      In the expression: box . label
      In an equation for ‘t’: t = box . label

And by the way, vstack and hstack both work for me. I think the problem containers I have are the ones where the function signatures are parameterized with either (WidgetModel s) or (WidgetEvent e).
like this:
box :: (WidgetModel s, WidgetEvent e) => WidgetNode s e -> WidgetNode s e

or
hsplit :: WidgetEvent e => (WidgetNode s e, WidgetNode s e) -> WidgetNode s e

and neither label nor the stacks have those parameterizations like
label :: Text -> WidgetNode s e

and they both work without issue.

monomer-issue.tar.gz
Here is an archive of a cabal project that should reproduce this issue

I tested the Node.Base example (not the tar.gz one), and this modified version compiles:
module Node.Base () where

import Data.Text
import Monomer

t :: (WidgetModel s, WidgetEvent e) => Text -> WidgetNode s e
t = box . label

This works because it satisfies the requirements of the box function: it expects to receive a WidgetNode whose type arguments are of type WidgetModel for s, and type WidgetEvent for e (both WidgetModel and WidgetType are aliases of Typeable). Since, in this case, we're being explicit in the type signature, everything works fine.
Alternatively, you can omit the type signature as long as you use the t function anywhere in your widget tree (and it resides in the same module). In that scenario, GHC is able to infer the type of t and it will also work.
t = box . label

buildUI
  :: WidgetEnv AppModel AppEvent
  -> AppModel
  -> WidgetNode AppModel AppEvent
buildUI wenv model = widgetTree where
  widgetTree = vstack [
      label "Hello world",
      t "Test"
  ]

In any other situation, GHC can't be sure that s and e satisfy the requirements imposed by box and gives you a compilation error.

(WidgetModel s, WidgetEvent e) =>

Was exactly what I was missing from my WidgetNode definition. Adding that to each of my definitions fixed the problem, simple fix lol. Thanks so much!


Don't include extra attributed in metadata when creating a patch

Expected behavior
Creating a patch in ship init, the minimal attributes necessary should be included in the patch.
Actual behavior
labels are included in metadata.
Information

Ship version: efb845c

Steps to reproduce the behavior

create a patch by clicking on a deployment
see the tiller labels in the patch

It seems that when the labels are removed and the patch is applied -  the labels are removed from the overlay. I can remove the labels from the UI and add them only when the overlays are finalized. However, that seems too "magic" and you would be unable to change the labels. Thoughts?


Don't silently fix invalid JSON with duplicate keys

Checklist

[x] I've searched for similar feature requests.

What enhancement would you like to see?
When a server returns invalid JSON, the HTTPie formatter should either leave it untouched or fail loudly. As it stands, if the JSON contains duplicate keys, HTTPie will quietly remove the duplicates during formatting.
What problem does it solve?
When debugging broken services, it's important that I can trust HTTPie to faithfully show me what the server returned, so that I focus on figuring out what's going wrong with my services and not have to spend that time thinking about HTTPie.
From my point of view it's helpful for HTTPie to format and color text, I'd rather it didn't sort keys by default but I know that I can reconfigure that, but it's a problem if HTTPie is removing anything that isn't non-significant whitespace. If HTTPie is to be a general purpose tool it is important that it doesn't mask problems.
Provide any additional information, screenshots, or code examples below:
The below example is my motivation for this feature. This server is returning invalid JSON with duplicate keys in the "dps" object. But I could not tell it was doing this, because HTTPie had silently "corrected" the output during formatting. You can see that if I turn off formatting and only colorize the output, I see the true output.
annettewilson@ANNEWILS02M:~/scratch/undercity$ http GET 'http://opentsdb.skymetrics.prod.skyscanner.local:4242/api/query' m=='zimsum:prod.undercity.search_cycle.meter.count_delta{}{dataCenter=literal_or(EU_WEST_1),endpoint=literal_or(search),from_bot=literal_or(false)}' start==1630064720 end==1630064727
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 232
Content-Type: application/json;charset=utf-8
Date: Wed, 01 Sep 2021 09:07:45 GMT
Vary: Accept-Encoding
X-OpenTSDB-Query-Complexity: 318

[
    {
        "aggregateTags": [
            "ip",
            "traffic_source"
        ],
        "dps": {
            "1630064726": 6.0
        },
        "metric": "prod.undercity.search_cycle.meter.count_delta",
        "tags": {
            "dataCenter": "EU_WEST_1",
            "endpoint": "search",
            "from_bot": "false"
        }
    }
]

annettewilson@ANNEWILS02M:~/scratch/undercity$ http GET 'http://opentsdb.skymetrics.prod.skyscanner.local:4242/api/query' m=='zimsum:prod.undercity.search_cycle.meter.count_delta{}{dataCenter=literal_or(EU_WEST_1),endpoint=literal_or(search),from_bot=literal_or(false)}' start==1630064720 end==1630064727 --pretty colors
HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
Date: Wed, 01 Sep 2021 09:07:59 GMT
Vary: Accept-Encoding
X-OpenTSDB-Query-Complexity: 318
Content-Length: 232
Connection: keep-alive

[{"metric":"prod.undercity.search_cycle.meter.count_delta","tags":{"endpoint":"search","dataCenter":"EU_WEST_1","from_bot":"false"},"aggregateTags":["ip","traffic_source"],"dps":{"1630064726":5.0,"1630064726":3.0,"1630064726":6.0}}]

Thanks for the thorough description. I agree that the current behavior is not acceptable for the formatted output use case. It’s the default behavior of the underlying library we use.
We should customize the JSON loader/serializer we use for formatting to allow repeated keys. Ideally, we’d also extend the JSON lexer to mark repeated keys as errors, but that might be too big of a project for such a rare scenario.

Oh, it's thornier than I realised. Apparently the JSON specification doesn't require keys to be unique. It just leaves it up to JSON processors. 😱 Still, I don't think that remove the onus from HTTPie to do something sensible. It just makes it harder. It looks like it's super easy to parse using object_pairs_hook=multidict.MultiDict and largely impossible to serialise without rewriting the json library. I guess you could at least use that to detect such a case and fall back to something safe.

Interesting that JSON doesn’t prohibit duplicate keys. But it makes sense, though. It’s valid on the language syntax level, and semantically it could be explained as following the JS object notation behavior where the latest occurrence overwrites any earlier ones.
In any case, we shouldn’t alter the data for display. object_pairs_hook=multidict.MultiDict might be a good start. Cc @BoboTiG

@annettejanewilson Using a custom multidict, we can achieve that output:
{
    "dps": {
        "1630064726": [
            5.0,
            3.0,
            6.0
        ]
    }
}

It is still not the same output as for --pretty=colors in the sens we loose the repeated lines. Still, does such output would help in you case?

The data should not be interpreted/transformed in any way other than the documented one. So this doesn’t work.

OK I have a working patch. I'll wait for the #1130 merge because changes will conflict then.


[BUG] Login-Home bug

Added user authorization api and working on UI
Originally posted by @BosamiyaSimran in https://github.com/thosaniparth/Recipe_Recommender/issues/1#issuecomment-977515411
A new bug is seen on the existing issue:
When we search recipe on home page, then go to login page and then come back to home page the recipe list is still rendered based on previous search

Resolved.


Fix build errors due to dep changes

Codecov Report
Patch and project coverage have no change.

Comparison is base (e1525bf) 100.00% compared to head (fbab7bc) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main        #2   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         2
  Lines          234       234
  Branches        48        48
=========================================
  Hits           234       234

Flag
Coverage Δ

unittests
100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


The first ARM (Apple Silicon) bottles are here, help us test them

Help needed
Our Apple Silicon CI is ready, hardware- and software-wise. We have built our first ARM bottles, and they are working fine on our testing machines. But before we go on building as many bottles as possible, we want to have more exposure of these bottles, and gather feedback. There are, necessarily, some kinks to work out in brew itself (and its bottling process) for ARM, since we're deploying to a new platform, and we want to make sure we identify as many as possible before we start mass-bottling.
What can you do? Test those new ARM bottles on your ARM Macs, and report below if you have any failure, problem, or other weirdness.
How to report an issue? Create a post below, and include:

what you were doing (the command)
what the output was (and give the full output in a link)
the output of brew config in all cases (without it, for us it's like using a crystal ball)

What bottles are available?
autoconf automake bash bison boost
c-ares cairo cmake cscope fontconfig
freetype gdbm gettext git glib
gmp icu4c isl jpeg jsonlint
krb5 libevent libffi libomp libpng
libsodium libtiff libtool libyaml little-cms2
lua lzo meson mpfr mysql
ncurses ninja node<EMAIL_ADDRESS>p11-kit
pcre pcre2 perl pixman pkg-config
protobuf<EMAIL_ADDRESS>readline ruby sphinx-doc
sqlite tcl-tk vim xz zsh

List available with:
cd $(brew --repo homebrew/core)/Formula ; grep -l :arm64_big_sur *.rb | sed 's/.rb$//' | xargs

Do you want any confirmation that something works as expected, or only specific issues found?

@unitof good question. Things should be working, and I don't want to be flooded with “works for me too”-type posts, so let's go for: please only report issues/negative outcomes/problems with the bottles.
On the other hand, if things are working for you with one or more of these bottle, a 🚀  or ❤ or other emoji response to this post will let me count if people have been actively testing, or not.

In the list of bottles for ARM is node. But when I tried to install homebrew started compiling node. Dependencies (gdbm, xz<EMAIL_ADDRESS>icu4c) were installed without any compilation.
$ brew install node
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> Updated Formulae
Updated 1 formula.

We do not provide support for this (yet).
Reinstall Homebrew under Rosetta 2 until we support it.
You will encounter build failures with some formulae.
Please create pull requests instead of asking for help on Homebrew's GitHub,
Twitter or any other official channels. You are responsible for resolving
any issues you experience while you are running this
unsupported configuration.

==> Downloading https://homebrew.bintray.com/bottles/gdbm-1.18.1_1.arm64_big_sur.bottle.tar.gz
==> Downloading from https://d29vzk4ow07wi7.cloudfront.net/d5ae1727d7a669559f4f9333d165006ee5d2d7282a3e3a7aa1a28fddcdac6da2?response-content-disposition=attachment%3Bfilename%3D%22gdbm-1.18.1_1.arm64_big_
######################################################################## 100.0%
==> Downloading https://homebrew.bintray.com/bottles/xz-5.2.5.arm64_big_sur.bottle.tar.gz
==> Downloading from https://d29vzk4ow07wi7.cloudfront.net/409cface94d33051d3d5280af662e99c3e9d19a2a44d64e1d09a8af9717495d7?response-content-disposition=attachment%3Bfilename%3D%22xz-5.2.5.arm64_big_sur.b
######################################################################## 100.0%
==> Downloading https://homebrew.bintray.com/bottles/python%403.9-3.9.0_5.arm64_big_sur.bottle.tar.gz
==> Downloading from https://d29vzk4ow07wi7.cloudfront.net/5d890c25f640aa43b37102c7a922a723fa94886f8c8acb1e916eb267c297d526?response-content-disposition=attachment%3Bfilename%3D%22python%403.9-3.9.0_5.arm
######################################################################## 100.0%
==> Downloading https://homebrew.bintray.com/bottles/icu4c-67.1.arm64_big_sur.bottle.tar.gz
==> Downloading from https://d29vzk4ow07wi7.cloudfront.net/0d03423f2a4a557fc04a021fad963ab71d05b9129693887522dde996aff8c9f9?response-content-disposition=attachment%3Bfilename%3D%22icu4c-67.1.arm64_big_sur
######################################################################## 100.0%
==> Downloading https://registry.npmjs.org/npm/-/npm-7.0.15.tgz
######################################################################## 100.0%
==> Downloading https://nodejs.org/dist/v15.4.0/node-v15.4.0.tar.gz
######################################################################## 100.0%
==> Installing dependencies for node: gdbm, xz<EMAIL_ADDRESS>and icu4c
==> Installing node dependency: gdbm
==> Pouring gdbm-1.18.1_1.arm64_big_sur.bottle.tar.gz
🍺  /opt/homebrew/Cellar/gdbm/1.18.1_1: 25 files, 876.2KB
==> Installing node dependency: xz
==> Pouring xz-5.2.5.arm64_big_sur.bottle.tar.gz
🍺  /opt/homebrew/Cellar/xz/5.2.5: 95 files, 1.4MB
==> Installing node dependency<EMAIL_ADDRESS>==> Pouring<EMAIL_ADDRESS>==><EMAIL_ADDRESS>-s setup.py --no-user-cfg install --force --verbose<EMAIL_ADDRESS>--install-lib=/opt/homebrew/lib/py
==><EMAIL_ADDRESS>-s setup.py --no-user-cfg install --force --verbose<EMAIL_ADDRESS>--install-lib=/opt/homebrew/lib/py
==><EMAIL_ADDRESS>-s setup.py --no-user-cfg install --force --verbose<EMAIL_ADDRESS>--install-lib=/opt/homebrew/lib/py
==> Caveats
Python has been installed as
  /opt/homebrew/bin/python3

Unversioned symlinks `python`, `python-config`, `pip` etc. pointing to
`python3`, `python3-config`, `pip3` etc., respectively, have been installed into
<EMAIL_ADDRESS>
You can install Python packages with
  pip3 install <package>
They will install into the site-package directory
  /opt/homebrew/lib/python3.9/site-packages

See: https://docs.brew.sh/Homebrew-and-Python
==> Summary
🍺<EMAIL_ADDRESS>4,453 files, 72.8MB
==> Installing node dependency: icu4c
==> Pouring icu4c-67.1.arm64_big_sur.bottle.tar.gz
==> Caveats
icu4c is keg-only, which means it was not symlinked into /opt/homebrew,
because macOS provides libicucore.dylib (but nothing else).

If you need to have icu4c first in your PATH run:
  echo 'export PATH="/opt/homebrew/opt/icu4c/bin:$PATH"' >> ~/.zshrc
  echo 'export PATH="/opt/homebrew/opt/icu4c/sbin:$PATH"' >> ~/.zshrc

For compilers to find icu4c you may need to set:
  export LDFLAGS="-L/opt/homebrew/opt/icu4c/lib"
  export CPPFLAGS="-I/opt/homebrew/opt/icu4c/include"

For pkg-config to find icu4c you may need to set:
  export PKG_CONFIG_PATH="/opt/homebrew/opt/icu4c/lib/pkgconfig"

==> Summary
🍺  /opt/homebrew/Cellar/icu4c/67.1: 258 files, 72.4MB
==> Installing node
==> ./configure --prefix=/opt/homebrew/Cellar/node/15.4.0 --without-npm --with-intl=system-icu
==> make install
==> node /private/tmp/node-20201209-18177-7237f/node-v15.4.0/npm_bootstrap/bin/npm-cli.js install -ddd --global --prefix=/opt/homebrew/Cellar/node/15.4.0/libexec ~/Library/Caches/Homebrew/downl
🍺  /opt/homebrew/Cellar/node/15.4.0: 3,288 files, 54.6MB, built in 11 minutes 58 seconds
==> Caveats
==><EMAIL_ADDRESS>Python has been installed as
  /opt/homebrew/bin/python3

Unversioned symlinks `python`, `python-config`, `pip` etc. pointing to
`python3`, `python3-config`, `pip3` etc., respectively, have been installed into
<EMAIL_ADDRESS>
You can install Python packages with
  pip3 install <package>
They will install into the site-package directory
  /opt/homebrew/lib/python3.9/site-packages

See: https://docs.brew.sh/Homebrew-and-Python
==> icu4c
icu4c is keg-only, which means it was not symlinked into /opt/homebrew,
because macOS provides libicucore.dylib (but nothing else).

If you need to have icu4c first in your PATH run:
  echo 'export PATH="/opt/homebrew/opt/icu4c/bin:$PATH"' >> ~/.zshrc
  echo 'export PATH="/opt/homebrew/opt/icu4c/sbin:$PATH"' >> ~/.zshrc

For compilers to find icu4c you may need to set:
  export LDFLAGS="-L/opt/homebrew/opt/icu4c/lib"
  export CPPFLAGS="-I/opt/homebrew/opt/icu4c/include"

For pkg-config to find icu4c you may need to set:
  export PKG_CONFIG_PATH="/opt/homebrew/opt/icu4c/lib/pkgconfig"

So, node has a built bottle for ARM, or not?

node has an arm bottle listed in the formula bottle block.

How to report an issue? Create a post below, and include:

...
the output of brew config in all cases (without it, for us it's like using a crystal ball)

@deepj a bottle for node was built, but the update later today erased it. I am rebuilding, it should be available in ~15 minutes (brew upgrade should bring it to you)

Is there a brew command that lists bottles?

Is there a brew command that lists bottles?

@galak I put this together to list all bottles, part of the jq logic was from another issue in this repo. (sorry whoever you are, I don't remember 😦)
brew info --json=v1 --all | jq -r "map(select(.bottle.stable.files.arm64_big_sur) | .name) | unique | .[]"

It does take ~30s to run since it's loading all the formulae available, but it works. 🤷🏻

Here's something that will take much than 30 seconds:
cd $(brew --repo homebrew/core)/Formula
rg -l ':arm64_big_sur'

If you don't like the .rb suffix,
cd $(brew --repo homebrew/core)/Formula
rg -l ':arm64_big_sur' | xargs -I{} basename {} .rb

<EMAIL_ADDRESS>didn't install from a bottle for me. (it did compile, just didn't come from the bottle.) literally everything else on that list worked though.

Thanks for the report, @idyll. Could you please include the following information?

How to report an issue? Create a post below, and include:

what you were doing (the command)
what the output was (and give the full output in a link)
the output of brew config in all cases (without it, for us it's like using a crystal ball)

brew upgrade readline
output: https://gist.github.com/idyll/5d0760dcb080275e664014a7ee8eb0ef

HOMEBREW_VERSION: 2.6.1-25-gfc921bb
ORIGIN: https://github.com/Homebrew/brew
HEAD: fc921bb640f1fc60eaa263db50fbeccf3fc66324
Last commit: 2 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 93697825da4944984a7b496f565fc01f4d0c63ad
Core tap last commit: 25 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_EDITOR: vi
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit arm_firestorm_icestorm
Clang: 12.0 build 1200
Git: 2.24.3 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.0.1-arm64
CLT: N/A
Xcode: 12.2
Rosetta 2: false

This is why you don't get a bottle:
Warning: Building<EMAIL_ADDRESS>from source:
  The bottle needs the Apple Command Line Tools to be installed.
  You can install them, if desired, with:
    xcode-select --install

From your brew config:
...
CLT: N/A
...

@idyll thanks for the report. The reason is stated in the output, our Python bottles need the command-line tools:
Warning: Building<EMAIL_ADDRESS>from source:
  The bottle needs the Apple Command Line Tools to be installed.
  You can install them, if desired, with:
    xcode-select --install

So it's expected behaviour that on your system (without CLT) they build from source.

Very strange. I am 99% sure I installed the CLT. But the CLT installation stuff has been so problematic with Big Sur that I think I've installed it 30 times throughout the course of the beta.
And I just tried and it installed. So. 🤷

Very strange. I am 99% sure I installed the CLT. But the CLT installation stuff has been so problematic with Big Sur that I think I've installed it 30 times throughout the course of the beta.
And I just tried and it installed. So. 🤷

In my experience, the Big Sur Beta tools often needed to be downloaded separately from the dev download portal.  When the M1 arrived, I avoided the Beta Channel for this single reason.

brew install protobuf has error!
==> Downloading https://files.pythonhosted.org/packages/6b/34/415834bfdafca3c5f451532e8a8d9ba89a21c97
Already downloaded: /Users/hejiahao/Library/Caches/Homebrew/downloads/e99698a932bde9f5fb8ca552923ae339984f284e1c7764df95c12175f573c0d7--six-1.15.0.tar.gz
==> Downloading https://github.com/protocolbuffers/protobuf/releases/download/v3.14.0/protobuf-all-3.
Already downloaded: /Users/hejiahao/Library/Caches/Homebrew/downloads/703fe5ff9c3437b572add06c8fb8f734731cf4650ea84d5052c934839a14313d--protobuf-all-3.14.0.tar.gz
==> ./configure --prefix=/opt/homebrew/Cellar/protobuf/3.14.0 --with-zlib
==> make
==> make check
==> make install
==><EMAIL_ADDRESS>-c import setuptools... --no-user-cfg install --prefix=/
==><EMAIL_ADDRESS>-c import setuptools... --no-user-cfg install --prefix=/
Last 15 lines from /Users/hejiahao/Library/Logs/Homebrew/protobuf/06.python3:
--prefix=/opt/homebrew/Cellar/protobuf/3.14.0/libexec
--install-scripts=/opt/homebrew/Cellar/protobuf/3.14.0/libexec/bin
--single-version-externally-managed
--record=installed.txt
--cpp_implementation
Traceback (most recent call last):
File "", line 3, in
File "setup.py", line 211, in
if mac_target and (pkg_resources.parse_version(mac_target) <
File<EMAIL_ADDRESS>line 113, in parse_version
return packaging.version.Version(v)
File<EMAIL_ADDRESS>line 275, in init
match = self._regex.search(version)
TypeError: expected string or bytes-like object
Do not report this issue to Homebrew/brew or Homebrew/core!

brew install<EMAIL_ADDRESS>`==> /opt/homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/bin/pip install -v --no-deps --no-binary :all: --
==> /opt/homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/bin/pip install -v --no-deps --no-binary :all: --
==> /opt/homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/bin/pip install -v --no-deps --no-binary :all: --
==> /opt/homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/bin/pip install -v --no-deps --no-binary :all: --
==> /opt/homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/bin/pip install -v --no-deps --no-binary :all: --
==> /opt/homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/bin/pip install -v --no-deps --no-binary :all: --
Last 15 lines from /Users/hejiahao/Library/Logs/Homebrew/sphinx-doc/15.pip:
requirement.install(
File "/opt/Homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/lib/python3.9/site-packages/pip/_internal/req/req_install.py", line 856, in install
six.reraise(*exc.parent)
File "/opt/Homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/lib/python3.9/site-packages/pip/_vendor/six.py", line 703, in reraise
raise value
File "/opt/Homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/lib/python3.9/site-packages/pip/_internal/operations/install/legacy.py", line 74, in install
runner(
File "/opt/Homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/lib/python3.9/site-packages/pip/_internal/utils/subprocess.py", line 273, in runner
call_subprocess(
File "/opt/Homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/lib/python3.9/site-packages/pip/_internal/utils/subprocess.py", line 242, in call_subprocess
raise InstallationError(exc_msg)
pip._internal.exceptions.InstallationError: Command errored out with exit status 1: /opt/Homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/private/tmp/pip-req-build-89sd1ogr/setup.py'"'"'; file='"'"'/private/tmp/pip-req-build-89sd1ogr/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' install --record /private/tmp/pip-record-sxwedzx3/install-record.txt --single-version-externally-managed --compile --install-headers /opt/Homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/include/site/python3.9/MarkupSafe Check the logs for full command output.
WARNING: You are using pip version 20.2.4; however, version 20.3.1 is available.
You should consider upgrading via the '/opt/Homebrew/Cellar/sphinx-doc/3.3.1_1/libexec/bin/python -m pip install --upgrade pip' command.
Removed build tracker: '/private/tmp/pip-req-tracker-dfp0nn_m'
Do not report this issue to Homebrew/brew or Homebrew/core!
`

brew config :
HOMEBREW_VERSION: 2.6.0-51-gedb7496-dirty
ORIGIN: https://mirrors.ustc.edu.cn/brew.git
HEAD: edb7496630d3c6febab6003bf421eb072f1391bd
Last commit: 8 days ago
Core tap ORIGIN: https://mirrors.ustc.edu.cn/homebrew-core.git
Core tap HEAD: 88132eb4a1c8993a28c1a15b6ff2b1caf1b45f22
Core tap last commit: 8 days ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_REPOSITORY: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit dunno
Clang: 12.0 build 1200
Git: 2.24.3 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.0.1-arm64
CLT: <IP_ADDRESS>.1.1604076827
Xcode: N/A
Rosetta 2: false

Your brew and brew-core are out of date

Core tap HEAD: 88132eb4a1c8993a28c1a15b6ff2b1caf1b45f22
Core tap last commit: 8 days ago

This is your problem. There are no ARM bottles yet at this commit hash.

I tested with git clone, the mirror is up to date

@hexiu thanks for the report. You need to brew update to make sure you get the ARM bottles. Also, note that protobuf should have a bottle, but<EMAIL_ADDRESS>is not yet supported.
Thanks to @carlocab and @ywwry66 for investigating

@hexiu I see you have CPU: octa-core 64-bit dunno in your brew config output. Can you tell me what hardware (what exact mac model) you're using, and what the output of sysctl hw.cpufamily is for you?

hw.cpufamily: 458787763    @fxcoudert

@fxcoudert I think the dunno is explained by the outdated brew:

ORIGIN: https://mirrors.ustc.edu.cn/brew.git
HEAD: edb7496
Last commit: 8 days ago

@hexiu thanks!
@carlocab agreed, I wanted to double-check the value to see if we had missed something

@fxcoudert thanks，run brew update,  protobuf is installed<EMAIL_ADDRESS>is error,  waiting<EMAIL_ADDRESS>merged https://github.com/Homebrew/homebrew-core/pull/66489

@hexiu do you still see CPU: octa-core 64-bit dunno in brew config?

brew install<EMAIL_ADDRESS>==><EMAIL_ADDRESS>-c import setuptools... --no-user-cfg install --prefix=/
==><EMAIL_ADDRESS>-c import setuptools... --no-user-cfg install --prefix=/
Last 15 lines from<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>--single-version-externally-managed
--record=installed.txt
--cpp_implementation
Traceback (most recent call last):
File "", line 3, in
File "setup.py", line 198, in
if mac_target and (pkg_resources.parse_version(mac_target) <
File<EMAIL_ADDRESS>line 113, in parse_version
return packaging.version.Version(v)
File<EMAIL_ADDRESS>line 275, in init
match = self._regex.search(version)
TypeError: expected string or bytes-like object
Do not report this issue to Homebrew/brew or Homebrew/core!

@carlocab
➜  ~ abrew config
HOMEBREW_VERSION: 2.6.1-46-gd5283a7-dirty
ORIGIN: https://mirrors.ustc.edu.cn/brew.git
HEAD: d5283a77b95f1ce6740a429541f80bdad8a8da3b
Last commit: 11 hours ago
Core tap ORIGIN: https://mirrors.ustc.edu.cn/homebrew-core.git
Core tap HEAD: fff35e78c9b52392be323717075c78200063e60d
Core tap last commit: 2 hours ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit arm_firestorm_icestorm
Clang: 12.0 build 1200
Git: 2.24.3 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.0.1-arm64
CLT: <IP_ADDRESS>.1.1604076827
Xcode: N/A
Rosetta 2: false

@hexiu<EMAIL_ADDRESS>is not currently supported, only the main protobuf

thanks,  Since the main protobuf has some new changes that are not compatible with the old GRPC, Let me update my own project @fxcoudert

Installing swiftlint:

Command: brew install --build-from-source swiftlint
Tested on my iOS projects, works very well
Output: https://gist.github.com/bdolewski/8a6bdbff28edf9c861cb317bd4068e64
config:

HOMEBREW_VERSION: 2.6.2-123-ga065dbc
ORIGIN: https://github.com/Homebrew/brew
HEAD: a065dbcc9b10b15af1708f430630e792ca7b187f
Last commit: 12 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: f089a94551a521192bc13ad75a1ed6d4219ae3da
Core tap last commit: 2 hours ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit arm_firestorm_icestorm
Clang: 12.0 build 1200
Git: 2.29.2 => /opt/homebrew/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.1-arm64
CLT: <IP_ADDRESS>.1.1607026830
Xcode: 12.3
Rosetta 2: false

I started to doubt if that's the Issue where I should put errors from packages being installed (compiled) from source rather than bottles created by Homebrew's CI. Please, redirect me if possible 🙂
Also tried to install swiftgen. Not so joyful results:

Command: brew install --build-from-source swiftgen
Output: https://gist.github.com/bdolewski/53359ba6379c7c8834939265bd9e7e8b
Config:

➜  ~ brew config
HOMEBREW_VERSION: 2.6.2-123-ga065dbc
ORIGIN: https://github.com/Homebrew/brew
HEAD: a065dbcc9b10b15af1708f430630e792ca7b187f
Last commit: 13 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: fe40c5cb127c64b4a12aa47b0e94d35bf376a462
Core tap last commit: 7 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit arm_firestorm_icestorm
Clang: 12.0 build 1200
Git: 2.29.2 => /opt/homebrew/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.1-arm64
CLT: <IP_ADDRESS>.1.1607026830
Xcode: 12.3
Rosetta 2: false

Error messages:

Error: Failed applying an ad-hoc signature to /opt/homebrew/Cellar/swiftgen/6.4.0/lib/Commander.framework/Versions/A/Commander
Error: Failed applying an ad-hoc signature to /opt/homebrew/Cellar/swiftgen/6.4.0/lib/Kanna.framework/Versions/A/Kanna
Error: Failed applying an ad-hoc signature to /opt/homebrew/Cellar/swiftgen/6.4.0/lib/PathKit.framework/Versions/A/PathKit
Error: Failed applying an ad-hoc signature to /opt/homebrew/Cellar/swiftgen/6.4.0/lib/Stencil.framework/Versions/A/Stencil
Error: Failed applying an ad-hoc signature to /opt/homebrew/Cellar/swiftgen/6.4.0/lib/StencilSwiftKit.framework/Versions/A/StencilSwiftKit
Error: Failed applying an ad-hoc signature to /opt/homebrew/Cellar/swiftgen/6.4.0/lib/SwiftGenKit.framework/Versions/A/SwiftGenKit
Error: Failed applying an ad-hoc signature to /opt/homebrew/Cellar/swiftgen/6.4.0/lib/Yams.framework/Versions/A/Yams
🍺  /opt/homebrew/Cellar/swiftgen/6.4.0: 203 files, 19.9MB, built in 1 minute 2 seconds

Are those issues related more to Homebrew or the swiftgen itself?
When I try to run swiftgen in Terminal, it got killed:
➜  ~ swiftgen
[1]    25847 killed     swiftgen

<EMAIL_ADDRESS>didn't install from a bottle for me. (it did compile, just didn't come from the bottle.) literally everything else on that list worked though.
can I nominate Erlang 23.1.5 for a bottle next ;)

Can confirm as for today (19.12.2020). Cannot install<EMAIL_ADDRESS>from bottle (ask me to compile it), the same with vim

I'm trying to rebuild the Python bottle after an update, but there is a test issue:
==><EMAIL_ADDRESS>-c import sqlite3
==><EMAIL_ADDRESS>-c import tkinter; root = tkinter.Tk()
macOS 11 or later required !
An exception occurred within a child process:

Help welcome to investigate this

Doesn't seem to be ARM specific, also happened on my Intel machine. Are you on Big Sur 11.1? @fxcoudert

The backtrace says:
0   libsystem_kernel.dylib        	0x00007fff2031f462 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff2034d610 pthread_kill + 263
2   libsystem_c.dylib             	0x00007fff202a0720 abort + 120
3   Tcl                           	0x00007fff6fe1eb55 Tcl_PanicVA + 398
4   Tcl                           	0x00007fff6fe1ebd5 Tcl_Panic + 128
5   Tk                            	0x00007fff6ff1ead5 TkpInit + 385
6   Tk                            	0x00007fff6fe9e788 0x7fff6fe6d000 + 202632
7   _tkinter.cpython-39-darwin.so 	0x0000000102d2d701 Tcl_AppInit + 84
8   _tkinter.cpython-39-darwin.so 	0x0000000102d289fa _tkinter_create + 975
9   org.python.python             	0x00000001027251bb cfunction_vectorcall_FASTCALL + 203
10  org.python.python             	0x000000010279cff3 call_function + 403
11  org.python.python             	0x000000010279a184 _PyEval_EvalFrameDefault + 27452
12  org.python.python             	0x000000010279db3b _PyEval_EvalCode + 1998
13  org.python.python             	0x00000001026f55d8 _PyFunction_Vectorcall + 248
14  org.python.python             	0x00000001026f4e67 _PyObject_FastCallDictTstate + 212
15  org.python.python             	0x00000001026f5891 _PyObject_Call_Prepend + 139
16  org.python.python             	0x000000010273de96 slot_tp_init + 87
17  org.python.python             	0x00000001027376f7 type_call + 150
18  org.python.python             	0x00000001026f4fa3 _PyObject_MakeTpCall + 266
19  org.python.python             	0x000000010279d027 call_function + 455
20  org.python.python             	0x000000010279a184 _PyEval_EvalFrameDefault + 27452
21  org.python.python             	0x000000010279db3b _PyEval_EvalCode + 1998
22  org.python.python             	0x000000010279356d PyEval_EvalCode + 79
23  org.python.python             	0x00000001027ce5b5 run_eval_code_obj + 110
24  org.python.python             	0x00000001027cd9ad run_mod + 103
25  org.python.python             	0x00000001027cc9dc PyRun_StringFlags + 182
26  org.python.python             	0x00000001027cc8e9 PyRun_SimpleStringFlags + 69
27  org.python.python             	0x00000001027e3802 Py_RunMain + 425
28  org.python.python             	0x00000001027e40c1 pymain_main + 306
29  org.python.python             	0x00000001027e410f Py_BytesMain + 42

Regarding Python: there is an upstream bug report at https://bugs.python.org/issue42480
However I think it's an Apple Tcl/Tk issue, the same error occurs with Big Sur's python3

ARM bottle for<EMAIL_ADDRESS>rebuilt

<EMAIL_ADDRESS>has been giving me the same error as<EMAIL_ADDRESS>had previously
  File "./setup.py", line 971, in detect_readline_curses     (tuple(int(n) for n in dep_target.split('.')[0:2]) AttributeError: 'int' object has no attribute 'split'
I've tested applying the same fix that was done to 3.9 and it built successfully.

@fxcoudert Hello, is it possible to add more bottles for testing? I'd appreciate to try PostgreSQL, Redis, Erlang and Elixir.

I think swiftlint bottle can be added for testing. However I reported issue for SwiftGen team because, I tested 2 different build scenarios and it looks like their issue with builds in command line (building SwiftGen from Xcode works perfectly).
SwiftGen's issue:
https://github.com/SwiftGen/SwiftGen/issues/811

So, a quick heads-up: we are readying a final (quick) round of testing before we start shipping ARM bottles in bigger numbers. Here is what is going to happen:

the 50 existing bottles will be removed today
they will be reintroduced in the next couple of hours
I will post once that's done, and will kindly ask all of you to test the new bottles
if we're satisfied that nothing's awry, we will start adding more bottles

Removing bottles… now!

OK so we have 60 new bottles. Please test those new bottles and provide feedback (both positive and negative) below. You can test them by running brew reinstall ninja && brew test ninja (and similarly for other formulas).
I intend to leave about 24 hours to see if something is broken, and if not, start bottling at a faster pace.
autoconf automake bash bison c-ares cairo cmake cscope
fontconfig freetype gdbm gettext git glib gmp gnu-sed
icu4c isl jemalloc jpeg krb5 libev libevent libffi
libidn libmpc libomp libpng libsodium libtasn1 libtiff libtool
libunistring libyaml little-cms2 lua lzo meson mpfr ncurses
nghttp2 ninja node<EMAIL_ADDRESS>p11-kit pcre pcre2 perl
pixman pkg-config protobuf<EMAIL_ADDRESS>readline redis ruby
sphinx-doc sqlite tcl-tk xz zsh

Thanks again to everyone here helping us test on ARM!

I ran brew reinstall and brew test on a bunch of bottles:
git
gdbm
<EMAIL_ADDRESS>readline
sqlite
xz
python
libyaml

No issues for those whatsoever. However I tried the same steps for ruby with following results:
➜  ~ brew reinstall ruby
Warning: You are running macOS on a arm64 CPU architecture.
We do not provide support for this (yet).
Reinstall Homebrew under Rosetta 2 until we support it.
You will encounter build failures with some formulae.
Please create pull requests instead of asking for help on Homebrew's GitHub,
Twitter or any other official channels. You are responsible for resolving
any issues you experience while you are running this
unsupported configuration.

==> Downloading https://homebrew.bintray.com/bottles/ruby-2.7.2.arm64_big_sur.bottle.tar.gz
Already downloaded: /Users/bartoszdolewski/Library/Caches/Homebrew/downloads/1a670e50d3cc3354f8d08e1d33bc3557d55f01b6dad7ae231ac4a0340f62a8b2--ruby-2.7.2.arm64_big_sur.bottle.tar.gz
==> Reinstalling ruby
==> Pouring ruby-2.7.2.arm64_big_sur.bottle.tar.gz
==> Caveats
By default, binaries installed by gem will be placed into:
  /opt/homebrew/lib/ruby/gems/2.7.0/bin

You may want to add this to your PATH.

ruby is keg-only, which means it was not symlinked into /opt/homebrew,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.

If you need to have ruby first in your PATH run:
  echo 'export PATH="/opt/homebrew/opt/ruby/bin:$PATH"' >> ~/.zshrc

For compilers to find ruby you may need to set:
  export LDFLAGS="-L/opt/homebrew/opt/ruby/lib"
  export CPPFLAGS="-I/opt/homebrew/opt/ruby/include"

==> Summary
🍺  /opt/homebrew/Cellar/ruby/2.7.2: 20,156 files, 37.2MB
➜  ~ brew test ruby
==> Testing ruby
==> /opt/homebrew/Cellar/ruby/2.7.2/bin/ruby -e 'puts :hello'
==> /opt/homebrew/Cellar/ruby/2.7.2/bin/gem install json
==> /opt/homebrew/Cellar/ruby/2.7.2/bin/bundle exec ls
Last 15 lines from /Users/bartoszdolewski/Library/Logs/Homebrew/ruby/test.02.bundle:
2020-12-21 19:03:51 +0100

/opt/homebrew/Cellar/ruby/2.7.2/bin/bundle
exec
ls

/opt/homebrew/Cellar/ruby/2.7.2/bin/bundle:23:in `load': cannot load such file -- /opt/homebrew/lib/ruby/gems/2.7.0/gems/bundler-2.2.2/exe/bundle (LoadError)
	from /opt/homebrew/Cellar/ruby/2.7.2/bin/bundle:23:in `<main>'
Error: ruby: failed
An exception occurred within a child process:
  BuildError: Failed executing: /opt/homebrew/Cellar/ruby/2.7.2/bin/bundle exec ls
/opt/homebrew/Library/Homebrew/formula.rb:2072:in `block in system'
/opt/homebrew/Library/Homebrew/formula.rb:2008:in `open'
/opt/homebrew/Library/Homebrew/formula.rb:2008:in `system'
/opt/homebrew/Library/Taps/homebrew/homebrew-core/Formula/ruby.rb:240:in `block in <class:Ruby>'
/opt/homebrew/Library/Homebrew/formula.rb:1876:in `block (3 levels) in run_test'
/opt/homebrew/Library/Homebrew/utils.rb:530:in `with_env'
/opt/homebrew/Library/Homebrew/formula.rb:1875:in `block (2 levels) in run_test'
/opt/homebrew/Library/Homebrew/formula.rb:904:in `with_logging'
/opt/homebrew/Library/Homebrew/formula.rb:1874:in `block in run_test'
/opt/homebrew/Library/Homebrew/mktemp.rb:63:in `block in run'
/opt/homebrew/Library/Homebrew/mktemp.rb:63:in `chdir'
/opt/homebrew/Library/Homebrew/mktemp.rb:63:in `run'
/opt/homebrew/Library/Homebrew/formula.rb:2121:in `mktemp'
/opt/homebrew/Library/Homebrew/formula.rb:1868:in `run_test'
/opt/homebrew/Library/Homebrew/test.rb:43:in `block in <main>'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/timeout.rb:93:in `block in timeout'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/timeout.rb:33:in `block in catch'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/timeout.rb:33:in `catch'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/timeout.rb:33:in `catch'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/timeout.rb:108:in `timeout'
/opt/homebrew/Library/Homebrew/test.rb:42:in `<main>'

@bdolewski thanks, can you edit your post and paste the output of brew config and brew doctor please? I'll look into it

No problem :)
brew config
➜  ~ brew config
HOMEBREW_VERSION: 2.7.0-2-g6994633
ORIGIN: https://github.com/Homebrew/brew
HEAD:<PHONE_NUMBER>67072d577d0f13f76b0722e32d8cc0
Last commit: 3 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 84c6c43b31ece5cc412db7092a2331d9a843d753
Core tap last commit: 27 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit arm_firestorm_icestorm
Clang: 12.0 build 1200
Git: 2.29.2 => /opt/homebrew/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.1-arm64
CLT: <IP_ADDRESS>.1.1607026830
Xcode: 12.3
Rosetta 2: false

brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

We do not provide support for this (yet).
Reinstall Homebrew under Rosetta 2 until we support it.
You will encounter build failures with some formulae.
Please create pull requests instead of asking for help on Homebrew's GitHub,
Twitter or any other official channels. You are responsible for resolving
any issues you experience while you are running this
unsupported configuration.

uname -a (bonus input ;) )
Darwin MacBook-Pro-Bartosz.local 20.2.0 Darwin Kernel Version 20.2.0: Wed Dec  2 20:40:21 PST 2020; root:xnu-7195.60.75~1/RELEASE_ARM64_T8101 arm64

Success! Installed from bottle and tested
bash readline git<EMAIL_ADDRESS><EMAIL_ADDRESS>ruby zsh autoconf automake cmake lua sqlite

@scottstanfield did you run brew test ruby with success? I did rm -rf $(brew --cache) and then brew instal ruby, brew test ruby again. The same failure as before 🤨

@bdolewski Does /opt/homebrew/lib/ruby/gems/2.7.0/gems/bundler-2.2.2/exe/bundle or /opt/homebrew/bin/bundler exist? Do either of them work as expected?

@bdolewski Does /opt/homebrew/lib/ruby/gems/2.7.0/gems/bundler-2.2.2/exe/bundle or /opt/homebrew/bin/bundler exist? Do either of them work as expected?

@MikeMcQuaid how do I test that? Should I just go to /opt/homebrew/lib/ruby/gems/2.7.0/gems/bundler-2.2.2/exe/ and run ./bundle ? Unfortunately I'm not a Ruby developer, don't really know how to test those tools ;) I install Ruby on my machine because of open-source tools for iOS Developers written in Ruby.

@bdolewski Given that: are you having any problems with ruby beyond the brew test failing? If not: I think you can ignore it.

We're at 400 bottles tonight, and bottling will continue for all software that builds. I'm closing this call for testing, thanks everyone!

Woah! Is there an updated list of ARM bottles, or best to just check formulae?

cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula && git grep :arm64_big_sur will give you a quick overview.

We're at 590 bottles two hours later, so clearly we're not going to be able to keep a list up-to-date. Looking at the formulas is the best option (@iMichka's command, but with /opt/homebrew as prefix if you're on Apple Silicon)

@fxcoudert Hmm, it seems that the node bottle has mysteriously disappeared. Homebrew is installed via the untar method to /opt/homebrew on an M1-based Mac.
% brew install node
Updating Homebrew...

We do not provide support for this (yet).
Reinstall Homebrew under Rosetta 2 until we support it.
You will encounter build failures with some formulae.
Please create pull requests instead of asking for help on Homebrew's GitHub,
Twitter or any other official channels. You are responsible for resolving
any issues you experience while you are running this
unsupported configuration.

Error: node: no bottle available!
You can try to install from source with e.g.
  brew install --build-from-source node
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.

@richiksc thanks for reporting, following the update the bottle has not been rebuilt immediately, I'm starting a build. Things will be a little bit out of sync in the next couple of days, as we continue to build bottles, but then we can enable ARM fully on our CI and this problem will disappear

Thanks @fxcoudert, looks like the Node 15.5.0 bottle is available now. Looking forward for it to be fully integrated with the CI!

The arm64 bottle for mosquito is broken, libmosquitto.1.dylib not found:
brew reinstall mosquitto
==> Downloading https://homebrew.bintray.com/bottles/mosquitto-2.0.5.arm64_big_sur.bott
Already downloaded: /Users/dsc/Library/Caches/Homebrew/downloads/2e43e01e305214511e7fec05b8e1ed1d1fd52d998b0b0309275b6972e6f1d503--mosquitto-2.0.5.arm64_big_sur.bottle.tar.gz
==> Reinstalling mosquitto
==> Pouring mosquitto-2.0.5.arm64_big_sur.bottle.tar.gz
==> Caveats
mosquitto has been installed with a default configuration file.
You can make changes to the configuration by editing:
    /opt/homebrew/etc/mosquitto/mosquitto.conf

To have launchd start mosquitto now and restart at login:
  brew services start mosquitto
Or, if you don't want/need a background service you can just run:
  mosquitto -c /opt/homebrew/etc/mosquitto/mosquitto.conf
==> Summary
🍺  /opt/homebrew/Cellar/mosquitto/2.0.5: 41 files, 1.6MB

 $ mosquitto_sub
dyld: Library not loaded: @rpath/libmosquitto.1.dylib
  Referenced from: /opt/homebrew/bin/mosquitto_sub
  Reason: image not found
zsh: abort      mosquitto_sub

The library is there:
$ pwd
/opt/homebrew/Cellar/mosquitto/2.0.5/lib

$ ls -l
total 440
lrwxr-xr-x  1 dsc  staff      24 Jan 14 09:04 libmosquitto.1.dylib -> libmosquitto.2.0.5.dylib
-r--r--r--  1 dsc  staff  141008 Jan 14 09:04 libmosquitto.2.0.5.dylib
lrwxr-xr-x  1 dsc  staff      20 Jan 14 09:04 libmosquitto.dylib -> libmosquitto.1.dylib
lrwxr-xr-x  1 dsc  staff      26 Jan 14 09:04 libmosquittopp.1.dylib -> libmosquittopp.2.0.5.dylib
-r--r--r--  1 dsc  staff   78560 Jan 14 09:04 libmosquittopp.2.0.5.dylib
lrwxr-xr-x  1 dsc  staff      22 Jan 14 09:04 libmosquittopp.dylib -> libmosquittopp.1.dylib
drwxr-xr-x  4 dsc  staff     128 Jan 14 09:04 pkgconfig

There are no signing problems.

The arm64 bottle for mosquito is broken, libmosquitto.1.dylib not found:
brew reinstall mosquitto
==> Downloading https://homebrew.bintray.com/bottles/mosquitto-2.0.5.arm64_big_sur.bott
Already downloaded: /Users/dsc/Library/Caches/Homebrew/downloads/2e43e01e305214511e7fec05b8e1ed1d1fd52d998b0b0309275b6972e6f1d503--mosquitto-2.0.5.arm64_big_sur.bottle.tar.gz
==> Reinstalling mosquitto
==> Pouring mosquitto-2.0.5.arm64_big_sur.bottle.tar.gz
==> Caveats
mosquitto has been installed with a default configuration file.
You can make changes to the configuration by editing:
    /opt/homebrew/etc/mosquitto/mosquitto.conf

To have launchd start mosquitto now and restart at login:
  brew services start mosquitto
Or, if you don't want/need a background service you can just run:
  mosquitto -c /opt/homebrew/etc/mosquitto/mosquitto.conf
==> Summary
🍺  /opt/homebrew/Cellar/mosquitto/2.0.5: 41 files, 1.6MB

 $ mosquitto_sub
dyld: Library not loaded: @rpath/libmosquitto.1.dylib
  Referenced from: /opt/homebrew/bin/mosquitto_sub
  Reason: image not found
zsh: abort      mosquitto_sub

The library is there:
$ pwd
/opt/homebrew/Cellar/mosquitto/2.0.5/lib

$ ls -l
total 440
lrwxr-xr-x  1 dsc  staff      24 Jan 14 09:04 libmosquitto.1.dylib -> libmosquitto.2.0.5.dylib
-r--r--r--  1 dsc  staff  141008 Jan 14 09:04 libmosquitto.2.0.5.dylib
lrwxr-xr-x  1 dsc  staff      20 Jan 14 09:04 libmosquitto.dylib -> libmosquitto.1.dylib
lrwxr-xr-x  1 dsc  staff      26 Jan 14 09:04 libmosquittopp.1.dylib -> libmosquittopp.2.0.5.dylib
-r--r--r--  1 dsc  staff   78560 Jan 14 09:04 libmosquittopp.2.0.5.dylib
lrwxr-xr-x  1 dsc  staff      22 Jan 14 09:04 libmosquittopp.dylib -> libmosquittopp.1.dylib
drwxr-xr-x  4 dsc  staff     128 Jan 14 09:04 pkgconfig

There are no signing problems.

@domschl can you trying rebuilding from source, with -DCMAKE_INSTALL_RPATH=#{lib} added to the cmake arguments in the formula?

@domschl can you trying rebuilding from source, with -DCMAKE_INSTALL_RPATH=#{lib} added to the cmake arguments in the formula?

@fxcoudert No change:
change to formula:
def install
    system "cmake", ".", *std_cmake_args, "-DCMAKE_INSTALL_RPATH=#{lib} -DWITH_WEBSOCKETS=ON"
    system "make", "install"
  end

output:
$ brew install -s mosquitto                                               1
==> Downloading https://mosquitto.org/files/source/mosquitto-2.0.5.tar.gz
Already downloaded: /Users/dsc/Library/Caches/Homebrew/downloads/2c9713316856338d478ad2203f6d54c101f7fe8294a925895c82b451f74031c7--mosquitto-2.0.5.tar.gz
==> cmake . -DCMAKE_INSTALL_RPATH=/opt/homebrew/Cellar/mosquitto/2.0.5/lib -DWITH_WEBSOCKETS=ON
==> make install
==> Caveats
mosquitto has been installed with a default configuration file.
You can make changes to the configuration by editing:
    /opt/homebrew/etc/mosquitto/mosquitto.conf

To have launchd start mosquitto now and restart at login:
  brew services start mosquitto
Or, if you don't want/need a background service you can just run:
  mosquitto -c /opt/homebrew/etc/mosquitto/mosquitto.conf
==> Summary
🍺  /opt/homebrew/Cellar/mosquitto/2.0.5: 41 files, 1.3MB, built in 5 seconds

 $ mosquitto_sub
dyld: Library not loaded: @rpath/libmosquitto.1.dylib
  Referenced from: /opt/homebrew/bin/mosquitto_sub
  Reason: image not found
zsh: abort      mosquitto_sub

@fxcoudert No change:
change to formula:
def install
    system "cmake", ".", *std_cmake_args, "-DCMAKE_INSTALL_RPATH=#{lib} -DWITH_WEBSOCKETS=ON"
    system "make", "install"
  end

output:
$ brew install -s mosquitto                                               1
==> Downloading https://mosquitto.org/files/source/mosquitto-2.0.5.tar.gz
Already downloaded: /Users/dsc/Library/Caches/Homebrew/downloads/2c9713316856338d478ad2203f6d54c101f7fe8294a925895c82b451f74031c7--mosquitto-2.0.5.tar.gz
==> cmake . -DCMAKE_INSTALL_RPATH=/opt/homebrew/Cellar/mosquitto/2.0.5/lib -DWITH_WEBSOCKETS=ON
==> make install
==> Caveats
mosquitto has been installed with a default configuration file.
You can make changes to the configuration by editing:
    /opt/homebrew/etc/mosquitto/mosquitto.conf

To have launchd start mosquitto now and restart at login:
  brew services start mosquitto
Or, if you don't want/need a background service you can just run:
  mosquitto -c /opt/homebrew/etc/mosquitto/mosquitto.conf
==> Summary
🍺  /opt/homebrew/Cellar/mosquitto/2.0.5: 41 files, 1.3MB, built in 5 seconds

 $ mosquitto_sub
dyld: Library not loaded: @rpath/libmosquitto.1.dylib
  Referenced from: /opt/homebrew/bin/mosquitto_sub
  Reason: image not found
zsh: abort      mosquitto_sub

Should be:
system "cmake", ".", *std_cmake_args, "-DCMAKE_INSTALL_RPATH=#{lib}", "-DWITH_WEBSOCKETS=ON"
with an extra ", " to separate the arguments

Should be:
system "cmake", ".", *std_cmake_args, "-DCMAKE_INSTALL_RPATH=#{lib}", "-DWITH_WEBSOCKETS=ON"
with an extra ", " to separate the arguments

@fxcoudert : Thank you for your help! This works now.

@fxcoudert : Thank you for your help! This works now.


Booster's simplifier is unable to prune a #Bottom state

The integration test test-issue3764-vacuous-branch isolates a case where Booster's simplifier is unable to prune a bottom state.
When sent given the state-branch-in-zero.send request, booster-dev (and kore-rpc-booster --no-post-exec-simplify) returns a Branchingresponse, whilekore-rpc-boosterreturnsDepthBound, making two steps. This happens because kore-rpc-booster` will call Kore's simplify endpoint, which is more powerful (but much slower).
The other request, state-branch-after-one.send, is basically the same, but the state is from one step before. booster-dev branches after 1 step and kore-rpc-booster makes 3 steps.
We need to figure out exactly what allows the Kore's simplifier to prune the state. An important details is that the pruning happens not in Kore's rule unification algorithm, i.e. Kore returns Branching too. It is the simplify request that produces #Bottom in the end.
Note that https://github.com/runtimeverification/haskell-backend/pull/4020 (checking input pattern's conditions with SMT in Booster) is also not enough, i.e. even with that code Booster is unable to derive a contradiction.
To observe the relevant logs, run the following from the following from the repo root:
SERVER=$(cabal list-bin kore-rpc-booster) SERVER_OPTS="--log-context \"*>proxy>*\"" CLIENT=$(cabal list-bin kore-rpc-client) ./booster/test/rpc-integration/runDirectoryTest.sh booster/test/rpc-integration/test-issue3764-vacuous-branch

A similar phenomenon was observed in the wild on an engagement proof.
An execute request was erroneously branching because the branching condition could not be evaluated to False by the SMT solver. Due to a bug (fixed in #4078 ) this led to infinite branching in the proof. One of the branches can be simplified to #Bottom by the legacy backend but not by booster, it's unclear why.
Discussed here  with some artefacts.