Add an empty entry in combo list when nothing is selected (bug 1773680)

it aims to fix https://bugzilla.mozilla.org/show_bug.cgi?id=1773680
the empty is removed once something is selected.

/botio test

The "regression" in 160F-2019.pdf doesn't make sense. The patch just changed some code in ChoiceWidget and the hello world is in a TextWidget.
The one in annotation-choice-widget-forms.pdf is a bug fix: I opened it in Acrobat and the combo is empty and I rg for the md5 in the wrong directory so my test is useless.

@Snuffleupagus, the regression in 160F-2019 is very likely unrelated to this patch, or maybe I overlooked something, are you still ok to merge it ?

The "regression" in 160F-2019.pdf doesn't make sense. The patch just changed some code in ChoiceWidget and the hello world is in a TextWidget.

Agreed, I also don't understand how that could've happened.

the regression in 160F-2019 is very likely unrelated to this patch, or maybe I overlooked something, are you still ok to merge it ?

Assuming it's even a regression, since comparing with Adobe Reader I'm not sure...

While I'd suggest that it makes sense to try and understand what changed and importantly why here, I suppose that this PR can still land in the meantime :-)

It's very likely my fault:
https://github.com/mozilla/pdf.js/commit/5d88233fbb11da28e155fa136d1abac0f7393f00#diff-a7e409abd3d3209d32d3adc8457c5e23feb4c06113a2e065b0c6a9322a3a3369R744

The border is white so the reftest is now correct. Probably at some point the stroke color was black and because of wrong g we weren't using the white. So thanks to the patch for the ink stuff, it's now fixed.
I'm sorry about that.

The border is white so the reftest is now correct. Probably at some point the stroke color was black and because of wrong g we weren't using the white. So thanks to the patch for the ink stuff, it's now fixed.

Thanks for figuring this out, since it confirms that the current state is indeed correct now!
(We both missing running the full test-suite in PR #15006 apparently...)

I'm sorry about that.

Don't apologize for fixing an old bug :-)


chore - coverage reporting in CI

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@c863302). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master       #3   +/-   ##
=========================================
  Coverage          ?   96.00%
=========================================
  Files             ?        2
  Lines             ?       25
  Branches          ?        1
=========================================
  Hits              ?       24
  Misses            ?        0
  Partials          ?        1

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 c863302...98f7e19. Read the comment docs.


Crash on start up

java.lang.NullPointerException: Cannot invoke "net.minecraft.class_638.method_27983()" because "net.minecraft.class_310.method_1551().field_1687" is null
at Not Enough Crashes deobfuscated stack trace.(1.19+build.4)
at fishcute.celestial.sky.CelestialSky.getDimensionRenderInfo(CelestialSky.java:34)
at net.minecraft.client.render.WorldRenderer.renderCustomStars(WorldRenderer:8279)
at net.minecraft.client.render.WorldRenderer.handler$ekg000$injectRenderStars(WorldRenderer:3510)
at net.minecraft.client.render.WorldRenderer.renderStars(WorldRenderer)
at net.minecraft.client.render.WorldRenderer.renderStars(WorldRenderer:673)
at net.minecraft.client.render.WorldRenderer.(WorldRenderer:301)
at net.minecraft.client.MinecraftClient.(MinecraftClient:583)
at net.minecraft.client.main.Main.method_44604(Main:205)
at net.minecraft.client.main.Main.main(Main:51)
at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:461)
at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74)
at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23)
A detailed walkthrough of the error, its code path and all known details is as follows:
-- Head --
Thread: Render thread
Stacktrace:
at fishcute.celestial.sky.CelestialSky.getDimensionRenderInfo(CelestialSky.java:34)
at net.minecraft.class_761.renderCustomStars(class_761.java:8279)
at net.minecraft.class_761.handler$ekg000$injectRenderStars(class_761.java:3510)
at net.minecraft.class_761.method_3255(class_761.java)
at net.minecraft.class_761.method_3293(class_761.java:673)
at net.minecraft.class_761.(class_761.java:301)
at net.minecraft.class_310.(class_310.java:583)

Is this on 1.0.0 or 1.0.1?

Uh, fast! It is the latest version 1.0.1 on 1.19.2.
I am using Custom Stars too, not sure if this is related to this bug: https://www.curseforge.com/minecraft/mc-mods/custom-stars

Custom stars may be the problem, although I can't be sure. Try running the mod without Custom stars and let me know the result.

Yep, removing Custom Stars resolved the problem for me.

Alright. Celestial has its own star customization system, so there might have been some conflict there.

So there is no compatibility workaround possible?

Probably not. Whatever you are trying to do can probably be accomplished with Celestial, so you could try that.

Alright, thanks.


Halo interfering with colorama brightness

In my program, I'm attempting to use the library Colorama to use terminal colors, and to brighten up text in my program. I'm also using halo for the spinners, but the two libraries conflict when a halo spinner is added.
Colorama's colored text automatically gets dimmed, and regardless if I disable the spinner, I'd have to brighten up each print statement, and every color change.
This appears to only be occurring on Windows, and in the default command prompt. I'm thinking the issue stems from changing the terminal color on your side.

@o355 The only reason I can think of here is we need to call deinit in the library before exiting. But what confuses me is I'm not dimming the text anywhere in the library. Could you please share the code so that we can look into it?

The code is in my project PyWeather. It's in the pyweather.py file, and the code around line 1190 is where the issues begin to occur.

@o355 I've gone through your code and from the looks of it, it is quite possible you are not ending your colored text with Fore.RESET. I've also tried producing this error on my machine, but nothing failed.
I would need external help as I don't have access to Windows machine to particularly look into this problem and to reproduce this issue as of now.
I would appreciate if you could also share screenshots here for further investigation along with following details:

Operating System:
Terminal in use:
Python version:
Halo version:
pip freeze output:

Alright. I can tell you off the top of my head that I'm using Windows 10, and the issue occurs in PowerShell/Command Prompt. Python version is 3.6.2.
I'll get the halo version and pip freeze outout when I can.

Here's the pip freeze output:
appJar==0.70
certifi==2<IP_ADDRESS>
chardet==3.0.4
click==6.7
colorama==0.3.9
cursor==1.1.0
decorator==4.1.2
enum34==1.1.6
geopy==1.11.0
halo==0.0.6
idna==2.6
log-symbols==0.0.11
ratelim==0.1.6
requests==2.18.4
six==1.11.0
spinners==0.0.19
termcolor==1.1.0
urllib3==1.22

Halo version is 0.0.6 as seen above. I don't end my colored texts with Fore.RESET so I don't have an additional half a thousand Fore.RESET lines.

@o355 I tested your code on my Windows machine and didn't find any problem. Colorama and halo are working well together. Isn't any screenshots you expected and actually got? If you can, I hope you provide us minimal code we can test. 😄

Hmm...interesting. Here's a screenshot of what I'm getting:

I've been pretty busy lately, but I'll find some time to upload some minimal code that's based off the issues I'm getting. I also updated halo to 0.0.7 and the issue is persisting for my code.

I did a little investigating, and it looks to only be the brightness of the color that doesn't carry over from line to line, maybe even color to color.

I can confirm this for Ubuntu Xenial

Was this issue ever fixed? Seems that this issue is still occurring and also preventing the colour to activate.


After zooming in on the map, the wind field doesn't look as smooth as a curve

Describe your problem
I want to show the wind field in the urban construction area, but the effect is not satisfactory

The following effect is ideal

