Polylines on terrain via Primitive API

Opening a PR to indicate that this is "stable" enough to preview and for preliminary review, but there's still a decent amount of work to be done.
Features:

support for PolylineMaterialAppearance
mitered polylines
batching multiple instances with per-instance show and line width

Implementation notes:
More details in https://github.com/AnalyticalGraphicsInc/cesium/issues/2172#issuecomment-385685782.
We're using a single-pass, globe-depth-based algorithm.
~For each line segment in the polyline we generate a geometry instance volume that has several planes encoded in the batch table. For each fragment on the volume, we look up the globe depth to compute a terrain position in eyespace and clip this position based on the planes from the batch table.
The planes are also used to compute the position's distance from the center and ends of the line for material support.~
~Due to the batch table dependence and mapping of attributes from multiple instances to a single pick ID, this PR introduces a new Primitive type, GroundPolylinePrimitive.
There's also a new user-facing geometry, GroundPolylineGeometry, that doesn't actually have a createGeometry function but rather gets decomposed into individual volumes that are then used to generate vertex buffers and attributes.~
~This is a little troublesome for asynchronous geometry since GroundPolylineGeometry's computation currently happens on the main thread, with the worker threads mostly just converting chunks of this into the combined vertex buffer. In practice this doesn't seem to be a huge problem, but it's something we should talk about.~
For each line segment in the polyline we generate a volume with vertex attributes that describe the line segment using a series of planes. For each fragment on the volume, we look up the globe depth to compute a terrain position in eyespace and clip this position based on the planes from the vertex attributes.
The planes are also used to compute the position's distance from the center and ends of the line for material support.
The planes differ between 2D and 3D, and I haven't figured out yet how to interpolate them for morphing, so there's a new Primitive type that issues draw commands with different shaders for 2D and morph. When morphing we actually just draw the volumes themselves with materials, which seems acceptable because the camera goes so far away during the morph anyway.

[x] I should also do load and runtime comparisons with a hack that attempts to simulate polylines using corridors or something.

TODO:

[x] Integrate with changes in https://github.com/AnalyticalGraphicsInc/cesium/pull/6434 for better geometry heights
[x] batch per-instance colors
[x] doc and specs, compatibility checks
[x] spruce up Sandcastle example

more geometry cases
selection indicator?
volume debug toggle
Z ordering/Z ordering with GroundPrimitives

Entity API integration will be in a followup PR.

@likangning93, thanks for the pull request! Maintainers, we have a signed CLA from @likangning93, so you can review this at any time.
:warning: I noticed that CHANGES.md has not been updated. If this change updates the public API in any way, fixes a bug, or makes any non-trivial update, please add a bullet point to CHANGES.md and comment on this pull request so we know it was updated. For more info, see the Pull Request Guidelines.

I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.
:earth_africa: :earth_americas: :earth_asia:

For some views, the line width is much bigger than what was set because of the slope of the terrain.

Change the width of polyline2 to 32. Here is the view:
viewer.camera.setView({
        destination : new Cesium.Cartesian3(-1919172.892822556, -4782158.333815719, 3749491.554081307),
        orientation : {
            heading : 3.877303220462619,
            pitch : -0.11656491800053193
        }
    });

For some views, the line width is much bigger than what was set because of the slope of the terrain.

This is kind of inevitable for shadow-volume-type algorithms... part of the motivation for a single-pass algorithm was possible hybridization with @pjcozzi's wall-based algorithm, and I think it's also worth exploring if the per-fragment terrain slope can help us with this. We were hoping those could be "future work" if the current smearing is acceptable in most use cases though.

if the per-fragment terrain slope can help us with this

Aaaaand there we go, I'm nerd sniped... right now we're doing per-fragment point-plane distances, hence the smearing problem. But if we took the local terrain slope into account we could maybe do ray-plane distance checks, I think this could work! Will definitely take some fiddling though, I'll leave that until after I've addressed existing PR comments...

Integrate with changes in #6434 for better geometry heights

@bagnell ideally we'd want to do this per-segment, unlike GroundPrimitive which seems to do this over the entire GroundPrimitive, but I ran a little experiment that suggests doing ~64800 does take a nonzero amount of time (maybe 0.1-0.2 seconds on my mid-to-high-range CPU) on the main thread. Is it possible/advisable to do these lookups on a worker? That would also simplify point interpolation, which is possibly a big source of additional height lookups.
Some concerns about the additional cost on worker spinup, but does this happen very frequently?

@bagnell ideally we'd want to do this per-segment, unlike GroundPrimitive which seems to do this over the entire GroundPrimitive

Ah, OK. You can definitely move it to a worker. Worker spin up only happens once on the first post message.
One thing you can do in the future is group line segments by terrain tile. This would reduce the number of times you need to get the min/max heights. Right now, with that many segments, it wouldn't be bad. If we ever need to query a server for the min/max heights, you don't want to make that many HTTP requests.

@bagnell there's a problem with polylines that have large bounding volumes:
var polylineCartographics = [
    Cesium.Cartographic.fromDegrees(-50, -50),
    Cesium.Cartographic.fromDegrees(-50,  50),
    Cesium.Cartographic.fromDegrees( 50,  50),
    Cesium.Cartographic.fromDegrees( 50, -50)
];

var instance = new Cesium.GeometryInstance({
    geometry : new Cesium.GroundPolylineGeometry({
        loop : true,
        width : 16,
        positions : polylineCartographics
    })
});

var polylineOnTerrainPrimitive = new Cesium.GroundPolylinePrimitive({
    polylineGeometryInstances : instance,
    debugShowShadowVolume : false,
    debugShowBoundingVolume : false
});
viewer.scene.primitives.add(polylineOnTerrainPrimitive);

GeometryPipeline tries to split this (although this one doesn't actually cross the IDL) and I don't think it handles the custom vertex attributes correctly. Is this a problem with regular polylines too?

I don't think it handles the custom vertex attributes correctly

Sure doesn't! See #4739
You'll have to add something to GeometryPipeline for each attribute you added. You can see the changes I made for my new attribute in #6607

tears
I need to take a deeper look, but has there been any discussion of letting it take fully generic attributes? I might end up giving that a try...

has there been any discussion of letting it take fully generic attributes?

It's a little tricky. I'm not sure there's a generic way to figure out what the value is at the new vertex that works for every kind of attribute. For example, mines a boolean attribute so you can't interpolate it, you need to decide what the new value should be based on what the other vertices of the triangle are

It's a little tricky. I'm not sure there's a generic way to figure out what the value is at the new vertex that works for every kind of attribute. For example, mines a boolean attribute so you can't interpolate it, you need to decide what the new value should be based on what the other vertices of the triangle are

Playing with fire a little bit, but if the boolean is different between the top and bottom caps of the geometry you might still be able to just interpolate and clamp and expect this to just work because the IDL should be splitting bottoms and caps? I guess it's still tricky since there might not be a good way to indicate a clampable bool, though.
Wonder how far I could get by having GeometryPipeline detect triangles crossing the IDL and just make sure the IDL splits are handled in my createGeometry function... hmmmm...

splitting bottoms and tops instead of walls

Erm, clarification. Splitting walls, but vertically instead of horizontally if that makes sense.
v0 -- S -- v1
     \      |
       \    |
         \ v2

So if the values at V0 and V1 are the same, S === V0 === V1?

Oh wait I see, nevermind. The split on the diagonal will be weird.

Wonder how far I could get by having GeometryPipeline detect triangles crossing the IDL and just make sure the IDL splits are handled in my createGeometry function... hmmmm...

Hmmmm this isn't really how things work right now either... past few comments are definitely the sound of me panicking slightly, time to get off github for the day...

Okay, I've calmed down a bit. I'm going to see if I can wire a "don't split longitude" parameter down and just handle IDL splitting in the geometry itself.

just handle IDL splitting in the geometry itself

That's probably not the right thing to do. Why can't you just make changes in the GeometryPipline?

Why can't you just make changes in the GeometryPipeline?

It's quite a lot of custom vertex attributes. I think the interpolation case might also be kind of weird, since the attributes describe line segments and GeometryPipeline would basically be splitting line segments. I haven't confirmed, but failing to handle the IDL at the geometry creation level might also be causing problems right now.

Discussion with @hpinkos:

instead of using a "don't split" parameter, probably better to have GeometryPipeline handle custom vertex attributes when splitting, right now it ignores these

should just copy these values when "split" doesn't actually generate new triangles
need generic barycentric interpolation for this to work correctly for #4739
need to be careful when integrating with #6607 since offsetAttribute shouldn't be generically interpolated

if we don't worry about primitive model matrices (GroundPrimitive doesn't support this at the moment either), we can get away with splitting the segment that the user inputs across the IDL and creating the geometry with a built-in IDL split

attributes here can't be generically interpolated either b/c IDL weirdness
volume that would be contiguous in 3D becomes two volumes in CV, so all the geometry descriptor stuff in the vertex attributes would be "wrong"

have GeometryPipeline handle custom vertex attributes when splitting, right now it ignores these

Smells like a separate PR, and this is something that we want anyway. I'll get started on this.
In the meantime, @bagnell I think I've tackled all your feedback here from the preliminary review, this is ready for another look but should I go ahead and do unit tests first? We can tack on the IDL fix after the GeometryPipeline fix probably.

need to be careful when integrating with #6607 since offsetAttribute shouldn't be generically interpolated

Yeah, instead of changing anything that's already happening in the computeTriangleAttributes function, I would just try to do a "for each attribute not already copied, do some sort of generic interpolation".   You'll just need to change that function to take the attributes object as an argument instead of passing each attribute separately.

This is the problem with encoding the endpoints of each line segment as a 64-bit position and a 32-bit vector offset, there's precision problems at centimeter-scale viewing. Intent was to save some memory vs. two 64-bit positions... maybe this was just a bad idea to begin with. It's started bothering me enough that I'm going to fix it. The precision issues go away with finer interpolation granularity, but at that point we aren't saving anything at all anymore...

The precision issues go away with finer interpolation granularity, but at that point we aren't saving anything at all anymore...

So it turns out even using double-precision for start and end points doesn't get rid of this problem, and the thing with changing granularity still applies. Maybe it's a problem with all the normals being 32-bit precision?
I'm just going to bump the default granularity, but I'll keep a branch around if we revisit this.

specific to polylines on terrain

Just for polylines on terrain. I'll keep looking as well, there might be something else weird going on under the hood.

there might be something else weird going on under the hood

This also isn't a problem at all in CV, so it's probably bad math and not bad precision.

Okay. It was kind of a precision problem that was being caused by sloppy math.
When encoding points for the start/end planes of each line segment, I was computing them at a height of -100000.0 meters under the ellipsoid, ApproximateTerrainHeights._defaultMinTerrainHeight. I think this is so huge because it's a conservative bound, but anyway, it wasn't a good choice because fragment shader checks of terrain against those planes were inevitably going to have precision problems. Here's a cross-section slice of what was going on:

