Vertex Shader Syntax Megathread

I NEED FEEDBACK. IF YOU LOVE OR HATE THIS, PLEASE SPEAK LOUDLY.
IF THIS WILL ABSOLUTELY CAUSE PAIN AND MISERY, SPEAK TWICE AS LOUDLY.
THANK YOU.
Here's a first example of where I'm heading towards. The syntax and the heavy commenting explaining the syntax are what's important; the code itself is not and just meant to be an example.
/*
 * FIRST DRAFT OF SDL SHADER LANGUAGE (or whatever we're calling it) SYNTAX.
 *
 * This was a random HLSL shader generated by Unreal Engine 3, that I trimmed up
 * to remove unused code, etc.
 *
 * Don't worry about what this shader _does_, as it's just one of thousands of
 * variations UE3 generated from whatever and I grabbed one at random.
 *
 *
 * I don't know if this program is correct yet; not only is the grammar still
 * evolving and the compiler still in development, it's possible I deleted
 * a needed function by accident or fat-fingered a simple edit. Just get the
 * idea of what I'm trying to do here.
 *
 * Anything in here might change. Also, if something looks like a
 * short-sighted, dumbass mistake, it probably is. Come talk to me about it.
 *
 * --ryan.
 *
 *<EMAIL_ADDRESS> * https://twitter.com/icculus
 */

// These are constants (uniforms). We put them in a struct, because we'll be
// setting them up in a buffer on the CPU and sending them to GPU memory all
// at once, where the shader will _also_ be treating them as fields in a block
// of memory instead of individual variables. In that sense, there's no value
// in considering them individually.
//
// Since this piece happens to be compatible with C/C++ syntax, and you
// can #include files from there _and_ in these shaders, it's not unreasonable
// that this would go in a header by itself that the shader and native code
// can share (or the shader can have some #ifdefs so you can include it and
// only see this part of the file from C)...this can help make sure they're
// definitely looking at the same data layout.
//
// Alignment and packing on these will be well-defined.
struct FVertexConstants
{
    float4x4 ViewProjectionMatrix;
    float4x4 LocalToWorld;
    float3x3 WorldToLocal;
    float4 CameraPosition;
    float4 ScreenPositionScaleBias;
};

// This is _also_ a constant, but it's one that changes at a different
// rate than the others (one lives per-mesh, one lives per-frame), so
// it will live in a seperate buffer.
struct BoneMatricesConstants
{
    float4x3 BoneMatrices[75];
};

// These are your vertex attributes. You set up your arrays however you like
//  (interleaved in a single buffer, or totally separate buffers, or a little
//  of both), and fill in the details (format, offset, stride, buffer index)
//  when creating a pipeline object. Then assign the buffers with the data to
//  the appropriate indices before drawing, and when the vertex shader
//  runs, it assembles this struct from those sources. You specify
//  this struct as an argument to your main function.
//
// "@attribute(0)" means "this value is retrieved with the details in the
// first entry of SDL_GpuPipelineDescription::vertices array." There are
// several things with "@keyword" in the current language. I call them
// ATtributes. I'm _funny_!
struct FVertexInput
{
    float4 Position @attribute(0);
    half3 TangentX @attribute(1);
    half4 TangentZ @attribute(2);
    int4 BlendIndices @attribute(3);
    float4 BlendWeights @attribute(4);
    float3 DeltaPosition @attribute(5);
    half3 DeltaTangentZ @attribute(6);
};

// This struct holds all the _outputs_ from this shader.
// This struct is passed to the next stage of the pipeline (the fragment
// shader, at this moment). That next shader will need to know what these
// attributes mean and match up, so putting this in a common header
// (or having the matching fragment shader function _in the same source
// file_) is highly recommended.
//
// Other shader languages let you specify what these outputs mean, so
// the fragment shader can pick out the parts it cares about, but I'm
// hoping to avoid that and just pass it all through. If this turns out
// to be a terrible idea, we have @attributes at the ready!
//
// The "@position" means "this is the vertex position set by this shader"
// The system needs to know this beyond your shader pipeline, so there's
// an attribute to let it know where to find it in the output. Everything
// else here is just data that the fragment shader acts on.
struct FVertexOutput
{
    float4 ScreenPosition;
    float4 CameraVector_FogA;
    float4 Position @position;
};

// Heretical to C, functions start with the word "function" ...I am
// gambling that when people say "C-like language" they mean some
// set of characteristics that may include: curly braces, a preprocessor,
// almost no rules about whitespace, the distinctive for-loop syntax,
// and calculate-then-assign operators like +=, *=, etc. But not that it
// exactly resembles C in all ways.
//
// Notably, PHP and Javascript both use the "function" keyword and
// everyone thinks they are "C enough," so I hope this is okay.
//
// The C grammar just expects you to drop right into a datatype and figure
// out what you're talking about several tokens down the line...was it a
// function declaration? A function definition? A variable? A struct that
// might be defining a variable or a new type...?! An identifier, which
// might be a user-declared typedef, making parsing REALLY HARD...?!
//
// Sprinkling some "function" and "var" prefixes on these things helps me,
// the parser writer, immensely, and if we're being honest I bet it helps
// you, the program writer, too.
function float3 MorphPosition(FVertexInput Input)
{
    return Input.Position.xyz + Input.DeltaPosition;
}

// This function uses intrinsic functions, like "normalize" and "cross". Right now
// these match naming conventions in Direct3D, but that may change (GLSL provides
// many of the same functions but disagrees on what to call some of them).
//
// You can also see that matrices can be dereferenced like arrays.
//
// local variables are defined with a "var" keyword, which is also heretical
// to C users, but I couldn't help but notice WebGPU did this too, probably
// because parsing C is hard.
function float3x3 MorphTangents(FVertexInput Input)
{
    var float3x3 Result = 0;
    var float3 TangentX = ((Input.TangentX / 127.5) - 1);
    var float4 TangentZ = ((Input.TangentZ / 127.5) - 1);
    var float3 DeltaTangentZ = ((Input.DeltaTangentZ / 127.5) - 1);
    Result[2] = normalize(float3(TangentZ.x, TangentZ.y, TangentZ.z) + DeltaTangentZ);
    Result[0] = normalize(TangentX - (dot(TangentX, Result[2]) * Result[2]));
    Result[1] = normalize(cross(Result[2], Result[0]) * TangentZ.w);
    return Result;
}

// Note that this calls CalcBoneMatrix which has not been predeclared (it appears
// later in the file). There is no predeclaration; as long as the function is
// in the same compilation unit, the compiler will accept it (parsing accepts all
// function calls, then during semantic analysis, it parses functions definitions
// first to build a full list of predeclarations).
function float3 SkinPosition(FVertexInput Input, BoneMatricesConstants BoneBuffer)
{
    var float4 Position = float4(MorphPosition(Input), 1);
    var float4x3 BoneMatrix = CalcBoneMatrix(Input, BoneBuffer);
    return Position * BoneMatrix;
}

// Notable: all structs are passed by reference (which means if you change
// a field, it will be changed for the caller too). There are no pointers,
// references, or copies made. We should probably offer a way to mark it "const" though...
function float4x3 CalcBoneMatrix(FVertexInput Input, BoneMatricesConstants BoneBuffer)
{
    var float4x3 BoneMatrix = Input.BlendWeights.x * BoneBuffer.BoneMatrices[Input.BlendIndices.x];
    BoneMatrix += Input.BlendWeights.y * BoneBuffer.BoneMatrices[Input.BlendIndices.y];
    BoneMatrix += Input.BlendWeights.z * BoneBuffer.BoneMatrices[Input.BlendIndices.z];
    BoneMatrix += Input.BlendWeights.w * BoneBuffer.BoneMatrices[Input.BlendIndices.w];
    return BoneMatrix;
}

// Vector constructors work like you'd expect. Also, if you haven't noticed, these are
// floatX instead of vecX.
// Matrix and vector multiplication is built-in using standard C operators (even if this
// dithers down to an intrinsic "mul" function in Direct3D, etc).
function float3x3 SkinTangents(FVertexInput Input, BoneMatricesConstants BoneBuffer)
{
    var float3x3 Tangents = MorphTangents(Input);
    var float3x3 TangentBasis;
    var float4x3 BoneMatrix = CalcBoneMatrix(Input, BoneBuffer);
    TangentBasis[0] = float4(Tangents[0], 0) * BoneMatrix;
    TangentBasis[1] = float4(Tangents[1], 0) * BoneMatrix;
    TangentBasis[2] = float4(Tangents[2], 0) * BoneMatrix;
    return TangentBasis;
}

// The main event, literally. This is called once for each vertex. A vertex shader!
//
// You'll note the "@vertex" attribute. General functions can be shared between different shader types, but
// you have to flag the entry point as @vertex so certain magic can occur. Likewise for @fragment entry points.
// One parameter is marked "@inputs," which tells the compiler that this is the magic struct that will be
// assembled from various buffers based on the pipeline details. It changes values for every vertex. "@buffer(1)" means
// "whatever was bound to buffer index 1 with SDL_GpuSetRenderPassVertexBuffer() is available here." It stays
// the same for every vertex until you change it.
// The outputs are returned from the function in a struct.
// Note that you can have more than one shader in a single source file, and can also have vertex _and_
// fragment shaders in the same file; when loading shaders for use, you tell it the name of the entry point
// you want.
// Note that local variable declarations can be interspersed with code.
// Note that assignment is NOT an expression; the `Output.ScreenPosition = Output.Position = X;` works because
// assignment statements allow this as syntactic sugar, but something like `if (X = Y)` or even `if ((X = Y) != 0)` would be illegal.
function @vertex FVertexOutput VertexMain(FVertexInput Input @inputs, FVertexConstants Constants @buffer(0), BoneMatricesConstants BoneBuffer @buffer(1))
{
    var FVertexOutput Output;
    var float4 WorldPosition = Constants.LocalToWorld * float4(SkinPosition(Input, BoneBuffer), 1);
    Output.ScreenPosition = Output.Position = Constants.ViewProjectionMatrix * WorldPosition;
    var float3x3 TangentBasis = SkinTangents(Input, BoneBuffer);
    var float3 WorldVector = Constants.CameraPosition.xyz - WorldPosition.xyz * Constants.CameraPosition.w;
    Output.CameraVector_FogA.xyz = TangentBasis * (Constants.WorldToLocal * WorldVector);
    Output.CameraVector_FogA.w = 0;
    return Output;
}

// end of example_sdlsl_vertex_shader_ue3.sdlsl ...

Hello.
I notice that some of the comments are criticizing the declaration syntax only such as var float3x3 Result = ...;.
I understand that this is done to keep it as C-like as possible with its pseudo type-focused declaration syntax but it adds extra noise for not added benefit. A simple approach would be consistent with the qualifier focused declaration syntax, which would make it look a lot more like Go or Rust.
The rest of the syntax and smenatics for the language can remain the same or be whatever you like, but when people judge a language, I have noticed that the first thing that they focus on is the declaration syntax. Even if two languages have wildly different semantics but have the same declaration syntax, people will judge them to be the same.
I have to done two mockups of your original code but with the newer declaration syntax and showing the benefits of what the newer syntax allows for too. Both declaration syntaxes will be easier to parse than any C-like type-first syntax, and as an added benefit allow for very basic type inference allowing the user to omit the type in the declaration if the type can be trivially inferred from the expression.
Minor note: I am the creator and main architect of the Odin programming language, and have created numerous different programming languages over the years. I know quite a lot of the pitfalls in terms of designs of languages. I also recommend reading an old article of mine On The Aesthetics of the Syntax of Declarations.