What I want to do is to enlarge the map and see that the wind field is still smooth.
I know it takes a lot of short enough connections to make the line look smooth.
**What i tried
I noticed that there are three variables that affect the effect of presentation(pixelSize,speedFactor,lineWidth).
I tried to change the values of these variables to achieve the desired effect, but failed. :(
And I noticed that after the map was enlarged to a certain extent, cesium's scene.getPixelSize() method gets almost no change, which puzzles me.
Could you help me out or give me some guidance? Thanks anyway

I believe that it is a precision problem, maybe precision of 32 bit floating number is not enough when the zoom level is very high. And unfortunately, WebGL does not provide double floating number data type. I am still in search of a good solution for this problem.

I believe that it is a precision problem, maybe precision of 32 bit floating number is not enough when the zoom level is very high. And unfortunately, WebGL does not provide double floating number data type. I am still in search of a good solution for this problem.


Allow constructing a RedisStore from a RedisPool

Makes RedisStore generic over any type that implements fred's KeysInterface so either a RedisClient or RedisPool can be used.
Since RedisPool is generally preferred for most applications, I switched all examples and documentation to use RedisPool. But, existing code that used RedisClient will not fail to compile.
I also modified the integration test that tests RedisStore to use a RedisPool.
Fixes issue #92

Lovely! Thank you for this.


allow for complex schema to refer to previously named schema

I believe this allow for recursive schemata which admits thing such as linked lists and trees.

I'd be very interested in this as well. As while the schema i'm using does not define recursive types, it does define some custom types (like a type for UUID values) which are defined at first use and then afterwards only referenced by name in the schemata (which was generated using avro tools from a idl spec).

Been a while. How's this pull going? Need some help? How far to completion?

closing in favor of #99 ; I'm thrilled that someone else is making an effort here, (thanks @GregBowyer :) )
I apologize that the conditions that got me motivated to get this working didn't exist for long :(


docs: clarify blue/green support and limitations

Summary and Description
Adds additional clarification and limitations in regards to Blue/Green.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

I'm confused.
https://github.com/aws/aws-advanced-jdbc-wrapper/releases/tag/2.3.6 says reconnection after Blue/Green switchover is fixed:

Green node endpoint replacement, allowing the AWS JDBC Driver to detect and connect to green nodes after Blue/Green switchover (PR# 948)(https://github.com/aws/aws-advanced-jdbc-wrapper/pull/948). Addresses https://github.com/awslabs/aws-advanced-jdbc-wrapper/issues/678.

but the documentation has just been updated to clarify it does not work?

@nosnilmot , thanks for reaching out.
I can see where the confusion is coming from with the change log, we can take action to clarify that directly.
For visibility, the intention was to make clear of the limitations with Blue/Green and the driver. Officially, the driver does not support Blue/Green. We wanted to make this clear with After a Blue/Green switchover, the wrapper may not be able to properly detect the new topology and handle failover, as there are discrepancies between the metadata and the available endpoints..
However, we do see the need to have a workaround until full support is rolled out. For example, In the meantime, users can consider utilizing the enableGreenNodeReplacement configuration parameter, which allows the driver to override incorrect topology metadata and try to connect to available new Blue endpoints..
My proposal is to modify the change log with the mention of enableGreenNodeReplacement.


Remove cancellation token overload

Fixes https://github.com/aspnet/Identity/issues/1060
Requires another baseline update :(
@divega

7fbc36c56684769d3535cf1dfd1cddf88fb26343


judge the status of processor at list system processors (redfish api)

Fix the issue:
failed to get processor information with redfish api:/Systems/{identifier}/Processors/{socket}
https://github.com/RackHD/RackHD/issues/269
The redfish api "/Systems/{identifier}/Processors" always list all the processors including unpopulated processors.
However, when try to get the information of unpopulated processors, the api "/Systems/{identifier}/Processors/{socket} " just response error.
Unpopulated processors should be filtered.

@RackHD/corecommitters please review.

@zyoung51 @iceiilin  @panpan0000

test this please

Jenkins: test this please

:+1: after addressing the comment

+1


candidate-scheduler and proxy-scheduler: Forbidden: cannot list resource "csinodes"

I'm not able to schedule pods across clusters using v0.8.0.
After deploying v0.8.0 using helm to 3 clusters, I'm seeing the following error in proxy-scheduler and candidate-scheduler:
E0507 13:29:58.249696       1 reflector.go:156] pkg/mod/k8s.io/client-go@v0.17.0/tools/cache/reflector.go:108: Failed to list *v1.CSINode: csinodes.storage.k8s.io is forbidden: User "system:serviceaccount:admiralty:multicluster-scheduler" cannot list resource "csinodes" in API group "storage.k8s.io" at the cluster scope

Following online guidance, I tried adding the following lines to the multicluster-scheduler ClusterRole:
- apiGroups:
  - storage.k8s.io
  resources:
  - csinodes
  verbs:
  - watch
  - list
  - get

After applying to the cluster, I now see the following error message (again in proxy-scheduler and candidate-scheduler).
E0507 13:25:51.759485       1 reflector.go:156] pkg/mod/k8s.io/client-go@v0.17.0/tools/cache/reflector.go:108: Failed to list *v1.CSINode: the server could not find the requested resource

Environment
Kubernetes Version: version.Info{Major:"1", Minor:"15+", GitVersion:"v1.15.11-eks-af3caf", GitCommit:"af3caf6136cd355f467083651cc1010a499f59b1", GitTreeState:"clean", BuildDate:"2020-03-27T21:51:36Z", GoVersion:"go1.12.17", Compiler:"gc", Platform:"linux/amd64"}
Cloud: AWS (EKS)
Helm chart/version: v0.8.0

Hi @buzzsurfr, the current release of multicluster-scheduler (v0.8.0) requires Kubernetes v1.17 or v1.18, because it uses the scheduler framework (TODO @adrienjt add this requirement to the readme). If you're stuck with v1.15, e.g., on EKS, there's a hack to make it work:

fork Kubernetes,
disable the CSINode feature gate in code (cannot be disabled at runtime because it is locked in code),
add a nil check where the csiNodeLister is referenced in the CSI volume predicate,
replace k8s.io/kubernetes with your fork in multicluster-scheduler's go.mod,
build and push your own image to your own registry,
use that image in your Helm release's values.

We might publish this image as a convenience, but we don't plan to maintain the fork in the open.


Newly introduces inbuild function for record types not picked up by the VSCode tooling

Description:
$subject.
Please refer to the following image.

Steps to reproduce:
Affected Versions:
Ballerina lang 1.2.0-rc1
OS, DB, other environment details and versions:

macOS Catalina
VSCode

Related Issues (optional):
https://github.com/ballerina-platform/ballerina-lang/pull/21488

Close this issue since it was an error due to the fact that the VSCode plugin was not configured correctly. The configuration issue was it had configured manual Ballerina home and VSCode plugin was in the dev mode.


[#113262177] Lint checks for duplicate YAML keys

What
Enable lint checks to find duplicate keys in static and dynamically generated YAML documents. Please see the individual commit messages for more information.
How to review

Check whether Travis is passing
Install the dependencies and run locally (see README and would welcome feedback on how easy this is)
Try adding a duplicate key, run the tests again, and see if they fail

Who can review
Not @dcarley

A few minor comments, otherwise this looks good to me.
We could usefully enable some of the other lint checks as I've noticed some inconsistencies with the formatting of our YAML (specifically around indentation of array elements). That that's something for a separate PR/story.

Rebased to fix merge conflicts.


Directory paths with an index.html does not format.

JavaHTTPServer Version: 1.0.0

Exit Code: 0

Reproduction Steps:

Get a fresh JHS installation.
Run it in a new folder, then stop it.
Add any file called index.html to files directory.
Run the server again.
Go to http://localhost:8080/
You see the raw HTML code.

Edit: The crash was a one-time issue.


hide estimate reward

hide estimate reward when voting
re-calculate current epoch in crawler

Pull Request Test Coverage Report for Build 1122

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

Totals

Change from base Build 1121:
0.0%

Covered Lines:
92

Relevant Lines:
103

💛  - Coveralls


[Bug]: HMR fails with RSPack v0.7.1

System Info
MacOS 14.4.1
Details
With RSPack v0.7.1, HMR seems to have issues. Here is the stack trace:
app1 start: Panic occurred at runtime. Please file an issue on GitHub with the backtrace below: https://github.com/web-infra-dev/rspack/issues
app1 start: Message:  should have module graph module
app1 start: Location: crates/rspack_core/src/module_graph/mod.rs:563
app1 start: Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.
app1 start: Run with RUST_BACKTRACE=full to include source snippets.
app1 start: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
app1 start:  1: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start:  2: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start:  3: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start:  4: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start:  5: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start:  6: _wasmer_vm_imported_memory32_atomic_notify
app1 start:     at <unknown source file>
app1 start:  7: _wasmer_vm_imported_memory32_atomic_notify
app1 start:     at <unknown source file>
app1 start:  8: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start:  9: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start: 10: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start: 11: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start: 12: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start: 13: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start: 14: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start: 15: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start: 16: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start: 17: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start: 18: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start: 19: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start: 20: _napi_register_module_v1
app1 start:     at <unknown source file>
app1 start: 21: __pthread_joiner_wake
app1 start:     at <unknown source file>

I have included a reproducible. It is based on https://github.com/module-federation/module-federation-examples/tree/master/advanced-api/dynamic-remotes, but with upgraded RSPack.
Note that with v0.7.0, HMR worked without problem.
Reproduce link
https://github.com/markmssd/module-federation-runtime-shared/tree/rspack-0.7.1
Reproduce Steps
git clone https://github.com/markmssd/module-federation-runtime-shared/tree/rspack-0.7.1
cd  module-federation-runtime-shared
pnpm install
pnpm start

// everything works so far.
// edit any file, e.g. `app1/src/App.js`, to trigger HMR
// it crashes 💥

Digging a bit more, I'm seeing https://github.com/web-infra-dev/rspack/pull/6670 and https://github.com/web-infra-dev/rspack/pull/6694 that might be related, since they're touching the module graph as reported by the error, @jerrykingxyz would you know why this could happen? 🙏🏼

fixed by https://github.com/web-infra-dev/rspack/pull/6730

Ok so seems that using
      new rspack.container.ModuleFederationPlugin({
        name: 'core',
        shared,
      }),

is what makes it fail, however using
      new rspack.container.ModuleFederationPluginV1({
        name: 'core',
        shared,
      }),

works without issue! Still weird that I can't reproduce it in https://github.com/markmssd/module-federation-runtime-shared/tree/rspack-0.7.1 though, I'll keep trying, but let me know if you have an idea of what could be wrong 🙏🏼

FWIW I'm seeing the same issue with:
{
  "dependencies": {
    "@module-federation/enhanced": "^0.1.18",
    "react": "^18.3.1",
    "react-dom": "^18.3.1"
  },
  "devDependencies": {
    "@rsbuild/core": "^0.7.3",
    "@rsbuild/plugin-react": "^0.7.3",
    "@types/react": "^18.3.3",
    "@types/react-dom": "^18.3.0",
    "typescript": "^5.4.2"
  }
}

About the module federation issue, we need a reproduce here, or if you really can't reproduce you can provide the config file, I will try to reproduce based on the config file once my time available

@ahabhgk would something like this work?

The panic should already been fixed, try the latest nightly version

Confirmed, the panic is fixed in the nightly, thanks @ahabhgk !

@ahabhgk I was finally able to reproduce the issue, there you go: https://github.com/markmssd/module-federation-runtime-shared/tree/rspack-0.7.2-canary.
It's a problem only with dynamic imports. In this repro, it would be app1/src/DynamicPage.js. Editing this file will result in this error:

If you edit any other page, for example app1/src/App.js, it does not happen. I've also noticed that commenting out ModuleFederationPlugin in app1/rspack.config.js would fix it (however we wouldn't have Module Federation anymore so it's not really a solution, but could help pinpoint the issue).
Let me know if you need more info, I'd be glad to help further.

Hey @ahabhgk , just checking whether you had an idea why that would happen, and if you were able to see the error on the reproducible.
Also, should I re-open a new issue for it since the initial issue is technically resolved already?

Let's move to the new issue https://github.com/web-infra-dev/rspack/issues/6773, I will take a look in the next one or two days


Go to def is not working for imported type constructors

Having type data constructors imported:
import Data.Maybe (Maybe(..))
import Data.Maybe as Maybe

If to use just imported constructors without a namespace (Just, Nothing) one cannot go to definition, though if to use namespaced version (Maybe.Just) go to definition can be triggered.
x = Just 1 -- <- can NOT go to `Just` defintion,

y = Maybe.Just 2 -- <- can go to `Just` defintion

Isn't possible to implement it currently?

Oh it's not just go to definition, hover tooltips are not showing for type constructors either. I think this is a regression.

It works if the type is defined in the same module, does not for external types, so maybe it is not a regression.


Invalid record length - value read was 805306492

hi i have a IPM mastercard file and i'm trying to get the transaction or whatever information maybe in it iv tried to convert it using the command mci_ipm_to_csv i always get this error
mci_ipm_to_csv --debug file.IPM --in-encoding CP500 mci_ipm_to_csv (cardutil 0.6.4) parameters:  -in_filename:file.IPM  -in_encoding:CP500  -debug:True DEBUG:cardutil.cli:config_dir=None DEBUG:cardutil.mciipm:record_length=805306492 *** ERROR - processing has stopped *** Error detected in record 1 Invalid record length - value read was 805306492
fileIPM.txt

If the first record has an invalid record length then the file is not valid.
The first 4 bytes should contain the length of the record in binary.

Good morning but the file that is attached is from mastercard and i suppose it have the structure required to be extracted with the command mci_ipm_to_csv

Closing as the file is not in IPM format

It appears that this file is using the Mastercard Clearing Optimiser AutoEdit input file structure.
When I reviewed the file, it does have valid IPM records embedded within the structure with some additional file and record headers. I am not sure how these files are used and when you would use these in preference to a standard IPM file.
The bottom line is that cardutils does not support this format. I will leave this here as a "TODO" to see if there is
any interest in supporting this format.


could be exported to html and markdown to generate a readme file

I will change this example to demonstrate how to use likec4 artifacts in html/markdown.
I update you here

This repository likec4/template shows how to generate html and deploy to github pages


Replace system dependency with the embedded version of SQLite

'nuff said. SQLite is a marvel.

Codecov Report

Merging #13 into master will decrease coverage by -38.02%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master      #13       +/-   ##
===========================================
- Coverage   69.49%   31.47%   -38.02%
===========================================
  Files           5        6        +1
  Lines         177    42786    +42609
===========================================
+ Hits          123    13467    +13344
- Misses         54    29319    +29265

Impacted Files
Coverage Δ

Sources/SQLite/SQLite+Statement.swift
36% <ø> (ø)
:white_check_mark:

Sources/SQLite/SQLite.swift
50.98% <ø> (ø)
:white_check_mark:

Sources/SQLite/SQLite+Result.swift
91.89% <ø> (ø)
:white_check_mark:

Sources/CSQLite/sqlite3.c
31.31% <ø> (ø)

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 f8ff964...756f9ff. Read the comment docs.


re-appearing player after crossing the border (?)

New mechanic idea:

when player leaves through the right border, while still moving right, he appears again from the left border (and like-wise)
when player leaves through the bottom border, while still moving down, he appears again from the up border (and like-wise)

conclusion: infinite movement range closed within the size of game's window

I even thought of the very same thing recently and thought that it would be very tricky thing to do xD and instead thought that we will probably need some graphical representation of walls to clearly indicate where are the borders :D
I will turn it into a discussion for now - once we have the prototype ready and we will start iterating over game mechanics, we will go through all the ideas we have there and if we will want to implement it, we will turn it into the issue


🐛 [firebase_auth, etc] version conflict with Firebase SDK 10.0.0

Bug report
Describe the bug
ML Kit SDK version conflicts and build fails. Firebase SDK 10.0.0
It worked fine until 9.6.0.
ios % pod install
Analyzing dependencies
firebase_auth: Using Firebase SDK version '10.0.0' defined in 'firebase_core'
firebase_core: Using Firebase SDK version '10.0.0' defined in 'firebase_core'
[!] CocoaPods could not find compatible versions for pod "GTMSessionFetcher/Core":
  In Podfile:
    firebase_auth (from `.symlinks/plugins/firebase_auth/ios`) was resolved to 4.0.2, which depends on
      Firebase/Auth (= 10.0.0) was resolved to 10.0.0, which depends on
        FirebaseAuth (~> 10.0.0) was resolved to 10.0.0, which depends on
          GTMSessionFetcher/Core (~> 2.1)

    mobile_scanner (from `.symlinks/plugins/mobile_scanner/ios`) was resolved to 0.0.1, which depends on
      GoogleMLKit/BarcodeScanning (~> 3.2.0) was resolved to 3.2.0, which depends on
        MLKitBarcodeScanning (~> 2.2.0) was resolved to 2.2.0, which depends on
          MLKitVision (~> 4.2) was resolved to 4.2.0, which depends on
            GTMSessionFetcher/Core (~> 1.1)

Steps to reproduce
Steps to reproduce the behavior:

Use the following pubspec.yml
Run flutter pub get
Run pod install
See error or incorrect behavior

Expected behavior
Successful build.
Sample pubspec.yml
name: firebase_build_error
description: A new Flutter project.
publish_to: 'none'
version: 1.0.0+1
environment:
  sdk: '>=2.18.2 <3.0.0'

dependencies:
  flutter:
    sdk: flutter
  cupertino_icons: ^1.0.2

  firebase_core: ^2.1.0
  firebase_auth: ^4.0.2
  mobile_scanner: ^3.0.0-beta.1

dev_dependencies:
  flutter_test:
    sdk: flutter
  flutter_lints: ^2.0.1
flutter:
  uses-material-design: true

Additional context
There seems to be a problem with the MLKitVision podspec.
I do not know where to report this problem.
https://github.com/CocoaPods/Specs/blob/master/Specs/8/1/e/MLKitVision/4.2.0/MLKitVision.podspec.json
    "GTMSessionFetcher/Core": [
      "~> 1.1"
    ],

Flutter doctor
Run flutter doctor and paste the output below:
Click To Expand
% flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.3.5, on macOS 13.0 22A380 darwin-arm, locale ja-JP)
[✓] Android toolchain - develop for Android devices (Android SDK version 32.1.0-rc1)
[✓] Xcode - develop for iOS and macOS (Xcode 14.0.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2021.3)
[✓] Android Studio (version 2021.3)
[✓] IntelliJ IDEA Ultimate Edition (version 2022.2.3)
[✓] IntelliJ IDEA Ultimate Edition (version 2022.2.2)
[✓] IntelliJ IDEA Ultimate Edition (version 2022.2.3)
[✓] VS Code (version 1.72.2)
[✓] Connected device (3 available)
[✓] HTTP Host Availability

• No issues found!

Flutter dependencies
Run flutter pub deps -- --style=compact and paste the output below:
Click To Expand
% flutter pub deps -- --style=compact
Dart SDK 2.18.2
Flutter SDK 3.3.5
firebase_build_error 1.0.0+1

dependencies:
- cupertino_icons 1.0.5
- firebase_auth 4.0.2 [firebase_auth_platform_interface firebase_auth_web firebase_core firebase_core_platform_interface flutter meta]
- firebase_core 2.1.0 [firebase_core_platform_interface firebase_core_web flutter meta]
- flutter 0.0.0 [characters collection material_color_utilities meta vector_math sky_engine]
- mobile_scanner 3.0.0-beta.1 [flutter flutter_web_plugins js]

dev dependencies:
- flutter_lints 2.0.1 [lints]
- flutter_test 0.0.0 [flutter test_api path fake_async clock stack_trace vector_math async boolean_selector characters collection matcher material_color_utilities meta source_span stream_channel string_scanner term_glyph]

transitive dependencies:
- _flutterfire_internals 1.0.5 [cloud_firestore_platform_interface cloud_firestore_web collection firebase_core firebase_core_platform_interface flutter meta]
- async 2.9.0 [collection meta]
- boolean_selector 2.1.0 [source_span string_scanner]
- characters 1.2.1
- clock 1.1.1
- cloud_firestore_platform_interface 5.8.2 [_flutterfire_internals collection firebase_core flutter meta plugin_platform_interface]
- cloud_firestore_web 3.0.2 [_flutterfire_internals cloud_firestore_platform_interface collection firebase_core firebase_core_web flutter flutter_web_plugins js]
- collection 1.16.0
- fake_async 1.3.1 [clock collection]
- firebase_auth_platform_interface 6.10.4 [_flutterfire_internals collection firebase_core flutter meta plugin_platform_interface]
- firebase_auth_web 5.0.2 [firebase_auth_platform_interface firebase_core firebase_core_web flutter flutter_web_plugins http_parser intl js meta]
- firebase_core_platform_interface 4.5.1 [collection flutter flutter_test meta plugin_platform_interface]
- firebase_core_web 2.0.0 [firebase_core_platform_interface flutter flutter_web_plugins js meta]
- flutter_web_plugins 0.0.0 [flutter js characters collection material_color_utilities meta vector_math]
- http_parser 4.0.2 [collection source_span string_scanner typed_data]
- intl 0.17.0 [clock path]
- js 0.6.4
- lints 2.0.1
- matcher 0.12.12 [stack_trace]
- material_color_utilities 0.1.5
- meta 1.8.0
- path 1.8.2
- plugin_platform_interface 2.1.3 [meta]
- sky_engine 0.0.99
- source_span 1.9.0 [collection path term_glyph]
- stack_trace 1.10.0 [path]
- stream_channel 2.1.0 [async]
- string_scanner 1.1.1 [source_span]
- term_glyph 1.2.1
- test_api 0.4.12 [async boolean_selector collection meta source_span stack_trace stream_channel string_scanner term_glyph matcher]
- typed_data 1.3.1 [collection]
- vector_math 2.1.2

Hi @motucraft, unfortunately, there's is nothing for us to do here as the conflict is caused by MLKitVision.
This issue has been reported in https://github.com/juliansteenbakker/mobile_scanner/issues/335 on the mobile_scanner repo and it appears that a bug has also been filed in the google tracker, see https://github.com/juliansteenbakker/mobile_scanner/issues/335#issuecomment-1286346905.
I'll be closing this as there's nothing for the flutterfire team to do.
Thank you

@danagbemava-nc
Thanks to you, I found that it has been reported to google tracker.
But I don't know when it will be fixed... Thanks.

Hi @motucraft, unfortunately, there's is nothing for us to do here as the conflict is caused by MLKitVision. This issue has been reported in juliansteenbakker/mobile_scanner#335 on the mobile_scanner repo and it appears that a bug has also been filed in the google tracker, see juliansteenbakker/mobile_scanner#335 (comment).
I'll be closing this as there's nothing for the flutterfire team to do.
Thank you

@danagbemava-nc
I can no longer access IssueTracker, which I was told about here, do you know why?

See https://issuetracker.google.com/issues/254418199#comment48 for workaround


Bluetooth: Controller: LE Connected Isochronous Stream Established failure 0x20

Describe the bug
Attempting to setup a bidirectional CIS to 2 peripherals 2 times seems to fail the second time. It works fine when there is only 1 peripheral, but when there are 2 peripherals it fails with Unsupported LMP Parameter Value / Unsupported LL Parameter Value (0x20).
To Reproduce
Steps to reproduce the behavior:
Build and run the Bluetooth Audio shell (the BT shell with audio.conf).
On the 2 peripherals do
bt init sync
bap init
cap_acceptor init
bt adv-create conn-nscan ext-adv name-ad
bt adv-data discov
bt adv-start

On the central do
bt init
bap init
bt connect-name shell
bap discover
cap_initiator discover

bt connect-name shell
bt select <addr of the other peripheral)
bap discover
cap_initiator discover