Setting the plane points on the ellipsoid itself helps a lot. Something similar happened in #6393 I think.

Rough performance comparison with corridors
Sandcastle on localhost:8080
1000 polylines of 10 segments each.
This is compared to corridors on terrain configured so there won't be any depth texture reads in the fragment shader. The corridor instances are also fully batched within the GroundPrimitive.
In the interest of fairness, I tried making the granularity on polylines finer so the vertex count would be comparable. Performance is slightly worse than for default granularity at the default view (~50 fps vs ~40 fps at 1080p).
For the default view I'm seeing that polyline performance is significantly better (~40 fps vs 12) at 1080p for the default view in the demo. This is for a horizon-facing view, which is worst-case for both algorithms.
I think part of the performance difference is that granularity for shadow volumes is better on polylines than on the corridors, since zooming out (and setting corridor width to, say, 800 so they still draw around the same size as the polylines) seems to show a less dramatic performance difference. Similarly, performance for top-down views isn't as dramatically different. Both for far-views and top-down there's still a noticeable difference though, somewhere in the range of 50 vs 30 fps.
If I set up the timers correctly, it seems that synchronous setup times are roughly similar.

Can you avoid the overdraw on corners?

Some offline discussion, one possibility is to add state to the "start" and "end" planes of each volume that lets us push the vertices along the plane directions as well as "away" from the plane normals. This would let us do something like add a triangular volume covering the overdrawn area, or change the geometry so that it never overlaps in this case.
Besides complexity though, a problem with this technique is that as the turn gets even sharper the solution becomes less and less robust... the nice thing about just snapping the line in two like this is that it can even handle a line backing up on itself completely.
An easier option is to implement the "more perfect" pushing of vertices that I mentioned in a comment in PolylineShadowVolumeVS and use 2D point-line-segment distances in the FS instead of the existing 3D point-plane distance to determine if a fragment is part of the polyline.
This could cause rounded outside corners because point-line-segment distances, and we'd still have overdraw for extreme cases, it'd just be curvy?

Rounding corners
I think I have enough of this implemented to identify two major problems. (Incompletey) Code here: https://github.com/likangning93/cesium/commit/541843e8508572286c5c56c7832c754e9ee53c43

noticeable performance hit, even with all branching eliminated. In the performance case above I'm seeing maybe 30-35 fps instead of 40, which is still better than corridors. So whether this is a reason or not to scrub is maybe up for debate
precision problems: I'm doing point-line distance checks using lines made by intersecting the right plane with the mitering planes, but it's not meeting up at centimeter scale. See how the dot isolated here is split at close viewing distances:

I'm... not sure why this happens, but it seems to be related to altitude since this isn't a problem on the ellipsoid itself. I had some other really significant floating point jitter as well that's only mostly resolved.
@bagnell instead of doing properly rounded corners I might do something closer to the current broken miter but without overdraw, and continue to "break" miter for things that are way too sharp:

@bagnell and I had an offline discussion about doing less CPU side weirdness and more in the vertex shader for defining the geometry by passing in a lot more position information and computing planes and stuff in the shader itself. We concluded this probably isn't practical at the moment...
...but I realized on my drive home that it might be doable if each segment was an elbow macaroni instead of a penne segment. So each segment instead of containing two miter vectors only contains one, meaning you only need 3 positions as opposed to 4 to compute all the planes for the segment.
This complicates the fragment shader a little since it's checking each fragment against two line segments instead of one, though.
Counting vertex attributes:
12 - 3 positions (high/low/2D high/low) - technically only 6 if we don't support morphing
1 - batch ID
1 - texture coordinate stuff
@bagnell what do you think?

elbow macaroni instead of a penne

Thinking about varyings too.
9 floats - start, end, and middle of the macaroni
3 floats - miter plane normal
3 floats - up normal
1 float - width
2 floats - texture coordinate stuff
2 floats - material stuff
4 floats - color
If we assume 4 * 16 = 64 floats are available, or even 4 * 8 = 32 floats, we should actually be able to pull this off even if I'm missing a few attributes!

normals for planes at the ends of the volume (not needed in 2D/CV)

Might actually want to put in ellipsoid surface normals for each point. Normalizing the world coordinate for these isn't quite the same thing.

IDL handling: for a vertex on the IDL, generate two macaronis, one for each side, that have very short straights on one side.

elbow macaroni instead of a penne

If it's simple enough, then give it a try. It would simplify the code a bunch. You wouldn't need to split the geometry or project to 2D. The PrimitivePipeline would do it for you. Also, you would need separate shaders for 3D, 2D, and morphing. czm_computePosition should give you the right positions and you compute all of the unit vectors from them in the vertex shader.
Do this in a separate branch though. We would need to see how it impacts performance since there is more computation in shaders.

IDL handling: for a polyline vertex on the IDL, generate two macaronis, one for each side, that have very short straights on one side.

This should also be handled for you.

You could also remove all of the picking shaders and commands. I remember we talked offline about not discarding when the alpha is 0.0, but your, pick shaders specify a pick color varying which calls this code:
https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Renderer/ShaderSource.js#L208
The injects this into the shader:
if (gl_FragColor.a === 0.0 {
    discard;
}

I think @pjcozzi specifically wanted picking on dashed lines to work for in between dashes though.
I'll keep thinking about the macaroni thing too. We can pack heights in with the up-vectors.

@bagnell wait, no... these are only the positions for the "bottom" of the line. Might need to pack heights in as well, which puts us over-budget for vertex attributes when morphing.

Why would you need extra heights? The 2D positions are vec3s, the position on the xy-plane and the height above it.

I think @pjcozzi specifically wanted picking on dashed lines to work for in between dashes though.

You can add something like #ifndef PICK_ALPHA here:
https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Scene/DerivedCommand.js#L231
Then, add PICK_ALPHA to the defines for the shader and still remove all of the pick shaders.

wait, no... these are only the positions for the "bottom" of the line. Might need to pack heights in as well, which puts us over-budget for vertex attributes when morphing.

Why would you need extra heights? The 2D positions are vec3s, the position on the xy-plane and the height above it.

We have to pack into each vertex all the information for the volume, but the volume isn't just 3 positions, it's actually 6 since it's an expandable wall. Currently what we're doing is packing all the information into each vertex but also giving each vertex its own position, which is arguably slightly wasteful but fits within the attribute budget.

EDIT: For the up vectors in 3D? Can you normalize the position in world space or do you need more precision?

These won't be quite the same as ellipsoid surface normals though. I think it's possible that a lat/long point on terrain wouldn't match up to the same point on the polyline if the terrain was substantially higher than the ellipsoid.
Also, just normalizing the world space position has me a little worried about floating point precision. Currently we're using the hi/lo/relative-to-eye thing, but I worry that the world origin relative-to-eye would be too far away and that we'd have floating point jitter.

You can add something like #ifndef PICK_ALPHA here:

PolylineDashMaterial does its own discard, though.
On second thought, @pjcozzi I'm not sure having pick ignore dashes is a good idea.
I can imagine users creating multiple crossing dashed lines and picking at an intersection, then getting confused when the pick returns the one "on top" instead of what's actually showing at that point.

The line starts disappearing in 2D when it crosses the anti-meridian:

This is the same line in 3D.

@likangning93 can you merge in master and fix the conflict in Source/Core/GeometryPipeline.js?  Would love to run this.

Update CHANGES.md.

Fixes #2172.  Assuming Entity API is en route.

What is the roadmap?  Can you start a new issue, e.g.,

Improve smearing with screen-space partial derivatives
Improve performance with shorter ways based on local terrain
Anything with batching?  or per-entity post-processing?  It just works ™ ?
Line styles that don't dance when zooming (surprisingly didn't find an issue for this with a quick search)

The line starts disappearing in 2D when it crosses the anti-meridian:

This is partially my fault, I noticed some weirdness with crossing segments in CV as well, but I think part of this is also a problem with the depth buffer in 2D.

Debug views seem to show the depth values drop off moving west-to-east towards the IDL, varying with view distance. The effect is worse if there's things drawn over a wider range of longitudes (wider rectangle).
here on Sandcastle

Terrain heights over parts of the ocean have min/max heights below the ellipsoid, so lines in these areas on the ellipsoid itself look weird. This is (-100, 0), (-100.01, 0):

Should I clamp terrain heights to the ellipsoid in this case? If not I might just open an issue after the PR closes.

Did the early discards impact performance at all?

I'm getting noticeable performance improvements on Windows/Nvidia and Linux/Intel, will test Windows/Intel soon. Hopeful.

@pjcozzi @bagnell I think this is up-to-date for feedback.
I'll add roadmap stuff to the top of this PR and move it into a dedicated issue when this is merged.

This puts us over 10,000 tests:

This crashes in IE.

I'm seeing some overdraw in Edge.

I'm seeing some overdraw in Edge.

This is happening in Chrome too, it's because we're permitting much steeper angles now before breaking the miter.
So the problem is that the solution for this thing doesn't actually work:

It works almost okay for the two volumes on either side of the sharp turn, but the next set of volumes don't have enough information to avoid overdraw. In other words, it was only fixing a part of the original overdrawn region.
Here's what the original overdrawn region can look like for very steep angles:

Note that there are 3 regions of overdraw here, with only one region (the furthest to the right) exclusively involving the two segments immediately adjacent to the turn. Only that region is getting resolved correctly by my solution, leaving overdraw in all other areas:

This problem becomes much less noticeable when granularity in the examples is set to zero, which isn't practical for long-distance lines.
Resolving this completely might require giving those longer rectangular regions information about the turn, which is another pile of vertex attributes (definitely some high precision ones) and could be kind of terrible.
Had an offline discussion with @bagnell and @pjcozzi, again, the overdraw is only a problem with transparent materials, is mostly noticeable for very wide lines, and also might not even be a huge deal to most users. I'm going to revert to breaking less acute angles and accepting the overdraw for now and open an issue with notes from this PR for further investigation/experimentation.

@bagnell up-to-date and passing


Explore Gisting

How can we take advantage of gisting?
Thread
Paper

I've tried mapping the concept to fit Puterbot's case but I'm having trouble understanding what the paper is essentially proposing. Are we compressing prompts into "gist tokens" after initially feeding the LM the entire uncompressed prompt so that it saves on read and compute time later on? Or are we compressing it from the beginning ? The attention masks part is especially confusing, so I was wondering if I could get someone else's perspective on Gisting :D

Thank you for engaging on this issue @FFFiend !

Are we compressing prompts into "gist tokens" after initially feeding the LM the entire uncompressed prompt so that it saves on read and compute time later on?

I believe that is correct. From https://arxiv.org/pdf/2304.08467.pdf:

we add a single special gist token to
the model vocabulary and embedding matrix, much
like the start/end-of-sentence tokens often present
in such models. Then, given a (task, input) pair
(t, x), we concatenate t and x with a set of k successive gist tokens in between: (t, g1, . . . , gk, x), e.g.
Translate French:   The cat. This
sequence is fed into the model, with the restriction that input tokens after the gist tokens cannot
attend to any of the prompt tokens before the gist
tokens (but they can attend to the gist tokens). This
forces the model to compress the information in
the prompt into the gist tokens, since the input x
(and output y) cannot attend to the prompt t.