VERSION 1
Without : and -> (Go-like as some people will say)
// Qualifier-focused declaration syntax
// KEYWORD NAME TYPE
struct FVertexConstants
{
    ViewProjectionMatrix    float4x4;
    LocalToWorld            float4x4;
    WorldToLocal            float3x3;
    CameraPosition          float4;
    ScreenPositionScaleBias float4;
}

struct BoneMatricesConstants
{
    BoneMatrices [75]float4x3;
}

struct FVertexInput
{
    Position      float4 @attribute(0);
    TangentX      half3  @attribute(1);
    TangentZ      half4  @attribute(2);
    BlendIndices  int4   @attribute(3);
    BlendWeights  float4 @attribute(4);
    DeltaPosition float3 @attribute(5);
    DeltaTangentZ half3  @attribute(6);
}

struct FVertexOutput
{
    ScreenPosition    float4;
    CameraVector_FogA float4;
    Position          float4 @position;
}

func MorphPosition(Input FVertexInput) float3
{
    return Input.Position.xyz + Input.DeltaPosition;
}

func MorphTangents(Input FVertexInput) float3x3
{
    var Result float3x3 = 0;
    // Basic type inference based declaration
    var TangentX = float3((Input.TangentX / 127.5) - 1);
    var TangentZ = float4((Input.TangentZ / 127.5) - 1);
    var DeltaTangentZ = float3((Input.DeltaTangentZ / 127.5) - 1);
    Result[2] = normalize(float3(TangentZ.x, TangentZ.y, TangentZ.z) + DeltaTangentZ);
    Result[0] = normalize(TangentX - (dot(TangentX, Result[2]) * Result[2]));
    Result[1] = normalize(cross(Result[2], Result[0]) * TangentZ.w);
    return Result;
}

func SkinPosition(Input FVertexInput, BoneBuffer BoneMatricesConstants) float3
{
    var Position = float4(MorphPosition(Input), 1);
    var BoneMatrix = CalcBoneMatrix(Input, BoneBuffer);
    return Position * BoneMatrix;
}

func CalcBoneMatrix(Input FVertexInput, BoneBuffer BoneMatricesConstants) float4x3
{
    var BoneMatrix = Input.BlendWeights.x * BoneBuffer.BoneMatrices[Input.BlendIndices.x];
    BoneMatrix += Input.BlendWeights.y * BoneBuffer.BoneMatrices[Input.BlendIndices.y];
    BoneMatrix += Input.BlendWeights.z * BoneBuffer.BoneMatrices[Input.BlendIndices.z];
    BoneMatrix += Input.BlendWeights.w * BoneBuffer.BoneMatrices[Input.BlendIndices.w];
    return BoneMatrix;
}

func SkinTangents(Input FVertexInput, BoneBuffer BoneMatricesConstants) float3x3
{
    var Tangents = MorphTangents(Input);
    var TangentBasis float3x3;
    var BoneMatrix = CalcBoneMatrix(Input, BoneBuffer);
    TangentBasis[0] = float4(Tangents[0], 0) * BoneMatrix;
    TangentBasis[1] = float4(Tangents[1], 0) * BoneMatrix;
    TangentBasis[2] = float4(Tangents[2], 0) * BoneMatrix;
    return TangentBasis;
}

// I'm putting this attribute at the front compared to fields/parameters because it is easier for the user to read
@vertex
func VertexMain(Input FVertexInput @inputs, FVertexConstants Constants @buffer(0), BoneBuffer BoneMatricesConstants @buffer(1)) FVertexOutput
{
    var Output FVertexOutput;
    var WorldPosition = Constants.LocalToWorld * float4(SkinPosition(Input, BoneBuffer), 1);
    Output.ScreenPosition = Output.Position = Constants.ViewProjectionMatrix * WorldPosition;
    var TangentBasis = SkinTangents(Input, BoneBuffer);
    var WorldVector = Constants.CameraPosition.xyz - WorldPosition.xyz * Constants.CameraPosition.w;
    Output.CameraVector_FogA.xyz = TangentBasis * (Constants.WorldToLocal * WorldVector);
    Output.CameraVector_FogA.w = 0;
    return Output;
}

VERSION 2
With : and -> (Rust-like as some people will say)
// Qualifier-focused declaration syntax
// KEYWORD NAME TYPE
struct FVertexConstants
{
    ViewProjectionMatrix:    float4x4;
    LocalToWorld:            float4x4;
    WorldToLocal:            float3x3;
    CameraPosition:          float4;
    ScreenPositionScaleBias: float4;
}

struct BoneMatricesConstants
{
    BoneMatrices: [75]float4x3;
}

struct FVertexInput
{
    Position:      float4 @attribute(0);
    TangentX:      half3  @attribute(1);
    TangentZ:      half4  @attribute(2);
    BlendIndices:  int4   @attribute(3);
    BlendWeights:  float4 @attribute(4);
    DeltaPosition: float3 @attribute(5);
    DeltaTangentZ: half3  @attribute(6);
}

struct FVertexOutput
{
    ScreenPosition:    float4;
    CameraVector_FogA: float4;
    Position:          float4 @position;
}

func MorphPosition(Input FVertexInput) -> float3
{
    return Input.Position.xyz + Input.DeltaPosition;
}

func MorphTangents(Input FVertexInput) -> float3x3
{
    var Result: float3x3 = 0;
    // Basic type inference based declaration
    var TangentX = float3((Input.TangentX / 127.5) - 1);
    var TangentZ = float4((Input.TangentZ / 127.5) - 1);
    var DeltaTangentZ = float3((Input.DeltaTangentZ / 127.5) - 1);
    Result[2] = normalize(float3(TangentZ.x, TangentZ.y, TangentZ.z) + DeltaTangentZ);
    Result[0] = normalize(TangentX - (dot(TangentX, Result[2]) * Result[2]));
    Result[1] = normalize(cross(Result[2], Result[0]) * TangentZ.w);
    return Result;
}

func SkinPosition(Input FVertexInput, BoneBuffer BoneMatricesConstants) -> float3
{
    var Position = float4(MorphPosition(Input), 1);
    var BoneMatrix = CalcBoneMatrix(Input, BoneBuffer);
    return Position * BoneMatrix;
}

func CalcBoneMatrix(Input FVertexInput, BoneBuffer BoneMatricesConstants) -> float4x3
{
    var BoneMatrix = Input.BlendWeights.x * BoneBuffer.BoneMatrices[Input.BlendIndices.x];
    BoneMatrix += Input.BlendWeights.y * BoneBuffer.BoneMatrices[Input.BlendIndices.y];
    BoneMatrix += Input.BlendWeights.z * BoneBuffer.BoneMatrices[Input.BlendIndices.z];
    BoneMatrix += Input.BlendWeights.w * BoneBuffer.BoneMatrices[Input.BlendIndices.w];
    return BoneMatrix;
}

func SkinTangents(Input FVertexInput, BoneBuffer BoneMatricesConstants) -> float3x3
{
    var Tangents = MorphTangents(Input);
    var TangentBasis: float3x3;
    var BoneMatrix = CalcBoneMatrix(Input, BoneBuffer);
    TangentBasis[0] = float4(Tangents[0], 0) * BoneMatrix;
    TangentBasis[1] = float4(Tangents[1], 0) * BoneMatrix;
    TangentBasis[2] = float4(Tangents[2], 0) * BoneMatrix;
    return TangentBasis;
}

// I'm putting this attribute at the front compared to fields/parameters because it is easier for the user to read
@vertex
func VertexMain(Input FVertexInput @inputs, FVertexConstants Constants @buffer(0), BoneBuffer BoneMatricesConstants @buffer(1)) -> FVertexOutput
{
    var Output FVertexOutput;
    var WorldPosition = Constants.LocalToWorld * float4(SkinPosition(Input, BoneBuffer), 1);
    Output.ScreenPosition = Output.Position = Constants.ViewProjectionMatrix * WorldPosition;
    var TangentBasis = SkinTangents(Input, BoneBuffer);
    var WorldVector = Constants.CameraPosition.xyz - WorldPosition.xyz * Constants.CameraPosition.w;
    Output.CameraVector_FogA.xyz = TangentBasis * (Constants.WorldToLocal * WorldVector);
    Output.CameraVector_FogA.w = 0;
    return Output;
}

First shot at semantic analysis just landed in revision control; got a little to clean up in there and then I'm going to start incorporating feedback from this thread.

Opinions on constructors, anyone?
The language is fairly strict about not implicitly coercing datatypes to match (assigning an int to a float will fail, you can't do if (1) because it's not a bool, etc). There is a little syntactic sugar to make things less ugly in one specific case, though: int literals will promote to various things:
var float x;
var int y = 5;
x = y;  // compiler error, you can't assign an int to a float!
x = 5;  // this will work, though, but only because it's a literal.
var float4 z = y;   // an int is not a float4.
z = 5;  // the compiler understands this literal is shorthand for float4(5.0,5.0,5.0,5.0)
// the real reason for this:
var float4 a = z / 5;  // this looks nice and clear instead of having to build a float4 to divide.

(float literals will do this too, but only promotes to vector and matrix types, not integers, bools, etc.)
That digression aside, GLSL is also strict in similar ways, but has a constructor syntax for when you need to cast, and it's the wild west: basically you can construct anything from almost anything:
bool x = bool(232);  // becomes true
vec4 f = vec4(1);  // becomes 1,1,1,1
vec4 u = vec4(2,3);
vec4 z = vec4(y.xy, f.z, float(true));

How permissive do we want this to be? Do we want this to be "almost anything can construct anything" as a guarantee you won't get stuck in a situation where you can't reasonably get your data into the necessary format, or do we want to impose rules of some sort?
We can be as strict as "you can't construct an int from a bool, even though it would be obvious for true to become 1 and false to become 0, use the ? operator instead", or we can be as loose as "if you construct a float4 from a user-defined struct, it'll use the fields until it has enough elements to fill in the whole vector and default to zero for the fields that can't be initialized because there weren't enough fields in the struct."

