Add find function to List module

First of all, thanks to everyone for working on Elm! It's been a real pleasure working with it over the past few days. I'd love to contribute. To get my feet wet I decided to implement List.find which I needed several times on a pet project I'm working on. Let me know what you think.

To make sure we can handle these ideas in a scalable way we are doing this now. Going with that advice, the find function appears here if you need it!


Se refactor

Codecov Report

Merging #29 (5b9ef4b) into master (75ef945) will increase coverage by 14.88%.
The diff coverage is 91.95%.

@@             Coverage Diff             @@
##           master      #29       +/-   ##
===========================================
+ Coverage   79.69%   94.57%   +14.88%
===========================================
  Files           4        4
  Lines         197      166       -31
===========================================
  Hits          157      157
+ Misses         40        9       -31

Impacted Files
Coverage Δ

src/wenbo.jl
91.95% <91.95%> (ø)

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 75ef945...5b9ef4b. Read the comment docs.


Hey @wenhuwang, I see a signed commit now but there are other commits on the branch that are unsigned. Unfortunately those are still preventing merge. If you can squash to a single commit or sign them all, we can complete this 🙂

@rbtr  hello，it should be fine now?

thanks @wenhuwang! this will be in v0.0.5


docs: Variable default_cache_behavior is required if distribution is enabled

Description
The variable default_cache_behavior is required if distribution is enabled
Motivation and Context
Documentation does not mention this requirement.
https://github.com/terraform-aws-modules/terraform-aws-cloudfront/issues/123
Breaking Changes
No
How Has This Been Tested?
This is an update to the documentation and does not affect Terraform at all.

Not stale. Title updated.

@bryantbiggs Please review

I don't think we need this PR since it is always up to a user to determine the required variables and conditions. We do our best to show features in the examples.


challenage

Hello, I checked your contest docs, it shows that the RAM required for reasoning and fine-tuning is 34/35Gb, but I don't have that high graphics card, can I reduce the batch_size to reduce the amount of video memory required?

By the way, I only have a 4090, can I participate in the challenage？

It should be possible to use one 4090 if you reduce the batch_size.

Closing as no further response.


Create issues for all // ToDo: comments in the codebase and add linting rule to restrict them in future commits

There are currently 44 ToDos in the codebase, we would like to remove those and add a linter rule to further disallow future ToDos.

Hopefully some of these are stale and can be entirely removed


Missing reference to the lecture