cap_initiator unicast-start conns 2
cap_initiator unicast-stop
cap_initiator unicast-start conns 2

where the last command will trigger the issue.
Expected behavior
Expect that it is possible to setup streams and tear them down and then set them up again with the same parameters without issue.
Impact
Significant annoyance, but can be circumvented by disconnecting the ACLs inbetween.
Logs and console output
central.txt
peripheral_1.txt
peripheral_2.txt
The issue can be seen in the central.txt BTMON log where the second attempt to connect the first CIS ends up with
> HCI Event: LE Meta Event (0x3e) plen 29                                                                                #2855 83.683674
      LE Connected Isochronous Stream Established (0x19)
        Status: Unsupported LMP Parameter Value / Unsupported LL Parameter Value (0x20)
        Connection Handle: 6
        CIG Synchronization Delay: 4440 us (0x001158)
        CIS Synchronization Delay: 4440 us (0x001158)
        Central to Peripheral Latency: 4440 us (0x001158)
        Peripheral to Central Latency: 4440 us (0x001158)
        Central to Peripheral PHY: LE 2M (0x02)
        Peripheral to Central PHY: LE 2M (0x02)
        Number of Subevents: 3
        Central to Peripheral Burst Number: 1
        Peripheral to Central Burst Number: 1
        Central to Peripheral Flush Timeout: 1
        Peripheral to Central Flush Timeout: 1
        Central to Peripheral MTU: 40
        Peripheral to Central MTU: 40
        ISO Interval: 8

Things I have noted from the log:
The first group is created as
< HCI Command: LE Set Connected Isochronous Group Parameters (0x08|0x0062) plen 33                                                          #2446 74.956508
        CIG ID: 0x00
        Central to Peripheral SDU Interval: 10000 us (0x002710)
        Peripheral to Central SDU Interval: 10000 us (0x002710)
        SCA: 201 - 500 ppm (0x00)
        Packing: Sequential (0x00)
        Framing: Unframed (0x00)
        Central to Peripheral Maximum Latency: 10 ms (0x000a)
        Peripheral to Central Maximum Latency: 10 ms (0x000a)
        Number of CIS: 2
        CIS ID: 0x00
        Central to Peripheral Maximum SDU Size: 40
        Peripheral to Central Maximum SDU Size: 40
        Central to Peripheral PHY: LE 2M (0x02)
        Peripheral to Central PHY: LE 2M (0x02)
        Central to Peripheral Retransmission attempts: 0x02
        Peripheral to Central Retransmission attempts: 0x02
        CIS ID: 0x01
        Central to Peripheral Maximum SDU Size: 40
        Peripheral to Central Maximum SDU Size: 40
        Central to Peripheral PHY: LE 2M (0x02)
        Peripheral to Central PHY: LE 2M (0x02)
        Central to Peripheral Retransmission attempts: 0x02
        Peripheral to Central Retransmission attempts: 0x02
> HCI Event: Command Complete (0x0e) plen 10                                                                                #2447 75.024486
      LE Set Connected Isochronous Group Parameters (0x08|0x0062) ncmd 1
        Status: Success (0x00)
        CIG ID: 0x00
        Number of Handles: 2
        Connection Handle #0: 6
        Connection Handle #1: 7

where the first CIS gets handle 6, and the second CIS gets handle 7.
The first CIS are then connected as
< HCI Command: LE Create Connected Isochronous Stream (0x08|0x0064) plen 5                                                                  #2570 75.690162
        Number of CIS: 1
        CIS Handle: 6
        ACL Handle: 0

and the second as
< HCI Command: LE Create Connected Isochronous Stream (0x08|0x0064) plen 5                                                                  #2596 76.137561
        Number of CIS: 1
        CIS Handle: 7
        ACL Handle: 1