(We can be whatever we want to be, we don't have to say "GLSL/HLSL/MSL does this, so we must match it perfectly." If GLSL's constructors are a footgun, let's do our own thing.)

I would start conservative, you can always relax the restrictions in future versions of the language. I think coercing ints or floats to bools is a no-go and I think the vec constructors should accept the correct number of elements, no more or no less (assigning a scalar TO the vector feels like the right way to set all the elements). It's too easy to end up with weird bugs due to GLSL and HLSL's behaviors here.

assigning a scalar TO the vector feels like the right way to set all the elements

I think there's going to be way to much temporary object creation that wants to do...
myfunction(float4(splat));

...without an explicit temporary var and an assignment statement, so I don't think we can avoid it completely.
The other thing I see all over the place, that feels like fingernails on a chalkboard to me despite its popularity, is this...
x = float4(myvar.xyz, 1.0);

...and once you have that, it's pretty much open season.
I'm still fighting with this.

assigning a scalar TO the vector feels like the right way to set all the elements

As much as I hate it, NOT doing this has saved me a lot of bugs.
The following should be ok:
float4( float, float, float, float )
float4( float3, float )
float4( float2, float2 )
float4( float2, float, float )

These are in hot water:
float4( float, float3 )
float4( float, float, float2 )

These are not ok:
float4( float )
float4( float2 )
float4( float3 )

It may seem arbitrary, but it just comes from experience. The thing is that this hides a lot of bugs:
result = float4( myValue );
When myValue can be either float or float4 (or worse if float3 & float2 are allowed).
Nothing worse than realizing result.xyzw == result.xxxx because myValue is accidentally a scalar.
The following idiom will compile correctly and avoid bugs:
result = float4( myValue.xxxx );
Metal unfortunately doesn't allow this for float (because float is a native datatype while floatN is a template class) but I think that was mistake.
Additionally IMO swizzles on literals should work:
result = float4( 4.0f.xxxx );
Or in any case:
result = float4( float( 4.0f ).xxxx );
Open Question
In my experience, although more verbose, I've learnt to appreciate using explicit swizzles.
For example:
float3 myValue;
r = float4( myValue, anotherVar );

vs
float3 myValue;
r = float4( myValue.xyz, anotherVar );

Functionally they're the same. However it may be worth debating if you want to forbid r = float4( myValue, anotherVar ); while allowing r = float4( myValue.xyz, anotherVar ); since the former hides a potential bug (are myValue & anotherVar both float2? or float3 and float? or viceversa?) while the latter leaves no room for doubt (myValue.xyz is float3, anotherVar must be float).

Explicit swizzles for all these cases could be a good compromise. They're not super verbose but they clearly state intent.
Hypothetical question: If you were to require val = float4(foo.xxxx) what's wrong with val = foo.xxxx at that point, assuming you prohibit val = foo (i'm fine with this)?
The float4(a.xyz, w) case is common enough that I'm receptive to the need to support it without having things explode out into all sorts of gross permutations. @darksylinc's suggested list of patterns seems good to me - the rule can generalize to '1-N parameters containing a total of N scalars, where the size of each parameter is equal or less than the size of the previous parameter'. That prohibits stuff like float4(1, r.xyz) and such happening by accident (they can always recreate it at 0 execution cost with a swizzle).

Heretical thought: should we require flow control statements to use {}?
So this wouldn’t work:
if (x) do_something();

But this would:
if (x) { do_something(); }

This way there’s no risk of this mistake:
if (x);  // uhoh, the following statement block always runs!
{
   do_something();
}

But this might drive people positively nuts. But if we’re killing sacred C cows to remove C footguns, this would be an easy fix.

But if we’re killing sacred C cows to remove C footguns, this would be an easy fix.

I killed the sacred cow this morning; braces required now.
While I'm issuing decrees here: since we need braces and expressions can't be statements (etc), it's not ambiguous if you don't have parentheses around the condition expression, so they're optional, now...
if x == 1 {   // now legal!
    do_something();
}

C aficionados can wrinkle their nose then ignore this, since an expression can be wrapped in parentheses for the expected effect without any changes to the parser:
if (x == 1) {    // like C requires, it doesn't make any difference to us.
    do_something();
}

Now I'm sitting here deciding if the function signature should allow void:
function int x(void) { return 1; }   // this is currently legal.
function int x() { return 1; }   // this is also legal, but maybe it should be the only thing that is...?

Call me ignorant, but is inventing yet another high-level shading language strictly necessary? Is it possible to just adopt SPIR-V as an intermediate shading format instead? Then the developers can use any shading language they like, as long as there is a compiler to output SPIR-V for it. I admit, I have not researched if this is even remotely feasible, especially on Apple platforms, but it seems theoretically possible at least.
Creating your own shading language seems like too much of a duplicated effort to me. Additionally, you should have to maintain it like forever, adding new features constantly, every time a new video card with a new shading model hits the market

I can't speak for Ryan, but adopting SPIR-V as your official IR and (presumably) GLSL or HLSL as your official language has problems. Here are some reasons I can think of for a custom language:

SDL_gpu users will attempt to use features from GLSL or HLSL and file bugs when they don't work.
SDL_gpu users will have to install and keep up-to-date the whole toolchain (GLSL/HLSL compiler, spirv-cross, etc) and navigate compatibility issues
You need to maintain some amount of adaptor/interop layer for each of your supported targets just to map the SPIRV to that target
SDL_gpu has its own specific feature set, so a custom language can map well to that feature set and the intended way to use it - for example perhaps GLSL or HLSL have multiple ways you can represent uniforms, while SDL_gpu's shader language will make sure you do uniforms and constants right every time.
SDL_gpu's shader language can maintain a lower barrier to entry than other languages, much like how SDL has a low barrier to entry for casual developers.
<possible legal hazards censored so you don't have to think about them>

While I disagree with their decision for other reasons, the WebGPU spec committee also opted to do stuff custom instead of adopt GLSL+SPIR-V for multiple reasons. Sadly it is a decision with precedent so it's not weird for SDL_gpu to do it.  I don't personally want to learn another language but if SDL_gpu is going to have a custom one, it should be good :-)
The need to maintain it forever adding new features is overstated - SDL_gpu doesn't have to support every new feature. If you want to use a bleeding edge Vulkan extension, you're probably not using SDL_gpu to begin with.
fwiw I've been using d3d9/ps3_0 for like 12 years now (first via XNA, now via FNA+SDL2+MojoShader) and while it's annoying to have limitations, I've been able to do high spec experimental graphics stuff with that toolchain for a long time. I think people underestimate what the average developer can get done if they have a good toolchain and SDL+SDL_gpu will likely empower a lot of people to focus on being productive.

For what it's worth (and just because I want to be part of this thread in case it becomes historical or something :P), adding to @kg 's excellent points above, BGFX already does what @vanka78bg mentions, using GLSL as its base and it's not really a pleasant experience.
Besides a completely lack of documentation about the actual incompatibilities with "raw" GLSL (which is not GLSL's fault of course), it converts GLSL to GLSL (for optimizations I think), ESSL, SPIRV, HLSL and Metal (using HLSL as a base for everything except GLSL/ESSL IIRC), but you always have different gotchas depending on what the target actually is and you need to change your GLSL slightly depending on unknown rules.
Granted, this doesn't mean it cannot be done better, but given the "market share" BGFX already has and the base projects it uses to do all this (I don't think you'd be reinventing the wheel if you go this route, but using existing compilers I'm assuming) I really doubt you'll get a different result unless you write everything from scratch, and that's already a similar (and huge!) amount of work just to shoehorn GLSL into all of this, at which point creating your own flavor with your own limitations seems to be a better solution.
Just my (hopefully slightly informed) 2c.

This may or may not be interesting: https://twitter.com/icculus/status/1557753925469671425

This may or may not be interesting: https://twitter.com/icculus/status/1557753925469671425

1129 votes total, was almost exactly 70/30 at any given hour of the poll in progress.

I ended up letting both forms be valid, so use what you like!
https://github.com/icculus/SDL_shader_tools/blob/e2b3df139ac4118d9894bd7c4b54b703d324bac1/docs/README-shader-language-quickstart.md#variable-declaration-can-be-c-like-or-not

I don't know how widespread switch statements are in shaders in general, but do we want to remove fallthrough cases as a footgun?
This thing:
switch (x) {
    case 1:
         do_something();
         /* there's no `break` statement here */
    case 2:
         do_something_else();
         break;
}

Where if x == 1, this will call both do_something() and do_something_else().
This can be useful, but it can also be a disaster, as everyone knows. Should we require cases to end with a break/return/discard, or require them to be wrapped in braces that imply a break, or maybe just even imply a "break" at the end of a case without braces?
(or just dump the switch statement entirely? Or leave it as-is? There are arguments for every possibility on this one.)

I lack enough understanding to offer advise other than

Historically switch statements had been deemed as slow (if ladders, divergence, etc). We're talking > 10 year habits
Later certain usages of switch statements could degrade into high register pressure as a worst case. I can't remember if lack of default statement was good or worse, but it had an impact. If/else are more predictable. However for simple cases there's no difference (perf speaking)

if ladders

I'm certain on some targets, this is absolutely going to degrade to a collection of if-statements.
But like I said, the argument might be not to fix switch syntax, but to remove the switch statement outright (and revisit in version 2 if people really miss it).

About fallthrough:
Both on nelua and odin, you need to use the fallthrough keyword instead of break in order to use fall through.
This way, accidental fall through is avoided.

I've started work on the bytecode format, so if anyone has opinions on that sort of thing, discussion is sitting over in #6.

I admit having another shading language makes me edgy.  However, there is something else to consider: what GPU features are to be considered "core" and what features are optional? Across desktop and mobile there is a huge range of features (or tiers). Is it for GL2 class features, GL3 class features, GL4 class features and/or bleeding edge features?

GL2.x vs GL3.x class hardware: which means things like UBO's, native integer support, floating point texture and render target support. Actually it is even harsher, if one wants to support GLES2; that nightmare requires that all loops in fragment shading must be unrollable at compile time and even getting fp32 support in fragment shading is optional.
GL3 features that can be awkward on some platforms: transform feedback, geometry shaders, texture buffer objects
HW tessellation is usually considered a bad thing to do on mobile, even when it is offered, such as in GLES3.2
Compute shaders in how to specify buffer reads and writes: some platforms have additional limitations that others do not.
Fancy features that are big game changers: bindless texturing, sparse texturing come to mind immediately.

It seems VERSION 1 is simpler and with less clutter so I'd use that but I don't have a strong opinion there.
In general I wanted to share that the idea of SDLSL is cool, and I was waiting for something like this, an in-SDL way to deal with pixel shaders, to substitute a lot of custom cpu code to do sprite outlines, effects etc in my 2D engine and games.
Whatever you do, I'd just ask to keep it as simple as possible; if one wants access to super complex features and have a million options, they can use vulkan, Direct3D, OpenGL etc, but at least for me (solo dev, working on my own 2D engine and small games in my free time) simple and uncluttered is the main thing. Just like SDL is.
I currently use SDL2 with plain C and with its builtin texture render API, it has the minimum needed and I love it for it.
I also use SDL_image to load pngs, and SDL_mixer for the simple audio part of the engine.
If SDLSL were available I would use it to make the existing stuff more efficient and simple, doing outlines, shading the sprites,  some water effects etc.
Thanks and can't wait to use it!

I also strongly dislike the idea of having two syntaxes for variable declarations. I don't really care about how it looks like in the end, but please stick with one. The C-like style probably makes more sense given how C-like the rest of the language is, and out of practical concerns such as GLSL/HLSL compatibility for people who enjoy pain.
I'm not a fan of the var either; personally I think it should be removed if it doesn't complicate the parsing, but I can live with it.