Hey, I am trying to reference the lecture in my master thesis, but unfortunately the "Reference" page (https://compstat-lmu.github.io/lecture_i2ml/reference/index.html) is empty.
I guessed your desired format to look like this:
@misc{i2ml,
title   = "Introduction to Machine Learning (I2ML)",
author  = "B. Bischl and F. Scheipl and H. Seibold and L. Bothmann and D. Schalk and C. Molnar and T. Pielok",
journal = {https://github.com/compstat-lmu/lecture_i2ml},
year    = "2020",
url     = {https://introduction-to-machine-learning.netlify.app}
}
If you prefer a different one, please tell me.

Need to update authors

should be updated:
@misc{bischl22i2ml,
author = {Bischl, Bernd and Bothmann, Ludwig and Scheipl, Fabian and Pielok, Tobias and Wimmer, Lisa and Li, Yawei and Kolb, Chris and Schalk, Daniel and Seibold, Heidi and Molnar, Christoph and Richter, Jakob},
title = {{Introduction to Machine Learning (I2ML)}},
howpublished = "\url{https://slds-lmu.github.io/i2ml/}",
year = {2022},
note = "[Online; accessed yyyy-mm-dd]"
}


Conversion from 'AssemblyScript' to 'Value' for source type 'EthereumTuple' is not supported

When trying load in an ABI local file for a deployed contract, I get the following error:
Error: Conversion from 'AssemblyScript' to 'Value' for source type 'EthereumTuple' is not supported
    at findConversionFromType (/Users/brockelmore/.nvm/versions/node/v8.12.0/lib/node_modules/@graphprotocol/graph-cli/src/codegen/types/index.js:42:11)
    at valueTypeForAsc (/Users/brockelmore/.nvm/versions/node/v8.12.0/lib/node_modules/@graphprotocol/graph-cli/src/codegen/types/index.js:96:3)
    at ethereumTypeToGraphQL (/Users/brockelmore/.nvm/versions/node/v8.12.0/lib/node_modules/@graphprotocol/graph-cli/src/scaffold.js:89:10)
    at event.inputs.map (/Users/brockelmore/.nvm/versions/node/v8.12.0/lib/node_modules/@graphprotocol/graph-cli/src/scaffold.js:97:50)
    at Array.map (<anonymous>)
    at generateEventType (/Users/brockelmore/.nvm/versions/node/v8.12.0/lib/node_modules/@graphprotocol/graph-cli/src/scaffold.js:95:10)
    at Array.map (<anonymous>)
    at generateSchema (/Users/brockelmore/.nvm/versions/node/v8.12.0/lib/node_modules/@graphprotocol/graph-cli/src/scaffold.js:107:8)
    at generateScaffold (/Users/brockelmore/.nvm/versions/node/v8.12.0/lib/node_modules/@graphprotocol/graph-cli/src/scaffold.js:152:16)
    at withSpinner (/Users/brockelmore/.nvm/versions/node/v8.12.0/lib/node_modules/@graphprotocol/graph-cli/src/commands/init.js:529:28)

@brockelmore Good catch, I know what the problem is:
We do not support struct/tuple fields in the subgraph schema yet but if --from-contract sees an ABI that includes a tuple event parameter, it tries to create an event entity type with a struct/tuple field for that parameter.
We have a few options here, some more useful, some less:

Represent the type as a byte array. This would require the ability to encode structs in mappings, which isn't hard to do. It wouldn't be super useful from a user's perspective though.

Represent the struct/tuple as an inline object. This would require allowing non-entity object types in the schema (one for each struct) and supporting these in entity fields. This would be the most useful approach. It would require changes across the board (the tricky parts being the GraphQL execution that'll need to distinguish between inline objects and entity objects, as well as the AssemblyScript deserialization.). Should be doable though.

We'll look into it.

Awesome, glad I could point this out

There is a third option:
For any event parameter that is a struct, generate GraphQL fields like
type EventName @entity {
  paramName_structFieldName: BigInt!
  paramName_structFieldName_innerStructFieldName: Bytes!
}

So basically map any struct field like paramName.structFieldName to paramName_structFieldName, while also supporting nested structs.
This could be a decent solution for now; a longer term solution would be inline objects.

Are there any plans to support Solidity structs directly?


Add code linting

It'd be great to add some code linting to enforce consistent code style. I use the somewhat-controversial Standard for Helmet, but I think some ESLint-derived code linting would be helpful.
Happy to help discuss what lint setup to use and am happy to make a pull request to add it!

Yeah, I'm open to this! I've used jshint in the past, however I am far from an authority about best practices with linting. @EvanHahn, your input (as well as PR contributions) are welcome.

Personally, I like Standard because it requires no configuration. Would you be okay with that?


RFC: REST Api's for Remote Management for IIS Based Deployments

This is mostly a clarification item, or up for discussion.
We are managing a number servers where we use KUDU for deployments (mainly a load balancing thing, we don't work with more than a few web applications, there is multiple environments to be managed pr. app though so simple sync between all kuduservers is not possible), what we wish to do is manage all of these servers from a central location as well as pull information out of KUDU remote.
When it comes to applications, this is fairly supported out of the box, we can fetch and trigger deployments etc... But when it comes to KUDU Web it self, the management of applications it self seems to go though regular MVC controllers.
What I wish to do is expose many of the features used in KUDU Web as REST services as well, like creating kudu applications and getting existing ones etc.
I have to ways to do this as I see it...
A) Implement it in the the core of KUDU Web, giving a PR at some point to allow others to use the same API if they wish ( When ready, the management tool I am building will be open sourced as well ) This would be the most clean solution and it would allow others to do the same.
B) Implement it on the side in it's own project that is not part of KUDU, but which integrates some of the kudu core libraries. This would be more work and it would probably be more difficult to manage over time (keeping in sync with KUDU)... I also can't figure out if it would be stepping on KUDU's toes a bit... Regardless it would be less useable to the public as I see it.
Now Questiong being, how would the KUDU team react to having such a REST api available, would it be something they would be all for, all against or something in between?... And is there perhaps alternatives out there that I have overlooked?

I would not object to having a Kudu.Web API for this. Any thoughts from others?

That seems like a fine feature to have.

Sounds great. I already have a Preliminary implementation, not one that is super ideal but I can't seem to get WebAPI controller to react in a more truly verb based manner in the KUDU Web project...
That means the url's won't be what I had envisioned...
Right now I have another PR (https://github.com/projectkudu/kudu/pull/1527) hanging which kind of blocks any further work on this one, but as we are in a test phase atm. I won't have the time either.
Branch is available here: https://github.com/jeme/kudu/tree/KuduWeb_Rest_endpoints
For initial work...

Just adding this for documenting it somewhere for now.
Endpoints for managing applications
GET /api/applications
Returns a list of applications

POST /api/applications/{name}
Creates a new Application, returns the application object.

DELETE /api/applications/{name}
Deletes an Application.

Endpoints for managing a single application configuration
GET /api/application/{name}
Returns details about an application, bindings etc.

POST /api/application/{name}/addbinding
Payload: { sitetype: "live|service", port: number, ip: string, host: string, certificate: string, sni: bool }
Adds a new binding to the application

POST /api/application/{name}/removebinding
Payload: { sitetype: "live|service", port: number, ip: string, host: string, certificate: string, sni: bool }
Removes a binding from the application

Jens, I must apologize for the slow responses on your PRs, as so many other things are going on on our side. But we'll get to them!

@davidebbo Thats quite ok, as I said, I/We are also very busy up until and past 1. of June.
As for the change in the PR I mentioned, that is a fix for one of the issues where you mentioned me, it makes a much sense for a REST API as well though, with some further refining, so I think I will look more into it as part of what I end up with here...
I am still SUPER annoyed that I can't get Verb based methods to work as I am otherwise use to...
GET /api/applications
-> OK

POST /api/applications/add/{name}
 - > Would have liked that to be: POST /api/applications/{name}

DELETE /api/applications/delete/{name}
 - > Would have liked that to be: DELETE /api/applications/{name}

Hi
Kudu will continue to run in Azure App Service. However, this repo will no longer be maintained.
If the problem persists and is related to running on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service


deploy-cloud, base config: add explicit deployment config to build stage-stable and stage-beta both from master

npm run deploy reads the current branch name (in cloud mode) and decides to build a beta version when the branch is master
but since #2308, we're deploying to stage-stable as well, leading to issues on stage-stable:
Loading chunk 849 failed. (error: https://console.stage.redhat.com/beta/apps/automation-hub/js/849.1661953046888.a80f84b3e77abc4bde6d.js)

=> adding a HUB_CLOUD_BETA env var to override the autodetection,
and building with HUB_CLOUD_BETA=true for stage-beta, HUB_CLOUD_BETA=false for stage-stable,
and no override for prod builds, as before.
(and moving the npm run deploy call to custom_release.sh so we can run it twice from master)

Cc @awcrosby @Hyperkid123
This should fix stage-stable deploys.. I hope :)


Here's a couple of things we might want to document:
How to clone your fork onto your computer
git clone https://github.com/USERNAMEFood-Pantry-Inventory.git
How to add the main w-a-r-m-inventory-system/Food-Pantry-Inventory repository on your computer so you can pull changes from the main repo into your fork.
git remote add upstream https://github.com/w-a-r-m-inventory-system/Food-Pantry-Inventory.git

Hi John,
Please look at the document “Git Guidelines.rst” in the docs folder.
If this seems inadequate for describing how to do these activities,
please help us improve this document.
Thanks,
Travis
On 1 Mar 2019, at 23:18, John Cassidy wrote:

Here's a couple of things we might want to document:
How to clone your fork onto your computer
git clone https://github.com/USERNAMEFood-Pantry-Inventory.git
How to add the main w-a-r-m-inventory-system/Food-Pantry-Inventory
repository on your computer so you can pull changes from the main repo
into your fork.
git remote add upstream  https://github.com/w-a-r-m-inventory-system/Food-Pantry-Inventory.git
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w-a-r-m-inventory-system/Food-Pantry-Inventory/issues/12

Setup instructions for PyCharm  include instructions for setting up the main repository as a remote repository.


Unify returned tuples

Always return two-items tuple as result {:ok, result} or {:error, "message"} or {:error, {:validation, {...}}.

Hi, thanks for fast changes!
Notice that you should be able to return error from inside of operation, not only on validation error. Sometimes even when validation passes, something else can break. Now when I return {:error, "Can't find user"} operation return `{:ok, {:error, "Can't find user"}} witch is bad.
I think process function should always return tuple {:ok, ...} or {:error, ...}.
Maybe behaviours is good way to implement it ?

Thanks for response.
I understand your requirement. You are talking about behaviour-based restrictions for the code within process/1 the return types. Personally I don't like {:ok, :ok} too, but Behaviors don't guarantee the code will return either :ok or :error as we expect (we should treat everything except :ok as :error, is it good?). I mean, if passed params passed the contract and process/1 was invoked successfully it is {:ok, result} (whatever result is), {:error, reasons} otherwise (except exceptions during invocation). Anyway, I'll think about it, for sure. If I didn't understand you correctly, you can propose PR, we'll review it.

"we should treat everything except :ok as :error, is it good?" I think this is the main question, actually

Oops


Release to PyPI

Would be useful to have the TLS fix as an official PyPI release.

Good point. I'll make a new release ASAP.

https://github.com/django-salesforce/django-salesforce/tree/0.6.3


Using calculate_frechet_distance.py, The FID between  cifar-10 and the standard npz provided by TTUR, the FID is 15. Any idea why?

Using calculate_frechet_distance.py, The FID between  cifar-10 and the standard npz provided by TTUR, the FID is 15. Any idea why?

Can you compute the FID using the TTUR codebase on the same set of inputs? Just to see if it actually results in zero as one might expect.

Any update on this?


change SLOAD to MLOAD

Motivation
Reading a state variable costs more gas than reading a local variable. In the following example, function assignOperator0 costs 89 more gases than assignOperator.
contract LibDemo {
    address public operator;

    event OperatorUpdated(address newOperator);

    function assignOperator0(address operatorToAssign) external {
         // Set the given address as the new operator.
        operator = operatorToAssign;

        // Emit an event indicating the operator has been updated.
        emit OperatorUpdated(operator);
    }

    function assignOperator(address operatorToAssign) external {
         // Set the given address as the new operator.
        operator = operatorToAssign;

        // Emit an event indicating the operator has been updated.
        emit OperatorUpdated(operatorToAssign);
    }
}

Solution
If a state variable is read immediately after assignment, then replacing this read directly with the previously assigned local variable will change one SLOAD to one MLOAD to save some gases.

@0age Can you take a look at this pull request?

Codecov Report
Base: 100.00% // Head: 100.00% // No change to project coverage :thumbsup:

Coverage data is based on head (afbbc0e) compared to base (e4c6e7b).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #685   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           45        45
  Lines         1917      1917
  Branches       322       322
=========================================
  Hits          1917      1917

Flag
Coverage Δ

production
100.00% <100.00%> (ø)

reference
100.00% <ø> (ø)

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

Impacted Files
Coverage Δ

contracts/zones/PausableZone.sol
100.00% <100.00%> (ø)

contracts/zones/PausableZoneController.sol
100.00% <100.00%> (ø)

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

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


Possible runtime error / incremental compilation bug?

Hi there,
I'm not sure how it works internally, but for me when I update one file it doesn't seem to recompile files where I use it. That leeds to a runtime error. I use Atom with elm-linter & elm-format on save. So it's important not to hit save on src/Finance.src after changes to src/AddForm.elm has been made.
To replicate:

Clone https://github.com/nLight/elm-finance/releases/tag/possible-bug
Compile, it works (clicking add button adds a new entry)
Update src/AddForm.elm:

--- a/src/AddForm.elm                                                                                [0/384]
+++ b/src/AddForm.elm
@@ -3,7 +3,6 @@ module AddForm exposing (Model, Msg, view, update)
 import Html exposing (..)
 import Html.Events exposing (onSubmit, onInput)
 import Html.Attributes exposing (type', value)
-import Platform.Cmd as Cmd exposing (none)
 import Maybe
 import String
 import Entry
@@ -24,25 +23,25 @@ type Msg
     | Submit

-update : Msg -> Model -> ( Model, Cmd Msg, Maybe Model )
+update : Msg -> Model -> ( Model, Maybe Model )
 update message model =
     case message of
         Submit ->
-            ( Entry.init, none, Just model )
+            ( Entry.init, Just model )

         Update Name value ->
-            ( { model | name = value }, none, Nothing )
+            ( { model | name = value }, Nothing )

         Update Date' value ->
-            ( { model | date = value }, none, Nothing )
+            ( { model | date = value }, Nothing )

         Update Price value ->
             case String.toFloat value of
                 Ok float ->
-                    ( { model | price = float }, none, Nothing )
+                    ( { model | price = float }, Nothing )

                 Err _ ->
-                    ( model, none, Nothing )
+                    ( model, Nothing )

 view : Model -> Html Msg

Recompile (compilation passes)
Clicking add button throws a runtime error.

I expect elm to recompile and check src/Finance.src when the file it imports changes.
I get TypeError: undefined is not an object (evaluating '_p1._2.ctor') because generated code still tries to fetch Maybe from a third argument which doesn't exist anymore:
function (message, model) {
	var _p0 = message;
	if (_p0.ctor === 'FormMsg') {
		var _p1 = A2(_user$project$AddForm$update, _p0._0, model.form);
		if (_p1._2.ctor === 'Just') { // <==== Error happens here
			var newSheet = A2(_user$project$Sheet$add, _p1._2._0, model.sheet);
			return {
				ctor: '_Tuple2',
				_0: _elm_lang$core$Native_Utils.update(
					model,
					{form: _p1._0, sheet: newSheet}),
				_1: _elm_lang$core$Platform_Cmd$none
			};
		} else {
			return {
				ctor: '_Tuple2',
				_0: _elm_lang$core$Native_Utils.update(
					model,
					{form: _p1._0}),
				_1: _elm_lang$core$Platform_Cmd$none
			};
		}
	} else {
		return {
			ctor: '_Tuple2',
			_0: _elm_lang$core$Native_Utils.update(
				model,
				{
					sheet: A2(_user$project$Sheet$update, _p0._0, model.sheet)
				}),
			_1: _elm_lang$core$Platform_Cmd$none
		};
	}
});

This is a known issue of elm-make, and there is already a report of it in the elm-make GitHub repository.

Thanks @jvoigtlaender !


Add accelerated fallbacks and use them

Add functions contain fallbacks to accelerate epi8 mask and maskz intrinsics without native support.
The 128-bit and 256-bit versions are in avx512vl.h but they are useful for me in avx512bw.h.
So make them simde_x_ in avx512bw.h and just call them in avx512vl.h.
Add the following intrinsics
_mm512_mask_add_epi8
_mm512_maskz_add_epi8
_mm512_mask_adds_epi8
_mm512_maskz_adds_epi8
_mm512_mask_adds_epu8
_mm512_maskz_adds_epu8
_mm512_mask_shuffle_epi8
_mm512_maskz_shuffle_epi8
_mm512_cmpge_epi8_mask
_mm512_cmpge_epu8_mask
_mm512_cmpgt_epi8_mask
_mm512_cmpgt_epu8_mask
_mm512_cmple_epi8_mask
_mm512_cmple_epu8_mask
_mm512_cmplt_epi8_mask
_mm512_cmplt_epu8_mask

I executed the Travis-CI tests successfully in my fork as Evan suggested.
I have concentrated on the mask conversions for epi8 because they are the most time-consuming (and this is also the case in which I am most interested).
If these are accepted, I shall do similar conversions for epi16, epi32, epi64, ps and pd cases.

Definite yes to the basic idea.  I'd think it can be a bit simpler, though..
I recently changed the preprocessor macros for feature detection for exactly this reason.  All that stuff is now in simde-features.h, so no matter where you are in the codebase you should have access to the right macro to detect which features you're allowed to use.  So, you don't need to put them in simde_x_*… just so you don't conflict with a version from a later ISA extension.
I don't think there is a need to be overly strict about functions being in the same file as the ISA extension they're part of.  As long as, for example, #including "avx512vl.h" pulls in all the AVX-512VL functions we're good, and avx512vl.h already includes avx512bw.h.
So, for example, something like this should go in avx512bw.h (or even in avx512f.h if there is something there which could make use of them):
SIMDE__FUNCTION_ATTRIBUTES
simde__m128i
simde_mm_movm_epi8 (simde__mmask16 k) {
  #if defined(SIMDE_X86_AVX512VL_NATIVE) && defined(SIMDE_X86_AVX512BW_NATIVE)
    return _mm_movm_epi8(k);
  #elif defined(SIMDE_X86_SSSE3_NATIVE)
    const simde__m128i zero = simde_mm_setzero_si128();
    const simde__m128i bits = simde_mm_set_epi16(0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80);
    const simde__m128i shuffle = simde_mm_set_epi8(15, 13, 11, 9, 7, 5, 3, 1, 14, 12, 10, 8, 6, 4, 2, 0);
    simde__m128i r;

    r = simde_mm_set1_epi16(HEDLEY_STATIC_CAST(short, k));
    r = simde_mm_mullo_epi16(r, bits);
    r = simde_mm_shuffle_epi8(r, shuffle);
    r = simde_mm_cmpgt_epi8(zero, r);

    return r;
  #else
    simde__m128i_private r_;

    SIMDE__VECTORIZE
    for (size_t i = 0 ; i < (sizeof(r_.i8) / sizeof(r_.i8[0])) ; i++) {
      r_.i8[i] = ((k >> i) & 1) ? INT8_C(0xFF) : INT8_C(0);
    }

    return simde__m128i_from_private(r_);
  #endif
}

(Note that I also added the native implementation, and changed the macros to SIMDE_X86_*_NATIVE to match the new feature detection code.)
That should let us use the fastest available implementation everywhere.
As a side note, thanks for pointing out the movm functions.  I didn't know those existed, I'm going to want to refactor some stuff in SIMDe to make use of them.
We're going to need test cases for all these functions before they are merged; if you'd like I can take care of that, or maybe @himanshi18037 would be interested (she has been adding a ton of tests latelly that Michael noticed were missing).
Other than that, I only see a couple very minor nit-picks in the code.  There is a note in simde_mm512_cmpgt_epi8_mask about using Hedley for the cast; please do.  I should really add -Wold-style-casts to the CXXFLAGS for clang to prevent these from creeping in, as I too have a tendency to use C-style casts.  Also, you use 1ULL in a couple places; that should probably be UINT64_C(1) if it's really a 64-bit unsigned integer (which is what __mmask64 is) that you want.

Definite yes to the basic idea. I'd think it can be a bit simpler, though..
I recently changed the preprocessor macros for feature detection for exactly this reason. All that stuff is now in simde-features.h, so no matter where you are in the codebase you should have access to the right macro to detect which features you're allowed to use. So, you don't need to put them in simde_x_*… just so you don't conflict with a version from a later ISA extension.
I don't think there is a need to be overly strict about functions being in the same file as the ISA extension they're part of. As long as, for example, #including "avx512vl.h" pulls in all the AVX-512VL functions we're good, and avx512vl.h already includes avx512bw.h.

OK. Unfortunately I made the extra effort to avoid putting the real version in the wrong header file :-(

So, for example, something like this should go in avx512bw.h (or even in avx512f.h if there is something there which could make use of them):
SIMDE__FUNCTION_ATTRIBUTES
simde__m128i
simde_mm_movm_epi8 (simde__mmask16 k) {
  #if defined(SIMDE_X86_AVX512VL_NATIVE) && defined(SIMDE_X86_AVX512BW_NATIVE)
    return _mm_movm_epi8(k);
  #elif defined(SIMDE_X86_SSSE3_NATIVE)
    const simde__m128i zero = simde_mm_setzero_si128();
    const simde__m128i bits = simde_mm_set_epi16(0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80);
    const simde__m128i shuffle = simde_mm_set_epi8(15, 13, 11, 9, 7, 5, 3, 1, 14, 12, 10, 8, 6, 4, 2, 0);
    simde__m128i r;

    r = simde_mm_set1_epi16(HEDLEY_STATIC_CAST(short, k));
    r = simde_mm_mullo_epi16(r, bits);
    r = simde_mm_shuffle_epi8(r, shuffle);
    r = simde_mm_cmpgt_epi8(zero, r);

    return r;
  #else
    simde__m128i_private r_;

    SIMDE__VECTORIZE
    for (size_t i = 0 ; i < (sizeof(r_.i8) / sizeof(r_.i8[0])) ; i++) {
      r_.i8[i] = ((k >> i) & 1) ? INT8_C(0xFF) : INT8_C(0);
    }

    return simde__m128i_from_private(r_);
  #endif
}

(Note that I also added the native implementation, and changed the macros to SIMDE_X86_*_NATIVE to match the new feature detection code.)
That should let us use the fastest available implementation everywhere.

Oops, sorry I left out the _X86 in the macros.
Incidentally, for this reason personally I hate using #if defined(x).
I obviously followed your practice but I prefer #if x (with x defined to 1 or 0), which, with the -Wundef compilation flag, throws a warning if you misspell the name of the macro.
As for the test whether the real intrinsic can simply be used, I used to do it like this inside the function as seemed to me to be common practice, but you told me to put it outside and after the function.
(Sorry, I can no longer find where you wrote this.)

We're going to need test cases for all these functions before they are merged; if you'd like I can take care of that, or maybe @himanshi18037 would be interested (she has been adding a ton of tests latelly that Michael noticed were missing).

Which test cases were missing? I thought I had covered all the intrinsics I added.

Other than that, I only see a couple very minor nit-picks in the code. There is a note in simde_mm512_cmpgt_epi8_mask about using Hedley for the cast; please do. I should really add -Wold-style-casts to the CXXFLAGS for clang to prevent these from creeping in, as I too have a tendency to use C-style casts. Also, you use 1ULL in a couple places; that should probably be UINT64_C(1) if it's really a 64-bit unsigned integer (which is what __mmask64 is) that you want.

Sorry, I think I just copied the code with 1ULL from an existing example.

Incidentally, for this reason personally I hate using #if defined(x).
I obviously followed your practice but I prefer #if x (with x defined to 1 or 0), which, with the -Wundef compilation flag, throws a warning if you misspell the name of the macro.

Yeah, I do that sometimes but I don't like the inconsistency.  You generally need to use defined() when interfacing with other code, so you end up with a mix of both ways, then you have to remember which code works which way.

As for the test whether the real intrinsic can simply be used, I used to do it like this inside the function as seemed to me to be common practice, but you told me to put it outside and after the function.
(Sorry, I can no longer find where you wrote this.)

I don't have the link handy, but it was probably when were were discussing something like:
#if SIMDE_X86_FOO_NATIVE
  #define simde_mm_foo(x) _mm_foo(x, imm8)
#else
  void simde_mm_foo(simde__m128 x, int imm8) {
    ...
  }
#endif

Inside the function is preferable, but outside the function is the only option if there is an immediate-mode argument.  For a lot of compilers you can't even use compile time constants (in the __builtin_constant_p() sense), they actually have to be integer constant expressions.  In that case, for SIMDe the convention a function-like macro after the function is declared.
If you want to just leave it as-is I don't mind fixing it up when I merge.

We're going to need test cases for all these functions before they are merged; if you'd like I can take care of that, or maybe @himanshi18037 would be interested (she has been adding a ton of tests latelly that Michael noticed were missing).

Which test cases were missing? I thought I had covered all the intrinsics I added.

Maybe you forgot to add avx512vl.c to the PR?

Other than that, I only see a couple very minor nit-picks in the code. There is a note in simde_mm512_cmpgt_epi8_mask about using Hedley for the cast; please do. I should really add -Wold-style-casts to the CXXFLAGS for clang to prevent these from creeping in, as I too have a tendency to use C-style casts. Also, you use 1ULL in a couple places; that should probably be UINT64_C(1) if it's really a 64-bit unsigned integer (which is what __mmask64 is) that you want.

Sorry, I think I just copied the code with 1ULL from an existing example.

Do you want me to perform these modifications or will you do it prior to merging?

I can take care of it, unless they're in your way in which case feel free.

As for the test whether the real intrinsic can simply be used, I used to do it like this inside the function as seemed to me to be common practice, but you told me to put it outside and after the function.
(Sorry, I can no longer find where you wrote this.)

I don't have the link handy, but it was probably when were were discussing something like:
#if SIMDE_X86_FOO_NATIVE
  #define simde_mm_foo(x) _mm_foo(x, imm8)
#else
  void simde_mm_foo(simde__m128 x, int imm8) {
    ...
  }
#endif

Inside the function is preferable, but outside the function is the only option if there is an immediate-mode argument. For a lot of compilers you can't even use compile time constants (in the __builtin_constant_p() sense), they actually have to be integer constant expressions. In that case, for SIMDe the convention a function-like macro after the function is declared.

Sorry I completely misunderstood you on this.
I thought you wanted me to code like this systematically.
Which is what I did :-(
I imagined that your reason was that, like this, a bit more of the function was compile-tested.
I think that I pointed out at the time that it was different from common practice in SIMDe.
I even asked here https://github.com/nemequ/simde/pull/253#issuecomment-621735126 whether this coding style was what you expected.

If you want to just leave it as-is I don't mind fixing it up when I merge.

We're going to need test cases for all these functions before they are merged; if you'd like I can take care of that, or maybe @himanshi18037 would be interested (she has been adding a ton of tests latelly that Michael noticed were missing).

Which test cases were missing? I thought I had covered all the intrinsics I added.

Maybe you forgot to add avx512vl.c to the PR?

Probably I'll check.

Do you want me to perform these modifications or will you do it prior to merging?

I can take care of it, unless they're in your way in which case feel free.

I am not sure what time zone you are in. Are you in the USA? I am in Europe as is Michael, I think.
It is the morning for me so I could do it.
I am also slightly worried that with the _X86 modifications my fallbacks weren't tested: I was expecting endian problems but there weren't any, perhaps becaus my fallbacks weren't used.

Sorry I completely misunderstood you on this.
I thought you wanted me to code like this systematically.
Which is what I did :-(

Sorry I should have been clearer.  Again, if you want to just leave these as-is I don't mind making the changes so you can keep working on the more interesting bits.

I imagined that your reason was that, like this, a bit more of the function was compile-tested.
I think that I pointed out at the time that it was different from common practice in SIMDe.
I even asked here #253 (comment) whether this coding style was what you expected.

In this case it is what I was expecting; the imm8 argument to _mm512_slli_epi32 is supposed to be an immediate mode argument (hence "imm8").  OTOH, for _mm512_sll_epi32 it should go inside the function.  I don't know if compilers actually require it to be an immediate made argument (i.e., issue 267), but according to the IIG it should be.

Probably I'll check.
Edit: As I thought when I pushed, all my changes in avx512vl.h seem to be covered by existing tests in avx512vl.c. Can you see any that aren't covered?
/Edit

I don't see any of the movm functions.  simde_mm512_movm_epi8, for example.

I am not sure what time zone you are in. Are you in the USA? I am in Europe as is Michael, I think.
It is the morning for me so I could do it.

PDT (-0700).  I'm in San Diego.  Now it's morning ;)
I'll hold off until this is in so I don't create conficts.  If you want to add those changes as part of this PR go for it, otherwise I'll take care of it after I merge.

I am also slightly worried that with the _X86 modifications my fallbacks weren't tested: I was expecting endian problems but there weren't any, perhaps because my fallbacks weren't used.

You're right that the macros are wrong in gfni.h (I'll fix that it a couple minutes), but that doesn't really matter here since the only version that will ever run right now on BE are the portable fallbacks.  It will never fall back on, for example, SSE2, since SSE2 is only implemented on x86 which is only ever LE.  Additionally, the SIMDE_ARCH_* macros are still there and do the same thing as before.

I'm going to go ahead and merge everything and do all the cleanup I can now.  I may not merge it into master quite yet, but you should have a fresh, conflict-free branch in the morning to base future work on.

It looks like we are both working in my fork.
I must have forgotten to remove some of the stuff in avx512vl.h resulting in duplicates.
I don't know why this didn't show up in my local tests.
So I'll hold off for now.
I have already pushed several additions (mullo in AVX2 which I needed and missing movm tests) and corrections.

I must have forgotten to remove some of the stuff in avx512vl.h resulting in duplicates.

I think that was caused by a bad merge from me ; sorry!

The rosbif / simde merge branch just passed all the Travis-CI tests :-)

I merged most of this in one form or another.  The only exception I'm aware of several of the _mm512_cmp* implementations, which are wrong.
I also switched the headers so avx512bw.h includes avx512vl.h instead of the other way around.  See b84c9e4cdc0238d884f706ca23d491f3781aa876.
I'll leave this open in case you want to use it for the remaining comparison functions, but you may want to just close it and start a new one.

I merged most of this in one form or another. The only exception I'm aware of several of the _mm512_cmp* implementations, which are wrong.

Sorry.
Strange: I am sure that I cleaned these up. Maybe just in a local version (which I can no longer find).
I'll push corrections.

I also switched the headers so avx512bw.h includes avx512vl.h instead of the other way around. See b84c9e4.

NAK: unless you have reorganized the movm, mask_mov, and maskz_mov stuff, avx512vl.h needs them from avx512bw.h. So avx512vl.h must include avx512bw.h.

I'll leave this open in case you want to use it for the remaining comparison functions, but you may want to just close it and start a new one.

I think I prefer to leave it open.

NAK: unless you have reorganized the movm, mask_mov, and maskz_mov stuff, avx512vl.h needs them from avx512bw.h. So avx512vl.h must include avx512bw.h.

Not at all. The movm functions are in avx512vl.h.  See 0d3609ed99109ee6fd020d35120b9059d17031f6.  I also converted a lot of function-like macros to be calls inside of of their respective functions.  For example, where you had something
#if defined(SIMDE_X86_AVX512BW_NATIVE) && defined(SIMDE_X86_AVX512VL_NATIVE)
  #define simde_mm_mask_mov_epi8(src, k, a) _mm_mask_mov_epi8(src, k, a)
#else
  #define simde_mm_mask_mov_epi8(src, k, a) simde_mm_blendv_epi8(src, a, simde_mm_movm_epi8(k))
#endif
#if defined(SIMDE_X86_AVX512VL_ENABLE_NATIVE_ALIASES)
  #define _mm_mask_mov_epi8(src, k, a) simde_mm_mask_mov_epi8(src, k, a)
#endif

I just did
diff --git a/simde/x86/avx512vl.h b/simde/x86/avx512vl.h
index d35d20f..4fce874 100644
--- a/simde/x86/avx512vl.h
+++ b/simde/x86/avx512vl.h
@@ -122,8 +122,10 @@ simde_mm512_movm_epi8 (simde__mmask64 k) {
 SIMDE__FUNCTION_ATTRIBUTES
 simde__m128i
 simde_mm_mask_mov_epi8(simde__m128i src, simde__mmask16 k, simde__m128i a) {
-  #if defined(SIMDE_X86_AVX512VL_NATIVE)
+  #if defined(SIMDE_X86_AVX512VL_NATIVE) && defined(SIMDE_X86_AVX512BW_NATIVE)
     return _mm_mask_mov_epi8(src, k, a);
+  #elif defined(SIMDE_X86_SSE4_1_NATIVE)
+    return simde_mm_blendv_epi8(src, a, simde_mm_movm_epi8(k));
   #else
     simde__m128i_private
       src_ = simde__m128i_to_private(src),
@@ -138,7 +140,7 @@ simde_mm_mask_mov_epi8(simde__m128i src, simde__mmask16 k, simde__m128i a) {
     return simde__m128i_from_private(r_);
   #endif
 }

Here are the relevant commits:

0d3609ed99109ee6fd020d35120b9059d17031f6
5702c5a6a0a8d1380c95ded6f1886f304688beda
2b9751f70f1cac2dbf1e70e142b607c7b056e172
7ae207836b90f6be69ce0ef888cc39e4cdeb2711
27917ad33bd855834a118dee31d60f5b7a533fc2
b689653a0359c00e2bd068b7b41a62cfb9d77338
b3fa2c21ccdad9d6cae012914f27e56bdd1d16bf
c4f87426c50b92bc33b5dcef09abbaaaf5fbc609

If there are still changes you want to make (such as adding simde_mm512_cmple_epi8_mask, simde_mm512_cmple_epu8_mask, simde_mm512_cmplt_epi8_mask, and simde_mm512_cmplt_epu8_mask) you should rebase them on top of master (currently 1582d2f8c83c64cef0f0d37edd185b2d9f66a85b).
As a cosequence of reorganizing everything several minor issues, like incorrect macro names or the typo you fixed with dad33587f291bdd4b6011ff90fe057f4399bebb1, should disappear.

I think I prefer to leave it open.

Okay, in that case it would probably be best to force push to your "merge" branch after rebasing your changes on top of current master (or at least master post-c4f87426c50b92bc33b5dcef09abbaaaf5fbc609).  That way we'll be working from the same place.  If you want some help (IIRC you said you weren't particularly familiar with git) let me know and I can help you through the process on some kind of chat platform (Gitter or Signal maybe?), I don't think the issue tracker would be a good place only because it's not designed for a real-time back-and-forth.

OK, I'll trust you on the avx512bw.h vs avx512vl.h question.

If there are still changes you want to make (such as adding simde_mm512_cmple_epi8_mask, simde_mm512_cmple_epu8_mask, simde_mm512_cmplt_epi8_mask, and simde_mm512_cmplt_epu8_mask) you should rebase them on top of master (currently 1582d2f).

I am not sure what I should do. here
I pushed these updated cmp intrinsics to my fork about 9 hours ago.
From what you say I suppose you removed them before merging to master.
In that case I suppose you must also have removed their tests.

I think I prefer to leave it open.

(I only said that because I wanted to push the above cmp intrinsics before you closed everything.)

Okay, in that case it would probably be best to force push to your "merge" branch after rebasing your changes on top of current master (or at least master post-c4f87426c50b92bc33b5dcef09abbaaaf5fbc609). That way we'll be working from the same place. If you want some help (IIRC you said you weren't particularly familiar with git) let me know and I can help you through the process on some kind of chat platform (Gitter or Signal maybe?), I don't think the issue tracker would be a good place only because it's not designed for a real-time back-and-forth.

OK, I'll try to do this.

I am lost :-(
In master I find lots of e.g. SIMDE_X86_SSE2_NATIVE in avx512bw.h
I thought you had said to use SIMDE_ARCH_X86_SSE2.
I changed all mine to this style.
Have you reverted it?
I also see a SIMDE_X166_AVX512BW_NATIVE which is obviously a result of s/8/16/ :-(
Again if you used #if X instead of #if defined(X) this could be picked up on compilation.

In master I find lots of e.g. SIMDE_X86_SSE2_NATIVE in avx512bw.h
I thought you had said to use SIMDE_ARCH_X86_SSE2.
I changed all mine to this style.

There are three macros here:

SIMDE_ARCH_X86_SSE2
SIMDE_SSE2_NATIVE
SIMDE_X86_SSE2_NATIVE

SIMDE_ARCH_X86_SSE2 does the same thing it used to do, which is detecting what the compiler thinks is available (i.e., it's basically like __SSE2__ except it works on MSVC too).
To figure out which functionality we actually want to use in SIMDe you should use SIMDE_X86_SSE2_NATIVE, which uses SIMDE_ARCH_X86_SSE2 internally but can also be disabled by defining SIMDE_X86_SSE2_NO_NATIVE or SIMDE_NO_NATIVE or forcibly enabled by defininig SIMDE_X86_SSE2.  That's particulary important for MSVC, since for a lot of ISA extensions you can't actually tell the compiler to enable them, they're only available as explicit calls to the intrinsics in question.  SSE2 isn't a good example here (it's one MSVC does actually advertise in macros, by setting _M_IX86_FP >= 2), but for example there is no __SSSE3__ in MSVC.
Compounding the confusion is that it's a recent change.  Until May 2 SIMDE_ARCH_X86_SSE2 was usually the right macro to use outside of sse2.h (unless you were in sse3.h, for example, in which case there may have been a SIMDE_SSE3_SSE2), but inside of sse2.h it would have been SIMDE_X86_SSE2_NATIVE.
Take a quick look at simde-arch.h and simde-features.h, that should clear things up.  I don't know about you, but it's generally easier for me to just read the code than a description.  The new system is actually a lot simpler, which is why I made the changes.

Have you reverted it?

Kind of, it depends what you mean.  I didn't exactly revert anything.  I went through your patch and picked out the substantive changes which were correct, then integrated them into master.  That was something I didn't merge.

I also see a SIMDE_X166_AVX512BW_NATIVE which is obviously a result of s/8/16/ :-(

Yes, I'll fix that.

Again if you used #if X instead of #if defined(X) this could be picked up on compilation.

Yes, but it would also create a lot of inconsistencies, and if you want to write code where the definition may or may not exist (like because you may be using a library where you can't control which specific version of the library is available at compile time) you have to do something like
#if defined(FOO)
  #if FOO > X
    // use foo
  #endif
#endif

Since the preprocessor doesn't short-circuit defined(FOO) && (FOO > X) will cause a problem with -Wundef if FOO is not defined.  That makes chaining these conditions together difficult.  You trade one problem which is easy to fix for one that requires ugly worked arounds and you don't even fully solve the original problem since a lot of people don't bother with non-default warnings like -Wundef.
I get the argument for #if FOO > X, and if it weren't for the drawbacks I'd definitely switch.  However, when you factor in all the pros and cons of each approach I feel like defined/!defined is the ~better~ less bad option.

You don't seem to like me implementing intrinsics as macros, even when they are trivial.
(You changed several in avx512bw.h.)
Should I always use functions?

You don't seem to like me implementing intrinsics as macros, even when they are trivial.
(You changed several in avx512bw.h.)
Should I always use functions?

Yes.  The only time to use a macro are the native implementations of intrinsics with immediate mode arguments which compilers actually require to be compile time constants (IIG isn't trustworthy here).
Even if the x86 implementations are trivial, others may not be.  Putting them in functions means future patches are less intrusive (and less destructive of the git blame), and the consistency is nice.  Macros aren't good for type safety, are generally more error prone, harder for tooling, etc.  Really the only down side I can think of is that they're a bit more verbose, but I'd much rather the code be easy to read than quick to write.

I am not sure what I should do here
I pushed these updated cmp intrinsics to my fork about 9 hours ago.
From what you say I suppose you removed them before merging to master.
In that case I suppose you must also have removed their tests.

Sorry, I missed this paragraph earlier.
Yes, I dropped the tests since they only passed because they had incorrect values.  For example, you have #define simde_mm512_cmple_epu8_mask(a, b) simde_mm512_cmpge_epu8_mask(b, a) for the non-native version.  The tests match what you expect because they're based on the SIMDE_AVX512BW_NATIVE, which will never be defined, so it's always hitting the fallback path and calling cmpge instead of cmple.
I'll go ahead and add the missing functions and tests so we can close this PR, and you'll have a clean place to work from.  That way you don't have to worry about rebasing or anything.  I should have it done within the next couple hours.

The missing cmp functions are in master now, I think that's all the changes from this PR.
Thanks for the patch, sorry the merge process was so painful.

I also see a SIMDE_X166_AVX512BW_NATIVE which is obviously a result of s/8/16/ :-(

Yes, I'll fix that.
Edit: fixed with 4f2582c. I also added a check to CI to make sure it doesn't happen again.

Again if you used #if X instead of #if defined(X) this could be picked up on compilation.

Yes, but it would also create a lot of inconsistencies, and if you want to write code where the definition may or may not exist (like because you may be using a library where you can't control which specific version of the library is available at compile time) you have to do something like
#if defined(FOO)
  #if FOO > X
    // use foo
  #endif
#endif

Since the preprocessor doesn't short-circuit defined(FOO) && (FOO > X) will cause a problem with -Wundef if FOO is not defined. That makes chaining these conditions together difficult. You trade one problem which is easy to fix for one that requires ugly worked arounds and you don't even fully solve the original problem since a lot of people don't bother with non-default warnings like -Wundef.
I get the argument for #if FOO > X, and if it weren't for the drawbacks I'd definitely switch. However, when you factor in all the pros and cons of each approach I feel like defined/!defined is the ~better~ less bad option.

I didn't realize that defined(FOO) && (FOO > X) would throw a warning with -Wundef  if FOO is undefined. You very frequently see this construction in header files.
However I was considering  "binary" macros which would be either defined to 0 or to 1, like those we were talking about here.
These are purely for internal SIMDe  use and converting to the other style would allow developers who care to use -Wundef.
I realize that the two are incompatible and that, during a transition period, we would have to introduce a second macro with a slightly modified name.
Anyway I think we must agree to disagree on this one.
(I am old with failing memory and eyesight so I would appreciate anything the compiler can do to pick up my silly mistakes. This is also why I also suggested previously that run-tests should compile-test other code paths.)

Yes, I dropped the tests since they only passed because they had incorrect values. For example, you have #define simde_mm512_cmple_epu8_mask(a, b) simde_mm512_cmpge_epu8_mask(b, a) for the non-native version. The tests match what you expect because they're based on the SIMDE_AVX512BW_NATIVE, which will never be defined, so it's always hitting the fallback path and calling cmpge instead of cmple.

I don't understand you at all here :-(
What values were incorrect?
E.g. cmple calling cmpge with reversed arguments was deliberate.
(a <= b is equivalent to b >= a.)
It seemed more economical to introduce a macro to just call an existing function with reversed arguments than to write a new function.
But as you don't like me implementing intrinsics in macros the point is moot.

I didn't realize that defined(FOO) && (FOO > X) would throw a warning with -Wundef  if FOO is undefined. You very frequently see this construction in header files.

It might not be -Wundef, but I know there is an off-by-default warning that triggers it.  It's kind of annoying because IIRC the standard is pretty clear about undefined macros evaluating (I don't think that's right word, but you get the idea) to 0.  Still, I really like for the public headers to compile cleanly even for ridiculous warnings since I don't want to teach people to disable or ignore compiler warnings.

However I was considering "binary" macros which would be either defined to 0 or to 1, like those we were talking about here.

Yes, but you still have to compare them to something.  Instead of > X maybe it's == 1 or just an implicit comparison to != 0 (i.e., just #if FOO), and you still have the same problem.  If you can't be sure the macro is defined you have to first test that it is defined, then check the value.

These are purely for internal SIMDe use and converting to the other style would allow developers who care to use -Wundef.

Yeah, in the case of macros defined in the same project as we want to use them it's really about consistency.  I don't like the idea of having to do things differently outside of SIMDe.
That said, what I would be willing to do is define all these macros to 1 instead of nothing.  That would let people who disable -Wundef just do #if FOO.  But I do still want to allow defined(FOO) to work, so I don't want to #define FOO 0 if for false.
To be honest, it's possible these are just all rationalizations and all I really care about is consistency.  defined(x) has been what I've always used, and it's been what I encounter most in the wild.

Anyway I think we must agree to disagree on this one.

Yeah, I think so.  Still, it's nice to discuss this stuff occasionally.  Complacency is bad, and having my preferred conventions challenged forces me to actually think about them :)

(I am old with failing memory and eyesight so I would appreciate anything the compiler can do to pick up my silly mistakes.

Maybe I'm getting old, too.  I'm usually a big fan of getting the compiler to pick up more bugs for me (hence wanting to compile cleanly even with dumb compiler warnings).  C is a hard language to get right, we need all the help we can get from compilers and static analyzers…

This is also why I also suggested previously that run-tests should compile-test other code paths.)
Edit: Even better would be for run-tests to take a flag giving the choice between:

I don't remember what you're talking about for run-tests, do you have a link for that?  I like to think our CI is pretty aggressive, but getting more out of local tests wouldn't be bad.  I'm not really sure how you esvision this working, but maybe you could open up a new issue to discuss it?  It's definitely the sort of thing I'd be interested in.

It seemed more economical to introduce a macro to just call an existing function with reversed arguments than to write a new function.

I don't think I noticed that the arguments were reversed.  I remember I looked for negation, but completely forgot about reversing the arguments, sorry :(

It seemed more economical to introduce a macro to just call an existing function with reversed arguments than to write a new function.
But as you don't like me implementing intrinsics in macros the point is moot.

Not entirely.  We could still do the same thing inside functions, which would make it so ports to other architectures would really only need to implement a single function.  If negation is required there would be a small performance hit to return ~r instead of r, so maybe a couple functions if you want to avoid that.  I don't think it would have a big input since these are the type of things compilers should really be able to autovectorize, but I don't really see a down-side.

I didn't realize that defined(FOO) && (FOO > X) would throw a warning with -Wundef  if FOO is undefined. You very frequently see this construction in header files.

It might not be -Wundef, but I know there is an off-by-default warning that triggers it. It's kind of annoying because IIRC the standard is pretty clear about undefined macros evaluating (I don't think that's right word, but you get the idea) to 0. Still, I really like for the public headers to compile cleanly even for ridiculous warnings since I don't want to teach people to disable or ignore compiler warnings.

Warnings are just for that: signalling things that are permitted but which could indicate a mistake or an oversight. I had a colleague who always wrote tests against a constant backwards. I suppose it was to throw an error if she wrote e.g. if (9 = foo) instead of  if (9 == foo). For equality it is not too bad but I found readability suffered for other tests. (But maybe it is just me.)

This is also why I also suggested previously that run-tests should compile-test other code paths.)
Edit: Even better would be for run-tests to take a flag giving the choice between:

I don't remember what you're talking about for run-tests, do you have a link for that? I like to think our CI is pretty aggressive, but getting more out of local tests wouldn't be bad. I'm not really sure how you esvision this working, but maybe you could open up a new issue to discuss it? It's definitely the sort of thing I'd be interested in.

I suggested it here: https://github.com/nemequ/simde/issues/169#issuecomment-620582863.
Yes the CI is excellent, congratulations.
However you have to add, commit, push and PR to pick up every silly error in a code path that you didn't test locally.

I put an RFC version of avx512bw.h with my 0 or 1 macro ideas in the define branch of my fork.
It passes all Travis-CI tests.
Obviously the stuff at the beginning which just converts into 0 or 1 macros will disappear if this solution is adopted.
My 0 or 1 macros just have a trailing underscore added.
The advantages of my approach:

with -Wundef almost all misspelt macros will be detected,
almost all code paths are compile-tested with any compilation.

The proof: two latent pre-existant MSVC warning/errors (bad casts) were picked up.

I think I have finished this round if the tests pan out OK.
(xlc failed but I don't think it is my fault. I restarted it and all Travis-CI is green now.)
I shall no longer touch this branch.
But it is getting late so if there is a problem it will have to wait till tomorrow.
Sorry it has taken so long.
For the future I have improvements to gfni.h which is nearly finished and NEON stuff which is embryonic.
@nemequ: Would you please give feedback (even negative ;-)) on what I did here https://github.com/nemequ/simde/pull/265#issuecomment-626328121 ?
See also the previous messages.
TIA.

Sorry, I thought this issue was finished.  Are there any commits in here that haven't been merged but you feel are ready to be?  It gets a bit confusing for issues like this where the PR continues to evolve after it has been merged, especially when it hasn't been rebased, but if there are still changes in here I'd definitely like to get them merged ASAP so they don't bit rot any more than they already have.
Reading comments since my last comment now…

However you have to add, commit, push and PR to pick up every silly error in a code path that you didn't test locally.

I'd like to have the ability to test more stuff locally too.  For me the biggest issue with CI is the waiting.  IIRC it usually takes more than 30 minutes for CI to test a commit because we have so many things to check, and unfortunately that's only going to get worse as we add more instructions.  Even spread across 5 different providers (Travis CI, GitHub Actions, Drone.io, Azure Pipelines, and Appveyor) it's excruciating.
The noise I can definitely relate to; that's why I try to use a different repo which nobody should be watching for commits where I'm really just trying something to see how it goes.
As for the shame, that goes away pretty quickly once you realize everyone is going through the same stuff, especially for highly portable projects with aggressive diagnostics treated as errors like SIMDe.
I just didn't know what your were proposing.  Switching over to replying to the linked comment:

While I appreciate that to actually run all tests on all code paths would be very time consuming, couldn't run-tests at least compile-test all code paths (different pure C/MMX/SSE/AVX/AVX512/GFNI levels)?

I wouldn't want to do that by default, but it would be possible to add an option to Meson for something like that.  You could detect the CPU features in the test harness to figure out which tests to run, so you don't need to limit yourself to compile-only.  It would be a pretty big undertaking, though.
An easier way would be to just add a shell script to the test directory to automate the process of building each version.  At its core, just something like (untested)
COMPILER_FLAGS="-Wall -Wextra -Werror"
BUILDDIR="$(mktemp -d)"

for ISAX in \
    "-mno-mmx -mno-sse -mno-sse2" \
    "-mmmx -mno-sse -mno-sse2" \
    "-mmmx -msse -mno-sse2" \
    "-mmmx -msse -msse2" \
    "-mno-mmx -msse -msse2" \
    "-msse3" "-mssse3" "-msse4.1" "-msse4.2" "-mavx" "-mavx2" "-mfma" \
    "-mavx512f" \
    "-mavx512f -mavx512vl" \
    "-mavx512f -mavx512bw" \
    "-mavx512f -mavx512vl -mavx512bw" \
    "-mavx512f -mavx512dq" \
    "-mavx512f -mavx512vl -mavx512bw -mavx512dq"; do
  if [ ! -e build-lots ]; then
    mkdir build-lots
  else
   rm -rf build-lots/*
  fi
  CFLAGS='"${COMPILER_FLAGS} ${ISAX}" CXXFLAGS="${COMPILER_FLAGS} ${ISAX}" meson "${BUILDDIR}" || break
  ninja -C "${BUILDDIR}"
done

The AVX-512F stuff would need some tuning to figure out which combinations of flags to test, but that should give you the general idea.  I'd be happy to add something like that.  We could even add code to try different compilers.
Of course, all this assumes you're on x86.  On other architectures there is a different (though less extensive) set of flags to try for each.
Obviously this would only supplement CI, not replace it, but I think that's all you're talking about anyways.

Also as you are really serious about big-endian support it would be useful to have portable macros or functions for 16-bit, 32-bit and 64-bit byte swaps.

https://github.com/nemequ/simde/blob/f9e183b37de00965e007e6773488a4eea4678a8e/simde/simde-common.h#L342-L417
I think I added this after I saw the __builtin_bswap64 in your code along with a note to fix it (so I fixed it).  I didn't bother with other lengths, I figured we could add them as necessary.  I just haven't needed endian-swapping code for SIMDe, but if you do I can add it.  Maybe even update it a bit to merge it into a single header.

Edit: I haven't thought through this but maybe with real tests against a const (or a macro evaluating to a constant) rather than preprocessor tests, the compiler would check all code paths but optimize away unreachable ones.

Even if you gave all the macros values (instead of just checking if they're defined), it would fail if, for example, you call an invalid function, like a NEON function on x86, or a _builtin* that the compiler doesn't support.  Or if there was a syntax error because the compile doesn't support an extension, like statement exprs or vector extensions (or even parts of vector extensions which it doesn't support).  Or cases where we're working around compiler bugs.
There is a fairly broad set of circumstances where this would work, like falling back on previous ISA extensions for the same architecture, but there would also be tons of exceptions and no consistency.  We would still need to use preprocessor logic in a lot of places, and having to constantly switch back and forth between the different styles would make working on the code extremely unpleasant.

I put an RFC version of avx512bw.h with my 0 or 1 macro ideas in the define branch of my fork.
It passes all Travis-CI tests.

I get the idea, and it does have advantages.  However, seeing the code convinces me that I really don't like it, largely for the reasons I mentioned above.

The proof: two latent pre-existant MSVC warning/errors (bad casts) were picked up.

Nice, do you know where those were?  We should fix them.

Sorry, I thought this issue was finished. Are there any commits in here that haven't been merged but you feel are ready to be? It gets a bit confusing for issues like this where the PR continues to evolve after it has been merged, especially when it hasn't been rebased, but if there are still changes in here I'd definitely like to get them merged ASAP so they don't bit rot any more than they already have.

In https://github.com/nemequ/simde/issues/261#issuecomment-623590615 you said that dialogue could continue after things are closed. I continued here because it is vaguely related: with the current scheme additional fallbacks create code paths that are removed by the pre-processor and that the compiler cannot even compile-test. That is why I really  don't like your #if defined(FOO) approach ;-)
But apparently we violently disagree on this.
Apart from this the only other commits would be for the two MSVC cast errors but I'll generate a PR for these based on the current master if they are still present.

The noise I can definitely relate to; that's why I try to use a different repo which nobody should be watching for commits where I'm really just trying something to see how it goes.

Does a fork count as a different repo?
It is not clear to me who sees what messages. For instance if I add a specific @nemequ does the message just go to you?

As for the shame, that goes away pretty quickly once you realize everyone is going through the same stuff, especially for highly portable projects with aggressive diagnostics treated as errors like SIMDe.

Yes but unfortunately there are also (in my case) many typos in completely untested code paths removed by the pre-processor with your #if approach.

I just didn't know what your were proposing. Switching over to replying to the linked comment:

While I appreciate that to actually run all tests on all code paths would be very time consuming, couldn't run-tests at least compile-test all code paths (different pure C/MMX/SSE/AVX/AVX512/GFNI levels)?

I wouldn't want to do that by default, but it would be possible to add an option to Meson for something like that. You could detect the CPU features in the test harness to figure out which tests to run, so you don't need to limit yourself to compile-only. It would be a pretty big undertaking, though.
An easier way would be to just add a shell script to the test directory to automate the process of building each version. At its core, just something like (untested)
COMPILER_FLAGS="-Wall -Wextra -Werror"
BUILDDIR="$(mktemp -d)"

for ISAX in \
    "-mno-mmx -mno-sse -mno-sse2" \
    "-mmmx -mno-sse -mno-sse2" \
    "-mmmx -msse -mno-sse2" \
    "-mmmx -msse -msse2" \
    "-mno-mmx -msse -msse2" \
    "-msse3" "-mssse3" "-msse4.1" "-msse4.2" "-mavx" "-mavx2" "-mfma" \
    "-mavx512f" \
    "-mavx512f -mavx512vl" \
    "-mavx512f -mavx512bw" \
    "-mavx512f -mavx512vl -mavx512bw" \
    "-mavx512f -mavx512dq" \
    "-mavx512f -mavx512vl -mavx512bw -mavx512dq"; do
  if [ ! -e build-lots ]; then
    mkdir build-lots
  else
   rm -rf build-lots/*
  fi
  CFLAGS='"${COMPILER_FLAGS} ${ISAX}" CXXFLAGS="${COMPILER_FLAGS} ${ISAX}" meson "${BUILDDIR}" || break
  ninja -C "${BUILDDIR}"
done

The AVX-512F stuff would need some tuning to figure out which combinations of flags to test, but that should give you the general idea. I'd be happy to add something like that. We could even add code to try different compilers.
Of course, all this assumes you're on x86. On other architectures there is a different (though less extensive) set of flags to try for each.
Obviously this would only supplement CI, not replace it, but I think that's all you're talking about anyways.

But with my approach all these complications are removed as (almost) all code paths are compile-tested because the compiler sees and reports errors in code in an if (0) but not in a #if 0.

Also as you are really serious about big-endian support it would be useful to have portable macros or functions for 16-bit, 32-bit and 64-bit byte swaps.

https://github.com/nemequ/simde/blob/f9e183b37de00965e007e6773488a4eea4678a8e/simde/simde-common.h#L342-L417
I think I added this after I saw the __builtin_bswap64 in your code along with a note to fix it (so I fixed it). I didn't bother with other lengths, I figured we could add them as necessary. I just haven't needed endian-swapping code for SIMDe, but if you do I can add it. Maybe even update it a bit to merge it into a single header.

Thank you. The code was a temporary quick and dirty (but successful) attempt to fix the endian problem. I cannot do big-endian tests locally because Ubuntu screws up the four or five big-endian cross-compilations and cross-executions that I have tried.
(I confirmed that this works in a Debian Sid chroot but it is inconvenient.)

Edit: I haven't thought through this but maybe with real tests against a const (or a macro evaluating to a constant) rather than preprocessor tests, the compiler would check all code paths but optimize away unreachable ones.

Even if you gave all the macros values (instead of just checking if they're defined), it would fail if, for example, you call an invalid function, like a NEON function on x86, or a _builtin* that the compiler doesn't support. Or if there was a syntax error because the compile doesn't support an extension, like statement exprs or vector extensions (or even parts of vector extensions which it doesn't support). Or cases where we're working around compiler bugs.

Yes you will see in my code that I had to leave a few  #if for (mainly vector) constructs that aren't  standard C. I also moved the native replacement outside the functions because the native intrinsic would be undefined in compilations for "lower levels". I am not sure that it would fail on a NEON function if it were simde_ prefixed. As for builtins it is best to have portable versions elsewhere like you did for the byte swap.

There is a fairly broad set of circumstances where this would work, like falling back on previous ISA extensions for the same architecture, but there would also be tons of exceptions and no consistency. We would still need to use preprocessor logic in a lot of places, and having to constantly switch back and forth between the different styles would make working on the code extremely unpleasant.

Yes, as I said above, there are some exceptions but IMHO not  tons.

I put an RFC version of avx512bw.h with my 0 or 1 macro ideas in the define branch of my fork.
It passes all Travis-CI tests.

I get the idea, and it does have advantages. However, seeing the code convinces me that I really don't like it, largely for the reasons I mentioned above.

And I really do like it, but it's your call :-(
I didn't mention, but it is obvious, that the two approaches can co-exist.

The proof: two latent pre-existant MSVC warning/errors (bad casts) were picked up.

Nice, do you know where those were? We should fix them.

Yes, as I said above I'll generate a PR for current master to fix them if they are still present.

Sorry, I thought this issue was finished. Are there any commits in here that haven't been merged but you feel are ready to be? It gets a bit confusing for issues like this where the PR continues to evolve after it has been merged, especially when it hasn't been rebased, but if there are still changes in here I'd definitely like to get them merged ASAP so they don't bit rot any more than they already have.

In #261 (comment) you said that dialogue could continue after things are closed. I continued here because it is vaguely related:

Yes, I don't have a problem continuing here, it just kind of got buried in my notifications.

with the current scheme additional fallbacks create code paths that are removed by the pre-processor and that the compiler cannot even compile-test. That is why I really don't like your #if defined(FOO) approach ;-)

Yes, that's definitely a big advantage of your suggestion.  I just don't think it's worth all the drawbacks, especially when we can compile-test much more thoroughly using other means.

But apparently we violently disagree on this.

Yeah, I think so.  Unfortunatley I don't think there is a right answer; it's just two conflicting opinions :(

Apart from this the only other commits would be for the two MSVC cast errors but I'll generate a PR for these based on the current master if they are still present.

Excellent, thanks!

The noise I can definitely relate to; that's why I try to use a different repo which nobody should be watching for commits where I'm really just trying something to see how it goes.

Does a fork count as a different repo?

Yes.  I don't receive any notifications for your rosbif/simde repo unless I "watch" the repo, which I don't.

It is not clear to me who sees what messages. For instance if I add a specific @nemequ does the message just go to you?

Yes, if you @ me in an issue (or a commit, etc.), I'll get a message, but AFAIK nobody else will.
There might be an exception for people who watch me as a user instead of watching SIMDe.  I'm not sure since I've never actually watched a user, but think it just means you see their activity not their mentions.  That said, if someone watches you they're (literally) asking for it, so shrug.

As for the shame, that goes away pretty quickly once you realize everyone is going through the same stuff, especially for highly portable projects with aggressive diagnostics treated as errors like SIMDe.

Yes but unfortunately there are also (in my case) many typos in completely untested code paths removed by the pre-processor with your #if approach.

That's okay, it happens to everyone.  Unfortunately that's never going to go away, unless you want to install all the compilers on local hardware.  Even with your approach where will still be a lot of untested code; not all compilers can handle the same supersets of C.  I guess you could limit yourself to a strict lowest-common-denominator, but then you're leaving a lot of really nice features on the table.

I just didn't know what your were proposing. Switching over to replying to the linked comment:

While I appreciate that to actually run all tests on all code paths would be very time consuming, couldn't run-tests at least compile-test all code paths (different pure C/MMX/SSE/AVX/AVX512/GFNI levels)?

I wouldn't want to do that by default, but it would be possible to add an option to Meson for something like that. You could detect the CPU features in the test harness to figure out which tests to run, so you don't need to limit yourself to compile-only. It would be a pretty big undertaking, though.
An easier way would be to just add a shell script to the test directory to automate the process of building each version. At its core, just something like (untested)
COMPILER_FLAGS="-Wall -Wextra -Werror"
BUILDDIR="$(mktemp -d)"

for ISAX in \
    "-mno-mmx -mno-sse -mno-sse2" \
    "-mmmx -mno-sse -mno-sse2" \
    "-mmmx -msse -mno-sse2" \
    "-mmmx -msse -msse2" \
    "-mno-mmx -msse -msse2" \
    "-msse3" "-mssse3" "-msse4.1" "-msse4.2" "-mavx" "-mavx2" "-mfma" \
    "-mavx512f" \
    "-mavx512f -mavx512vl" \
    "-mavx512f -mavx512bw" \
    "-mavx512f -mavx512vl -mavx512bw" \
    "-mavx512f -mavx512dq" \
    "-mavx512f -mavx512vl -mavx512bw -mavx512dq"; do
  if [ ! -e build-lots ]; then
    mkdir build-lots
  else
   rm -rf build-lots/*
  fi
  CFLAGS='"${COMPILER_FLAGS} ${ISAX}" CXXFLAGS="${COMPILER_FLAGS} ${ISAX}" meson "${BUILDDIR}" || break
  ninja -C "${BUILDDIR}"
done

The AVX-512F stuff would need some tuning to figure out which combinations of flags to test, but that should give you the general idea. I'd be happy to add something like that. We could even add code to try different compilers.
Of course, all this assumes you're on x86. On other architectures there is a different (though less extensive) set of flags to try for each.
Obviously this would only supplement CI, not replace it, but I think that's all you're talking about anyways.

But with my approach all these complications are removed as (almost) all code paths are compile-tested because the compiler sees and reports errors in code in an if (0) but not in a #if 0.

I think you overestimate the number of paths that you could test like this that aren't also covered by the existing tests (not talking about CI, just the native and emul tests for each function).  It's basically just fallbacks using previous ISA extensions.  No GCC-style vector extensions, no SIMDE_SHUFFLE/CONVERT_VECTOR (__builtin_shuffle/__builtin_shufflevector/__builtin_convertvector). No other architectures.

Also as you are really serious about big-endian support it would be useful to have portable macros or functions for 16-bit, 32-bit and 64-bit byte swaps.

https://github.com/nemequ/simde/blob/f9e183b37de00965e007e6773488a4eea4678a8e/simde/simde-common.h#L342-L417
I think I added this after I saw the __builtin_bswap64 in your code along with a note to fix it (so I fixed it). I didn't bother with other lengths, I figured we could add them as necessary. I just haven't needed endian-swapping code for SIMDe, but if you do I can add it. Maybe even update it a bit to merge it into a single header.

Thank you. The code was a temporary quick and dirty (but successful) attempt to fix the endian problem. I cannot do big-endian tests locally because Ubuntu screws up the four or five big-endian cross-compilations and cross-executions that I have tried.
(I confirmed that this works in a Debian Sid chroot but it is inconvenient.)

Edit: I haven't thought through this but maybe with real tests against a const (or a macro evaluating to a constant) rather than preprocessor tests, the compiler would check all code paths but optimize away unreachable ones.

You can do it with a union:
https://github.com/nemequ/portable-snippets/blob/master/endian/endian.h#L152-L181
But you're not supposed to use #if/#else in your code.  That's why simde_endian_bswap64_be/le are defined the way they are:
https://github.com/nemequ/simde/blob/master/simde/simde-common.h#L422-L428
You just call simde_endian_bswap64_le(value) and it will preprocess to a swap if you're on little-endian and just (value) if you're on big-endian.  simde_endian_bswap64_be(value) does the reverse; it's a swap if you're on big-endian and the value if you're on little endian.

Even if you gave all the macros values (instead of just checking if they're defined), it would fail if, for example, you call an invalid function, like a NEON function on x86, or a _builtin* that the compiler doesn't support. Or if there was a syntax error because the compile doesn't support an extension, like statement exprs or vector extensions (or even parts of vector extensions which it doesn't support). Or cases where we're working around compiler bugs.

Yes you will see in my code that I had to leave a few #if for (mainly vector) constructs that aren't standard C.

The number of those are going to increase soon.  You've been working on adding x86 fallbacks, and I intend to go through and start adding vector extensions, other architectures, and OpenMP SIMD versions (which would work with your proposal).  What you're seeing is a heavily biased view; take a look at sse.h if you want to get a better idea of how the code should look in the future.  I intend to start working on that soon; that's what #275 is about.

I also moved the native replacement outside the functions because the native intrinsic would be undefined in compilations for "lower levels". I am not sure that it would fail on a NEON function if it were simde_ prefixed.

That would work, but it would require us to implement every ISA extension simultaneously.  That's asking a lot.

As for builtins it is best to have portable versions elsewhere like you did for the byte swap.

You could use something like the builtin module in portable-snippets (or possibly a subset) for some functions, but there are a lot of builtins which can't be emulated, and frankly those tend to be the ones which are useful in SIMDe.  I haven't had to use __builtin_ffs or __builtin_ctz yet, but __builtin_shuffle, __builtin_shufflevector, and __builtin_convertvector are all over the place.

There is a fairly broad set of circumstances where this would work, like falling back on previous ISA extensions for the same architecture, but there would also be tons of exceptions and no consistency. We would still need to use preprocessor logic in a lot of places, and having to constantly switch back and forth between the different styles would make working on the code extremely unpleasant.

Yes, as I said above, there are some exceptions but IMHO not tons.

The classes of exceptions aren't that great, but each will be fairly common.
Anyways, I think you're right that we're going to have to agree to disagree here :(


Typescript support

No typescript support exists, either via the Definitely Typed @types package or through using typescript itself.
Could not find a declaration file for module '@opencage/geosearch-core'. <EMAIL_ADDRESS>implicitly has an 'any' type.
  Try `npm i --save-dev @types/opencage__geosearch-core` if it exists or add a new declaration (.d.ts) file containing `declare module '@opencage/geosearch-core';`

Hi @pr0ton, please bear with me I will add the definition file for the core package

The new release 0.1.0 (https://www.npmjs.com/package/@opencage/geosearch-core) contains a built-in typescript declaration.
You can also check the declaration file here: https://github.com/OpenCageData/geosearch/blob/master/packages/geosearch-core/index.d.ts.
please let me know if there is anything I can help with.

@pr0ton I updated the DTS, as I forgot the only mandatory parameter key. This is now fixed on 0.1.1.
I keep the issue open for a few days. Please let me know if there is anything we can help with.

Thanks. This works well.


More fixes: Remove repeated tokens, add BibTeX, improve website

This PR does a mix of things:

Automatically removes repeated tokens from defenses when evaluating attacks using GPT 3.5 Turbo. This gets around some breaking changes that OpenAI made to the API (it now rejects inputs where the same token is provided more than 200 times in a row).
Adds BibTeX citation to the README (requested by Justin)
Adds  to public-facing pages to de-duplicate entries in Google Search (the search console keeps complaining to me about this)
Mentions prompt injection on the homepage. It'd be nice if we could break into the Google results for "prompt injection", and hopefully mentioning it a few times makes that more likely.
Improves wording of the account restriction dialog in response to feedback from a user.
Fixes from Olivia: remove Noto Color Emoji CSS (which was causing DuckDuckGo Browser and maybe Safari to hang) and fix the login link on the homepage so that it doesn't show up while the page is loading.

Hopefully this is not too long. I wanted to avoid making four separate PRs because that would be a PITA to test manually on the staging site (it should be available on staging as of ~7pm PT).

Merging now that review comments are fixed.


fix(write_handler): fix duplicate metrics registration panic

Potentially closes https://github.com/grafana/agent/issues/6548 when PR got merged and upgraded in linked project's go.mod
Fixes another infamous case of duplicate metrics registration panic. This time it's on write_handler

[x] Unit test added

Hey @hainenber, while this fixes the issue I don't think upstream would accept it (though you'd have to open a PR upstream to check).
The code which is panicking in grafana/agent#6548 already has a mechanism to avoid these panics in place.
I think we should figure out why that existing isn't working anymore, and what we can do to fix that rather than adding additional mechanisms in Prometheus for catching this.

@hainenber I see the issue in static mode, it's this line: https://github.com/grafana/agent/blob/72b08cae804624f444b1c7529aaa4148672b4db8/internal/static/metrics/instance/instance.go#L412
It's passing i.reg to Prometheus instead of the register arugment (which would have the proper re-registration handling)

Great finding, I wasnt aware that there's already a guard rail in place 😄
Can close off the PR. Im on mobile now so will do it later in the day

Closing as discussed above. Thank you for the discussion!


Transformed Date(s) in query ends up as empty string(s)

Description
If you have a client with the date type configured as types+transform for example:
  base: 'https://petstore3.swagger.io/api/v3',
  client: '@hey-api/client-fetch',
  input:
    'https://raw.githubusercontent.com/swagger-api/swagger-petstore/master/src/main/resources/openapi.yaml',
  output: {
    format: 'prettier',
    lint: 'eslint',
    path: './src/client',
  },
  types: {
    dates: 'types+transform',
    enums: 'javascript',
  },

and have an api call with a query that contains date(s) such as:
export type UpdatePetData = {
  /**s
   * Update an existent pet in the store
   */
  body: Pet;
  query: {
    toDate: Date;
    fromDate: Date;
  };
};

const { data, error } = await updatePet({
      body: {
        category: {
          id: 0,
          name: 'Cats',
        },
        id: 2,
        name: 'Updated Kitty',
        photoUrls: ['string'],
        status: 'available',
        tags: [
          {
            id: 0,
            name: 'string',
          },
        ],
      },
      query: {
        toDate: new Date(),
        fromDate: new Date(),
      },
      // setting headers per request
      headers: {
        Authorization: 'Bearer <token_from_method>',
      },
    });

then it will simply append empty strings (this is the case if you only have 1 date query parameter or multiple).

Reproducible example or configuration
https://stackblitz.com/edit/hey-api-client-fetch-example-ujvl7y?file=src%2FApp.tsx
Slightly modified of the default example, just added a query with toDate and fromDate to the updatePet PUT call. This doesn't actually have any functionality in the pet API, but this is simply to show that the API Call generated isn't correct.
OpenAPI specification (optional)
No response
System information (optional)
No response

@Nick-Lucas do you think we should add request transformers? Or not allow passing Date(s) into requests and require users to transform them into strings?

This strikes me as more of a client bug. When you pass a Date to a body, it gets serialised to an ISO string automatically by every client I've used.
It looks like the createQuerySerializer needs updating to identify Date and call .toISOString() on it
https://github.com/hey-api/openapi-ts/blob/37a991a91cea15f5116eafa11664f29fb90e8545/packages/client-fetch/src/utils.ts#L261

@mrlubos I updated @hey-api/openapi-ts to ^0.52.3 and @hey-api/client-fetch to ^0.2.2, but the resulting request url is now on the format https://test.com/test?2024-08-03T21:59:59.999Z&2024-08-10T21:59:59.999Z. So it's correctly serializing the date to a string now, but it's not including the query parameter name.

@AndreasJJ Ugh. This is with the example above? I'll check, sorry for that

@AndreasJJ I am not sure which path I tested the last time, but the new fix works with your example. Will fix whatever it might be breaking if that's the case

Thanks for the quick fix, it works for us now.


Modularise parts of the LoginView

Description
I modularized parts of the LoginView, as far as I can tell without modifying existing behavior, but providing more hooks to custromize the LoginView via inheritance.
Notice how I split the constants defining the steps into AUTH_STEP and FIRST_STEP. I assume the clearing of the state in post() is meant to happen at the first step of the wizard, which does not necessarily have to be the 'auth' step.
Motivation and Context
We use a custom version of the LoginView that adds an additional step in the login flow before the actual 'auth' step. At the moment this requires duplicating large amounts of code. By merging this change it would become a lot easier to accommodate such customization without large changes.
How Has This Been Tested?
We are currently integrating my fork and it allows large parts of the customization we require.
Types of changes

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

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Could you please make a separate PR with your first commit?

I extracted the first commit and pushed to #604.

@mpauly, your first commit is now in master, thanks a lot! Would you like to rebase this patch (and merge commits)?

I just rebased against the current master and squashed the commits.


Authentication example [feature request]

First of all, THANKS A LOT for this huge piece of great work!!!! Honestly, really appreciated.
What I'm suggesting is for you guys to add an Auth form (login), and mostly an example hitting an Oauth2 backend to perform a login.
Thanks

That would be a nice addition, PR maybe ? 😉

I am working to integrate Firebase Authentication to this project. If interested I can submit a PR once I am done with the revisions and tests.

Hi @GuateDevIO yes that would be great!

@GuateDevIO - I would be very interested in this as well.

Any updates on this topic  ?

I am migrating my projects to Angular 8 and I believe Tomas is also doing the same with this project. I think it will be better to wait for the upgrade to be done and then I can possibly submit a PR for the Authentication. Also I think its a great moment to introduce Nestjs to this project. I started using it recently and I am very impressed. Due to my new job it may take me some time to get this done hence anyone is welcome to submit a PR for this. Thanks.

@GuateDevIO the Angular 8 migration is finished, an richer auth example would be nice but would prefer to keep it simple and NOT introduce nestjs ( even though I am a big fan! ) to keep both the starter and the deployment process simple. Current deployment to github pages would not be enough for node backend.
Anyway a nice login page with either simulated login or against some free API would be nice!

Tomas, and every else, thank you!!!!!!! I almost have the auth for graphql done for my project...should I submit a PR? Maybe as a feature

With auth it is complicated, you usually need some kind of server right ?
This starer is deployed to GH pages so there is no possibility of having backend, so it is hard to imagine how to make this work frontend only so that when people clone this project then it just works as expected... ideas?

How about a heroku version?

Using Google Firebase Auth would be a good solution to this issue, should be no trouble deploying to GH.
One still needs to configure the Firebase project however.

Any update guys on login page example?

For those who seek for a good example of Auth with ngrx check this repo: https://github.com/samjulien/nostalgia-mart


Try out Vue.js

Use Vue in React and React in Vue
https://github.com/devilwjp/veaury

Initial review is that veaury completely removes TypeScript definitions from imported Vue components?

I'm extremely into the way Vue.js supports scoped styles and CSS modules out of the box
The template syntax is honestly really nice
The setup functions can get a bit wordy with "computed" everywhere, but it's a lot easier to understand

Using "veaury" to allow Vue<->React compat is fine, but it gets pretty rough around the edges
I think it'd be a lot faster to "just" rewrite the whole code base top down instead lol

Again, seems very cool, but I'm not sure I actually want to do this. It's going to be a ton of work.
Maybe I can move to Preact instead to save some bytes...


Design updates and diagram for the Operation form related user workflows

As reflected by the team, user workflow diagram would offer extra clarity in addition to or before we create detailed design in Figma.
AC:

[x] Review the "Operation" tab in the Reg Pt. Fields spreadsheet
[x] Update the placeholder Operation form with detailed fields in Figma
[x] Create user workflow diagram for Operation-level information management
[x] Gather feedback
[x] Address feedback and fine tune the design in Figma to align with the user workflow diagram

Hi @hannavovk (cc: @zoeyli-46) - This ticket is created as discussed. Feel free to review or refine as you see fit.

Hi @hannavovk - This ticket is ready for you to review and can be closed with:

the business area and developers feedback addressed
the design walked through with developers

External | Operations grid
Internal | Operations grid
Operation form in the Editing mode
Operation from in the View-Only mode

Scenario 1
Scenario 2

Helpful context and intended behaviors communicated to developers and commented where applicable in Figma


DO OS types are not supported

I am trying to create different images using docker machine on Digital Ocean.
Currently, only ubuntu works and anytime I try the other images, I get a 'OS type not recognized' when trying other images (i.e. fedora, debian, coresos, centos).
Please forgive the odd formatting. We are calling docker-machine from a golang program via exec.cmd.
docker-machine create -d digitalocean --digitalocean-image fedora-21-x64
--digitalocean-size 1gb --digitalocean-region nyc3 --digitalocean-access-token mytoken
stdout: time=\"2015-04-03T16:22:24Z\" level=\"info\" msg=\"Creating CA: /var/lib/cattle/machine/16e12da7-70af-4f4f-ba05-df348bfcfef8/certs/ca.pem\"
stdout: time=\"2015-04-03T16:22:24Z\" level=\"info\" msg=\"Creating client certificate: /var/lib/cattle/machine/16e12da7-70af-4f4f-ba05-df348bfcfef8/certs/cert.pem\"
stdout: time=\"2015-04-03T16:22:26Z\" level=\"info\" msg=\"Creating SSH key...\"
stdout: time=\"2015-04-03T16:22:26Z\" level=\"info\" msg=\"Creating Digital Ocean droplet...\"
stdout: time=\"2015-04-03T16:22:33Z\" level=\"info\" msg=\"Waiting for SSH...\"
stdout: time=\"2015-04-03T16:23:06Z\" level=\"error\" msg=\"Error creating machine: OS type not recognized\"

When can we expect the other OS to be fixed so that it works?

Expanding provisioning capabilities is in the milestone for v0.3.0 #905.

Closing as this will be in 0.3.0.


ReferenceError: Property '__scanOCR' doesn't exist, js engine: hermes

I get this error
ReferenceError: Property '__scanOCR' doesn't exist, js engine: hermes
whenever I load my app with the package installed. I have added the right code to the babel.config.js, it looks like this:
module.exports = function(api) {
  api.cache(true);
  return {

     presets: ['babel-preset-expo'],
     plugins: [
       [
          'react-native-reanimated/plugin',
         {
           globals: ['__scanOCR'],
         },
       ],
     ]
  };
};

I am using a expo dev client if that is relevent. I would appreciate any and all help thanks in advance.

import { scanOCR } from "vision-camera-ocr"

Did you remember to import it before using it?


Acknowledge In-Kind Support by AWS on the page

Thanks! For now fine with me as is - follow up PR can separate etc


Create a Signup Components and add it to the NavBar

Currently, the Signup menu on the navigation bar onclick didn't link to any page. I'd love to work on this by creating a Singup components and link it to the Signup menu.

I want to work on this issue as a contributor.
Pleasure Assign so that I can show my skills under GSSoC'23.

hey..similar issue is already been assigned: #12


Error reproducing Voxelmorph results on IXI.

I am getting the below error -
    raise RuntimeError('Error(s) in loading state_dict for {}:\n\t{}'.format(
RuntimeError: Error(s) in loading state_dict for VxmDense_huge:
        size mismatch for unet_model.downarm.0.main.weight: copying a param with shape torch.Size([8, 2, 3, 3, 3]) from checkpoint, the shape in current model is torch.Size([14, 2, 3, 3, 3]).
        size mismatch for unet_model.downarm.0.main.bias: copying a param with shape torch.Size([8]) from checkpoint, the shape in current model is torch.Size([14]).
        size mismatch for unet_model.downarm.1.main.weight: copying a param with shape torch.Size([32, 8, 3, 3, 3]) from checkpoint, the shape in current model is torch.Size([28, 14, 3, 3, 3]).
...

Hi @bhosalems ,
I believe you are trying to load VoxelMorph-1 or -2's weights into VoxelMorph-huge. You'll need to change this line according to the model that you are using:
https://github.com/junyuchen245/TransMorph_Transformer_for_Medical_Image_Registration/blob/47517d0cc5b7b8b56c77b6b3efa60d59abba3432/IXI/Baseline_registration_methods/VoxelMorph/infer.py#L63
You may find the names of the models here:
https://github.com/junyuchen245/TransMorph_Transformer_for_Medical_Image_Registration/blob/47517d0cc5b7b8b56c77b6b3efa60d59abba3432/IXI/Baseline_registration_methods/VoxelMorph/infer.py#L12
Junyu


Libreoffice fails to build on nixos-unstable

https://hydra.nixos.org/eval/1784611?filter=libreoffice&compare=1784592&full=
Build log
https://hydra.nixos.org/build/197381087
Notify maintainers
 @7c6f434c

As a temporary workaround, you can use libreoffice-fresh which builds fine.
The problem seems to come from the recent update to poppler 22.09.0 in https://github.com/NixOS/nixpkgs/commit/ca9eb8eee37736e4ae2d493136597e1edb3f813d, which contains this commit which changes the API for GfxState::getLineDash.

I will note that poppler explicitly makes no promises about the stability of that function:

UNSTABLE, INTERNAL C++ API to operate directly on Poppler's internal representation of PDF files. If you use this API, you are on your own. This API may change at any time, even among minor versions of Poppler!

So if LibreOffice relies on this internal API that's something to look out for.


Fediverse account name on about page uses @localhost even if domain is set

I updated the src/utils file as described to reflect my personal domain. However, the username on the about page is still @localhost

This is because the values imported from .env are not available in src/utils

ack, good catch. That should be a quick-ish fix...

yeah i just added the dotenv import and config at the top of that file.


Add Firebase analytics

Issue: #134
Overview: This PR does setup to incorporate Firebase Analytics for Eatery. It also adds a new AppDevAnalytics cocoapod which contains some nice classes to use when logging.
Test:

NOTE: I will post the GoogleService-Info.plist in #uplift-ios. You will need this for Firebase to run properly

is the failing bitrise just b/c there's not enough approving reviews?

no its failing b/c our old Presentation fork for the cocoapod was deleted. I am fixing it right now. Will merge after its fixed


Provide a DSC and/or Powershell automated installation for this.

In environments with many, many DC's, it's very useful to be able to install via automation / unattended. Please add support for DSC or Powershell based automation...

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

ID: 6ee91dca-7081-4eaa-8728-7674d7cd4870
Version Independent ID: 2eae6069-f58f-ad69-3511-1a4e204db31e
Content: Install Azure ATP sensor quickstart
Content Source: ATPDocs/install-atp-step4.md
Service: azure-advanced-threat-protection
GitHub Login: @mlottner
Microsoft Alias: mlottner

@mschrisran Thanks for your docs comment. Please make sure to reach out to the product feedback group with your suggestion at<EMAIL_ADDRESS>

#please-close


Removed a reference usage in SelectWorkOrder.

It is particular useful in the distributed case, where a WorkOrder cannot access to its operator.

Looks good, merging.


Windows key shortcut guide needs Chinese translation

Description of the new feature / enhancement
Hope to add multi-language support to the shortcut key display, using dictionary translation or machine translation
Scenario when this would be used?
Shortcut key guidance display
Supporting information
No response

rep #20741 #22811 #890 lol we all notice that don't we

/dup #890