which works.
On the second attempt, the group is created as
< HCI Command: LE Set Connected Isochronous Group Parameters (0x08|0x0062) plen 33                                                          #2698 82.469154
        CIG ID: 0x00
        Central to Peripheral SDU Interval: 10000 us (0x002710)
        Peripheral to Central SDU Interval: 10000 us (0x002710)
        SCA: 201 - 500 ppm (0x00)
        Packing: Sequential (0x00)
        Framing: Unframed (0x00)
        Central to Peripheral Maximum Latency: 10 ms (0x000a)
        Peripheral to Central Maximum Latency: 10 ms (0x000a)
        Number of CIS: 2
        CIS ID: 0x00
        Central to Peripheral Maximum SDU Size: 40
        Peripheral to Central Maximum SDU Size: 40
        Central to Peripheral PHY: LE 2M (0x02)
        Peripheral to Central PHY: LE 2M (0x02)
        Central to Peripheral Retransmission attempts: 0x02
        Peripheral to Central Retransmission attempts: 0x02
        CIS ID: 0x01
        Central to Peripheral Maximum SDU Size: 40
        Peripheral to Central Maximum SDU Size: 40
        Central to Peripheral PHY: LE 2M (0x02)
        Peripheral to Central PHY: LE 2M (0x02)
        Central to Peripheral Retransmission attempts: 0x02
        Peripheral to Central Retransmission attempts: 0x02
> HCI Event: Command Complete (0x0e) plen 10                                                                                #2699 82.470480
      LE Set Connected Isochronous Group Parameters (0x08|0x0062) ncmd 1
        Status: Success (0x00)
        CIG ID: 0x00
        Number of Handles: 2
        Connection Handle #0: 7
        Connection Handle #1: 6

and the first CIS is connected as
< HCI Command: LE Create Connected Isochronous Stream (0x08|0x0064) plen 5                                                                  #2826 83.089953
        Number of CIS: 1
        CIS Handle: 7
        ACL Handle: 0

and the second CIS as
< HCI Command: LE Create Connected Isochronous Stream (0x08|0x0064) plen 5                                                                  #2850 83.541689
        Number of CIS: 1
        CIS Handle: 6
        ACL Handle: 1

Which arguably should work, but the difference in order of handles may indicate what the issue may be.
Environment (please complete the following information):

Commit SHA or Version used: 97935bb0dcc621b6bcc2e65b5365b1f93c5993b4

Additional context
N/A

@cvinayak @mtpr-ot if this could be resolved before UPF next week it would be amazing, but it's also understandable if it cannot

@cvinayak @mtpr-ot if this could be resolved before UPF next week it would be amazing, but it's also understandable if it cannot

That is very strange, but I see Vinayak has a seemingly unrelated PR which would fix this? Let me know if we need to look further into this, beyond Vinayak's PR.

@mtpr-ot The PR from @cvinayak fixes the issue with the invalid parameters. It does, however, not fix the "issue" that the handles are switched after the first CIG. So the first CIG is still created and returns handles {6, 7}, but any subsequent CIGs are created with handles {7, 6}. The host of course does not care about this, but it's still odd that it's not returning the same thing each time :)

not fix the "issue" that the handles are switched after the first CIG. So the first CIG is still created and returns handles {6, 7}, but any subsequent CIGs are created with handles {7, 6}. The host of course does not care about this, but it's still odd that it's not returning the same thing each time :)

The implementation uses memory pool, and hence the handles allocated will be LIFO based on the implementation of the memory pool. This behavior is as expected from the design, and is similar for ACL connection handles too.
From the BT Spec., it is a may when it comes to re-use of handles, there is no recommendation about the values of the handles, except being from different number space depending on being advertising handles, connection handles etc...

After a device deletes an ID or Handle (e.g. after the Controller deletes a
Connection_Handle for a disconnected ACL connection), it may reuse the ID or
Handle.


Added support for the EWDK

With these changes it's now possible to use the EWDK to build with this toolchain instead of a pre-installed VS version.
To use the EWDK follow the following steps..

Download EWDK from here: https://learn.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk
Extract to local disk (eg: C:\EWDK)
In a fresh command window run C:\EWDK\BuildEnv\SetupBuildEnv.cmd
Run cmake build with -DVS_INSTALLATION_PATH=%VSINSTALLDIR%

This was nessecary for my use case where I'm building a Windows driver project on an automated remote VM with no pre-existing visual studio installation.
Hopefully it's useful to someone else here!

Updated to fix an issue with the github actions windows environment used for testing.

Thanks for the contribution, @kaloth, but I'm a bit conflicted.  That's what this Toolchain is trying to avoid - I don't like having to launch a Visual Studio Developer Prompt to build, since the compiler toolchain is described in the environment and not in the CMake domain.

Hey, @MarkSchofield. Thanks for taking a look at the change. I think I understand your point but I remain hopefull that this could go in as it's so trivial.
Sadly there's no cmake-friendly way to search for the EWDK automatically as the user is free to install it anywhere they like and there's no registry entries or anything to check. A user could even have multiple EWDKs in different folders scattered around their system.
If you dislike the environment variable check I can remove that and have the user specify CMAKE_WINDOWS_KITS_10_DIR in the cmake command? That would keep it more in-line with the existing code.

I left a couple of comments.
One thing that makes me nervous is that when launching an eWDK prompt, it sets the host and target - if I launch a prompt it set environment variables that appear to default to an x86 host and an x86 target. If WindowsToolchain defaults to a x64 target, then the linker would be provided with a mix of paths for the two architectures. I think that:

the logic that sets/defaults CMAKE_SYSTEM_PROCESSOR would need to be made aware of the eWDK environment variables that define the target and default to that target, or complain (i.e. message(FATAL... if they are in disagreement.
the logic that sets/defaults CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE would need to be made aware of the eWDK environment variables that define the host and default to that host, or complain if they are in disagreement.

I wonder if the Toolchain should also defer the to eWDK's environment for VS_PLATFORM_TOOLSET_VERSION`VS_TOOLSET_PATH`?

I've had an idea. At the minute this PR does a couple of things;

It checks the 'WindowsSdkDir' environment variable to set CMAKE_WINDOWS_KITS_10_DIR. CMAKE_WINDOWS_KITS_10_DIR can already be set by the consumer.
It makes VS_INSTALLATION_PATH settable by the consumer.

If this change were to just scope to (2) - i.e. ensure that CMAKE_WINDOWS_KITS_10_DIR and VS_INSTALLATION_PATH are settable by the consumer, then we could introduce a new Toolchain file - Windows.eWDK.toolchain.cmake that would encapsulate eWDK-awareness, set defaults with its environment variable awareness, and check parameters (for example, my comment about host and target), and then it could include Windows.MSVC.toolchain.cmake. I think that would be a great way to support eWDK - it's a slightly more explicit 'opt-in', and the logic/resolution/environment variable behavior is all encapsulated and easier to manage. What do you think? I think it would end-up providing a much better user experience because it would be easier to default things proactively, and it would be easier to provide more specific, up-front error messages when needed.

Hey! Just read your last comment and I totally agree! I'll drop the environment stuff entirely and focus on the ability to manually override VS_INSTALLATION_PATH. That should keep things simple.


Drop Ruby 2.4/2.5/2.6 support

Echoing https://github.com/voxpupuli/puppet-blacksmith/pull/109#issuecomment-1474171820 I'd only drop 2.4 for now as I don't think you're helping anyone by being overly aggressive without tangible benefits.
Puppet 6 (with Ruby 2.5) has only just gone EOL.  IMO it's not helping people upgrading from 6 to 7 if we drop ruby 2.5 support in all the core testing gems.

I agree with @alexjfisher that - besides beaker - dropping Ruby 2.5 is a tad too aggressive for now.


NO-JIRA: Simplify tekton pipeline code(release-1.14)

PR is a manual cherry-pick of https://github.com/openshift/cert-manager-operator-release/pull/142.

/retry

/retest

/lgtm


How do I get the fitting size of either TZStackView or the UIStackView?

https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIStackView_Class_Reference/ has a section called Positioning and Sizing the Stack View — I don't understand this wording:

Along the stack view’s axis, its fitting size is equal to the sum of the sizes of all the arranged views plus the space between views.

Perpendicular to the stack view’s axis, its fitting size is equal to the size of the largest arranged view.

If the stack view’s layoutMarginsRelativeArrangement property is set to YES, the stack view’s fitting size is increased to include space for the margins.

This fitting size is exactly what I need — how do I get to it?

When you add subviews to UIStackView, it automatically resizes to accommodate the newcomer. Yet, this is not a change in intrinsic content size. How does TZStackView replicate this behaviour?

There is no API to get the "fitting size". You use auto layout to position the stack view, and the size of the stack view will be calculated by the layout engine automatically.

I believe you're looking for systemLayoutSizeFittingSize.
For example:
let fittingSize = stackView.systemLayoutSizeFittingSize(UILayoutFittingCompressedSize)

See more at https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIView_Class/#//apple_ref/occ/instm/UIView/systemLayoutSizeFittingSize:


Make each dietary restriction type an object

This will allow directors to filter users on dietary restriction. This functionality will also add support for mobile applications and future meal based features.

This should be in the questionnaire, not user I think -- and of course, also available in the API.


Websocket performance tweaks

@moogle19 you may be interested in the further tweak to your mask tweaks from a a few months back. Benchee:
Mix.install([:benchee])

defmodule Old do
  # Note that masking is an involution, so we don't need a separate unmask function
  def mask(payload, mask, acc \\ <<>>)

  def mask(payload, mask, acc) when is_integer(mask), do: mask(payload, <<mask::32>>, acc)

  def mask(<<h::32, rest::binary>>, <<mask::32>>, acc) do
    mask(rest, mask, acc <> <<Bitwise.bxor(h, mask)::32>>)
  end

  def mask(<<h::8, rest::binary>>, <<current::8, mask::24>>, acc) do
    mask(rest, <<mask::24, current::8>>, acc <> <<Bitwise.bxor(h, current)::8>>)
  end

  def mask(<<>>, _mask, acc), do: acc
end

defmodule New do
  # Note that masking is an involution, so we don't need a separate unmask function
  def mask(payload, mask) do
    payload
    |> do_mask(<<mask::32>>, [])
    |> IO.iodata_to_binary()
  end

  defp do_mask(<<h::32, rest::binary>>, <<int_mask::32>> = mask, acc) do
    do_mask(rest, mask, [acc, <<Bitwise.bxor(h, int_mask)::32>>])
  end

  defp do_mask(<<h::8, rest::binary>>, <<current::8, mask::24>>, acc) do
    do_mask(rest, <<mask::24, current::8>>, [acc, <<Bitwise.bxor(h, current)::8>>])
  end

  defp do_mask(<<>>, _mask, acc), do: acc
end

foo = String.duplicate("a", 10_002)

Benchee.run(
  %{
    "old" => fn -> Old.mask(foo, 1234) end,
    "new" => fn -> New.mask(foo, 1234) end
  },
  time: 10,
  memory_time: 2
)
...
Operating System: macOS
CPU Information: Apple M1
Number of Available Cores: 8
Available memory: 16 GB
Elixir 1.14.1
Erlang 25.1

Benchmark suite executing with the following configuration:
warmup: 2 s
time: 10 s
memory time: 2 s
reduction time: 0 ns
parallel: 1
inputs: none specified
Estimated total run time: 28 s

Benchmarking new ...
Benchmarking old ...

Name           ips        average  deviation         median         99th %
new         9.28 K      107.71 μs     ±9.44%      106.67 μs      122.88 μs
old         7.11 K      140.74 μs    ±20.00%      136.08 μs      277.74 μs

Comparison:
new         9.28 K
old         7.11 K - 1.31x slower +33.03 μs

Memory usage statistics:

Name    Memory usage
new        235.49 KB
old        450.59 KB - 1.91x memory usage +215.09 KB

If we replicate the mask to e.g. 256 bits and use that to bxor we can make it even faster:
Mix.install([:benchee])

defmodule NewImproved do
  @mask_size 256
  # Note that masking is an involution, so we don't need a separate unmask function
  def mask(payload, mask) do
    payload
    |> do_mask(
      <<mask::32, mask::32, mask::32, mask::32, mask::32, mask::32, mask::32, mask::32>>,
      []
    )
    |> IO.iodata_to_binary()
  end

  # Matching the full mask size
  defp do_mask(
         <<h::unquote(@mask_size), rest::binary>>,
         <<int_mask::unquote(@mask_size)>> = mask,
         acc
       ) do
    do_mask(rest, mask, [acc, <<Bitwise.bxor(h, int_mask)::unquote(@mask_size)>>])
  end

  # Generate do_mask for each mask size from @mask_size down to 8
  for x <- (@mask_size - 8)..8//-8 do
    defp do_mask(
           <<h::unquote(x), rest::binary>>,
           <<current::unquote(x), mask::unquote(@mask_size - x)>>,
           acc
         ) do
      do_mask(rest, <<mask::unquote(@mask_size - x), current::unquote(x)>>, [
        acc,
        <<Bitwise.bxor(h, current)::unquote(x)>>
      ])
    end
  end

  defp do_mask(<<>>, _mask, acc), do: acc
end

defmodule New do
  # Note that masking is an involution, so we don't need a separate unmask function
  def mask(payload, mask) do
    payload
    |> do_mask(<<mask::32>>, [])
    |> IO.iodata_to_binary()
  end

  defp do_mask(<<h::32, rest::binary>>, <<int_mask::32>> = mask, acc) do
    do_mask(rest, mask, [acc, <<Bitwise.bxor(h, int_mask)::32>>])
  end

  defp do_mask(<<h::24, rest::binary>>, <<current::24, mask::8>>, acc) do
    do_mask(rest, <<mask::24, current::8>>, [acc, <<Bitwise.bxor(h, current)::24>>])
  end

  defp do_mask(<<h::16, rest::binary>>, <<current::16, mask::16>>, acc) do
    do_mask(rest, <<mask::16, current::16>>, [acc, <<Bitwise.bxor(h, current)::16>>])
  end

  defp do_mask(<<h::8, rest::binary>>, <<current::8, mask::24>>, acc) do
    do_mask(rest, <<mask::24, current::8>>, [acc, <<Bitwise.bxor(h, current)::8>>])
  end

  defp do_mask(<<>>, _mask, acc), do: acc
end

Benchee.run(
  %{
    "new_improved" => fn input -> NewImproved.mask(input, 1234) end,
    "new" => fn input -> New.mask(input, 1234) end
  },
  time: 10,
  memory_time: 2,
  inputs: %{
    "tiny" => String.duplicate("a", 102),
    "small" => String.duplicate("a", 1_002),
    "medium" => String.duplicate("a", 10_002),
    "large" => String.duplicate("a", 100_002),
    "huge" => String.duplicate("a", 1_000_002)
  }
)
...
Operating System: macOS
CPU Information: Apple M1 Pro
Number of Available Cores: 10
Available memory: 32 GB
Elixir 1.14.3
Erlang 25.2

Benchmark suite executing with the following configuration:
warmup: 2 s
time: 10 s
memory time: 2 s
reduction time: 0 ns
parallel: 1
inputs: huge, large, medium, small, tiny
Estimated total run time: 2.33 min

Benchmarking new with input huge ...
Benchmarking new with input large ...
Benchmarking new with input medium ...
Benchmarking new with input small ...
Benchmarking new with input tiny ...
Benchmarking new_improved with input huge ...
Benchmarking new_improved with input large ...
Benchmarking new_improved with input medium ...
Benchmarking new_improved with input small ...
Benchmarking new_improved with input tiny ...

##### With input huge #####
Name                   ips        average  deviation         median         99th %
new_improved        234.32        4.27 ms    ±37.19%        3.96 ms       13.60 ms
new                  44.03       22.71 ms    ±17.54%       21.60 ms       42.17 ms

Comparison:
new_improved        234.32
new                  44.03 - 5.32x slower +18.45 ms

Memory usage statistics:

Name            Memory usage
new_improved         5.96 MB
new                 22.89 MB - 3.84x memory usage +16.93 MB

**All measurements for memory usage were the same**

##### With input large #####
Name                   ips        average  deviation         median         99th %
new_improved        2.15 K        0.47 ms   ±222.87%        0.41 ms        1.41 ms
new                 0.58 K        1.72 ms    ±63.47%        1.51 ms        5.08 ms

Comparison:
new_improved        2.15 K
new                 0.58 K - 3.70x slower +1.26 ms

Memory usage statistics:

Name            Memory usage
new_improved         0.60 MB
new                  2.29 MB - 3.84x memory usage +1.69 MB

**All measurements for memory usage were the same**

##### With input medium #####
Name                   ips        average  deviation         median         99th %
new_improved       18.71 K       53.46 μs   ±339.33%       30.04 μs      546.86 μs
new                 5.27 K      189.86 μs   ±115.64%      165.92 μs      386.85 μs

Comparison:
new_improved       18.71 K
new                 5.27 K - 3.55x slower +136.40 μs

Memory usage statistics:

Name            Memory usage
new_improved        61.30 KB
new                234.63 KB - 3.83x memory usage +173.32 KB

**All measurements for memory usage were the same**

##### With input small #####
Name                   ips        average  deviation         median         99th %
new_improved      123.01 K        8.13 μs  ±1516.11%        3.25 μs        8.21 μs
new                40.91 K       24.44 μs   ±619.30%        9.54 μs      488.95 μs

Comparison:
new_improved      123.01 K
new                40.91 K - 3.01x slower +16.31 μs

Memory usage statistics:

Name            Memory usage
new_improved         6.39 KB
new                 23.66 KB - 3.70x memory usage +17.27 KB

**All measurements for memory usage were the same**

##### With input tiny #####
Name                   ips        average  deviation         median         99th %
new_improved      835.71 K        1.20 μs  ±5243.19%        0.63 μs        1.71 μs
new               286.17 K        3.49 μs  ±3343.86%        1.08 μs        2.58 μs

Comparison:
new_improved      835.71 K
new               286.17 K - 2.92x slower +2.30 μs

Memory usage statistics:

Name            Memory usage
new_improved         0.90 KB
new                  2.57 KB - 2.86x memory usage +1.67 KB

**All measurements for memory usage were the same**

I also benchmarked it for 512 and 1024 bit:

Operating System: macOS
CPU Information: Apple M1 Pro
Number of Available Cores: 10
Available memory: 32 GB
Elixir 1.14.3
Erlang 25.2

Benchmark suite executing with the following configuration:
warmup: 2 s
time: 10 s
memory time: 2 s
reduction time: 0 ns
parallel: 1
inputs: huge, large, medium, small, tiny
Estimated total run time: 4.67 min

Benchmarking new with input huge ...
Benchmarking new with input large ...
Benchmarking new with input medium ...
Benchmarking new with input small ...
Benchmarking new with input tiny ...
Benchmarking new_improved1024 with input huge ...
Benchmarking new_improved1024 with input large ...
Benchmarking new_improved1024 with input medium ...
Benchmarking new_improved1024 with input small ...
Benchmarking new_improved1024 with input tiny ...
Benchmarking new_improved256 with input huge ...
Benchmarking new_improved256 with input large ...
Benchmarking new_improved256 with input medium ...
Benchmarking new_improved256 with input small ...
Benchmarking new_improved256 with input tiny ...
Benchmarking new_improved512 with input huge ...
Benchmarking new_improved512 with input large ...
Benchmarking new_improved512 with input medium ...
Benchmarking new_improved512 with input small ...
Benchmarking new_improved512 with input tiny ...

##### With input huge #####
Name                       ips        average  deviation         median         99th %
new_improved512         350.04        2.86 ms    ±35.95%        2.61 ms        7.39 ms
new_improved1024        256.25        3.90 ms    ±28.90%        3.67 ms        9.54 ms
new_improved256         237.23        4.22 ms    ±31.26%        3.97 ms        9.99 ms
new                      45.86       21.81 ms    ±11.82%       21.07 ms       35.19 ms

Comparison:
new_improved512         350.04
new_improved1024        256.25 - 1.37x slower +1.05 ms
new_improved256         237.23 - 1.48x slower +1.36 ms
new                      45.86 - 7.63x slower +18.95 ms

Memory usage statistics:

Name                Memory usage
new_improved512          4.41 MB
new_improved1024         2.92 MB - 0.66x memory usage -1.48987 MB
new_improved256          5.96 MB - 1.35x memory usage +1.55 MB
new                     22.89 MB - 5.19x memory usage +18.48 MB

**All measurements for memory usage were the same**

##### With input large #####
Name                       ips        average  deviation         median         99th %
new_improved512         3.18 K      314.86 μs   ±121.44%      287.25 μs      879.69 μs
new_improved1024        2.88 K      347.39 μs    ±83.77%      332.63 μs      535.17 μs
new_improved256         2.26 K      442.44 μs    ±72.49%      414.88 μs     1012.27 μs
new                     0.60 K     1657.07 μs    ±40.17%     1522.42 μs     4845.66 μs

Comparison:
new_improved512         3.18 K
new_improved1024        2.88 K - 1.10x slower +32.54 μs
new_improved256         2.26 K - 1.41x slower +127.58 μs
new                     0.60 K - 5.26x slower +1342.21 μs

Memory usage statistics:

Name                Memory usage
new_improved512        452.01 KB
new_improved1024       299.47 KB - 0.66x memory usage -152.53906 KB
new_improved256        610.66 KB - 1.35x memory usage +158.66 KB
new                   2344.01 KB - 5.19x memory usage +1892 KB

**All measurements for memory usage were the same**

##### With input medium #####
Name                       ips        average  deviation         median         99th %
new_improved1024       32.22 K       31.04 μs   ±217.66%       23.88 μs      171.09 μs
new_improved512        25.95 K       38.53 μs   ±314.93%       20.04 μs      613.90 μs
new_improved256        19.37 K       51.61 μs   ±260.61%       29.50 μs      549.00 μs
new                     4.88 K      205.02 μs   ±186.19%      167.13 μs      616.62 μs

Comparison:
new_improved1024       32.22 K
new_improved512        25.95 K - 1.24x slower +7.49 μs
new_improved256        19.37 K - 1.66x slower +20.57 μs
new                     4.88 K - 6.60x slower +173.98 μs

Memory usage statistics:

Name                Memory usage
new_improved1024        30.32 KB
new_improved512         45.55 KB - 1.50x memory usage +15.23 KB
new_improved256         61.30 KB - 2.02x memory usage +30.98 KB
new                    234.74 KB - 7.74x memory usage +204.42 KB

**All measurements for memory usage were the same**

##### With input small #####
Name                       ips        average  deviation         median         99th %
new_improved1024      278.14 K        3.60 μs   ±465.30%        3.08 μs        4.54 μs
new_improved512       186.00 K        5.38 μs  ±2006.55%        2.38 μs        7.13 μs
new_improved256       133.49 K        7.49 μs  ±1409.02%        3.25 μs        6.67 μs
new                    39.07 K       25.60 μs   ±764.58%        9.67 μs      506.61 μs

Comparison:
new_improved1024      278.14 K
new_improved512       186.00 K - 1.50x slower +1.78 μs
new_improved256       133.49 K - 2.08x slower +3.90 μs
new                    39.07 K - 7.12x slower +22.00 μs

Memory usage statistics:

Name                Memory usage
new_improved1024         3.23 KB
new_improved512          4.84 KB - 1.50x memory usage +1.61 KB
new_improved256          6.39 KB - 1.98x memory usage +3.16 KB
new                     23.78 KB - 7.35x memory usage +20.55 KB

**All measurements for memory usage were the same**

##### With input tiny #####
Name                       ips        average  deviation         median         99th %
new_improved512       898.10 K        1.11 μs  ±4578.12%        0.67 μs        1.63 μs
new_improved256       877.63 K        1.14 μs  ±5178.60%        0.63 μs        1.58 μs
new_improved1024      832.47 K        1.20 μs  ±2101.38%           1 μs        1.29 μs
new                   275.72 K        3.63 μs  ±3196.55%        1.13 μs        2.96 μs

Comparison:
new_improved512       898.10 K
new_improved256       877.63 K - 1.02x slower +0.0260 μs
new_improved1024      832.47 K - 1.08x slower +0.0878 μs
new                   275.72 K - 3.26x slower +2.51 μs

Memory usage statistics:

Name                Memory usage
new_improved512            808 B
new_improved256            920 B - 1.14x memory usage +112 B
new_improved1024           568 B - 0.70x memory usage -240 B
new                       2752 B - 3.41x memory usage +1944 B

**All measurements for memory usage were the same**

Some real https://www.theonion.com/fuck-everything-were-doing-five-blades-1819584036 energy here. I love it.

All joking aside this looks great. Lemme run a quick benchmark on an x86 machine and this should be good to go

512 is the sweet spot for x86 as well. I'll get this done up as a commit on this branch (I have a couple of small changes) and we can do a review pass on it.

I ran the Limits/Performance parts of the Autobahn suite with the current vs. 512 bit masking:
While the fragmented binary / text message part look quite nice (left current vs right 512 bit masking):

the non-fragmented binary / text message part performance is equal to worse than the current implementation:

Looking at the code for case 9.6.6 (https://github.com/crossbario/autobahn-testsuite/blob/master/autobahntestsuite/autobahntestsuite/case/case9_6_6.py), I don't see why there should be any systematic change. Is the difference reproducible, or could this just be test noise (FWIW, I don't generally put any value in differences of +/- 10% or so in the CI benchmarker; it's just noise at that point).

More golf:
Mix.install([:benchee])

defmodule Old do
  # Note that masking is an involution, so we don't need a separate unmask function
  def mask(payload, mask) do
    payload
    |> do_mask(<<mask::32>>, [])
    |> IO.iodata_to_binary()
  end

  defp do_mask(<<h::32, rest::binary>>, <<int_mask::32>> = mask, acc) do
    do_mask(rest, mask, [acc, <<Bitwise.bxor(h, int_mask)::32>>])
  end

  defp do_mask(<<h::8, rest::binary>>, <<current::8, mask::24>>, acc) do
    do_mask(rest, <<mask::24, current::8>>, [acc, <<Bitwise.bxor(h, current)::8>>])
  end

  defp do_mask(<<>>, _mask, acc), do: acc
end

defmodule New512 do
  @mask_size 512
  # Note that masking is an involution, so we don't need a separate unmask function
  def mask(payload, mask) do
    payload
    |> do_mask(String.duplicate(<<mask::32>>, div(@mask_size, 32)), [])
    |> IO.iodata_to_binary()
  end

  # Matching the full mask size
  defp do_mask(
         <<h::unquote(@mask_size), rest::binary>>,
         <<int_mask::unquote(@mask_size)>> = mask,
         acc
       ) do
    do_mask(rest, mask, [acc, <<Bitwise.bxor(h, int_mask)::unquote(@mask_size)>>])
  end

  defp do_mask(<<h::32, rest::binary>>, <<int_mask::32, _mask_rest::binary>> = mask, acc) do
    do_mask(rest, mask, [acc, <<Bitwise.bxor(h, int_mask)::32>>])
  end

  defp do_mask(<<h::8, rest::binary>>, <<current::8, mask::24, _mask_rest::binary>>, acc) do
    do_mask(rest, <<mask::24, current::8>>, [acc, <<Bitwise.bxor(h, current)::8>>])
  end

  defp do_mask(<<>>, _mask, acc), do: acc
end

defmodule Adaptive512 do
  @mask_size 512

  def mask(payload, mask) when bit_size(payload) > @mask_size do
    New512.mask(payload, mask)
  end

  def mask(payload, mask) do
    Old.mask(payload, mask)
  end
end

Benchee.run(
  %{
    "old" => fn input -> Old.mask(input, 1234) end,
    "new_512" => fn input -> New512.mask(input, 1234) end,
    "adaptive_512" => fn input -> Adaptive512.mask(input, 1234) end,
  },
  time: 10,
  memory_time: 2,
  inputs: %{
    "micro" => String.duplicate("a", 10),
    "tiny" => String.duplicate("a", 102),
    "small" => String.duplicate("a", 1_002),
    "medium" => String.duplicate("a", 10_002),
    "large" => String.duplicate("a", 100_002),
    "huge" => String.duplicate("a", 1_000_002)
  }
)

I noticed that the overhead of the 512 bit approach was of benefit only on larger strings, and was actually a pretty significant penalty on smaller strings (which is what I suspect most real-world websocket frames are). This adaptive approach uses either the previous 32 bit approach on this PR for smaller frames, and the 512 bit approach for larger frames, providing the best of both worlds.
I want to cover this with proper tests for larger and smaller frames; I'll get this coded up tomorrow if it makes sense to y'all.

If we need even more performance, we can also take a look at rustler:

Rustler benchmark
Operating System: macOS
CPU Information: Apple M1 Pro
Number of Available Cores: 10
Available memory: 32 GB
Elixir 1.14.3
Erlang 25.2

Benchmark suite executing with the following configuration:
warmup: 2 s
time: 10 s
memory time: 2 s
reduction time: 0 ns
parallel: 1
inputs: huge, large, medium, micro, small, tiny
Estimated total run time: 2.80 min

Benchmarking new_512 with input huge ...
Benchmarking new_512 with input large ...
Benchmarking new_512 with input medium ...
Benchmarking new_512 with input micro ...
Benchmarking new_512 with input small ...
Benchmarking new_512 with input tiny ...
Benchmarking rustler with input huge ...
Benchmarking rustler with input large ...
Benchmarking rustler with input medium ...
Benchmarking rustler with input micro ...
Benchmarking rustler with input small ...
Benchmarking rustler with input tiny ...

##### With input huge #####
Name              ips        average  deviation         median         99th %
rustler        1.31 K        0.76 ms     ±8.56%        0.77 ms        0.90 ms
new_512        0.29 K        3.45 ms    ±64.91%        2.71 ms       13.55 ms

Comparison:
rustler        1.31 K
new_512        0.29 K - 4.51x slower +2.69 ms

Memory usage statistics:

Name       Memory usage
rustler      0.00005 MB
new_512         4.41 MB - 96346.00x memory usage +4.41 MB

**All measurements for memory usage were the same**

##### With input large #####
Name              ips        average  deviation         median         99th %
rustler       13.29 K       75.27 μs     ±8.88%       76.75 μs       99.67 μs
new_512        3.07 K      325.91 μs   ±128.06%      286.67 μs     1224.17 μs

Comparison:
rustler       13.29 K
new_512        3.07 K - 4.33x slower +250.64 μs

Memory usage statistics:

Name       Memory usage
rustler       0.0469 KB
new_512       452.69 KB - 9657.33x memory usage +452.64 KB

**All measurements for memory usage were the same**

##### With input medium #####
Name              ips        average  deviation         median         99th %
rustler      130.14 K        7.68 μs   ±147.18%        7.50 μs        9.54 μs
new_512       22.31 K       44.83 μs   ±527.87%       20.29 μs      600.35 μs

Comparison:
rustler      130.14 K
new_512       22.31 K - 5.83x slower +37.14 μs

Memory usage statistics:

Name       Memory usage
rustler       0.0469 KB
new_512        45.89 KB - 979.00x memory usage +45.84 KB

**All measurements for memory usage were the same**

##### With input micro #####
Name              ips        average  deviation         median         99th %
rustler        3.39 M      294.88 ns ±20545.13%         125 ns         250 ns
new_512        1.05 M      952.93 ns ±10177.57%         292 ns        1500 ns

Comparison:
rustler        3.39 M
new_512        1.05 M - 3.23x slower +658.05 ns

Memory usage statistics:

Name       Memory usage
rustler            80 B
new_512           608 B - 7.60x memory usage +528 B

**All measurements for memory usage were the same**

##### With input small #####
Name              ips        average  deviation         median         99th %
rustler        1.11 M        0.90 μs  ±3611.37%        0.79 μs        0.96 μs
new_512       0.133 M        7.53 μs  ±1871.88%        2.54 μs        7.79 μs

Comparison:
rustler        1.11 M
new_512       0.133 M - 8.35x slower +6.63 μs

Memory usage statistics:

Name       Memory usage
rustler       0.0469 KB
new_512         5.70 KB - 121.50x memory usage +5.65 KB

**All measurements for memory usage were the same**

##### With input tiny #####
Name              ips        average  deviation         median         99th %
rustler        3.01 M        0.33 μs ±12263.70%        0.21 μs        0.42 μs
new_512        0.38 M        2.62 μs  ±4929.71%        0.71 μs        2.17 μs

Comparison:
rustler        3.01 M
new_512        0.38 M - 7.88x slower +2.28 μs

Memory usage statistics:

Name       Memory usage
rustler       0.0469 KB
new_512         1.55 KB - 33.17x memory usage +1.51 KB

**All measurements for memory usage were the same**

Maybe an approach like jason_native could be interesting in the future.
I played around with it a little here and here.

Improved 512 bit strides for masking are in and green.
I'm now looking at a similar approach for the largest component of our profiling, UTF-8 string validation:
Mix.install([:benchee])

defmodule BulkMatch do
  defguardp is_inner_byte(c) when c >= 128 and c < 192

  def valid?(str), do: do_valid?(str)
  defp do_valid?(<<a::512, rest::binary>>) when Bitwise.band(a, 0x80808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080) == 0, do: do_valid?(rest)
  defp do_valid?(<<a::8, rest::binary>>) when a < 128, do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, rest::binary>>) when a >= 192 and a < 224 and is_inner_byte(b), do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, c::8, rest::binary>>) when a >= 224 and a < 240 and is_inner_byte(b) and is_inner_byte(c), do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, c::8, d::8, rest::binary>>) when a >= 240 and is_inner_byte(b) and is_inner_byte(c) and is_inner_byte(d), do: do_valid?(rest)
  defp do_valid?(<<>>), do: true
  defp do_valid?(_str), do: false