I can remove one of them, but why is this such a terrible thing that there are two ways to do this? Are people that are capable of developing shaders going to see an unexpected "var mydata : int;" and not be able to piece together its cryptic meaning?
I think part of the struggle is not just creating a better language, but creating something that is still close enough to C that people won't rebel--which drives me nuts, but feels crucial. Keeping the C-like version of variable declaration as an option is part of that.
But if I had to drop one, the C-like version would be the one I'd like to drop.
The good news is that, since this is currently just syntactic sugar, it's easy to leave it in place now, and yank either out at the last moment, so decisions don't need to be made now.

I can remove one of them, but why is this such a terrible thing that there are two ways to do this? Are people that are capable of developing shaders going to see an unexpected "var mydata : int;" and not be able to piece together its cryptic meaning?

No that's not the problem. As I said above, the actual syntax doesn't matter all that much. But when (not if, when) I eventually see both of those syntaxes used in the same project I'm working on, or god forbid in the same file, I'm probably punching my monitor in OCD fueled rage :)
Are there actually any examples of other languages with two different, functionally identical syntaxes for variable declaration?

I think part of the struggle is not just creating a better language, but creating something that is still close enough to C that people won't rebel--which drives me nuts, but feels crucial. Keeping the C-like version of variable declaration as an option is part of that.
But if I had to drop one, the C-like version would be the one I'd like to drop.

I'm personally not very invested in keeping the language very C-like. I'm just saying that if that's the direction you're going with, the "rusty" declaration style makes little sense, in my opinion. I just don't see it adding anything other than needless inconsistency and mild confusion. For one, you can't use it in structs you share with your C/C++ code. And at that point, why would you go out of your way to use it anywhere else? Is there any reason for the alternative syntax to exist other than that it looks nicer (which is debatable in itself)?
On that note, I think the compiler needs some sort of a "reflection" API to probe at the layout of types for non-C-like languages and people who don't want or can't share headers between C/C++ and the shaders.

By the way, I have to say one departure from C that I really love is requiring braces for if/else/for/while/etc. clauses. Sometimes I wish actual C compilers had warning options to enforce this style.
One question though: how does else if work with this syntax? In C it emerges naturally, but I guess it's a special case syntactic sugar here?

By the way, I have to say one departure from C that I really love is requiring braces for if/else/for/while/etc. clauses. Sometimes I wish actual C compilers had warning options to enforce this style.
One question though: how does else if work with this syntax? In C it emerges naturally, but I guess it's a special case syntactic sugar here?

I think I probably forgot to update the grammar to deal with this, but yeah, I'd like "else if" to be legal. But it also makes me nervous that so many popular programming languages went with a separate elseif or elsif keyword here, like they discovered that this was a giant pain to parse. I guess I'll report back when I try this and find out its a disaster.

Does anyone have strong feelings about using array dereferencing with vectors?
So you have a float4 named x, and it's legal to do y = x[2]; and this is exactly identical to y = x.z; ... referencing x[4] would be a compile error, and possibly we disallow variables here,  too, so it's literally syntactic sugar that needs an integer constant.
Or maybe we just forbid array syntax at all with vectors?
Opinions?

I can remove one of them, but why is this such a terrible thing that there are two ways to do this? Are people that are capable of developing shaders going to see an unexpected "var mydata : int;" and not be able to piece together its cryptic meaning?

No that's not the problem. As I said above, the actual syntax doesn't matter all that much. But when (not if, when) I eventually see both of those syntaxes used in the same project I'm working on, or god forbid in the same file, I'm probably punching my monitor in OCD fueled rage :)

I'd prefer a single syntax for the language too, no matter which one is chosen in the end.

Does anyone have strong feelings about using array dereferencing with vectors?

There has been various times where I would've wanted to do that.
However bear in mind such cases were usually of the sort:
vec3 myVec = ...;
for( int i = 0; i < 3; ++i )
   myVec[i] = ...;

Rather than using literals. Which adds a few issues on the compiler side:

Some HW has no problem with i being dynamic (i.e. unknown at compile time). For the rest, older HW, however:
As long as i is known at compile time, it should be possible to support everywhere

This can be a rabbit hole of loop unrolling though
There are weird cases like:

for( int i = 0; i < fully_dynamic_variable; ++i )
{
    if( someBuffer[i] < 3 )
         myVector[someBuffer[i]]; // Technically legal, it's possible to support with an if-ladder. Do you want to support this?
}

FXC HLSL supports this (D3D11), but it can result in weird compiler errors once you nest a few loops or use ThreadGroup barriers, or divergence is involved; and it can lead to long compile times as FXC goes the extra mile to unroll the loop and try to make it work.
I don't know if all Vulkan/D3D12 HW would support dynamic addressing just fine though.