According to the repo (https://github.com/jayelm/gisting) it appears that the trained gist model parameter diffs are now available on HuggingFace for LLaMA-7B and FLAN-T5-XXL 😄

Alright so I think I spent an unreasonable amount of time trying to understand how exactly the gist tokens themselves looked like from multiple reads on the paper, but I think the repo you linked above blackboxes it for us.
What I think remains now is to take advantage of the above repo such that any prompting we do on the LLM we use to automate processes, can be gisted and we save on compute time. Unfortunately, I haven't tinkered around with the Puterbot codebase enough yet to try and see where we can inject this improvement :/ Will comment/commit soon :D

@FFFiend please join us on Slack if you haven't already: https://join.slack.com/t/mldsai/shared_invite/zt-1uf94nn7r-qcQnS~hinLPKftUapNzbuw (link at top of README)

Alright so I think I spent an unreasonable amount of time trying to understand how exactly the gist tokens themselves looked like from multiple reads on the paper,

Thank you!

but I think the repo you linked above blackboxes it for us.

Unfortunate, but not a deal breaker.

I haven't tinkered around with the Puterbot codebase enough yet to try and see where we can inject this improvement

I think the MVP looks like creating a GistingReplayStrategyMixin, analogous to e.g. LLMReplayStrategyMixin at https://github.com/MLDSAI/puterbot/blob/main/puterbot/strategies/llm_mixin.py (along the way, perhaps it's worthwhile thinking about what a general framework for any model might look like).

Edit: Also, I was hoping if you could explain what "diff" meant? I saw it used on the other repo too but I haven't been able to infer what it implies :D

In general a diff is just a difference between two states (e.g. the previous one and the current one). In our case it refers to Screenshots/WindowStates. I'm not sure about what "the other repo" is referencing, can you please clarify? 🙏

but I think the repo you linked above blackboxes it for us.

Can you please clarify?
From https://github.com/jayelm/gisting#demo--checkpoints:

To use the model and try out gist caching, use the src/compress.py script, e.g.
python -m src.compress --model_name_or_path jayelm/llama-7b-gist-1 --base_llama_path llama-7b \
    --instruction "Name the top cities in France that should not be missed. Include the best aspects of each place as well."

Edit: Also, I was hoping if you could explain what "diff" meant? I saw it used on the other repo too but I haven't been able to infer what it implies :D

In general a diff is just a difference between two states (e.g. the previous one and the current one). In our case it refers to Screenshots/WindowStates. I'm not sure about what "the other repo" is referencing, can you please clarify? 🙏

Oh I meant the Gisting repo used that word too and I was confused what its technical implications were :D

but I think the repo you linked above blackboxes it for us.

Can you please clarify?
From https://github.com/jayelm/gisting#demo--checkpoints:

To use the model and try out gist caching, use the src/compress.py script, e.g.
python -m src.compress --model_name_or_path jayelm/llama-7b-gist-1 --base_llama_path llama-7b \
    --instruction "Name the top cities in France that should not be missed. Include the best aspects of each place as well."

Seems to me like we want this in the GistingReplayStrategyMixin, with a compress method
Yep noticed this too, apologies on the confusion. The paper didn't go into an example of what the gist tokens looked like and upon a cursory read of the readme it didn't seem like showing the actual compression was something they highlighted, but I was wrong.

@FFFiend if you are interested in being considered for an internship, please submit a PR with your work, and reference this issue in the description.

Continuing our conversation, I just found out you can make Python modules using an empty init file LOL this task seems a tad bit easier now haha, I was going crazy looking for ways to integrate that ENTIRE codebase to complete the task

Alright, I sent an email to the owner of the repo (hoping I hear back soon) until then, going from whitepaper to implementation is a little tricky as there are things in files such as compress.py or weight_diff.py that I don't fully understand yet, so any PR at the moment would just be a skeleton GistingReplayStrategyMixin class with the completion method akin to the LLMReplayStrategyMixin class, except that the input_token variable would be generated differently, using a new compress method. I think I'm on the right track but I'm not sure ...
Additionally, I found two possible errors in the LLMReplayStrategyMixin class. In particular: when we truncate the prompt length to match max_input_size, we have prompt = prompt[max_input_size:] when it should instead be prompt[:max_input_size] . Also, the type contract on the max_input_size inside the initializer is off, should be integer.
I'm holding off making a PR because as stated above, the GistingReplayStrategyMixin is mostly non-functional until I get a grip on what exactly is going on in the Gisting repo, or if the owner makes it such that I can simply import Gisting as a package somehow.
Do let me know what you think :D

Update: A possible solution is to simply include the Gisting repo as a submodule in my fork and work off of that.


Lat Long vs Long Lat

Would be nice if you could have the option to flip the co-ordinates so that it maps Lat Long vs Long Lat coordinates.
Program I am using requires them the other way around so requires manually switching them.
Being able to switch would be great.

Sorry, but we're not accepting requests for new features. Besides, geojson.io is intended to promote the use of standard GeoJSON (among other formats) and won't muddy the waters, so to speak.


HACS Integration

Any chance we can get a working HACS integration of this awesome plugin?
https://custom-components.github.io/hacs/

Maybe

+1 for this.
I love your work
I love HACS


rename the link "Getting started" to "Developer and IT-Pro Help"

Also consider renaming the link "Getting started" to "Developer and IT-Pro Help"

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

ID: 6b86d301-cf03-0dd0-abdd-9a73743b4285
Version Independent ID: 4e4d4219-2c2f-0324-6166-414f31158224
Content: Meet Microsoft Dynamics 365 Business Central - Business Central
Content Source: business-central/index.md
Service: dynamics365-business-central
GitHub Login: @SorenGP
Microsoft Alias: sgroespe

Closing issue as internal.


cleanup of the JettyServletEngineAdapters and JettyHttpProxy for Jetty 9.4 and 12

Prefer use of insertHandler() where possible.
Do not add an RPC connector if in HttpConnector mode.
Only perform the configuration of the HttpConfiguration once.
In HTTP mode merge the two SizeLimitHandlers into one instead of having separate ones for request and response content.
Remove the GAE CoreSizeLimitHandler and use the one provided by Jetty.

This is targeted at the gzip-headers-jetty94 branch as it is built on top of those changes, but I will re-target this at main once https://github.com/GoogleCloudPlatform/appengine-java-standard/pull/308 is merged.

@maigovannon will do the full review.


fix: create package/lib when there is something to install there

:tada: This PR is included in version 1.4.6 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Removed style that was interfering with text selection within code cell.

This PR addresses #10738
Removed cell style that prevents user from selecting beginning with left-most text from inside code cell.

Coverage increased (+0.07%) to 34.209% when pulling 78452f637a5092f4c97d6a37747f32def9a99eba on 10738-notebook-ui-code-cell-text-selection into acefe7b081e101be911c776df06c0d36dd7ec13e on master.


AAF reader supports Timeline global_start_time

This PR adds support for reading Timeline's global_start_time from AAF files.

Codecov Report

Merging #478 into master will decrease coverage by 0.06%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #478      +/-   ##
==========================================
- Coverage   88.23%   88.17%   -0.07%
==========================================
  Files          68       68
  Lines        6900     6915      +15
==========================================
+ Hits         6088     6097       +9
- Misses        812      818       +6

Impacted Files
Coverage Δ

...neio_contrib/adapters/advanced_authoring_format.py
93.39% <100%> (+0.19%)
:arrow_up:

...elineio_contrib/adapters/tests/test_aaf_adapter.py
98.32% <100%> (+0.01%)
:arrow_up:

opentimelineio/adapters/fcp_xml.py
91.86% <0%> (-0.47%)
:arrow_down:

opentimelineio_contrib/adapters/fcpx_xml.py
93.28% <0%> (-0.47%)
:arrow_down:

opentimelineio_contrib/adapters/hls_playlist.py
90.68% <0%> (-0.31%)
:arrow_down:

Continue to review full report at Codecov.

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


Renaming in Azure Spring Monitor

One motivation is to have more specific Spring bean names

/azp run java - spring-monitor - tests

/azp run java - spring-monitor - tests

/azp run java - spring-monitor - tests


ImageBackground does not announce "disabled"

Description
When using a screen reader this component does not announce that it is disabled.
This issue is covered in-depth by parent issue #30840, please check there for more details.
React Native version:
v0.63

ImageBackground is composed of an Image component wrapped by a View. As View already implements the AccessibilityState, therefore we just need to pass the prop from ImageBackground to the wrapped view.
Is that a correct approach?


Spawned vehicles disappear

Version: 0.9.11
Platform: Ubuntu 18.04
Setting: I spawn something like 20 vehicles using the PythonAPI/examples/spawn_npc.py script,
and set up another script that that polls the locations of all actors in the simulation and writes them to a file
Issue: Over the course of a week-long simulation, some actors seem to be disappearing and random points (their location isn't being written to file anymore, so I'm assuming they are not present in world snapshot).
Is this a known bug? Any way to avoid it?
Thanks

Some cars are disappearing because we have a vehicle elimination policy within Traffic Manager, since in some cases they completely block intersections, thus effectively blocking traffic flow altogether.  I can guide you through removing this feature:
in ALSM.cpp, comment the following lines like this:
 // Destroy registered vehicle if stuck at a location for too long.   // if (IsVehicleStuck(max_idle_time.first)   //     && (current_timestamp.elapsed_seconds - elapsed_last_actor_destruction) > DELTA_TIME_BETWEEN_DESTRUCTIONS) {   //   registered_vehicles.Destroy(max_idle_time.first);   //   RemoveActor(max_idle_time.first, true);   //   elapsed_last_actor_destruction = current_timestamp.elapsed_seconds;   // }
Let me know if this fixes your issue.

@jackbart94 thanks for the explanation! I think it makes sense, but is there away to detect that this occurred using the client Python API?
I tried using the following to detect, and it didn't work:
if world.get_actor(id) is None: print("Stuck vehicle eliminated")

Thanks to your feedback we found an issue with the is_alive variable. We are working on a fix and it should be merged soon. After it's merged, you can check if a vehicle has been destroyed by Traffic Manager simply using:
if world.get_actor(id).is_alive is False: print("Vehicle has been eliminated")

@jackbart94 I just began using Carla. So I am not sure if I am doing things right. I edited the ALSM.cpp file but the TrafficManager still kept removing dormant vehicles.  Would Carla automatically build those CPP files again every time I launch it or is there some way for me to build those CPP files?


Descendants tracking error when cache_classes = true

We're getting an error when we have cache_classes = true on CI with Rails 7.0.1:
 RuntimeError:
              DescendantsTracker.clear was disabled because config.cache_classes = true
            # /home/circleci/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.1/lib/active_support/descendants_tracker.rb:119:in `clear'
            # /home/circleci/app/vendor/bundle/ruby/2.7.0/gems/with_model-2.1.6/lib/with_model/model.rb:59:in `cleanup_descendants_tracking'
            # /home/circleci/app/vendor/bundle/ruby/2.7.0/gems/with_model-2.1.6/lib/with_model/model.rb:38:in `destroy'
            # /home/circleci/app/vendor/bundle/ruby/2.7.0/gems/with_model-2.1.6/lib/with_model.rb:53:in `block in setup_object'

Me too.  config.cache_classes = true is the default in Rails 7.

Same here.

See https://guides.rubyonrails.org/upgrading_ruby_on_rails.html#upgrading-from-rails-6-1-to-rails-7-0-spring. It needs to be explicitly set to false from Rails 7 when Spring is not used.

@waiting-for-dev I read that the opposite way, i.e. it needs to be set to false in Rails 7 when Spring is used.

@waiting-for-dev I read that the opposite way, i.e. it needs to be set to false in Rails 7 when Spring is used.

Yeah, that wording is confusing. See here instead https://guides.rubyonrails.org/configuring.html#config-cache-classes

That's much clearer, thanks.

@airblade, in the end, I think you're right. It should be true in the test environment, and it should only be false when Spring is present, as it'll handle cache by itself. So, yeah, I think this should be fixed from with_model end.

Thanks for the workaround @Stex !

Does #44 fix this issue?

Unfortunately no, I still get the same error... Stex's workaround works like a charm, though.

Hey @nertzy if you're happy to add me as an owner on Rubygems I can get this out.


An API for interaction with the lightnet accounts manager.

This PR attempts to provide the simple API integrated into o1js in order to retrieve and release accounts managed by lightnet Mina network.
Note: Keep in mind that accounts manager synchronises access to the endpoints in order to guarantee the proper accounts management for concurrent requests.
As an example the corresponding live test was updated as well.

Run the local Mina:

docker run -id --env NETWORK_TYPE="single-node" --env PROOF_LEVEL="none" -p 3085:3085 -p 5432:5432 -p 8080:8080 -p 8181:8181 o1labs/mina-local-network:rampup-latest-lightnet

Build o1js:

npm run build && npm run build:node

Run live tests:

USE_CUSTOM_LOCAL_NETWORK=true TEST_TYPE="Live integration tests" ./run-ci-tests.sh

In result test will pass and in Docker container you should see the output like:
[2023-10-08 12:54:13] [INFO   ] Checking the 'http://localhost:8080/graphql' availability...
[2023-10-08 12:54:13] [INFO   ] An attempt to acquire non-zkApp account...
[2023-10-08 12:54:13] [INFO   ] Acquired account with Index #636 and Public Key: B62qrYhoJRyTtQ7RdU3KutCBQHs69BgYnMBjSY3E72QTNH6CkneM84B
[2023-10-08 12:56:10] [INFO   ] Account with public key B62qrYhoJRyTtQ7RdU3KutCBQHs69BgYnMBjSY3E72QTNH6CkneM84B is set to be released.

We have linter dependency but we don't provide scripts nor automatic linting on commit, hence some imports/exports were reformatted.
Am I missing something or we need to enable linter properly?

Closes https://github.com/o1-labs/quality-and-testing/issues/121
Closes https://github.com/o1-labs/o1js/issues/1074

Thanks @shimkiv for the PR!

We have linter dependency but we don't provide scripts nor automatic linting on commit, hence some imports/exports were reformatted.
Am I missing something or we need to enable linter properly?

We have a prettier config, and prettier handles auto-formatting of yaml files. However we don't apply this in CI, we just rely on developers to have prettier installed locally.
However, it seems that you have a different auto-formatter active which

overrides the prettier style of yaml formatting
adds additional sorting of imports which isn't done by prettier

In the interest of providing a clean and easy-to-review PR, and not make changes that would be reverted when the next developer touches the yaml file, I'd prefer if you revert all of the auto-formatting done here (both the yaml file and the import reordering; you can submit a separate PR that reorders imports, but I think it's better to not have auto-formatting enabled that does more than what is enforced by the repo configs and done by other developers.

I'd prefer if you revert all of the auto-formatting done here

Got it, thank you, then will do revert in next commit.

@shimkiv another general comment: I think "account manager" is better as a name than "accounts manager". Would be nice if you could remove the "s" everywhere :D

@shimkiv actually I have one more ask -- could you update the CHANGELOG?


fix (README.md): Markdown href link syntax

I fix the tiny error by correcting the markdown syntax.

Great, thanks.


List improvements to constraint support in the changelog

I forgot to add this to https://github.com/elixir-lang/ecto/pull/1180

:heart: :green_heart: :blue_heart: :yellow_heart: :purple_heart:


[10.0.x] Remove unused profiles to avoid enforcer no-managed-deps errors

Backport https://github.com/apache/incubator-kie-drools/commit/7d11b928a43b3f47bda6aac9ae4f79000d3ece72 only for profile fixes.

GHA Drools Ansible RuleBook Integration Check: Working on a fix. Okay to ignore the failure.


Move autocomplete.js into a component directory

Create an autocomplete folder and store autocomplete.js there instead of at the top level with app.js

created new components folder and moved script into it


🧼 Remove all nested Typography elements

Nesting MUI Typography elements works, but throws the console error show below. We should remove all nested text elements, making generic components if needed.
Error

Closed by #556


Support External Master Replica setup

Currently Cloud SQL instances support replicating from external server through use of a public ip address.
The parameter is source-ip-address see these docs.
Perusing the API docs, it's not immediately clear to me how to implement this.  I will update the issue when I figure it out.

Hi @johnlabarge
Thanks for the suggestion.
Looks very promising.

Let's open an issue against the Terraform provider.

Created feature request 23566

@paulpalamarchuk These requests need to be made on the provider not Terraform core: https://github.com/terraform-providers/terraform-provider-google

Issue moved to the provider repo #5087


Diagonal paths?

Does this support diagonal paths?

Yes, :intercardinal grids navigate adjacent and diagonal paths, here's a test demonstrating here.

Thanks


re-render

..and ensure icu 58.* link with libxml2.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Share course by email can't change reference to Richie

Bug Report
Expected behavior/code
A clear and concise description of what you expected to happen (or code).
The mailto subject and message should include the name of the platform (FUN-MOOC, NAU, etc.) instead of reference Richie.
The users don't understand what is Richie.
Actual Behavior
The mailto link includes Richie.
Steps to Reproduce

Open any course page
Click on mail button
The mailto has reference to Richie instead of the platform

Environment

Richie version: any
Platform: any

Possible Solution

Add new Django setting PLATFORM_NAME and use it when translating the mailto subject and body.
Additional context/Screenshots

Our solution on NAU, was to force the translation of those strings and replace Richie to NAU on both en and pt-pt languages.

If I'm not mistaken the idea was that it should be overriden via template override?

Yes, it could be overridden using a template override. I saw that you have overide it on each of fun-richie-site-factory, but you override it on each to do exactly that, change the application name.
On NAU I've changed the translation of that string, that is another approach to do exactly the same thing.
I suggest to add new Django setting PLATFORM_NAME, like what Open edX has, and to use it when translating the mailto subject and body. With that we no longer need to override that template (Fun solution) or forcefully change the translations (NAU solution).


[iOS] Adds getIsRecording method

Needed to get current recording status of Lookback.io SDK for the case where the user does not accept the terms and conditions and the recording doesn't actually start.

Okay, I believe I've fixed up the formatting to match.
I don't think there needs to be any bump of the Lookback SDK. Our podfile says we've got "LookbackSafe", "~> 1.4.1" installed. I'm not sure if the isRecording getter is a new method to the Lookback SDK though.
As far as NPM goes, it's additive and I didn't change any of the existing methods, so it should be good to go out as a minor release there.

looks good! Release on npm as 1.3.1


Add missing useNativeDriver in ToastContainer

Hi!
This PR adds a missing useNativeDriver inside the ToastContainer component.
Cheers

Can this be released, please? Facing the same issue.

Please merge, and publish on npm, thanks

#3278 fixes this issue in multiple components

Is it already published on npm ? Im using 2.13.14 and im having that issue with FAB.


Can we allow member variables to be public by default?

https://github.com/vim/vim/blob/ae3205aa55741152b0143dbd7d637b35f576793e/runtime/doc/vim9class.txt#L115-L139
In my opinion - the developer ought to know if setting a member variable has side-effects, so it's their responsibility to make it private.  I think that most of the time, you just want the convenience of setting the variable directly - without writing a setter function for it - or needing to remember to make it public.   So, if the default visibility is public, (explicitly writing "public" becomes optional) then that makes it easier most of the time - and I think that any potential risk that brings is something that the developer ought to be aware of.

On 23/01/15 2:56 PM, Christopher Plewright (Vim Github Repository) wrote:

the developer ought to know if setting a member variable has
side-effects, so it's their responsibility to make it private. I think
that most of the time, you just want the convenience of setting the
variable directly - without writing a setter function for it - or
needing to remember to make it public.

Unless there's a clear reason, I'll usually be conservative and limit
the scope; most of the time I don't want to set member variables from
someplace else. If the need arises for public access it's trivial to
make public. This is particularly good/convenient for code that gets
looked at after some time; if there's an issue, it forces me to revisit
what access rules I want.
-ernie

@vim-ml    Yes, there are some good reasons to default private, I'm aware its preferred by a lot of traditional OO programming languages - and being conservative/safe is good.
Actually, my last suggestion on the vim_dev mailing list would make this a mute point.  There would be no ambiguity about what is the default, because it would enforce all member variables to be explicitly public or private, simply by the prefix "." or "_", which has other advantages too - like removing the requirement of the "this." prefix.
ref:  https://groups.google.com/d/msgid/vim_dev/3f966524-130c-4a81-8a68-fc531883cca5n%40googlegroups.com

the default perhaps should be protect, neither public nor private, just available in class and its sub. IMO.
and so called this perhaps actually a bit confused..
// anyway, i felt vim script became a bit complex more than a script, do we really need class/abstract/extend/interface...?!

Also see the "Class implementation" thread in the vim-dev maillist.
Hopefully this link works: https://groups.google.com/g/vim_dev/c/yYpFNUHdRho

@zewpo please check https://github.com/vim/vim/pull/12932 if you still interesting on this, and this ticket can be closed when/if that one had final version.

thanks for considering my feedback.  I'm happy with whatever the community agrees to.


using ranchervm

Hello rancher,
I am trying to use ranchervm, after using
docker run -e "RANCHER_VM=true" --cap-add NET_ADMIN -v
/tmp/ranchervm:/ranchervm --device /dev/kvm:/dev/kvm
--device /dev/net/tun:/dev/net/tun rancher/vm-rancheros
how do I connect to the unix socket that it prints? looks like vncviewer does not support unix sockets
i am using vncviewer 1.3.9
Any help is appreciated

There are two ways to do this:

Use a VNC viewer that supports Unix sockets, like ssvncviewer.
Start the rancher/vmmgmt container to view the console.

@sainath14 If you have further questions about ranchervm, can you please open them up at https://github.com/rancherio/vm/issues. I'll close this issue.


update the flags for tuples write/delete

In agreement with the new behavior and flags https://github.com/openfga/cli/issues/161 we need to update the docs to reflect it
the new commands have same flags as import, and import is going to be deprecated.

can be assigned to me, once the PR is merged on cli, I will provide the update for the docs


docs: updated links to blog and watson studio

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Nate/propagate unconditional remaining

This extends the current behavior of @Argument array properties defined with the .unconditionalRemaining parsing strategy to work with subcommands, as well. For example, with a command hierarchy like this:
@main
struct Root: ParsableCommand {
    static var configuration: CommandConfiguration {
        .init(subcommands: [Sub.self])
    }

    @Flag var verbose = false
}

struct Sub: ParsableCommand {
    @Argument(parsing: .unconditionalRemaining)
    var remainder: [String] = []

    @OptionGroup var root: Root

    func run() {
        print("Verbose:", root.verbose)
        print("Remainder:", remainder)
    }
}

We want the Sub command to capture any arguments after the subcommand name appears in the command-line arguments. This fix enables the following behavior:
$ root --verbose sub foo --bar
Verbose: true
Remainder: foo --bar
$ root sub foo --bar --verbose
Verbose: false
Remainder: foo --bar --verbose
$ root --verbose sub foo --bar --verbose
Verbose: true
Remainder: foo --bar --verbose

Checklist

[x] I've added at least one test that validates that my change is working, if appropriate
[x] I've followed the code style of the rest of the project
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary

@swift-ci Please test


add string buffer for stdout and stderr

This PR adds support for using a string with a byte limit as the stdout and stderr for WasiCtx and WasiCtxBuilder.
Usage:
stdout_str = ""
stderr_str = ""
WasiCtxBuilder.new
          .inherit_stdin()
          .set_stdout_buffer(stdout_str, 50000)
          .set_stderr_buffer(stderr_str, 50000)
          .build

Note on the runners: 3.0 is no longer part of the stable-ruby-versions that are fetched by oxidize-rb/actions.
From: https://github.com/oxidize-rb/actions/blob/main/fetch-ci-data/evaluate.rb#L54
["3.1","3.2","3.3","head"]


Make antidote_dc_manager:create_dc idempotent

Running the connect script only works the first time, because of antidote_dc_manager:create_dc.

#399 must be fixed before this can be done.


support and resistance indicator supres.py

hi,
i converted support and resistance from tradingview to python
this is also associated with #217
https://www.tradingview.com/v/JAW0oW7R/

how to use
=======================================================
import ccxt
import pandas_ta as pta
import pandas as pd
import time

exchange = ccxt.binance({
    'enableRateLimit': True,
    'options': {
        'defaultType': 'future',  # ←-------------- quotes and 'future'
    },
})

_market="BTCUSDT"

ohlc = exchange.fetch_ohlcv(_market,limit=500, timeframe='5m')
df = pd.DataFrame(ohlc, columns = ['time', 'open', 'high', 'low', 'close', 'volume'])
df['time'] = pd.to_datetime(df['time'], unit='ms')
time.sleep(1)
df[['ha_open','ha_high','ha_low','ha_close']] = pta.ha(df['open'],df['high'],df['low'],df['close'])
df[['SUPPORT','RESISTANCE']] = pta.supres(df['ha_open'],df['ha_high'],df['ha_low'],df['ha_close'])
pd.set_option('display.max_rows', None)
pd.set_option('display.max_columns', None)
pd.set_option('display.width', None)
pd.set_option('display.max_colwidth', None)
print(df[-50:])

========================================================================

supres.py
==========================================
# -*- coding: utf-8 -*-
from numpy import nan as npNaN
from pandas import DataFrame
import pandas
from pandas_ta.overlap import hma,sma
from pandas_ta.momentum import rsi
from pandas_ta.volatility import atr
from pandas_ta.utils import get_offset, verify_series

def supres(open,high, low, close,offset=None,  **kwargs):
    """Indicator: Support and resistance"""
    # Validate Arguments
    _length = pandas.Series.count(close)
    open = verify_series(open, _length)
    high = verify_series(high, _length)
    low = verify_series(low, _length)
    close = verify_series(close, _length)
    offset = get_offset(offset)

    if high is None or low is None or close is None: return

    # Calculate Results
    pandas.options.mode.chained_assignment = None  # default='warn'
    src1=hma(open, length=5,offset=1)
    src2=hma(close, length=12)
    momm1 =pandas.Series(src1).diff(periods=1)
    momm2 =pandas.Series(src2).diff(periods=1)
    rsi_new =rsi(close,length=9)
    h=high.rolling(2).max()
    l=low.rolling(2).min()
    sh=sma(h, length=2)
    sl=sma(l, length=2)

    m=_length
    m1, m2 = [1] * m, [0] * m
    for i in range(1,m):
        if momm1.iloc[i] >= momm2.iloc[i]:
            m1[i] = momm1.iloc[i]
        # elif mom1'].iloc[i] < mom2'].iloc[i]:
        else:
            m1[i] = 0

        if momm1.iloc[i] >= momm2.iloc[i]:
            m2[i] = 0
        # elif mom1'].iloc[i] < mom2'].iloc[i]:
        else:
            m2[i] = -1 * momm1.iloc[i]

    sm1=pandas.Series(m1).rolling(1).sum()
    sm2=pandas.Series(m2).rolling(1).sum()

    CMO = 100 * ((sm1 - sm2)/ (sm1 + sm2))
    h1, l1, summh, summl, hpivot, lpivot = [0] * m, [0] * m, [0] * m, [0] * m, [0] * m, [0] * m
    hpivot_new, lpivot_new, SUPPORT, RESISTANCE=[npNaN] * m, [npNaN] * m,[npNaN] * m, [npNaN] * m

    for i in range(1, m):
        summh[i] = summh[i] +  abs( h.iloc[i] - sh.iloc[i] )
        h1[i]  =  summh[i] / m

        summl[i] = summl[i] +  abs( l.iloc[i] - sl.iloc[i] )
        l1[i]  =  summl[i] / m

    for i in range(0, m):
        if h1[i] != 0:
            hpivot_new[i] = high.iloc[i]
            hpivot[i] = True
        else:
            hpivot[i] = False

        if l1[i] != 0:
            lpivot_new[i] =  low.iloc[i]
            lpivot[i] = True
        else:
            lpivot[i] = False

        if rsi_new[i] > 75 and CMO[i] < -50 and hpivot[i] ==True:
            RESISTANCE[i] = hpivot_new[i]

        if rsi_new[i] < 25 and CMO[i] > 50 and lpivot[i] ==True:
            SUPPORT[i] = lpivot_new[i]

    # Prepare DataFrame to return
    _props = f"_{_length}"
    df = DataFrame({
            f"SUPPORT{_props}": SUPPORT,
            f"RESISTANCE{_props}": RESISTANCE
        }, index=close.index)

    df.name = f"SUPPORT{_props}"
    df.category = "overlap"
    df.fillna(method='ffill', inplace=True)

    # Apply offset if needed
    if offset != 0:
        df = df.shift(offset)

    # Handle fills
    if "fillna" in kwargs:
        df.fillna(kwargs["fillna"], inplace=True)

    if "fill_method" in kwargs:
        df.fillna(method=kwargs["fill_method"], inplace=True)

    return df

supres.__doc__ = \
"""supres (Support and resistance)

Supres  is an overlap indicator. It is used to help identify support and resistance

Sources:
   https://www.tradingview.com/v/JAW0oW7R/

Calculation:
    Default Inputs:
        hma open :lenght=5, offset=1
        hma close: lenght = 12
        rsi : lenght = 9

        if rsi_new.iloc[i] > 75 and CMO.iloc[i] < -50 and hpivot.iloc[i] ==True:
            RESISTANCE.iloc[i] = hpivot_new.iloc[i]

        if rsi_new.iloc[i] < 25 and CMO.iloc[i] > 50 and lpivot.iloc[i] ==True:
            SUPPORT.iloc[i] = lpivot_new.iloc[i]

Args:
    open (pd.Series): Series of 'open's
    high (pd.Series): Series of 'high's
    low (pd.Series): Series of 'low's
    close (pd.Series): Series of 'close's
    offset (int): How many periods to offset the result. Default: 0

Kwargs:
    fillna (value, optional): pd.DataFrame.fillna(value)
    fill_method (value, optional): Type of fill method

Returns:
    pd.DataFrame: SUPPORT (lowest low), RESISTANCE (recent highest high).
"""

Hello @mhgutier,
Awesome! Thanks for adding this to the library. 😎
However, this is one glitch. You are attempting to merge 179 commits from development into main. Ideally you should make a PR to the development branch only. If you can not figure it out, no worries. I or someone will update the development branch with the code you provided above.
Thanks,
KJ

greetings...
is there any plan to publish this great indicator officially?

would love to get an update!

Surprisingly busy. But it will be done.
Thanks,
KJ

Hi @mhgutier,
This PR will have many conflicts since you based it off the main branch. If possible, could you resubmit using the development branch? If not, I can include it in the development branch.
Kind Regards
KJ

Hi @mhgutier,
This PR will have many conflicts since you based it off the main branch. If possible, could you resubmit using the development branch? If not, I can include it in the development branch.
Kind Regards KJ

Hi Kevin,
#683 has been created


[2.7] KDM Update for K8s 2022 September patch release

KDM Updates
TO BE RELEASED: Enabled with Rancher v2.7.0

New Kubernetes Version
Min Rancher Version
Min RKE Version

1.24.6-rancher1-1
2.6.7-patch0
1.3.13-rc0

1.23.12-rancher1-1
2.6.4-patch0
1.3.8-rc0

1.22.15-rancher1-1
2.6.3-patch0
1.3.3-rc0

Rancher System Images & Add-ons
Note: Please update system images and add-ons in the template as needed.
TBD
Developer Changelog

Add templates for new K8s versions. If a template that hasn't been released yet already exists, update it in place.
Update the default K8s version, and add or update the version information (MinRancherVersion and MinRKEVersion) in k8s_version_info.go for new K8s versions if needed (Use table from above).
Confirm versions for system images, add-on templates are correct using versioning reference table from below (expand details to view the table). Update the table if new versions are introduced.
Confirm add-on template version constraints in template.go are correct using versioning reference table from below (expand details to view the table). Update the table if needed.

Versioning Reference

Expand for system images & add-on templates versioning table

Note: Truncated repository names with a * indicates there are multiple images with that prefix. All repository names that match a truncated prefix should be checked for the same version stated in the table.
For example: rancher/weave-* matches weaveworks/weave-kube and weaveworks/weave-npc, and they should both have the same version.
v1.24.6-rancher1-1

Repository
Tag

rancher/mirrored-coreos-etcd
v3.5.4

rancher/hyperkube
v1.24.6-rancher1

rancher/rke-tools
v0.1.87

rancher/mirrored-k8s-dns-*
1.21.1

rancher/mirrored-cluster-proportional-autoscaler
1.8.5

rancher/mirrored-coreos-flannel
v0.15.1

rancher/flannel-cni
v0.3.0-rancher6

rancher/mirrored-calico-*
v3.22.0

weaveworks/weave-*
2.8.1

noiro/* (All ACI images)
<IP_ADDRESS>.1d150da

rancher/mirrored-pause
3.6

rancher/nginx-ingress-controller
nginx-1.2.1-rancher1

rancher/mirrored-nginx-ingress-controller-defaultbackend
1.5-rancher1

rancher/mirrored-jettech-kube-webhook-certgen
v1.1.1

rancher/mirrored-metrics-server
v0.6.1

rancher/mirrored-coredns-coredns
1.9.3

rancher/mirrored-cluster-proportional-autoscaler
1.8.5

rancher/kubelet-pause
v0.1.6

rancher/mirrored-k8s-dns-node-cache
1.21.1

Add-on Name
Add-on Template Version Constraint

Calico
calicov319

Canal
canalv319

Flannel
flannelv115

CoreDNS
coreDnsv183

KubeDNS
kubeDnsv116

MetricsServer
metricsServerv050

Weave
weavev120

Aci
aciv500

NginxIngress
nginxIngressv110Rancher3

Nodelocal
nodelocalv121

v1.23.12-rancher1-1

Repository
Tag

rancher/mirrored-coreos-etcd
v3.5.3

rancher/hyperkube
v1.23.12-rancher1

rancher/rke-tools
v0.1.87

rancher/mirrored-k8s-dns-*
1.21.1

rancher/mirrored-cluster-proportional-autoscaler
1.8.5

rancher/mirrored-coreos-flannel
v0.15.1

rancher/flannel-cni
v0.3.0-rancher6

rancher/mirrored-calico-*
v3.22.0

weaveworks/weave-*
2.8.1

noiro/* (All ACI images)
<IP_ADDRESS>.1d150da

rancher/mirrored-pause
3.6

rancher/nginx-ingress-controller
nginx-1.2.1-rancher1

rancher/mirrored-nginx-ingress-controller-defaultbackend
1.5-rancher1

rancher/mirrored-jettech-kube-webhook-certgen
v1.1.1

rancher/mirrored-metrics-server
v0.6.1

rancher/mirrored-coredns-coredns
1.9.0

rancher/mirrored-cluster-proportional-autoscaler
1.8.5

rancher/kubelet-pause
v0.1.6

rancher/mirrored-k8s-dns-node-cache
1.21.1

Add-on Name
Add-on Template Version Constraint

Calico
calicov319

Canal
canalv3211

Flannel
flannelv0140

CoreDNS
coreDnsv183

KubeDNS
kubeDnsv116

MetricsServer
metricsServerv050

Weave
weavev120

Aci
aciv500

NginxIngress
nginxIngressv110Rancher3

Nodelocal
nodelocalv121

v1.22.15-rancher1-1

Repository
Tag

rancher/mirrored-coreos-etcd
v3.5.3

rancher/hyperkube
v1.22.15-rancher1

rancher/rke-tools
v0.1.87

rancher/mirrored-k8s-dns-*
1.21.1

rancher/mirrored-cluster-proportional-autoscaler
1.8.5

rancher/mirrored-coreos-flannel
v0.15.1

rancher/flannel-cni
v0.3.0-rancher6

rancher/mirrored-calico-*
v3.21.1

weaveworks/weave-*
2.8.1

noiro/* (All ACI images)
<IP_ADDRESS>.1d150da

rancher/mirrored-pause
3.6

rancher/nginx-ingress-controller
nginx-1.2.1-rancher1

rancher/mirrored-nginx-ingress-controller-defaultbackend
1.5-rancher1

rancher/mirrored-jettech-kube-webhook-certgen
v1.1.1

rancher/mirrored-metrics-server
v0.5.1

rancher/mirrored-coredns-coredns
1.8.6

rancher/mirrored-cluster-proportional-autoscaler
1.8.3

rancher/kubelet-pause
v0.1.6

rancher/mirrored-k8s-dns-node-cache
1.21.1

Add-on Name
Add-on Template Version Constraint

Calico
calicov319

Canal
canalv3211

Flannel
flannelv0140

CoreDNS
coreDnsv183

KubeDNS
kubeDnsv116

MetricsServer
metricsServerv050

Weave
weavev120

Aci
aciv500

NginxIngress
nginxIngressv110Rancher3

Nodelocal
nodelocalv121

/backport v2.6

Fresh install checks blocked by this issue.  https://github.com/rancher/rancher/issues/39188

Verified on rancher v2.7-head(35388ea)
Upgrade checks - PASS

On rancher v2.6.8, KDM pointing to release-v2.6, cluster creation succeeds for v1.24.4-rancher1-1, v1.23.10-rancher1-1 and v1.22.13-rancher1-1 with all network provider.
Pre-upgrade checks look good.
Upgraded rancher from v2.6.8 to v2.7-head(35388ea), KDM pointing to dev-v2.7.
Post-upgrade checks look good.
Upgraded k8s version to v1.24.6-rancher1-1, v1.23.12-rancher1-1 and v1.22.15-rancher1-1.
Post upgrade checks look good.

Verified on dev-v2.7 and RKEDefaultK8sVersions is pointing to v1.24.6-rancher1-1
"RKEDefaultK8sVersions": {
  "0.3": "v1.16.3-rancher1-1",
  "default": "v1.24.6-rancher1-1"
 }

#39188 issue is not reproducible on rancher v2.7-head(0de241c).
Fresh install checks passed.
Validations steps:

On rancher version v2.7-head, KDM pointing to dev-v2.7, cluster creation succeeds for v1.24.6-rancher1-1, v1.23.12-rancher1-1 and v1.22.15-rancher1-1
Network checks passed on all the clusters.
Validations for canal checks also passed.

moving this to-test since this is fixed - https://github.com/rancher/rancher/issues/39188 and new RKE RC is tagged - v1.4.0-rc3

RKE checks using v1.4.0-rc3 passed for k8s v1.24.6-rancher1-1, v1.23.12-rancher1-1 and v1.22.15-rancher1-1
All checks passed, hence closing this issue.


Typescript errors with the latest Backstage 1.33.0

The following error is generated when running tsc with the latest backstage release:
error TS2345: Argument of type 'TemplateAction<{ path: string; content: string; preserveFormatting?: boolean | undefined; }, JsonObject>' is not assignable to parameter of type 'TemplateAction<any, any>'.
  Types of property 'handler' are incompatible.
    Type '(ctx: ActionContext<{ path: string; content: string; preserveFormatting?: boolean | undefined; }, JsonObject>) => Promise<void>' is not assignable to type '(ctx: ActionContext<any, any>) => Promise<void>'.
      Types of parameters 'ctx' and 'ctx' are incompatible.
        Type 'ActionContext<any, any>' is not assignable to type 'ActionContext<{ path: string; content: string; preserveFormatting?: boolean | undefined; }, JsonObject>'.
          Types of property 'checkpoint' are incompatible.
            Type '<T extends JsonValue | void>(opts: { key: string; fn: () => T | Promise<T>; }) => Promise<T>' is not assignable to type '<U extends JsonValue>(key: string, fn: () => Promise<U>) => Promise<U>'.
              Types of parameters 'opts' and 'key' are incompatible.
                Type 'string' is not assignable to type '{ key: string; fn: () => U | Promise<U>; }'.

33           createWriteFileAction(),
             ~~~~~~~~~~~~~~~~~~~~~~~

Expected Behavior
The @roadiehq/scaffolder-backend-module-utils should pass tsc
Current Behavior
See above
Steps to Reproduce

Upgrade to Backstage 1.33.0
Run tsc:full

Your Environment

@backstage/plugin-catalog-react version: 1.14.1
"@roadiehq/scaffolder-backend-module-utils": "^2.0.2"

Currently experiencing the same error with createHttpBackstageAction()
Version: "scaffolder-backend-module-http-request": "^5.0.1"

Related #1728 and #1733

+1,  facing similar issue

I think the issue is with incompatible version of @backstage/plugin-scaffolder-node
The plugin uses version ^0.5.0 here https://github.com/RoadieHQ/roadie-backstage-plugins/blob/main/plugins/scaffolder-actions/scaffolder-backend-module-utils/package.json#L52 and also here (presents the same issue) https://github.com/RoadieHQ/roadie-backstage-plugins/blob/main/plugins/scaffolder-actions/scaffolder-backend-module-http-request/package.json#L53
But backstage latest uses 0.6.0 which appears to be incompatible.
I'm testing workaround to add a resolution in your root package.json
"resolutions": {
    "@backstage/plugin-scaffolder-node": "^0.6.0",
  },

it compiles at least 😄

Backstage upgrade https://github.com/RoadieHQ/roadie-backstage-plugins/pull/1728 has been merged, just need to cut a release ;)

@ScottGuymer did you get the resolutions approach working?

Should just be a matter of triggering the release now: https://github.com/RoadieHQ/roadie-backstage-plugins/pull/1746. I'm still having issues with yarn tsc locally with the resolution although yarn tsc --incremental false works.

@ScottGuymer did you get the resolutions approach working?

Yes it did.
But a new version is better!


Config WPDB

To allow extra flexibility, it should be possible to create a connection using a clone of WPDB. This would not only uncouple from the gloabl state, but also allow us to make changes to WPDB without the side effects being reflected elsewhere, or have other interactions cause side effects within the builder.
This would allow us to allow the setting of Charset, Colation, Error logging, etc all via the initial config array. A user could still make these changes by accessing the DBInstance() from within the connection itself.

Proposes config values

use wpdb prefix - this would set the prefix bases on current in wpdb
custom prefix - if set would overrule the use of wpdb prefix
show errors - this would call https://developer.wordpress.org/reference/classes/wpdb/#show-and-hide-sql-errors
use clone - will dictate if the instance of wpdb should be cloned before configuration. This avoids side effects as a result of these changes or external changes effecting the used instance


Request: improve compatibility with Ping Logger module

When combined with the Minimal UI module and the player list is set to auto-hide, the Ping Logger module does not display the ping on the same line as the player colored dot:

As you see each player takes two lines in the player list, one for the colored dot and one for their ping.
Ideally, both should be displayed on the same line. Alternatively, the ping could be hidden when in auto-hide mode.
Also see https://github.com/mawburn/foundry-ping-logger/issues/1

Nice job adding this to both repos.
I haven't looked into it yet, but my first thought is this looks like a flexbox display column. If that's the case, I should probably apply a class to the ping span that would make it get hidden along with the rest of the stuff.
I haven't actually looked into this yet, but @saif-ellafi is there a class I can apply to it that will hide it?

I am a bit off the race for the moment but will track this down when I get some time. It will likely require some ruling from either side to make an exception. In the worst case scenario, setting up the Player List to look like vanilla should solve this.
If anyone has some time, a similar compatibilty patch was done with "Raise my Hand" module, i.e. by customizing some of the style parameters, plus some specific style changes to the class of the ping logger.
                    if (game.modules.has('raise-my-hand') && game.modules.get('raise-my-hand').active) {
                        rootStyle.setProperty('--playerwidth', '42px');
                        rootStyle.setProperty('--playerslh', '20px');
                    }

Speaking of the compatibility patch, I get a lot of empty space on the right when the player is not hidden and set to standard size:

Ok I wrote down a compatibility patch for Ping Logger both with and without Raise My Hand enabled:

Ideally this would be fixed through changing the layout instead of hardcoding pixel size, but it works.
The patch:
                    // Compatibility for Raise Hand module
					let playerWidthPixel = 22;
                    if (game.modules.has('raise-my-hand') && game.modules.get('raise-my-hand').active) {
                        playerWidthPixel += 20;
                        rootStyle.setProperty('--playerslh', '20px');
                    }

                    // Compatibility for Ping Logger module
                    if (game.modules.has('ping-logger') && game.modules.get('ping-logger').active) {
                        playerWidthPixel += 50;
                        rootStyle.setProperty('--playerslh', '20px');
                    }

					if (playerWidthPixel > 22){
						rootStyle.setProperty('--playerwidth', `${playerWidthPixel}px`);
					}

PR request #51 fixes the compatibility issue.

Released! Thanks a lot. Wouldn't have happened otherwise :)

Unfortunately, with the new modifications the ping is still displayed on two lines when it reaches double digits:

Hmm, I wonder why? It looks fine to me

Which browser are you on?

Low (0-9) pings work fine to me, but not when the ping is in the double digits (10+).

ahh got it, ok maybe I tightened the values to much. Will set them back to 50 as you proposed originally.

Another option would be to directly disable auto-hide mode when Ping Logger is enabled. I am not sure how high can the pings go and also a large box doesn't make sense

Ok, I will submit a solution, to hide the pings as well if Players is in auto-hide mode. This way the pings will be visible only on hover. Just like the rest of the titles.

Released with https://github.com/saif-ellafi/foundryvtt-minimal-ui/releases/tag/1.0.9

I found what I think is a better solution, purely through CSS which also remove the need for the Raise my Hand patch.
In #players#, I change width: var(--playerwidth);towidth: auto;`
then, I add these CSS styles:
#players ol .player-active {
	display: inline-block;
	width: 8px;
	flex: auto;
}

.player.flexrow {
    display: block;
}

And this fixes it.

Alternatively, we can keep flex and do the following

In #players, I change width: var(--playerwidth); to width: auto;
Add the following:

.player.flexrow {
    flex-wrap: nowrap;
}

To support the Raise my Hand module, we can add

#players ol .player-name {
    overflow: visible;
}

Otherwise the hand gets partially hidden.

PR request opened to add back the ping.


Would you like to include ESLint support

Hello
There was a question asked in step "yo teams"  (about ESLint) before Azure Application Insights for telemetry which is not documented.
? Would you like personal apps to be rendered without a tab header-bar? No
? Would you like to include Test framework and initial tests? No
? Would you like to include ESLint support No
? Would you like to use Azure Applications Insights for telemetry? No

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

ID: 61f5ca59-ab3e-b7ef-d3bc-55a88a362abf
Version Independent ID: 6d43a761-19e0-541e-ba06-170099411ac1
Content: Create a personal tab - Teams
Content Source: msteams-platform/tabs/how-to/create-personal-tab.md
Product: msteams
GitHub Login: @laujan
Microsoft Alias: lajanuar

@bkakadiya, Thanks for the pointing it out.
We will update the doc as:
Would you like to include ESLint support? (y/N)
Choose not to include Azure AD Single-Sign-On support for the tab. The default is yes, enter n.


[C-API] Increase ML_TENSOR_RANK_LIMIT

This patch increases ML_TENSOR_RANK_LIMIT from 4 to 8.
Signed-off-by: Yelin Jeong<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #241. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.

I assumed this condition, but I'm not familiar at version control so feel free to tell the points to fix

This PR will be merged at the same time as nnstreamer version up ( I used 2.3.1 version for nnstreamer temporarily )
api can check nnstreamer's version

:octocat: cibot: @niley7464, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-api/ci/repo-workers/pr-checker/241-202301271339050.35460090637207-bbefbc455d5a49785fe556541ae6d7f9cac156c6/.

:octocat: cibot: @niley7464, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-api/ci/repo-workers/pr-checker/241-202303081041400.76915001869202-1c900834b0eaa5286be2ee26ba1ac642147a13fc/.

This requires https://github.com/nnstreamer/nnstreamer/pull/3987 to be merged and applied into Tizen-unified.

Question
In my opinion, the backward compatibility error might occur in case the old version of the nnstreamer application is installed in the new version of Tizen.  For example, below example code should be fixed and uploaded to Tizen store again. right? If then, this code is not acceptable by our Tizen PM.

Previous application code

/* Below code should be fixed and re-complied */
ml_tensor_dimension dim = { CH, CAM_WIDTH, CAM_HEIGHT, 1 };
...
ml_tensors_info_create(&info);
ml_tensors_info_set_count(info, 1);
ml_tensors_info_set_tensor_type(info, 0, ML_TENSOR_TYPE_UINT8);
ml_tensors_info_set_tensor_dimension(info, 0, dim);

Possible solutions

Default: ML_TENSOR_RANK_LIMIT is 4 for backward compatibility
Add new API to increase the ML_TENSOR_RANK_LIMIT to 8.

e.g. ml_extend_rank_limit()

It seems this PR has a backward compatibility error, so I closed Tizen ACR.
For not modifying example code and Tizen application, here is the possible solutions we disucssed last week.
// rank <= 4, using previous api
ml_tensors_info_set_tensor_dimension(info, 0, dim);

// rank > 4, using ml_option
ml_option_h option;
ml_option_create (&option);
ml_option_set (option, "input_dimension", "a:b:c:d:e:f:g:h", NULL);
ml_tensors_info_set_nth_info (info, 0, option);
ml_single_open_with_option (&single, option);

ml_option_h option;
ml_option_create (&option);
ml_option_set (option, "input_dimension", "a:b:c:d:e:f:g:h", NULL);
ml_tensors_info_set_nth_info (info, 0, option);

Suggestion:
ml_option_h option;
ml_option_create (&option);
ml_option_set (option, "types", "uint8,uint8,uint8", NULL);
ml_option_set (option, "dimensions", "a:b:c:d:e:f:g:h,a:b:c:d:e:f:g:h,a:b:c:d:e:f:g:h", NULL);
ml_tensors_info_set_with_option (info, option);
ml_option_destroy (option);

:octocat: cibot: @niley7464, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-api/ci/repo-workers/pr-checker/241-202303291517200.44503593444824-ba4d19ee2f4c14de96187e63022916c60faf68dd/.

Tizen TCT Failure list

tct-nnstreamer-native-utc (Native)

utc_ml_single_get_property_p()

Tizen.MachineLearning.Inference (.Net)

Tizen.MachineLearning.Inference.Tests.SingleShotTests.GetValue_NO_EXCEPTION()
Tizen.MachineLearning.Inference.Tests.SingleShotTests.SetValue_NO_EXCEPTION()

tct-mlsingleshot-tizen-tests (Web)

SingleShot_getValue()
SingleShot_setValue()

Detailed Error message

execute case: Tizen.MachineLearning.Inference.Tests # Tizen.MachineLearning.Inference.Tests.SingleShotTests.SetValue_NO_EXCEPTION...(FAIL)
    Failed to set input dimension\n  Expected string length 7 but was 15. Strings differ at index 7.\n  Expected: "5:1:1:1"\n  But was:  "5:1:1:1:1:1:1:1"\n  ------------------^\n
  Expected: True
  But was:  False

@again4you, Thank you for checking!!

Tizen TCT Failure list

tct-nnstreamer-native-utc (Native)

utc_ml_single_get_property_p()

Now this TC passed without change dimension string value after #283

Tizen ACR

https://code.sec.samsung.net/jira/browse/ACR-1755

:octocat: cibot: @niley7464, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-api/ci/repo-workers/pr-checker/241-202304042243480.88996505737305-585612a016a0940a4bc931fb84d5c2666f31adeb/.

Tizen TCT Failure list

None. Good Job!

:octocat: cibot: @niley7464, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-api/ci/repo-workers/pr-checker/241-202304061010360.87284994125366-9f3e8ae7f4485062379f3ad0c5f949f32a50d4ec/.

:octocat: cibot: @niley7464, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-api/ci/repo-workers/pr-checker/241-202304061125470.26541304588318-9f3e8ae7f4485062379f3ad0c5f949f32a50d4ec/.

:octocat: cibot: @niley7464, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-api/ci/repo-workers/pr-checker/241-202304061211100.90906691551208-9f3e8ae7f4485062379f3ad0c5f949f32a50d4ec/.

I manually verified this PR.
To make a group submit with NNStreamer, this PR will be merged even though the CI test failed.


[B14] Arcane Pattern Crafter Does Not Require All Ingredients

When using the Arcane Pattern Crafter, it only requires one of the ingredients. For example, when creating an Iron Block, instead of requiring 9 Iron Ingots, it only requires 1.
Short video of the bug:
https://www.dropbox.com/s/s15bofkjij3od2e/thaumcraft_crafter_bug.webm?dl=0
The whole setup:

The transfer node blacklists blocks, so everything gets turned into blocks where possible... Which just so happens to be always this beta.

Same issue as #840

Solved in B15 technically.


Final value on slide stop doesn't get sent to action handlers

I'm using Ember 2.9 and ui-slider 0.4.1. I've upgraded from ui-slider 0.3.5. seiyria-bootstrap-slider is at 7.1.1.
The behavior I'm seeing is that I can drag the slider but only the first value that was changed gets fired. If I have 1,2,3 and I start at 1, and drag to 3, the value in the handler is 2, and never 3.
I've looked at the examples and feel like I'm doing something very similar (the main change was sending sizeFilterTicks and sizeFilterTickLabels a string, instead of an array).
The major difference is that I'm setting my min & max & ticks, etc. from within my component that's using ui-slider, rather than passing in the scalar values in the template. Is there a specific lifecycle hook that I should be using? didReceiveAttrs doesn't seem to be adequate.

I've recreated a very basic component with a slider, and in my barebones app I get the opposite behavior: the change event only seems to get called on mouseup, so the final value is included in the event.
My guess is that I will have to Ember.observe the value to get this to work similarly to what I had before.

Hmmm. I have not seen this behaviour. Can you reproduce in a twiddle?


WIP: New notofonts profile

This PR includes a set of experimental checks ported from nototools/noto_lint.py

I forgot to tag this PR as "draft", so I have just renamed it to "Work In Progress" so that it does not get merged too early. I will be adding more commits here for a while.


Where do I find kube-controller-manager.kubeconfig?

Hi,
Thank you for the tutorial.  I am following all the steps successfully until mv kube-controller-manager.kubeconfig in Bootstrapping the Kubernetes Control Plane.  I do not see where the file is created or cp from earlier steps.  I appreciate any help pointing me to the file.  Thanks for your help.

I totally missed a step here.  Found it.


Update and move dependencies

Landed in https://github.com/metarhia/impress/commit/72ed40c14fa500f3b8b9e69ebb862a3abf416266, https://github.com/metarhia/impress/commit/84be1d1c55ae087b902ecf3b9827be39e9a7b45a, and https://github.com/metarhia/impress/commit/557be32406709d949da5fa4278682f5e5111b312


Use signed requests for attestation demo

Update attestation demo client to use signed requests for key wrapping/unwrapping
Update pelz to accept signed requests
Update demo script to generate keys and register a CA cert with pelz
Improve demo error handling
Replace placeholder demo input data with a new text file

In testing the demo, I am able to run it, but, for all of the JSON requests, I am getting the message ERROR - Request signature did not match.
I am still trying to figure out what I might be doing incorrectly, but it seems that this message results from a failed call to the kmyth function ec_verify_buffer() within the validate_signature() function in src/util/enclave_request_signing.c. Regardless of whether the invalid signature message is a result of my configuring and running the demo incorrectly or something else, I'm not sure why this "error" condition sets a "successful return" after printing this error.

It looks like the ERROR - Request signature did not match log message is incorrect, but we currently print it when signature validation is successful.
I can change the log message.


[docs] update custom_action

What type of PR is this?
/kind documentation
What this PR does / why we need it:
Mainly add en text to: docs/en/concepts/custom_action.md. The local preview is good.

/lgtm


[BUG]  Error: API Error Deleting Resource Role Collection Assignment (Subaccount).

Is there an existing issue for this?

[X] I have searched the existing issues

What version of the Terraform provider are you using?
1.5.0
What version of the Terraform CLI are you using?
1.9.3
What type of issue are you facing
bug report
Describe the bug
Error: API Error Deleting Resource Role Collection Assignment (Subaccount).
This happens when:

the tf script is run with a platform user that belongs to a custom idp defined on a global account level
a new subaccount is being created and additional subaccount admin users are being added
these additional subaccount admin users exclude both the platform user above and the GA owner
if these admin users are added to the default identity provider only the bug will occur
adding these users to both default and custom identity providers removes the race condition and solves the problem
on a side note, if the platform user - the runner of the tf script - is a user coming from a default identity provider, there is no error

resource "btp_subaccount_role_collection_assignment" "subaccount_users" {
  #
  # https://github.com/SAP/terraform-provider-btp/issues/345
  /*
  depends_on         = [btp_subaccount_trust_configuration.custom_idp]

  for_each             = toset("${var.emergency_admins}")
  subaccount_id        = data.btp_subaccount.context.id
  role_collection_name = "Subaccount Administrator"
  user_name            = each.value
  #origin               = btp_subaccount_trust_configuration.custom_idp.origin
}

To summerize, if the tf script runner is a custom identity provider user and admin users are being added to the subaccount as default identity provider users, this error occurs.
Expected Behavior
No response
Steps To Reproduce
This happens when:

the tf script is run with a platform user that belongs to a custom idp defined on a global account level
a new subaccount is being created and additional subaccount admin users are being added
these additional subaccount admin users exclude both the platform user above and the GA owner
if these admin users are added to the default identity provider only the bug will occur
adding these users to both default and custom identity providers removes the race condition and solves the problem
on a side note is the platform user - the runner of the tf script - is a user coming from a default identity provider, there is no error

resource "btp_subaccount_role_collection_assignment" "subaccount_users" {
  #
  # https://github.com/SAP/terraform-provider-btp/issues/345
  /*
  depends_on         = [btp_subaccount_trust_configuration.custom_idp]

  for_each             = toset("${var.emergency_admins}")
  subaccount_id        = data.btp_subaccount.context.id
  role_collection_name = "Subaccount Administrator"
  user_name            = each.value
  # uncomment the below line to solve the issue if the tf script runner is a user belonging to the custom idp
  # if the tf script runner belongs to the default SAP ID there is no error
  #origin               = btp_subaccount_trust_configuration.custom_idp.origin
}

To summerize, if the tf script runner is a custom identity provider user and admin users are being added to the subaccount as default identity provider users, this error occurs.
User's Role Collections
One can easily locate the undeleted role collection in the tf state file. Removing it from the state file and running the tf apply allows to complete the subaccount destruction
Add screenshots to help explain your problem
No response
Additional context
No response

@ptesny is the user who runs the tf script a part of this list var.emergency_admins specified here
for_each  =  toset("${var.emergency_admins}") If yes then this will throw error while destroy as specified by @lechnerc77  here https://github.com/SAP/terraform-provider-btp/issues/345#issuecomment-1655136400

@ptesny is the user who runs the tf script a part of this list var.emergency_admins specified here for_each = toset("${var.emergency_admins}") If yes then this will throw error while destroy as specified by @lechnerc77 here #345 (comment)

@CHERIANS , no it is not part of the list...please read steps above:

these additional subaccount admin users exclude both the platform user above and the GA owner

@ptesny I do not fully understand the procedure tbh. Could you share your complete TF scripts (in the best case a reference to GH repo) including the variables you set (in this case users), so that we can take a look at the complete script and the setup that causes the error.
The error message is a (in the meantime) unnecessary safeguard of the platform when trying to remove the last admin user on subaccount level.

@lechnerc77 , the root cause of the reported issue is most likely a problem with the BTP ga account that stopped populating the custom platform idp (the one define on a ga level) to both the existing and the newly created subaccounts (which is a default behaviour);
As of today, this seems to be working again (with the same ga), so for the sake of time I will be closing the issue for now.


Make use of parent::__construct in Shopware/Enlight Snippet Manager

1. Why is this change necessary?
You should preserve a class' parents constructor
2. What does this change do, exactly?
Use parent::__construct for instantiation in both Shopware and the base Enlight SnippetManager.
Plus some code improvements by type hinting private functions.
3. Describe each step to reproduce the issue or behaviour.
4. Please link to the relevant issues (if any).
5. Which documentation changes (if any) need to be made because of this PR?
6. Checklist

[ ] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[x] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/SW-24587
Please use this issue to track the state of your pull request.

Thanks for your Contribution! :blue_heart:


[Resolver] Move all resolver settings to repo variables for reusable workflow?

Since a custom macro has to be defined as a repo variable, it would make sense to refactor all other resolver settings to use repo variables as well instead of being hard coded inside the example workflow file. This way there is one central place for users to tweak their settings.
The only variable to refactor for now is MAX_ITERATIONS.

Moved from All-Hands-AI/openhands-resolver#325

I believe this is resolved!


Unable to timer helper entity to device

Creating a "virtual device" to group a number or entities together, attempted to add a timer helper binary_sensor.
In configuration, the binary sensor appeared in the list of entities which could be added, however on submit it did not appear in the list of sensors attached to the device.
Returning to configuration, the name of the sensor had been replaced by its unique_id.

The entity is no longer available in the rest of HA and can no longer be edited, although it still appears in the helpers list:

If it is deleted from the device tools configuration, and HA restarted, it becomes available again.
Log from a seond attempt (therefore entity id different):
2024-02-19 01:48:56.147 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1452, in _async_registry_updated
assert registry_entry is not None
AssertionError
2024-02-19 01:49:01.142 WARNING (MainThread) [custom_components.device_tools] [Probably occupied] Removing unknown entity (id: ce48fd1d27955867e5683ce33245fef7)
2024-02-19 01:49:06.160 WARNING (MainThread) [custom_components.device_tools] [Probably occupied] Removing unknown entity (id: ce48fd1d27955867e5683ce33245fef7)
2024-02-19 01:49:11.171 WARNING (MainThread) [custom_components.device_tools] [Probably occupied] Removing unknown entity (id: ce48fd1d27955867e5683ce33245fef7)
2024-02-19 01:49:16.189 WARNING (MainThread) [custom_components.device_tools] [Probably occupied] Removing unknown entity (id: ce48fd1d27955867e5683ce33245fef7)
2024-02-19 01:49:21.200 WARNING (MainThread) [custom_components.device_tools] [Probably occupied] Removing unknown entity (id: ce48fd1d27955867e5683ce33245fef7)

Do you know if there is anything different about that entity? Maybe it does not have a name or set up differently to the other entities somehow?

In my original post I called it a timer helper - actually it's a times of day helper, sorry. Still, a binary sensor.
To answer your question, yes, I set up all my helpers using the UI, then rename them so that they are grouped in searches. So this particular one would have been created as "In bed" (giving binary_sensor.in_bed), then renamed "[Housekeeping] In bed". When I search for it in the configuration dialog this is the name in the dropdown list. All the other entities I have tried so far have been created with templates, so no renaming involved.
When I delete the entity from the device-tools configuration and restart HA, as described above, the helper reappears but it no longer has the custom name.

The only thing I change with the entities that are assigned to the device is that I set the device_id. No idea how this could break the entity in the way you described. I will have to write some tests to hopefully find all these bugs and edge cases and fix them, but it will take some time, sorry.


CentOS release 5.9 madness

The commit 0dc3a7913d7dc1e3c22eb67844f81afe6216b8cb breakes vim-airline on both stock vim 7.3.315 and the custom vim 7.4. Reverting it fixes everything.

I've had the same problem as creaktive with CentOS 5.11, vim 7.0 (default version from CentOS repository installed with yum), and this commit of the vim-airline:

cdc6d98 - (HEAD, origin/master, origin/HEAD, master) Merge pull request #788 from toupeira/patch-1 (25 hours ago)

I've had vim-airline installed via Vundle. Here's the relevant snippet from my .vimrc detailing all installed plugins and vim-airline configuration options:
" Vundle init staff
set nocompatible
filetype off
set rtp+=~/.vim/bundle/Vundle.vim/
call vundle#begin()
Bundle 'gmarik/Vundle.vim'
Bundle 'tpope/vim-endwise'
Bundle 'tpope/vim-git'
Bundle 'tpope/vim-surround'
Bundle 'tpope/vim-fugitive'
"Bundle 'powerline/powerline'
Bundle 'bling/vim-airline'
Bundle 'scrooloose/nerdtree'
call vundle#end()
filetype plugin indent on
"vim-airline config
let g:airline#extensions#tabline#enabled = 1
let g:airline_powerline_fonts = 1
set guifont=Inconsolata\ for\ Powerline
I've spent hours trying to follow all possible instructions I could find on the net to make the airline appear in the gutter and tabs line on top with no avail.
Finally, I have just built and installed vim 7.4 from source by following this instructions:
http://www.fullybaked.co.uk/articles/installing-latest-vim-on-centos-from-source
Bingo! That fixed the problem right away - the airline embellished status line magically appeared at the bottom and the tab line - on top.
I thought I'd post my findings here to save some other poor soul hours wasted on googling and head-scratching.