end

Benchee.run(
  %{
    "old" => fn input -> String.valid?(input) end,
    "new" => fn input -> BulkMatch.valid?(input) end,
  },
  time: 10,
  memory_time: 2,
  inputs: %{
    "micro" => String.duplicate("a", 10),
    "tiny" => String.duplicate("a", 102),
    "small" => String.duplicate("a", 1_002),
    "medium" => String.duplicate("a", 10_002),
    "large" => String.duplicate("a", 100_002),
    "huge" => String.duplicate("a", 1_000_002)
  }
)

Operating System: macOS
CPU Information: Apple M1
Number of Available Cores: 8
Available memory: 16 GB
Elixir 1.14.1
Erlang 25.1

Benchmark suite executing with the following configuration:
warmup: 2 s
time: 10 s
memory time: 2 s
reduction time: 0 ns
parallel: 1
inputs: huge, large, medium, micro, small, tiny
Estimated total run time: 2.80 min

Benchmarking new with input huge ...
Benchmarking new with input large ...
Benchmarking new with input medium ...
Benchmarking new with input micro ...
Benchmarking new with input small ...
Benchmarking new with input tiny ...
Benchmarking old with input huge ...
Benchmarking old with input large ...
Benchmarking old with input medium ...
Benchmarking old with input micro ...
Benchmarking old with input small ...
Benchmarking old with input tiny ...