So, for a large number of GPU's there is a world of difference between dynamic and static array access. The usual story is that all variables (except UBO's, SSBO's and samplers/textures) in a shader are realized as a register. An array access determined at compile time is easy, but an array access of run time is a proper pain. For Intel GPU's the shader driver then stores these arrays in a scratch buffer (with enough buffer to cover all threads of all EU's). Reading and writing to that array then becomes a memory read and write with the gamble that the read and write are heavily cached. However, this is much, much slower than straight up register access.
The upshot is that allowing for the index of myVec4[] to be dynamic means a proper nightmare when it finally runs on a GPU. With that in mind, I suggest to avoid the issue completely and to not have array syntax to access elements of a [iu]vec2, [iu]vec3, [iu]vec4 unless the indices are static constants. Ditto for matrix element access too.

We have a parser, it's built with Lemon. Here it is:
https://github.com/libsdl-org/SDL_shader_tools/blob/main/SDL_shader_parser.lemon
(This is still work in progress, so things are changing.)
An overview of the language syntax is here: https://github.com/libsdl-org/SDL_shader_tools/blob/main/docs/README-shader-language-quickstart.md

Nice to see shader work aimed at the SDL community!
Can you elaborate a little on the design goals, please?  I've been looking around a bit for GLSL alternatives, and there seem to be a bunch of other shader languages out there (slang, rust-gpu, shady, ...), and I am a bit lost as to what the different advantages of the different languages are-- why would I use SDLSL instead of GLSL or one of the other shader languages?
You list "fast and cheap" and "reasonable to ship at runtime or embed in another project" as goals for the compiler, but it's not clear to me that this requires a new language (as opposed to a new compiler for an existing language).
I do agree that language design informs the necessary complexity of the compiler, but, if I may play devil's advocate for a second, making a compiler "fast and cheap" through a new language design is probably easier if you drop complex syntax and go for LISP-like S-expressions; parsing is still a nontrivial part of compile-time overhead.  Also, removing the preprocessor would avoid costly token/string manipulation; for meta-programming / modularisation, a macro mechanism that operates directly on the AST (or perhaps just better options for linking) would likely be faster.
Thus, my guess is that SDLSL has additional design goals, on top of the ones that are explicitly listed?

The upshot is that allowing for the index of myVec4[] to be dynamic means a proper nightmare when it finally runs on a GPU. With that in mind, I suggest to avoid the issue completely and to not have array syntax to access elements of a [iu]vec2, [iu]vec3, [iu]vec4 unless the indices are static constants. Ditto for matrix element access too.

Right now (in my working copy), my_vector[2] will dither down to the same code as my_vector.z ...if one were to specify my_vector[i] then it becomes a VECTORDEREF instruction in the bytecode instead, which I fully expect might turn into something at runtime as atrocious as this psuedo code:
float val;
if (i == 0) {
    val = my_vector.x;
} else if (i == 1) {
    val = my_vector.y;
} else if (i == 2) {
    val = my_vector.z;
} else if (i == 3) {
    val = my_vector.w;
} else {
    val = 0.0f;
}

I don't intend to bog down into loop unrolling to attempt to turn that back into a simple swizzle operation, because there will certainly be times where one can't obviously unroll the loop, and I don't want to have people trying to solve compiler error messages by making their code arbitrarily less complex.
I haven't decided if the luxury of this working slowly is worth it...if people are bothered that there's two ways to declare variables, surely they'll also be bothered by both vec[0] and vec.x working, and the unexpectedly bad fallback to that psuedocode when you don't have a constant index is probably not worth it.

why would I use SDLSL instead of GLSL or one of the other shader languages?

My personal hopes are that it's enjoyable to use, can be jumped into with an absolute minimum of hassle, and it Just Works everywhere you want your games to be. If other languages offer that, too, that's fantastic.

if people are bothered that there's two ways to declare variables, surely they'll also be bothered by both vec[0] and vec.x working, and the unexpectedly bad fallback to that psuedocode when you don't have a constant index is probably not worth it.

IMO this is not as bad as the two ways to declare a variable, because vec[i] and vec.x suggest different purposes: the former allows dynamic access and the later allows swizzling (and is arguably easier to read and write).
Dynamic access being silently transformed into horrible if-ladders is a nasty surprise, however. If the vec[i] syntax stays in the language, I would like to have a compiler option to make any non-constant access an error and/or a warning (regardless of whether the backend supports it or not). That'll be useful for people who wish to target hardware that does not support actual dynamic vector access.

I'd prefer a language completely different from GLSL over a language that is GLSL-like with a handful of differences. It's easier for my brain to compartmentalize it.
For instance, jumping between C11 and Python I can do very easily on the fly. Jumping between C# and Swift, also very easy. They inhabit separate parts on my brain.
However, jumping between GLSL and HLSL? Bit more cumbersome. I keep wanting to write something like GLSL in HLSL and vice versa. Jumping between JavaScript and Typescript, also cumbersome.
Makes me think of back when unity had javascript-like "UnityScript" and python-like "Boo" which were .NET CLR langs they made to look like javascript and python but worked different under the hood in many ways. Absolutely hated it. Programming in a language that looks like a certain language you have much muscle memory in, but behaves differently, is very annoying. I don't think I was alone in this, so few people used UnityScript and Boo they eventually removed both. Community in mass glommed onto C# even though it was technically more complex than either one and had "fluff" syntax for unity that you didn't really need. Knowing a more complex language with some things you don't need depending on context is less mental overhead than knowing two different languages that look the same but behave differently.
So, I'd expect if it is 95% like GLSL with a few differences, those few differences are going to be really obnoxious to me. Especially under-the-hood behavior changes where I have to go read docs to figure out what's happening. That is the type of thing that I can imagine for years, over and over, I will just keep forgetting on the periodic times I might jump out of GLSL and into this other lang. I'm inclined to say, if you're going to take GLSL style, take it all, even what you might not like. If it looks like GLSL it should behave like GLSL.
Or make it behave like C. Since SDL is so C-friendly making it so C can compile to shaders would probably fit quite well.
Changing the way buffers and images are declared is fine, probably preferable. Or changing/adding some attributes, that's probably fine. But the syntax and behavior of the general ops that do the logic? Something "GLSL-Like with little differences" will be far more annoying to me than just GLSL with things I have to omit or some methods I have to change. I'd rather copy over a chunk of GLSL and get a list of methods it doesn't support when trying to compile rather than rewriting it with a bunch of little nuances here and there.

What about adopting ReShade FX?
One advantage there is that there's a wealth of examples and shaders that you can potentially just drop into your project.

Also want to point out this to be thorough:
https://github.com/heroseh/hcc
Although I don't seriously consider anyone would get on board with making C11 the shader lang at this point :P But it's sitting right there, working, and is being actively worked on by its author. It would fit in with the overtly C-Style aesthetic of everything else in SDL well. Also the author heroseh might find SDL3 adopting this pretty cool and be into helping make changes.

something like https://github.com/heroseh/hcc seems perfect for me doing my indy stuff, as my engine and games are in C anyway, using C also for the shader lang would be the simplest thing.
But I'll use what is there as long as it fairly simple to get going, and can be made to work on all relevant platforms (pc, android etc).

Is there going to be @compute attribute and other kind?


Use display name for application delete confirmation modal

Fixes
https://issues.redhat.com/browse/HAC-1963

Description
Use display name instead of resource name for app delete modal.

Type of change

[ ] Feature
[x] Bugfix
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

Screen shots / Gifs for design review
https://user-images.githubusercontent.com/20013884/181466615-6ee7c445-0595-4daa-8912-4b03f1fe860c.mp4

How to test or reproduce?
Open application delete modal.

Browser conformance:

[ ] Chrome
[x] Firefox
[ ] Safari
[ ] Edge

/cc @sahil143 @rohitkrai03

/retest

/retest

/lgtm

CI passing locally


Comment for external vault config example is broken

Bugs should be filed for issues encountered whilst operating bank-vaults.
You should first attempt to resolve your issues through the community support
channels, e.g. Slack, in order to rule out individual configuration errors.
Please provide as much detail as possible.

Describe the bug:
This link is littered throughout the deployment examples and is supposed to link to an example of how to use the external configuration feature: https://github.com/banzaicloud/bank-vaults#example-external-vault-configuration. It appears whatever this used to point to is no longer there. Here is an example.
Expected behaviour:
The link points to an example of using the external configuration feature.
Steps to reproduce the bug:
N/A
Additional context:
I did a little digging but was unable to come up with a comprehensive example showing what details can be configured. For example, how would I configure Github auth backend?
Environment details:
N/A
/kind bug

Sorry for the broken link, please check https://github.com/banzaicloud/bank-vaults/blob/master/vault-config.yml#L35 in the meantime.

Excellent, thank you!


Fix incorrect QSPI setup

Thank you for your contribution!
We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:
Submission Checklist 📝

[x] I have updated existing examples or added new ones (if applicable).
[x] I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
[x] My changes were added to the CHANGELOG.md in the proper section.
[x] I have added necessary changes to user code to the Migration Guide.
[x] My changes are in accordance to the esp-rs API guidelines

Extra:

[x] I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖
Description
Two-parter:

QSPI setup was unfixed in #2198.
We didn't support multi-line address without data.

This fixes #2229 and adds test code to make sure we don't break QSPI again. This PR also works around an ESP32 limitation.
Testing
Observed behaviour change using a logic analyzer and also the changed test cases fail before the fix.

Awesome. The problem is, that the RX/TX swap introduced a buffer size issue and maybe your flash chip flashed the last 256 ! characters that it received. So one problem was fixed by restoring the buffer sizes in #2139 but then I managed to break this again, later, which your bisect might have jumped over.

I've been banging my head against ESP32 for a while now, and I think that chip simply can't do a 4-line address phase if it doesn't have data to transmit afterwards. The chip defaults back to 1-line address phase if usr_miso and usr_mosi are clear. I guess we could work around this by sending address as data if there is no data...

Just return an error if it's not supported I think.

Why? It's supported everywhere else, users expect it to work and it's simple to work around.

It's not like all the SPI hardware on all chips works the same. Some have more features that others. It just so happens the ESP32 can't support this one case.
If users want it to "just work" everywhere, they should just use the data phase for everything themselves. Doing it secretly is too hacky imo.

Also, not all implementations of DmaTxBuffer will support the methods you just added.

It's not like all the SPI hardware on all chips works the same.

One of the jobs of the HAL is to equalize support as much as possible.

Also, not all implementations of DmaTxBuffer will support the methods you just added.

Then they will be free to return an error.

Also, not all implementations of DmaTxBuffer will support the methods you just added.

Then they will be free to return an error.

How is that different from just returning an error upfront? User will still end up having to deal with it.
Also users won't be expecting their DmaTxBufs to suddenly contain data they never added. If they put it in a loop, the first iteration would do the right thing, then the second iteration would send the address (in the address phase) + the previous address (in the data phase).

It's not like all the SPI hardware on all chips works the same.

One of the jobs of the HAL is to equalize support as much as possible.

Yeah but there should be a line somewhere I think.

There's the option of not using DMA and just using the CPU Buffer for the data phase. (I don't really like this solution either to be honest, but it's better than tampering with the DMA buffer).

Sorry @bjoernQ I managed to completely hijack this PR, do you want me to send in the original fix separately?

Sorry @bjoernQ I managed to completely hijack this PR, do you want me to send in the original fix separately?

No problem - thanks for taking care of this

Hold on there's still something not quite right here :)


Bug when entering bolo

What version of Node.js are you using?
N/A
What version of npm are you using?
N/A
What operating system are you using?
Ubuntu
What version of SnailyCAD are you currently using?
v1.3.0 161fe31
Describe the Bug
When creating a bolo the user receives the following error:

Expected Behavior
N/A - Bug, this should not create an error.
To Reproduce
No response

seems to work fine on 1.5.0. Can you try update to the latest version and see if it works?

Seems like I was able to reproduce with a combined unit.


Console warning
require.js:94Requiring module 'ReactNative' by name is only supported for debugging purposes and will BREAK IN PRODUCTION!

Tested, works as before change, except not complaining.

Thank You, i will ship it when they release 0.39.0


Tests are unmapped when test file has angle bracket Typescript cast syntax

Describe the Bug
Tests that use the older Typescript cast syntax <type> result in TestLocator parsing error and the tests in the file get rendered as Unmapped in the test Explorer
[ERROR] [TestLocator]: Failed to get tests from spec file sample.spec.ts: SyntaxError: Unexpected token, expected "}"
Steps to Reproduce the Behavior
interface ISample {
  id: string;
  other: string;
}

describe('Outer Tests', () => {
  const sampleId: unknown = 12345;
  const sampleArray: unknown[] = [sampleId];

  it('this should trigger SyntaxError: Unexpected token', () => {
    // arrange
    const data: ISample = {
      id: <string>sampleId,
      other: 'value'
    };
    // act
    expect(data).toBeNull();
  });

  sampleArray.forEach(testValue => {
    it('with ' + testValue + ' should trigger SyntaxError: Unexpected token', () => {
      // arrange
      const data: ISample = {
        id: <string>testValue,
        other: 'value'
      };
      // act
      expect(data).toBeNull();
    });
  });
});

Provide Debug Logs
This is as much detail as there is
[ERROR] [TestLocator]: Failed to get tests from spec file sample.spec.ts: SyntaxError: Unexpected token, expected "}"
Please Provide the Following Information

OS: Windows 11
Environment: dev box
Node Version: v16.15.0
VS Code Version:  1.70.2
Karma Version: v6.3.5
Frameworks: Jasmine

Additional Context
Tests/parsing work fine when running tests via command: karma start karma.conf.js
From package.json
  "devDependencies": {
    "@commitlint/cli": "^14.1.0",
    "@commitlint/config-angular": "^14.1.0",
    "@types/copy-webpack-plugin": "^8.0.1",
    "@types/jasmine": "^3.10.0",
<EMAIL_ADDRESS>"^4.5.6",
    "@types/node": "^16.9.6",
    "@types/webpack": "^5.28.0",
    "@typescript-eslint/eslint-plugin": "^5.3.0",
    "@typescript-eslint/parser": "^5.3.0",
    "clean-webpack-plugin": "^4.0.0",
    "commitizen": "^4.2.4",
    "copy-webpack-plugin": "^9.0.1",
    "eslint": "^8.1.0",
    "eslint-config-prettier": "^8.3.0",
    "eslint-plugin-jasmine": "^4.1.3",
    "eslint-plugin-prettier": "^4.0.0",
    "husky": "^7.0.4",
    "istanbul-instrumenter-loader": "^3.0.1",
    "jasmine-core": "^4.2.0",
    "jasmine-spec-reporter": "^7.0.0",
    "karma": "^6.3.5",
    "karma-chrome-launcher": "^3.1.0",
    "karma-coverage": "^2.0.3",
    "karma-coverage-istanbul-reporter": "^3.0.3",
    "karma-jasmine": "^4.0.1",
    "karma-jasmine-html-reporter": "^1.7.0",
    "karma-webpack": "^5.0.0",
    "make-dir-cli": "^3.0.0",
    "prettier": "^2.4.1",
    "tsconfig-paths": "^4.1.0",
    "ts-loader": "^9.2.6",
    "ts-node": "^10.9.1",
    "tslib": "^2.3.1",
    "typescript": "^4.4.3",
    "webpack": "^5.59.1",
    "webpack-cli": "^4.9.1"
  },

@dmcweeney Try out the fix in the beta branch to confirm if it resolves the issue. You can use the vsix from the CI build, or build it yourself from the beta branch.

@lucono that worked - thank you.

Released in v0.7.4

I've just downloaded the latest version but still experincing this issue (I gues)
[2022-08-30 08:07:06.608] [ERROR] [TestLocator]: Failed to get tests from spec file C:/Users/***.component.spec.ts: SyntaxError: Unexpected token (10:23)
but the test file works perfectly anyway.
my current version is 0.7.4


Error installing and updating R packages

I cannot install nor update any package in R and get the following error
> install.packages("Rcpp")
Available system packages...

Install system packages...
[SKIPPED] R-littler-0.3.18-4.fc38.x86_64.rpm: Already downloaded
[SKIPPED] R-CRAN-Rcpp-1.0.11-1.fc38.copr6148288.x86_64.rpm: Already downloaded
Error in install.packages : dbus: Call failed: Transaction test error:  package R-CRAN-Rcpp-1.0.11-1.fc38.copr6148288.x86_64 does not verify: Header V4 RSA/SHA256 Signature, key ID 1a3b4456: NOTTRUSTED

I'm currently using Fedora 38 and this version of the repository:
Version      : 0.5.5
Release      : 1.fc38.copr6331124
Every R related was installed through dnf install. But I cannot identify the problem.

Is the command dnf remove R-CoprManager enough to remove any instance of the package? Also, since I'm not very familiar with Docker, I wanted to ask you if I just have to run the Dockerfile with docker and it will install automatically

Oh, no worries, it basically just provides an "existence proof" that a) yes bspm still works and b) also under f38.  In short we would need to know more from you about what you did -- the above does not reveal much, You did catch that it told you it already had Rcpp, right?
Anyway here is quick demo of RcppArmadillo (also fetching Rcpp) in the context of Docker (as my native system is not Fedora):
edd@rob:~$ docker run --rm -ti rocker/r-bspm:f38 Rscript -e 'install.packages("RcppArmadillo")'
Available system packages as root...
Copr repo for cran owned by iucar                                       30 MB/s |  25 MB     00:00
Fedora 38 - x86_64                                                      23 MB/s |  83 MB     00:03
Fedora 38 openh264 (From Cisco) - x86_64                               1.4 kB/s | 2.5 kB     00:01
Fedora Modular 38 - x86_64                                             5.1 MB/s | 2.8 MB     00:00
Fedora 38 - x86_64 - Updates                                            14 MB/s |  30 MB     00:02
Install system packages as root...
(1/14): R-CRAN-Rcpp-1.0.11-1.fc38.copr6148288.x86_64.rpm                12 MB/s | 2.0 MB     00:00
(2/14): libgomp-13.2.1-1.fc38.x86_64.rpm                               1.5 MB/s | 319 kB     00:00
(3/14): libgfortran-13.2.1-1.fc38.x86_64.rpm                           3.0 MB/s | 904 kB     00:00
(4/14): gcc-plugin-annobin-13.2.1-1.fc38.x86_64.rpm                    337 kB/s |  46 kB     00:00
(5/14): libstdc++-13.2.1-1.fc38.x86_64.rpm                              14 MB/s | 863 kB     00:00
(6/14): libstdc++-devel-13.2.1-1.fc38.x86_64.rpm                        16 MB/s | 2.6 MB     00:00
(7/14): R-CRAN-RcppArmadillo-<IP_ADDRESS>.0-1.fc38.copr6264944.x86_64.rpm   11 MB/s | 928 kB     00:00
(8/14): gcc-13.2.1-1.fc38.x86_64.rpm                                    31 MB/s |  34 MB     00:01
(9/14): gcc-gfortran-13.2.1-1.fc38.x86_64.rpm                           15 MB/s |  12 MB     00:00
(10/14): libquadmath-13.2.1-1.fc38.x86_64.rpm                          1.2 MB/s | 194 kB     00:00
(11/14): libquadmath-devel-13.2.1-1.fc38.x86_64.rpm                    833 kB/s |  36 kB     00:00
(12/14): libgcc-13.2.1-1.fc38.x86_64.rpm                               2.5 MB/s | 109 kB     00:00
(13/14): cpp-13.2.1-1.fc38.x86_64.rpm                                   19 MB/s |  11 MB     00:00
(14/14): gcc-c++-13.2.1-1.fc38.x86_64.rpm                              4.6 MB/s |  13 MB     00:02
  Preparing        :                                                                               1/1
  Upgrading        : libgcc-13.2.1-1.fc38.x86_64                                                  1/26
  Running scriptlet: libgcc-13.2.1-1.fc38.x86_64                                                  1/26
  Upgrading        : libstdc++-13.2.1-1.fc38.x86_64                                               2/26
  Upgrading        : libquadmath-13.2.1-1.fc38.x86_64                                             3/26
  Upgrading        : libgomp-13.2.1-1.fc38.x86_64                                                 4/26
  Installing       : R-CRAN-Rcpp-1.0.11-1.fc38.copr6148288.x86_64                                 5/26
  Upgrading        : libstdc++-devel-13.2.1-1.fc38.x86_64                                         6/26
  Upgrading        : libgfortran-13.2.1-1.fc38.x86_64                                             7/26
  Upgrading        : cpp-13.2.1-1.fc38.x86_64                                                     8/26
  Upgrading        : gcc-13.2.1-1.fc38.x86_64                                                     9/26
  Running scriptlet: gcc-13.2.1-1.fc38.x86_64                                                     9/26
  Upgrading        : libquadmath-devel-13.2.1-1.fc38.x86_64                                      10/26
  Upgrading        : gcc-gfortran-13.2.1-1.fc38.x86_64                                           11/26
  Upgrading        : gcc-c++-13.2.1-1.fc38.x86_64                                                12/26
  Upgrading        : gcc-plugin-annobin-13.2.1-1.fc38.x86_64                                     13/26
  Running scriptlet: gcc-plugin-annobin-13.2.1-1.fc38.x86_64                                     13/26
  Installing       : R-CRAN-RcppArmadillo-<IP_ADDRESS>.0-1.fc38.copr6264944.x86_64                   14/26
  Cleanup          : gcc-gfortran-13.0.1-0.12.fc38.x86_64                                        15/26
  Cleanup          : libgfortran-13.0.1-0.12.fc38.x86_64                                         16/26
  Cleanup          : gcc-c++-13.0.1-0.12.fc38.x86_64                                             17/26
  Cleanup          : gcc-plugin-annobin-13.0.1-0.12.fc38.x86_64                                  18/26
  Cleanup          : libquadmath-devel-13.0.1-0.12.fc38.x86_64                                   19/26
  Cleanup          : libstdc++-devel-13.0.1-0.12.fc38.x86_64                                     20/26
  Cleanup          : libstdc++-13.0.1-0.12.fc38.x86_64                                           21/26
  Cleanup          : gcc-13.0.1-0.12.fc38.x86_64                                                 22/26
  Cleanup          : libquadmath-13.0.1-0.12.fc38.x86_64                                         23/26
  Cleanup          : libgcc-13.0.1-0.12.fc38.x86_64                                              24/26
  Running scriptlet: libgcc-13.0.1-0.12.fc38.x86_64                                              24/26
  Cleanup          : cpp-13.0.1-0.12.fc38.x86_64                                                 25/26
  Cleanup          : libgomp-13.0.1-0.12.fc38.x86_64                                             26/26
  Running scriptlet: libgomp-13.0.1-0.12.fc38.x86_64                                             26/26
  Verifying        : R-CRAN-Rcpp-1.0.11-1.fc38.copr6148288.x86_64                                 1/26
  Verifying        : R-CRAN-RcppArmadillo-<IP_ADDRESS>.0-1.fc38.copr6264944.x86_64                    2/26
  Verifying        : cpp-13.2.1-1.fc38.x86_64                                                     3/26
  Verifying        : cpp-13.0.1-0.12.fc38.x86_64                                                  4/26
  Verifying        : gcc-13.2.1-1.fc38.x86_64                                                     5/26
  Verifying        : gcc-13.0.1-0.12.fc38.x86_64                                                  6/26
  Verifying        : gcc-c++-13.2.1-1.fc38.x86_64                                                 7/26
  Verifying        : gcc-c++-13.0.1-0.12.fc38.x86_64                                              8/26
  Verifying        : gcc-gfortran-13.2.1-1.fc38.x86_64                                            9/26
  Verifying        : gcc-gfortran-13.0.1-0.12.fc38.x86_64                                        10/26
  Verifying        : gcc-plugin-annobin-13.2.1-1.fc38.x86_64                                     11/26
  Verifying        : gcc-plugin-annobin-13.0.1-0.12.fc38.x86_64                                  12/26
  Verifying        : libgcc-13.2.1-1.fc38.x86_64                                                 13/26
  Verifying        : libgcc-13.0.1-0.12.fc38.x86_64                                              14/26
  Verifying        : libgfortran-13.2.1-1.fc38.x86_64                                            15/26
  Verifying        : libgfortran-13.0.1-0.12.fc38.x86_64                                         16/26
  Verifying        : libgomp-13.2.1-1.fc38.x86_64                                                17/26
  Verifying        : libgomp-13.0.1-0.12.fc38.x86_64                                             18/26
  Verifying        : libquadmath-13.2.1-1.fc38.x86_64                                            19/26
  Verifying        : libquadmath-13.0.1-0.12.fc38.x86_64                                         20/26
  Verifying        : libquadmath-devel-13.2.1-1.fc38.x86_64                                      21/26
  Verifying        : libquadmath-devel-13.0.1-0.12.fc38.x86_64                                   22/26
  Verifying        : libstdc++-13.2.1-1.fc38.x86_64                                              23/26
  Verifying        : libstdc++-13.0.1-0.12.fc38.x86_64                                           24/26
  Verifying        : libstdc++-devel-13.2.1-1.fc38.x86_64                                        25/26
  Verifying        : libstdc++-devel-13.0.1-0.12.fc38.x86_64                                     26/26
edd@rob:~$

Yes! I tried the workaround changing the GPG key and now everything works. You don't know how frustating it was LMAO. But, now everything seems like rainbows and flowers.

Aren't premade binaries the best?


Cask: fix signing audit using unexpected pkg method

[x] Have you followed the guidelines in our Contributing document?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[ ] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

I really hope this is the last fix to the signing audit. All my tests were with app files so I didn't catch this.

Review period skipped due to critical label.

No idea if this is correct, but it does fix #13710 for me.


Arabic strip

Add to functions:
1- Adding general Diacritics strip function that strip KASRATAN, FATHA, DAMMA, KASRA, FATHATAN, DAMMATAN, SUKUN, VOWELS, SHADDA, and HAMZA.
5- Adding a normalize function that did the following:
- Remove Stops.
- Remove Semicolon
- Remove Question Mark
- Remove Commas
- Remove Diacritics (KASRATAN, FATHA, DAMMA, KASRA, FATHATAN, DAMMATAN, SUKUN, VOWELS, SHADDA, HAMZA)

cf #2476


--add-condition for az monitor metrics alert update

Type of issue
Missing information
Feedback
Hi Team,
I am trying to run az monitor metrics alert update but --add-condition documentation isnt clear enough and also no example are provided. I am trying to update the threshold value from 0 to 10 but cannot proceed becuase lack of documentation and example. Please help. Following I am running command:
az monitor metrics alert update --resource-group batr-app-a-rg --name "Failed SQL Connections" --add-condition "GreaterThan connection_Failed >10"
Page URL
https://learn.microsoft.com/en-us/cli/azure/monitor/metrics/alert?view=azure-cli-latest
Content source URL
https://github.com/MicrosoftDocs/azure-docs-cli/blob/main/latest/docs-ref-autogen/monitor/metrics/alert.yml
Author
@dbradish-microsoft
Document Id
0cde4f15-6464-3106-b787-3ee37c7de0ee

Hello, @codegiverazure.  There are several articles that talk about or use az monitor metrics alert in the Azure CLI A to Z article list -- Azure Monitor.  (Scroll down in the list once you open the link.)
I'm seeing an example of the --condition parameter when creating a new alert here and there are several --condition examples given in Modify alert rules.  Did you see the examples in Create metric alert in Azure CLI?
I understand from your feedback that you are looking specifically for an update command example, and I will pass your request on to the engineering team.

Hi MicrosoftDocs/azure-docs-cli,
Yes, I am looking for update existing alerts and threshold value using CLI.
I see very less example. Please let me know how I can get help.
On Thu, Oct 10, 2024, 1:09 AM Delora Bradish @.***>
wrote:

Hello, @codegiverazure https://github.com/codegiverazure. There are
several articles that talk about or use az monitor metrics alert in the Azure
CLI A to Z article list -- Azure Monitor
https://learn.microsoft.com/en-us/cli/azure/reference-docs-index?view=azure-cli-latest#az-monitor.
(Scroll down in the list once you open the link.)
I'm seeing an example of the --condition parameter when creating a new
alert here
https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-create-rule-cli-powershell-arm#create-a-new-alert-rule-using-the-cli
and there are several --condition examples given in Modify alert rules
https://learn.microsoft.com/en-us/azure/azure-monitor/app/release-and-work-item-insights?tabs=continuous-monitoring#modify-alert-rules.
Did you see the examples in Create metric alert in Azure CLI
https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/azure-cli-metrics-alert-sample
?
I understand from your feedback that you are looking specifically for an
update command example, and I will pass your request on to the
engineering team.
—
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs-cli/issues/4675#issuecomment-2403593089,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXL2LRM4JDH5PJG23552KALZ2WZUDAVCNFSM6AAAAABPUXCEBWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBTGU4TGMBYHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@codegiverazure
Thank you for bringing this to our attention.
I've delegated this to content author, who will review it and offer their insightful opinions.

@codegiverazure , the accepted parameter values for the create and update commands are the same.  Modify one of these examples to be what you need:
--condition 'avg availabilityResults/availabilityPercentage < 99'
--condition 'count requests/failed > 5'
--condition 'avg requests/duration > 5'
--condition 'count exceptions/server > 5'

There are additional examples in Create metric alert in Azure CLI.

Hi,
I am wondering, If I want to update the threshold value of exsiting metric for SQL System Connection Failed , what should be the AZ command for it.
For example when I executed below command, it added new condition rather updating exisiting threshold value from 0 to 5
az monitor metrics alert update --resource-group  --name "Failed SQL Connections" --add-condition "count connection_Failed > 5"
@dbradish-microsoft

That's correct, @codegiverazure . You passed the --add-condition parameter.

@dbradish-microsoft But I have added update rather than adding new condition.
I was in impression that az monito metrics alert update shold update my threshold value rather than adding new condition.
I am really amazed with it.
Do you have example of AZ command which can update exisiting threshold value?

Use the --set parameter to update an existing rule.
az monitor metrics alert update --resource-group "my-rg" --name "my-alert-rule" --set "criteria.allOf[0].threshold=99"


Using RegEx `(.*)+` in File Search crashes VSCode.

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.58.0
OS Version: Windows_NT x64 10.0.19043
Steps to Reproduce:

Open File Search [Ctrl + Shift + F]
Type: `(.*)+` - or: `(.*)+?`
As soon as the last backtick is typed, VSCode freezes and the popup: The window is not responding appears.
Clicking: Reopen displays: The window has crashed (reason: 'crashed', code: '2') (for a split second, before the dialog box disappears without letting the user choose between Reopen and Close.

Hi, sorry that the RegEx in the title is not displaying properly.
I am trying to type: `(.*)+`

/needsMoreInfo
Do you have any editors opened at that time?
If yes - it's duplicate of #30874

Hi, yes, so the file where the RegEx finds matches has to be open for the app to crash.

/duplicate of #30874
You should avoid patterns that cause catastrophic backtracking like (.*)+ which is "match anything and repeat this match many times"
You should either remove * or + or make capture group more specific than .* so there won't be fight for repetitions


Adapt to xscen-509

Pull Request Checklist:

[x] pre-commit hooks are installed/active in my local clone ($ pre-commit install)
[x] This PR addresses an already opened issue (for bug fixes / features)

This PR fixes #13

[x] (If applicable) Documentation has been added / updated (for bug fixes / features)
[ ] If a merge request has been made in parallel to this PR in xscen-notebooks, it is merged and the submodules have been updated. MR#6
[x] HISTORY.rst has been updated (with summary of main changes)

[x] Link to issue (:issue:number) and pull request (:pull:number) has been added

What kind of change does this PR introduce?

Use cat: to prefix dataset attributes generated from catalogs.
New xscen.utils.get_cat_attrs that outputs a dictionary of those attributes without the prefix.

Does this PR introduce a breaking change?
Yes (but it comes from intake-esm)
Other information:
The intake-esm change also affects how lists are parsed :
https://github.com/intake/intake-esm/blob/ba4bb59ca1174369ff45a09aed030db0a7aa49d2/intake_esm/source.py#L100-L105
I.e.: every object that is iterable (like lists or tuples) is formatted as a comma-separated string. I think this doesn't break xscen, but might be worth noting. The only list-like attribute we usually use is variable.

@Zeitsperre  J'ai modifié l'action github pour exclure "docs/notebooks".


Feature: Add an option to allow indention

Currently the lines are trimed on output.
I want to show an indented message under the subject
Example:
- Subject
  The Message

Current output is:
- Subject
The Message

In Handlebar templates we can manually control the indention with ~, example {{~subject~}} removes whitespace before and after.

Does custom templates not solve this?

@cookpete I use a custom template, the problem is, that the rendered content will be trimmed on output by auto-changlog, not by handlebars.

Yes for compatibility it would be the best solution.


Add instructions on how to install pymqi on MacOs

Adds readme on how to install pymqi on Mac Os.
Removed Mac Os restriction on requirements file

So does this integration support Mac OS ? If so, we may need to update the README.md about the requirements and add mac_os to https://github.com/DataDog/integrations-core/blob/master/ibm_mq/manifest.json#L13

The validate step fails somehow.

Had to edit embedded deps

So does this integration support Mac OS ? If so, we may need to update the README.md about the requirements and add mac_os to https://github.com/DataDog/integrations-core/blob/master/ibm_mq/manifest.json#L13

Afaik they've released a dev toolkit for mac (Feb 2019) but that's about it.
On the other hand they dont seem to have OS requirements

But they dont have install instructions for Mac Os, so not sure:


Rebase of feature/490-editor-permissions-multisite onto refactor_elements, preparation for 2.0.0

I've made a rebase of these two branches..
Could we use this for the preparation of dev-2.0.0? @jochenklar
Still needs to be fixed:

[ ] some serializers that were mistakenly overwritten https://github.com/rdmorganiser/rdmo/pull/618/files

I tried to fix this rebase in this PR https://github.com/rdmorganiser/rdmo/pull/618, but the overwritten part was still there..

development continues in the merged branch, not in rebase

https://github.com/rdmorganiser/rdmo/pull/565#issuecomment-1604314263


adv improvements

goals:

see each first line of chakka
allow hotkey to first line of each chakka (1-F)
space bar for pauri re-reading from end of same pauri or first line of next chakka, space bar from first line of pauri should take you to first line of next chakka

This is good. Until we have line types implemented we cannot improve further it seems.
For v1 parity it would be to only allow hotkey while within pauri section or first salok section of each chakka
Improved, I think the logic should be that pauri and first salok are treated the same. There are times when people sing the first line of the first salok after reading them all. So do not allow any line in the first salok to jump to the first line of the preceding pauri.
First line of pauri jumps to last line of pauri. Any other line of pauri jumps to first line of pauri. First line of first salok section jumps to last line of said section. Any other line in said section jumps to first line of said section.
A little different, but clearer. Jumping in pauri is more obvious. Jumpining in first salok section is more clearly only going to jump within it's section. No other sections besides the first salok section and pauri section should have hotkeys.


transport: policy suboptimal API

The anonymous function based API
type HostSelectionPolicy interface {
	PlanIter(QueryInfo) func() *Node
}

// WrapperPolicy is used to combine round-robin policies with token aware ones.
type WrapperPolicy interface {
	HostSelectionPolicy
	WrapPlan([]*Node) func() *Node
}

Causes loads of small allocations and kills perf of pickConn.

I added cache to fix another issue with slices allocation but it seems to me that the whole API needs to be reworked.
We have two options
Option 1: return the whole slice, less changes but stupid
type HostSelectionPolicy interface {
	PlanIter(QueryInfo) []*Node
}

Option 2: more changes but correct - it would allow to remove my fix that adds RW mutex
type HostSelectionPolicy interface {
	Iter(QueryInfo, i) *Node
}

In that case user controls the iteration state and requests Node at position i.
Typically this is always 0 and we can save the effort and simplify the APIs.

Please drop f60c4da1 and proceed with option 2.

What about adding some preprocessing to cluster, so that for each token, we store a slice of it's replica nodes grouped by local DC (if local DC is specified). I believe they do something similar in gocql. This way, picConn function would only have to worry about RR (all interesting nodes are already calculated) and would basically consist only of a return statement. This make some sense, because replica nodes are fixed for a given token.
Moreover, we don't need to allocate many (usually 256 * nodes), small (size of RF) slices, we can allocate 1 big slice (we know it's length) and store slices of that slice for every token.
Finally, right now I am experimenting with removing all allocations from HSP, but it seems like it can only be achieved by writing duplicated and difficult to develop and maintain code. The reason is that without slice or function allocations, token aware policies don't really have a nice way of communicating with RR policies (like passing slice of replica nodes to them), so they have to do their work on their own.
What do you think about that?
@mmatczuk

This approach would go along with the second option that you described, so that the process of picConn is allocation free.


Example usage for a custom module

Could you please add an example showing offline transaction generation for a custom module extrinsic? Thank you!

Right now it's actually not possible, because we hardcode the methods exposed by txwrapper (for better documentation, nicer inputs etc).
But it's an interesting idea, if you want to make a PR I will review it for sure.

Closing due to inactivity


Separate docs app

Fixes #929, see there for motivation.
Setup inspired by https://github.com/ember-animation/ember-animated/tree/master/docs

Finally green ✅

While reviewing the PR I have noticed some other points related to docs. Mentioning them here to not forget it.

Nice! All good points, could you please copy those to one or more issues, so we don't forget those after merging this? Thanks! 👍

While reviewing the PR I have noticed some other points related to docs. Mentioning them here to not forget it.

Nice! All good points, could you please copy those to one or more issues, so we don't forget those after merging this? Thanks! +1

Have done so:

#952 Simplify the yarn / gulp setup for building API docs
#953 Add a chapter about API docs to contributing docs
#954 run lint and tests for docs app in CI (merge request)
#955 Add some basic acceptance tests for docs app
#956 Header used for API docs is missing the addons entry


Too many null object in the object

Question
I am using formly material, when I try to get the model I get a lot null object on the model,
I generate a dynamic form ( the form can contain an accordion and a stepper wrappers),
Can the use of the accordion be the cause for the existence of these null objects or there can be an other reason?
If not what should I look for (I have checked and found out no null object  are included in the field group)?

Hi,
The question is not clear, please elaborate and provide an example using our stackblitz starter example:
https://stackblitz.com/edit/ngx-formly-ui-bootstrap
Thanks!

@FirasSahli2010 if you don't mind still posting how you fixed it that would help people in the future! Thanks!


Consider adding Blazor Server and Blazor WebAssembly

Microsoft's newest web technology for the web is called Blazor.
Blazor Server should work everywhere as it only downloads a small Javascript file and uses SignalR for all browser UI updates.
Blazor WebAssembly depends on the browser supporting webassembly.
I see you already have an entry for webassembly https://caniuse.com/#feat=wasm
Just a thought. I think your community will eventually find this useful.

Seems like a framework rather than a web technology (it's not something browsers need to implement like web assembly support), so out of scope for caniuse.


LIBS-391 - enable container adjustments

Pull Request Test Coverage Report for Build 261

0 of 4 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 16.556%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/main/java/com/avides/springboot/testcontainer/common/container/AbstractBuildingEmbeddedContainer.java
0
4
0.0%

Totals

Change from base Build 116:
0.1%

Covered Lines:
25

Relevant Lines:
151

💛  - Coveralls


Sort multiple columns including the date in string format

I am not able to manipulate and sort multiple columns in orderBy filter.
var myApp = angular.module('myApp', []);
var t = [];
function MyCtrl($scope, $filter) {
    var r = [
        {'group':1,'sub':1, 'date': '11/4/2014 2:01 PM', 'numstr': '12-1'},
        {'group':2,'sub':10, 'date': '11/4/2014 4:36 PM', 'numstr': '13-1'},
        {'group':1,'sub':2, 'date': '11/4/2014 8:59 AM', 'numstr': '12-1'},
        {'group':1,'sub':20, 'date': '4/14/2015 5:54 PM', 'numstr': '11-1'},
        {'group':2,'sub':1, 'date': '11/3/2014 9:09 PM', 'numstr': '1-01'},
        {'group':2,'sub':11, 'date': '9/4/2014 2:48 PM', 'numstr': '1-1'}
    ];

    $scope.ncards = $filter('orderBy')(r, [function(a){
        return -new Date(a.date);  //Not working
    }]);

    $scope.mcards = $filter('orderBy')(r, [function(a){
        return parseInt(a.numstr.replace(/\-/g, '')); //Working awesome!
    }]);

    $scope.cards = $filter('orderBy')(r, ['group', function(a){
        return -a.sub;  //Working awesome!
    }]);
}

Fiddle
Is it possible to manipulate a date string before sorting? or Am i missing something?

I am not sure what is not working here. It seems to me that it's working as expected.
What are you seeing (and how would you expect things to be instead) ?

Closing due to lack of response.


TWO Separate Systems in Conflict

Hi, I have two control units that respectively control the living area and the second the bedrooms area of the house.
I have connected both koolnova 100-CPNR00 control units with two different RS485 USB Dongles.
Simply, I tired to connect first the living area dongle and the system recognises it with no issue, showing all the entities, controls, etc. When I try to connect the second dongle (one is USB00 and the second is USB01), it creates a second position that overwrites the first one.
I then tied both dongles and, if standalone without the second connected, works perfectly.
So my question is, there is a way to connect both dongles so that I can see the two control units (and devices connected) or a way to connect the two control units and then link both a a single system to home assistant?
Thank you.

Hi EdoTraverso,
Can you give me some screenshots of your issue to have a better idea of what happen ? Did you activate debug mod in your configuration.yaml ? if yes, can you send me some logs.

Hi EdoTraverso,
Can you give me some screenshots of your issue to have a better idea of what happen ? Did you activate debug mod in your configuration.yaml ? if yes, can you send me some logs.

Hi sinseman44, thank you for your reply.
Attached you will find the screenshots (1-2 are my try to connect the first dongle, connected to the control unit that controls just the living room, while from 3 to 5 when I try to connect the second dongle connected to the second control unit in the bedroom area). As you can see, when I add the second dongle it overwrites the first instance.
Attached also the logs.
Thank you.
Edoardo[

home-assistant_2024-11-18T13-25-58.953Z.log

](url)

On the configuration view, can you try to change the name ("Nome del dispositivo") of the integration for the two instance ? I think that Home Assistant overwrites values from the first instance of the integration when you configure the second integration.

On the configuration view, can you try to change the name ("Nome del dispositivo") of the integration for the two instance ? I think that Home Assistant overwrites values from the first instance of the integration when you configure the second integration.

Yes, now it works. I changed the entity name on the first configuration and then left everything unchanged for the second, the first entity now is not overwritten.
There is still an issue, it seams that the second configuration is the only available while the first one (salone) is just a slave. As you can see from the screenshot, it is listed that the device connected is the USB01, USB00 is not listed (that is the one connected to the "salone" control unit)
Thank you

Try the new release v0.2.0. it would correct your issue.

You have 2 koolnova systems with 2 USB/RS485 dongle connected (ttyUSB0 and ttyUSB1) to your Home Assistant. => I think you have 2 master radio controls for your 2 koolnova system and activate modbus for your 2 koolnova system (INT 49).
First Koolnova system (ttyUSB1) for 4 bedrooms areas and second Koolnova system (ttyUSB0) for 1 livingroom area named "salone"
You can see the configuration card view of the first koolnova system (ttyUSB1) but not the configuration card view of the second koolnova system (ttyUSB0) ? That's right ?
In one of your screenshots, i can see 19 entities for a instance of the integration (ttyUSB1 ?) and only 3 entities for the second instance of the integration (ttyUSB0 ?) => Can you take a screenshot of those entities for each instance ?
Why in your controls card view, i can see 5 areas configured (area 1 to 4 and "salone") ?

You have 2 koolnova systems with 2 USB/RS485 dongle connected (ttyUSB0 and ttyUSB1) to your Home Assistant. => I think you have 2 master radio controls for your 2 koolnova system and activate modbus for your 2 koolnova system (INT 49).
First Koolnova system (ttyUSB1) for 4 bedrooms areas and second Koolnova system (ttyUSB0) for 1 livingroom area named "salone" - CORRECT
You can see the configuration card view of the first koolnova system (ttyUSB1) but not the configuration card view of the second koolnova system (ttyUSB0) ? That's right ? - CORRECT
In one of your screenshots, i can see 19 entities for an instance of the integration (ttyUSB1 ?) and only 3 entities for the second instance of the integration (ttyUSB0 ?) => Can you take a screenshot of those entities for each instance ? - ATTACHED
Why in your controls card view, i can see 5 areas configured (area 1 to 4 and "salone") ? - THIS IS SOMETHING I STILL DO NOT UNDERSTAND
So now what I did, using the versione 0.2.0, is:
Adding USB01, renaming both the entity and the area (screenshots 1 and 2)
Adding USB00, renaming as above (screenshots 3 and 4).
Even if I can see all the rooms, the issue still remains where I can only see one controller (USB01)
If you see screenshot 5/6, there you can find what listed if I click on other positions in both USBs
Last but not least yes, I have studio code server even if I never used it.
Thank you!

home-assistant.log

I just do not know how to do the first step, sorry but is new for me! can you please explain how to do it?
Thank you

So, open Studio Code Server (after installed it), open the file configuration.yaml and at the end of the file, copy and paste this:
logger:
  default: info
  logs:
    custom_components.koolnova_bms: debug

to download the log file:
open Studio Code Server, right click on the file home-assistant.log and click on download.

Now it seems working, attached the requested files.
Thank You!!
home-assistant.log

Analyzing your log file, the configuration seems correct !
Koolnova_1 entities and Koolnova_2 entities are now defined in your Home Assistant.
Setting up koolnova_bms.sensor
Registered new sensor.koolnova_bms entity: sensor.koolnova_1_device
Registered new sensor.koolnova_bms entity: sensor.koolnova_1_address
Registered new sensor.koolnova_bms entity: sensor.koolnova_1_koolnova_1_modbus_rtu
Registered new sensor.koolnova_bms entity: sensor.koolnova_1_engine_ac1_throughput
Registered new sensor.koolnova_bms entity: sensor.koolnova_1_engine_ac1_temperature_order
Registered new sensor.koolnova_bms entity: sensor.koolnova_1_engine_ac2_throughput
Registered new sensor.koolnova_bms entity: sensor.koolnova_1_engine_ac2_temperature_order
Registered new sensor.koolnova_bms entity: sensor.koolnova_1_engine_ac3_throughput
Registered new sensor.koolnova_bms entity: sensor.koolnova_1_engine_ac3_temperature_order
Registered new sensor.koolnova_bms entity: sensor.koolnova_1_engine_ac4_throughput
Registered new sensor.koolnova_bms entity: sensor.koolnova_1_engine_ac4_temperature_order
Setting up koolnova_bms.select
Registered new select.koolnova_bms entity: select.koolnova_1_global_hvac_mode
Registered new select.koolnova_bms entity: select.koolnova_1_global_hvac_efficiency
Registered new select.koolnova_bms entity: select.koolnova_1_engine_ac1_state
Registered new select.koolnova_bms entity: select.koolnova_1_engine_ac2_state
Registered new select.koolnova_bms entity: select.koolnova_1_engine_ac3_state
Registered new select.koolnova_bms entity: select.koolnova_1_engine_ac4_state
Setting up koolnova_bms.switch
Registered new switch.koolnova_bms entity: switch.koolnova_1_koolnova_1_global_hvac_state
Registered new switch.koolnova_bms entity: switch.koolnova_1_koolnova_1_modbus_debug
Setting up koolnova_bms.climate
Registered new climate.koolnova_bms entity: climate.koolnova_1_area_a

Setting up koolnova_bms.sensor
Registered new sensor.koolnova_bms entity: sensor.koolnova_2_device
Registered new sensor.koolnova_bms entity: sensor.koolnova_2_address
Registered new sensor.koolnova_bms entity: sensor.koolnova_2_koolnova_2_modbus_rtu
Registered new sensor.koolnova_bms entity: sensor.koolnova_2_engine_ac1_throughput
Registered new sensor.koolnova_bms entity: sensor.koolnova_2_engine_ac1_temperature_order
Registered new sensor.koolnova_bms entity: sensor.koolnova_2_engine_ac2_throughput
Registered new sensor.koolnova_bms entity: sensor.koolnova_2_engine_ac2_temperature_order
Registered new sensor.koolnova_bms entity: sensor.koolnova_2_engine_ac3_throughput
Registered new sensor.koolnova_bms entity: sensor.koolnova_2_engine_ac3_temperature_order
Registered new sensor.koolnova_bms entity: sensor.koolnova_2_engine_ac4_throughput
Registered new sensor.koolnova_bms entity: sensor.koolnova_2_engine_ac4_temperature_order
Setting up koolnova_bms.select
Registered new select.koolnova_bms entity: select.koolnova_2_global_hvac_mode
Registered new select.koolnova_bms entity: select.koolnova_2_global_hvac_efficiency
Registered new select.koolnova_bms entity: select.koolnova_2_engine_ac1_state
Registered new select.koolnova_bms entity: select.koolnova_2_engine_ac2_state
Registered new select.koolnova_bms entity: select.koolnova_2_engine_ac3_state
Registered new select.koolnova_bms entity: select.koolnova_2_engine_ac4_state
Setting up koolnova_bms.switch
Registered new switch.koolnova_bms entity: switch.koolnova_2_koolnova_2_global_hvac_state
Registered new switch.koolnova_bms entity: switch.koolnova_2_koolnova_2_modbus_debug
Setting up koolnova_bms.climate
Registered new climate.koolnova_bms entity: climate.koolnova_2_area_aa
Registered new climate.koolnova_bms entity: climate.koolnova_2_area_bb
Registered new climate.koolnova_bms entity: climate.koolnova_2_area_cc
Registered new climate.koolnova_bms entity: climate.koolnova_2_area_dd

Thank you very much, amazing integration and great support!


Meshconvert support for glTF2

The glTF open standard is intended as a simple, modern runtime format for models. In addition to reading from Wavefront OBJ, meshconvert should be able to read from gltf files.

https://github.com/Microsoft/glTF-DXViewer

https://github.com/Microsoft/glTF-DXViewer

Work in progress in the gltf branch.