##### With input huge #####
Name           ips        average  deviation         median         99th %
new         729.28        1.37 ms    ±21.53%        1.34 ms        2.01 ms
old         343.63        2.91 ms     ±0.79%        2.90 ms        2.97 ms

Comparison:
new         729.28
old         343.63 - 2.12x slower +1.54 ms

Memory usage statistics:

Name    Memory usage
new          1.07 MB
old       0.00063 MB - 0.00x memory usage -1.07288 MB

**All measurements for memory usage were the same**

##### With input large #####
Name           ips        average  deviation         median         99th %
new         6.69 K      149.45 μs    ±45.53%      117.21 μs      347.64 μs
old         3.42 K      292.27 μs    ±13.25%      290.61 μs      312.70 μs

Comparison:
new         6.69 K
old         3.42 K - 1.96x slower +142.82 μs

Memory usage statistics:

Name    Memory usage
new        110.47 KB
old          0.64 KB - 0.01x memory usage -109.82813 KB

**All measurements for memory usage were the same**

##### With input medium #####
Name           ips        average  deviation         median         99th %
new        57.01 K       17.54 μs   ±525.67%        9.79 μs       83.89 μs
old        33.36 K       29.98 μs    ±59.90%       29.25 μs       36.58 μs

Comparison:
new        57.01 K
old        33.36 K - 1.71x slower +12.44 μs

Memory usage statistics:

Name    Memory usage
new         11.61 KB
old          0.64 KB - 0.06x memory usage -10.96875 KB

**All measurements for memory usage were the same**

##### With input micro #####
Name           ips        average  deviation         median         99th %
old       954.66 K        1.05 μs ±10898.38%        0.25 μs        1.38 μs
new       920.50 K        1.09 μs ±10298.99%        0.29 μs        1.42 μs

Comparison:
old       954.66 K
new       920.50 K - 1.04x slower +0.0389 μs

Memory usage statistics:

Name    Memory usage
old            656 B
new            656 B - 1.00x memory usage +0 B

**All measurements for memory usage were the same**

##### With input small #####
Name           ips        average  deviation         median         99th %
new       324.15 K        3.09 μs  ±3288.18%        1.42 μs        2.79 μs
old       261.03 K        3.83 μs  ±1508.17%        3.08 μs        4.46 μs

Comparison:
new       324.15 K
old       261.03 K - 1.24x slower +0.75 μs

Memory usage statistics:

Name    Memory usage
new          1.70 KB
old          0.64 KB - 0.38x memory usage -1.05469 KB

**All measurements for memory usage were the same**

##### With input tiny #####
Name           ips        average  deviation         median         99th %
old       768.04 K        1.30 μs  ±7823.95%        0.50 μs        1.67 μs
new       766.80 K        1.30 μs  ±7496.43%        0.54 μs        1.71 μs

Comparison:
old       768.04 K
new       766.80 K - 1.00x slower +0.00210 μs

Memory usage statistics:

Name    Memory usage
old            656 B
new            728 B - 1.11x memory usage +72 B

**All measurements for memory usage were the same**

So, quite a bit faster, in exchange for higher memory usage. I'm going to tinker with this a bit more and see if I can improve the memory numbers.

Really nice! I don't think we want to land native dependencies just yet (I'm not at all opposed to them, but I think we should wait until post 1.0 and maybe do them as a pluggable library, especially for ones outside the usual gcc based idiom). But it's great to know that we're able to get them (there's a whole bunch more golf to do on the rust side too!). Doing eg: HTTP/1 parsing and other really hot paths in Rust is very interesting.

@mtrudel I respect your opinion but would like to disagree a little.
I think the minimalist approach that has been presented could be an excellent way forward here. Even more so with the proposal being optional, I think you have everything to follow both paths here and make users who need brute force happy and those who don't too.

Don't get me wrong - I really like @moogle19's approach here, a LOT. I can foresee a time when native code like this replaces (or more correctly, 'optionally replaces') the native implementation within Bandit. I'm just saying that that time isn't here yet. Some rationale:

We're currently in the 0.6 release series, with just one more series (0.7, covering aspects of configurability) before prepping for a 1.0. It's been a long road to get here, and one that I'd like to see completed sooner rather than later. The perf work in the 0.6 series is intended to tweak the broad implementation we have today, not to introduce new paradigms that may slow progress or diminish the high quality bar we've set for ourselves.

We're still very much in the 'adoption' phase of the project, and as such should be doing everything we can to ensure that Bandit is as much of a 'drop-in' replacement as possible. While rustler does a great job of streamlining things, the fact remains that NIFs aren't as universally straightforward to get running in all instances, and run the very real risk of jeopardizing Bandit adoption by making the upgrade process even slightly more error-prone.

There are a lot of hot paths that would benefit greatly from native execution. Off the top of my head: header parsing in HTTP/1, iolist splitting in (mostly) HTTP/2, and UTF-8 validation and masking in WebSockets. I'd like us to tackle these in a consistent way as an intentional, standalone workup, not have it as a secondary tag-along in an otherwise pretty incidental PR.

From the Bandit README:

It is written with correctness, clarity & performance as fundamental goals.

I should note, even though it isn't called out explicitly, that I consider this an ordered list. Specifically, it is fundamentally more important to me for the project's code to be clear than it is for the code to be fast. I'm not yet sure of the best way to handle native tooling in this respect, and I'm loathe to rush into it.

Hopefully that clears up what my position on this is. I really can't emphasize enough how much I'm not saying 'no', but rather 'not right now'.

It is also worth noting that :jason_native, used here as the example, does not use rustler. There is an explanation here on the project README: https://github.com/spawnfest/json_native#why-not-rust
The NIF theme on the BEAM is subtle... many stories of successes and also of troubles :)

I think that for web servers, especially on BEAM there are few optimal options in terms of raw performance. We know all the qualities of BEAM and it is fantastic, but for certain use cases these qualities are not all that is needed. That said, if we could have an option that would give the user the option to make the choice then why not? NIF will always be a tricky case, but because the BEAM VM is preemptive and therefore there must be compromises to be made when you want performance over security (user choice). In addition, there are ways to provide the necessary security also we are not talking about C++ code, we are talking about Rust, which is a thousand times more secure than anything else out there.
So about the project's roadmap, I think it's worth waiting, but I would consider it a waste of opportunity to leave this indefinitely behind.

For example, in my current project we already use Bandit and we would benefit a lot if something like the parsing of the http headers was done via rust because being a Sidecar based solution every microsecond in the additional latency matters a lot to us.

I implemented Cowboy's implementation of UTF-8 validation in Elixir and benched it, and it's actually the slowest of the bunch by quite a bit:

Mix.install([:benchee])

defmodule BulkMatch1024 do
  defguardp is_inner_byte(c) when c >= 128 and c < 192

  def valid?(str), do: do_valid?(str)
  defp do_valid?(<<a::1024, rest::binary>>) when Bitwise.band(a, 0x8080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080) == 0, do: do_valid?(rest)
  defp do_valid?(<<a::8, rest::binary>>) when a < 128, do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, rest::binary>>) when a >= 192 and a < 224 and is_inner_byte(b), do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, c::8, rest::binary>>) when a >= 224 and a < 240 and is_inner_byte(b) and is_inner_byte(c), do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, c::8, d::8, rest::binary>>) when a >= 240 and is_inner_byte(b) and is_inner_byte(c) and is_inner_byte(d), do: do_valid?(rest)
  defp do_valid?(<<>>), do: true
  defp do_valid?(_str), do: false
end

defmodule BulkMatch512 do
  defguardp is_inner_byte(c) when c >= 128 and c < 192

  def valid?(str), do: do_valid?(str)
  defp do_valid?(<<a::512, rest::binary>>) when Bitwise.band(a, 0x80808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080808080) == 0, do: do_valid?(rest)
  defp do_valid?(<<a::8, rest::binary>>) when a < 128, do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, rest::binary>>) when a >= 192 and a < 224 and is_inner_byte(b), do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, c::8, rest::binary>>) when a >= 224 and a < 240 and is_inner_byte(b) and is_inner_byte(c), do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, c::8, d::8, rest::binary>>) when a >= 240 and is_inner_byte(b) and is_inner_byte(c) and is_inner_byte(d), do: do_valid?(rest)
  defp do_valid?(<<>>), do: true
  defp do_valid?(_str), do: false
end

defmodule BulkMatch64 do
  defguardp is_inner_byte(c) when c >= 128 and c < 192

  def valid?(str), do: do_valid?(str)
  defp do_valid?(<<a::64, rest::binary>>) when Bitwise.band(a, 0x8080808080808080) == 0, do: do_valid?(rest)
  defp do_valid?(<<a::8, rest::binary>>) when a < 128, do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, rest::binary>>) when a >= 192 and a < 224 and is_inner_byte(b), do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, c::8, rest::binary>>) when a >= 224 and a < 240 and is_inner_byte(b) and is_inner_byte(c), do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, c::8, d::8, rest::binary>>) when a >= 240 and is_inner_byte(b) and is_inner_byte(c) and is_inner_byte(d), do: do_valid?(rest)
  defp do_valid?(<<>>), do: true
  defp do_valid?(_str), do: false
end

defmodule BulkMatch32 do
  defguardp is_inner_byte(c) when c >= 128 and c < 192

  def valid?(str), do: do_valid?(str)
  defp do_valid?(<<a::32, rest::binary>>) when Bitwise.band(a, 0x80808080) == 0, do: do_valid?(rest)
  defp do_valid?(<<a::8, rest::binary>>) when a < 128, do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, rest::binary>>) when a >= 192 and a < 224 and is_inner_byte(b), do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, c::8, rest::binary>>) when a >= 224 and a < 240 and is_inner_byte(b) and is_inner_byte(c), do: do_valid?(rest)
  defp do_valid?(<<a::8, b::8, c::8, d::8, rest::binary>>) when a >= 240 and is_inner_byte(b) and is_inner_byte(c) and is_inner_byte(d), do: do_valid?(rest)
  defp do_valid?(<<>>), do: true
  defp do_valid?(_str), do: false
end

defmodule Cowboy do
  def valid?(str), do: validate_utf8(str, 0) == 0

  defp validate_utf8(<<>>, state), do: state
  defp validate_utf8(<<c::8, rest::bits>>, 0) when c < 128, do: validate_utf8(rest, 0)
  defp validate_utf8(<<c::8, rest::bits>>, 2) when c >= 128 and c < 144, do: validate_utf8(rest, 0)
  defp validate_utf8(<<c::8, rest::bits>>, 3) when c >= 128 and c < 144, do: validate_utf8(rest, 2)
  defp validate_utf8(<<c::8, rest::bits>>, 5) when c >= 128 and c < 144, do: validate_utf8(rest, 2)
  defp validate_utf8(<<c::8, rest::bits>>, 7) when c >= 128 and c < 144, do: validate_utf8(rest, 3)
  defp validate_utf8(<<c::8, rest::bits>>, 8) when c >= 128 and c < 144, do: validate_utf8(rest, 3)
  defp validate_utf8(<<c::8, rest::bits>>, 2) when c >= 144 and c < 160, do: validate_utf8(rest, 0)
  defp validate_utf8(<<c::8, rest::bits>>, 3) when c >= 144 and c < 160, do: validate_utf8(rest, 2)
  defp validate_utf8(<<c::8, rest::bits>>, 5) when c >= 144 and c < 160, do: validate_utf8(rest, 2)
  defp validate_utf8(<<c::8, rest::bits>>, 6) when c >= 144 and c < 160, do: validate_utf8(rest, 3)
  defp validate_utf8(<<c::8, rest::bits>>, 7) when c >= 144 and c < 160, do: validate_utf8(rest, 3)
  defp validate_utf8(<<c::8, rest::bits>>, 2) when c >= 160 and c < 192, do: validate_utf8(rest, 0)
  defp validate_utf8(<<c::8, rest::bits>>, 3) when c >= 160 and c < 192, do: validate_utf8(rest, 2)
  defp validate_utf8(<<c::8, rest::bits>>, 4) when c >= 160 and c < 192, do: validate_utf8(rest, 2)
  defp validate_utf8(<<c::8, rest::bits>>, 6) when c >= 160 and c < 192, do: validate_utf8(rest, 3)
  defp validate_utf8(<<c::8, rest::bits>>, 7) when c >= 160 and c < 192, do: validate_utf8(rest, 3)
  defp validate_utf8(<<c::8, rest::bits>>, 0) when c >= 194 and c < 224, do: validate_utf8(rest, 2)
  defp validate_utf8(<<224::8, rest::bits>>, 0), do: validate_utf8(rest, 4)
  defp validate_utf8(<<c::8, rest::bits>>, 0) when c >= 225 and c < 237, do: validate_utf8(rest, 3)
  defp validate_utf8(<<237::8, rest::bits>>, 0), do: validate_utf8(rest, 5)
  defp validate_utf8(<<c::8, rest::bits>>, 0) when c == 238 and c == 239, do: validate_utf8(rest, 3)
  defp validate_utf8(<<240::8, rest::bits>>, 0), do: validate_utf8(rest, 6)
  defp validate_utf8(<<c::8, rest::bits>>, 0) when c == 241 and c == 242 and c == 243, do: validate_utf8(rest, 7)
  defp validate_utf8(<<244::8, rest::bits>>, 0), do: validate_utf8(rest, 8)
  defp validate_utf8(_, _), do: 1
end

Benchee.run(
  %{
    "old" => fn input -> String.valid?(input) end,
    "cowboy" => fn input -> Cowboy.valid?(input) end,
    "32" => fn input -> BulkMatch32.valid?(input) end,
    "1024" => fn input -> BulkMatch1024.valid?(input) end,
    "512" => fn input -> BulkMatch512.valid?(input) end,
  },
  time: 10,
  memory_time: 2,
  inputs: %{
    "micro" => String.duplicate("a", 10),
    "medium" => String.duplicate("a", 10_002),
  }
)

##### With input medium #####
Name             ips        average  deviation         median         99th %
1024         99.56 K       10.04 μs   ±100.61%        9.58 μs       21.96 μs
512          99.11 K       10.09 μs    ±91.80%        9.75 μs       14.17 μs
old          34.32 K       29.14 μs    ±20.36%       28.75 μs       35.04 μs
32           32.79 K       30.50 μs    ±14.86%       30.17 μs       35.22 μs
cowboy       17.79 K       56.22 μs    ±10.55%       55.75 μs       73.99 μs

Comparison:
1024         99.56 K
512          99.11 K - 1.00x slower +0.0461 μs
old          34.32 K - 2.90x slower +19.09 μs
32           32.79 K - 3.04x slower +20.45 μs
cowboy       17.79 K - 5.60x slower +46.18 μs

Memory usage statistics:

Name      Memory usage
1024           11264 B
512            11888 B - 1.06x memory usage +624 B
old              656 B - 0.06x memory usage -10608 B
32               656 B - 0.06x memory usage -10608 B
cowboy           656 B - 0.06x memory usage -10608 B

**All measurements for memory usage were the same**

##### With input micro #####
Name             ips        average  deviation         median         99th %
old           2.80 M      356.65 ns ±11605.38%         250 ns         417 ns
32            2.78 M      360.32 ns ±11340.30%         250 ns         417 ns
cowboy        2.57 M      388.62 ns ±10957.31%         291 ns         458 ns
512           2.47 M      405.04 ns ±10510.44%         292 ns         458 ns
1024          2.45 M      407.58 ns ±10235.15%         292 ns         458 ns

Comparison:
old           2.80 M
32            2.78 M - 1.01x slower +3.67 ns
cowboy        2.57 M - 1.09x slower +31.98 ns
512           2.47 M - 1.14x slower +48.39 ns
1024          2.45 M - 1.14x slower +50.93 ns

Memory usage statistics:

Name      Memory usage
old              656 B
32               656 B - 1.00x memory usage +0 B
cowboy           656 B - 1.00x memory usage +0 B
512              656 B - 1.00x memory usage +0 B
1024             656 B - 1.00x memory usage +0 B

**All measurements for memory usage were the same**

I'm not sure that the improvements to runtime are worth the tradeoff on memory; I think I'm going to leave UTF-8 detection alone for now.

I'm not sure that the improvements to runtime are worth the tradeoff on memory; I think I'm going to leave UTF-8 detection alone for now.

In the medium case it was faster, wasn't it? Could you use this only for cases where the gain is certain?

I'm not sure that the improvements to runtime are worth the tradeoff on memory; I think I'm going to leave UTF-8 detection alone for now.

In the medium case it was faster, wasn't it? Could you use this only for cases where the gain is certain?

It's much faster (about 3x). Unfortunately it's also about 20x more memory intensive.

It's much faster (about 3x). Unfortunately it's also about 20x more memory intensive.

Suggestion. Again it might be a case of letting the user choose via configuration how he wants this to behave.


Interesting OpenAPI extensions

Here are some extensions which are interesting:

x-visibility and x-status
x-unofficialSpec
x-logo and another x-logo
x-summary and x-description for Path Item objects
x-codeSamples and Readme's version
x-contracts

x-logo is mostly supported as of b33736fdd65b7be2f830dc96546a347fe2cb61b8 (we've defined our own version with a path field, background colour and etc is todo).


Do not patch PLT stubs for MallocStackLogging in MacOS

MacOS has some memory interposition libraries that can make us crash
(via stackoverflow when initializing TLS variables) if we patch them.
This is because these libraries interact in a way we cannot avoid with
libdyld, which in turn sets the TLS on first init.
Closes: #476

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

Comparison is base (c016ce5) 91.97% compared to head (0bd8479) 92.15%.
Report is 19 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #477      +/-   ##
==========================================
+ Coverage   91.97%   92.15%   +0.18%
==========================================
  Files          91       91
  Lines       10803    10849      +46
  Branches     1485     1498      +13
==========================================
+ Hits         9936     9998      +62
+ Misses        865      849      -16
  Partials        2        2

Flag
Coverage Δ

cpp
85.68% <ø> (+0.45%)
:arrow_up:

python_and_cython
95.44% <ø> (+0.02%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 16 files with indirect coverage changes

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


Unable to import module '_warmup/index'

Hi. So I installed the plugin<EMAIL_ADDRESS>for<EMAIL_ADDRESS>using
plugins:
  - serverless-plugin-warmup

custom:
  warmup:
    prewarm: true
    schedule: 'rate(10 minutes)'

provider:
  # ...
  iamRoleStatements:
    - Effect: Allow
      Action:
        - lambda:InvokeFunction
      Resource:
      - Fn::Join:
        - ':'
        - - arn:aws:lambda
          - Ref: AWS::Region
          - Ref: AWS::AccountId
          - function:${self:service}-${opt:stage, self:provider.stage}-*
  # ...

deployment works
lambda is created and named {service}-{environment}warmup-plugin (not the same as README.md states, but close enough)
cloudwatch timer is created successfully
When the warmup lambda is triggered, it fails with various flavours of

Unable to import module '_warmup/index': Error
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)

None of the other functions in my project are Node, so I'm not sure whether there's a step missing from the setup that's causing this.

Hi @TrentBartlem.
Thanks for reporting the issue.
Well I had a read and actually there is a typo on the * iamRoleStatements* since last version due to a change on the default service name. The invoke function name must match with the default warmup function name. I will be fixing this.
That import module is strange, something looks wrong with your function executable path.
Could you go to the Lambda console and share  the index warmup path here.

Looks like it's a packaging issue. Since the other functions are Java8, I set
package:
  artifact: build/distributions/foo-service.zip

since that seems to be A Thing for java lambdas.
After removing the packaging declaration, the warmup service started working correctly (but all the other ones broke, as you'd expect)
i wonder if this could be avoided by the plugin setting the warmup lambda to
package:
      individually: true

I always use individual packaging to avoid boilerplate from other functions but I have tried without and it works fine. I don't see why runtime would be an issue, since the packaging all happens within SLS.
Question, is the warmup in that package artifact? If you are pointing to your own artifact file then the warmup must be inside that zip.

It's not in the artifact, since it's a Java project that doesn't use sls
packaging. Can the plug in specify individual packaging for its lambda?
On Thu, Jun 22, 2017, 7:14 PM Gonçalo Neves<EMAIL_ADDRESS>wrote:

I always use individual packaging to avoid boilerplate from other
functions but I have tried without and it works fine. I don't see why
runtime would be an issue, since the packaging all happens within SLS.
Question, is the warmup in that package artifact? If you are pointing to
your own artifact file then the warmup must be inside that zip.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/FidelLimited/serverless-plugin-warmup/issues/18#issuecomment-310324215,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKegiwL4Z9zXJretwA6iJrK3GOj9uFRks5sGjCJgaJpZM4OAUV7
.

Well you must find a way to have it inside your own package artifact.
When setting artifact you are stating that will be the file to be uploaded to all lambdas across your service, including warmup. But if you don't have warmup executable there... error.
Probably create your own plugin that merges and packages both warmup executable and your own java files hooking to serverless deploy events.
Since this is non related to Warmup plugin I will be closing.


Read and write slices to git-like subfolders

Closes #140
As it is currently implemented, the slice "12345" is put in the file "fragnix/slices/1/2/12345", i.e. the 12 prefix is not chopped off.
Since readSlice and writeSlice are not used anywhere, I renamed readSliceDefault and writeSliceDefault to readSlice and writeSlice.

I just noticed that we have to provide functionality for fragnix-browse.hs which recursively collects all slices..


Create a binary release in the nim-codex repo

Binary release to be create inside of the nim-codex repo. This binary will be downloaded by workshop participants to be used in the workshop.
I know this is going to bring up the versioning discussion. I remember that we had this discussion at some point in time regarding codex binary version vs REST api version vs network version (perhaps @AuHau you remember?)

Add Release workflow for Codex #749 - is that related or a successor?

Closing in favour of #749


chore: address Rust 1.71 clippy lints

Type of Change

[ ] Bugfix
[ ] New feature
[ ] Enhancement
[x] Refactoring
[ ] Dependency updates
[ ] Documentation
[ ] CI/CD

Description

This PR addresses a clippy lint stabilized in Rust 1.71.
Motivation and Context

N/A
How did you test it?

N/A
Checklist

[x] I formatted the code cargo +nightly fmt --all
[x] I addressed lints thrown by cargo clippy
[x] I reviewed submitted code
[ ] I added unit tests for my changes where possible
[ ] I added a CHANGELOG entry if applicable

Will be going ahead and merging this to unblock other PRs.


Need to lock releases during 'helm upgrade'

In Slack, @chancez asked a few questions that got me looking at the code. It appears that it may be possible to run two helm upgrade commands at very nearly the same time, and get a result that contains interleaved results.
One thing we can do to minimize this risk is modify performUpdate to lock a release (by name) when it starts the update, and unlock it when it completes. While we cannot ensure that that will fix all ordering issues (since really it's Kubernetes that is responsible for that), we can ensure that the manifests for a particular release are sent together in groups.
The same locks should be respected in rollback and delete.

I would like to give it a go