kui like CLI and endpoint?

this looks an interesting approach:
https://github.com/kubernetes-sigs/kui
making it easy to open a UI from kubectl to visualise results and essentially being able to run kubectl get ..... and visualise the results in the UI.
I wonder if it might make sense to add something like this to octant? so we could do something like octant get pod -n myns -l foo=bar and it was like kubectl get ..... only it opened a new window in octant to visualise the results?
Another aspect of kui thats interesting is being able to have multiple windows running kubectl get commands and then letting folks visualise/navigate the data. Maybe something like that could be added too to help CLI folks navigate quickly using k8s style CLIs?

given the k8s CLI muscle memory lots of us have built up over the years; having a little CLI like entry field we can use to quickly navigate to resource views might be quite handy; particularly understanding the CLI (resource/CRD) short names.
being inside octant means we don't have to type
kubectl get pod

we could just support inputs like:
po
po -n myns
po -l foo=bar
svc
pr -n cheese # for tekton PipelineRun

etc

That'd be a pretty cool idea. It also opens the door to having other tooling available like telepresence, kubectl plugins, etc almost out of the box.
Current implementation of terminals is coupled with a pod: https://github.com/vmware-tanzu/octant/issues/1751
Once that is refactored, it'd be fairly easy to build this out.

yeah; I'm not sure if it even needs to be an actual terminal per se.
e.g. what if we had a "Search Box" icon on the left hand nav bar which if you click on it you get an input field.

so the input field essentially lets you type the rest of the "kubectl get" command line (conceptually) then when you are ready you hit enter and it navigates to the right page to display those results?
it could easily understand the resource / CRD names and short names to do nice completion for you too with a little auto-complete box so that if you click the Search Box button and type p: you'd see something like
kubectl get: p

persistentvolumeclaims
persistentvolumes
pipelineactivities
pipelineresources
pipelineruns
pipelines
poddisruptionbudgets
po
pods
podsecuritypolicies
podtemplates
previews
pv
pvc

so typing a few characters would quickly help you select through any k8s resource/crd.
Once you've selected a resource kind maybe completion could help you either pick a name or label? (again could use completion like the CLI)
If we had this search box; maybe we could have a URL which encodes the search box text you enter (e.g. http://<IP_ADDRESS>:7777/#/myns/search?q=pods). If we had that then we could make a real CLI in the octant binary quite easily; so that typing
$> octant get pod cheese

opening: http://<IP_ADDRESS>:7777/#/myns/search?q=pod+cheese

so if you are really in a CLI then we'd have an octant get thats like kubectl get but which takes you to a page in octant that tries to view whatever resources you specify (with optional name / labels / filters / whatever)

even without the real CLI integration; having a kubectl get inspired quick search box to navigate to any k8s resource/CRD page would be super handy I think - lots of us use the CLI alot with k8s

@GuessWhoSamFoo an actual funky awesome terminal inside Octant is a cool idea too mind you ;)

DOH - I just noticed the quick switcher! (Ctrl-Enter) never noticed that before ;) - thats kinda the same thing I described above in many ways ;)
Though we could still do the CLI integration so you can open a page in Octant quickly from the CLI using a kubectl get like CLI for octant

Related in many ways to #2247
The idea being that Octant is able to create links that allow it to open specific resources - being able to provide context, namespace, filters and/or resource names and have that view open in Octant - be it from a CLI tool, or generating a link from the GUI - the desire is the same.


Don't run on build server if PipeOptions.CurrentUserOnly is not available

For security reasons, we don't want to have a build server running that accepts requests from all users. Since we don't have a good way of having that restriction without PipeOptions.CurrentUserOnly, we should just not run builds on the server in cases that option isn't available like when running in netcoreapp2.0.

@mkArtakMSFT we need this for preview2. I'm self assigning this.


Bugfixes

Improve node-redis-cache-store-test to use DEL not EXPIRE removing race condition
Move browserify-shim to devDependency
Add https://github.com/github/gitignore/blob/master/Node.gitignore
Update fakeredis

Thank you very much, it's always a pleasure!


Scale rewrite for v2.0

Overview
This update splits the scale code into separate x and y scales for the line, bar and scatter chart types. The line and bar charts use a "dataset" axis as their only x axis. The scatter chart allows arbitrary numbers of x and y axes.
I created a scale registration system. So far the following scale types are available: "linear", "dataset", and "radialLinear". The last axis type is used by the polar area and radar charts. The hope is that extensions can now provide axis types alone rather than new chart types as well. This means that it will be easier to expand Chart.js to use logarithmic axes.
I've also update the configuration to a more nested state with respect to the scales. More work is necessary to update the global defaults as well. I wrote a config merge function that can better handle nested data.
Sample Config
 var defaultConfig = {
        hoverMode: 'single',
        scales: {
            xAxes: [{
                scaleType: "linear", // scatter should not use a dataset axis
                display: true,
                position: "bottom",
                id: "x-axis-1", // need an ID so datasets can reference the scale

                // grid line settings
                gridLines: {
                    show: true,
                    color: "rgba(0, 0, 0, 0.05)",
                    lineWidth: 1,
                    drawOnChartArea: true, // if true, draw these grid lines on the chart area
                    drawTicks: true, // if true, draw these grid lines as ticks on the axis
                    zeroLineWidth: 1,
                    zeroLineColor: "rgba(0,0,0,0.25)",
                },

                // scale numbers
                beginAtZero: false,
                integersOnly: false,
                override: null,

                // label settings
                labels: {
                    show: true,
                    template: "<%=value%>",
                    fontSize: 12,
                    fontStyle: "normal",
                    fontColor: "#666",
                    fontFamily: "Helvetica Neue",
                },
            }],
            yAxes: [{
                scaleType: "linear", // only linear but allow scale type registration. This allows extensions to exist solely for log scale for instance
                display: true,
                position: "left",
                id: "y-axis-1",

                // grid line settings
                gridLines: {
                    show: true,
                    color: "rgba(0, 0, 0, 0.05)",
                    lineWidth: 1,
                    drawOnChartArea: true,
                    drawTicks: true, // draw ticks extending towards the label
                    zeroLineWidth: 1,
                    zeroLineColor: "rgba(0,0,0,0.25)",
                },

                // scale numbers
                beginAtZero: false,
                integersOnly: false,
                override: null,

                // label settings
                labels: {
                    show: true,
                    template: "<%=value%>",
                    fontSize: 12,
                    fontStyle: "normal",
                    fontColor: "#666",
                    fontFamily: "Helvetica Neue",
                }
            }],
        },

        //Number - Tension of the bezier curve between points
        tension: 0.4,

        //Number - Radius of each point dot in pixels
        pointRadius: 4,

        //Number - Pixel width of point dot border
        pointBorderWidth: 1,

        //Number - amount extra to add to the radius to cater for hit detection outside the drawn point
        pointHoverRadius: 20,

        //Number - Pixel width of dataset border
        borderWidth: 2,

        //String - A legend template
        legendTemplate: "<ul class=\"<%=name.toLowerCase()%>-legend\"><% for (var i=0; i<datasets.length; i++){%>
<span style=\"background-color:<%=datasets[i].borderColor%>\"><%if(datasets[i].label){%><%=datasets[i].label%><%}%>
<%}%>
",

        tooltipTemplate: "(<%= dataX %>, <%= dataY %>)",
        multiTooltipTemplate: "<%if (datasetLabel){%><%=datasetLabel%>: <%}%>(<%= dataX %>, <%= dataY %>)",

    };

Scale Constructor Registration
Extensions should register scale types in the following way.
Chart.scales.registerScaleType("my scale type name", MyScaleConstructor);

// The constructor can then be retrieved by doing the follwing
var scaleConstructor = Chart.scales.getScaleConstructor("my scale type name");

To use a new scale type, change the scale configuration as follows. The scatter chart will look up the corresponding constructor when building the scales.
scale: {
    scaleType: "my scale type name"
}

Linear Axis
The linear axis limit calculation has been redone to follow the nice number algorithm. http://stackoverflow.com/questions/8506881/nice-label-algorithm-for-charts-with-minimum-ticks
The scale config allows the user to provide a callback function that will determine the label for a given tick mark. The user provides this function as
labels: {
    show: true,
    template: "<%=value%>",
    fontSize: 12,
    fontStyle: "normal",
    fontColor: "#666",
    fontFamily: "Helvetica Neue",
    // tickValue {number} : the numerical value that a label is needed for
    // tickIndex {number} : the index of the tick in the internal ticks array
    // ticksArray {array} : the array of all ticks in the scale
    userCallback: function(tickValue, tickIndex, ticksArray) {
         return tickValue.toString();
    }
}

Zero Point Drawing
As can be seen in the scatter chart images below, the linear axis allows different draw settings for the line that represents the 0 points.
Resize Behaviour
During resizing, the linear chart will dynamically scale the number of ticks rather than rotating text.
Scatter Chart
The scatter chart uses a linear axis by default along the bottom. This axis may be moved to the top of the chart area by changing the position to "top" in the configuration. The data for a scatter chart is an object with two parameters x and y.
Single Y Axis

Multiple Y Axes

Bar Charts
Bar charts also support multiple y axes. In this example, the red and dark blue traces are bound to the left axis while the cyan trace is bound to the right axis.

Line Charts
Line charts also support multiple y axes.

Issues fixed
This PR should fix the following issues though testing is required and there may be bugs.

#12
#17
#80
#132
#143
#730
#753
#991
#1071

In the section above "Linear Axis" it's written that "The linear axis limit calculation has been redone to follow the nice number algorithm. ..."
It not clear to me how to integrate. Lets say I have 300 data points for x-axis and I only want to show a tick and corresponding label at every 10th data point. How is that done? Any example code would help.


nodejs-slim_22: 22.0.0 -> 22.1.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for nodejs-slim_22 is: Event-driven I/O framework for the V8 JavaScript engine
meta.homepage for nodejs-slim_22 is: https://nodejs.org
meta.changelog for nodejs-slim_22 is: https://github.com/nodejs/node/releases/tag/v22.1.0
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 22.1.0 with grep in /nix/store/qfmnyx4si2gp4p3c3y8v4bsj6s4s1qvn-nodejs-slim-22.1.0
found 22.1.0 in filename of file in /nix/store/qfmnyx4si2gp4p3c3y8v4bsj6s4s1qvn-nodejs-slim-22.1.0

Rebuild report (if merged into master) (click to expand)

7 total rebuild path(s)

7 package rebuild(s)

First fifty rebuilds by attrpath

corepack_22
corepack_latest
nodejs-slim_22
nodejs-slim_latest
nodejs_22
nodejs_latest

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/qfmnyx4si2gp4p3c3y8v4bsj6s4s1qvn-nodejs-slim-22.1.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A nodejs-slim_22 https://github.com/r-ryantm/nixpkgs/archive/ec5fa427c6e3ee0ee17d3928a8da4acb3147de14.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/ec5fa427c6e3ee0ee17d3928a8da4acb3147de14#nodejs-slim_22

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/qfmnyx4si2gp4p3c3y8v4bsj6s4s1qvn-nodejs-slim-22.1.0
ls -la /nix/store/qfmnyx4si2gp4p3c3y8v4bsj6s4s1qvn-nodejs-slim-22.1.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

5 packages built:

corepack_22 (corepack_latest)
nodejs-slim_22
nodejs-slim_22.libv8
nodejs_22
nodejs_22.libv8

Maintainer pings
cc @cillianderoiste @cko for testing.

Already on master.


revert

fixed bug when window scroll
absolute is More appropriate

great fix. thx for contribution :+1:


Camera overlay

Hi,
I am just wondering whether this plug in can have the overlay layer on the camera. In my use case, I need to provide the custom text and a custom button when the camera open. How can I do it with this plug in.
Thanks
THomas

+1

+1

+1

+1

+1

+1

Duplicate of #11


Ignore CODEOWNERS in XCBuildSupport

This was recently added, but generates a warning if unhandled, so we should mark it as excluded.

@swift-ci please smoke test


Clearing loaded _tiles in TileLayer.

While writing a heat map plugin for flutter_map, I came across the need to reset the tiles held in memory within TileLayerState (_tiles). When the data for the heat map changes, the heat map tiles should be rebuilt. currently this only happens zooming in/out or moving outside of the keepBuffer limit.
This also applies to working with WMS servers with server side filtering. When the filter changes, the tiles are the same.
I initially looked into using the rebuild stream to manually trigger the rebuild but this doesn't support unloading the current _tiles.

Hi @tprebs , some time ago I also started a heat map plugin, but using a CustomPainter instead of a tiled layer approach, so that it would properly repaint on data change.
On a sidenote I was blocked by the impossibility to get the current pixel value from the canvas and had to put the work aside due to other job issues. I was porting leaflet's heatmap plugin. May I ask what approach you chose?

I have done something similar regarding the CustomPainter. I have created an untiled version which doesn't work as well with larger (5000 + points) as there is no easy way to distinguish between an on map move start and on map move finish event which means it redraws and recalculates the heatmap data at a very high frequency. The tiled approach works much better for larger datasets as the individual tiles are cached (both in TileLayer and in a custom TileProvider).
I faced a similar issue with the attempting to get the current pixel value. I went down a similar route to the leaftlet heatmap plugin.

Create a canvas 1 pixel by 256 and apply the colour gradient to a rectangle 1x256. Capture the image with picture recorder and cache it (this is how I got the pixel values). This ByteData becomes the colour palette to apply colour to the grayscale heatmap image
Create a canvas to create a template image used to replace each LatLng (similar approach to above)
Generate the heatmap layer/tile by applying the template image at each point
process the heatmap layer pixel by pixel replacing the 255 grayscale value with the value on the colour ramp.

Steps 1 and 2 can be done on initialisation, only requiring step 3 and 4 to be run for each layer rebuild.

@tprebs , any chance that code goes public or is it a private project? I would be happy to contribute or test.
The issue that blocked me was that picture recorder only works async and I couldn't plug it into my rendering cycle :-)
But I will have to go back on that eventually.

This used to work properly, but now the cache looks like it not clearing. I just want to let the user switch back and forth between map types. It used to redraw right away, but now the user has to pan or zoom to get things going.

@moovida
This will go into a public repo once I have a bit more time to make it more generic. I will be happy collaborate with you on this.
I moved the heatmap generation outside of the render cycle to get around this. I have a heatmap generator which asynchronously generates bitmap images. once the image is rendered the imagedata can be painted on the canvas synchronously

@tprebs , clearly you did. Actually that is the perfect way to go, not sure why I didn't think of it :-D
Well, I have time to work on this later, I am leaving for 2 weeks. After that I can happily contribute with documentation you were to bored to write and review the code (I took the exact same approach on the heatmap side).
Ping me when you want me to dig in. Or I ping you if I come prior to the point in which I would like to have it implemented. Thanks!


PR for instana-agent

https://dcos.io/blog/2017/earn-a-t-shirt-by-updating-a-package-example-for-dc-os-1-9/index.html

Whoops my mistake! working on the changes now, will submit a new PR shortly.

New PR: https://github.com/dcos/examples/pull/164


tvOS Support: added tvOS target, test target, and scheme

This is an attempt to add tvOS support through separate targets, solving the issues raised in https://github.com/pinterest/PINRemoteImage/pull/401
Adds targets:

PINRemoteImage-tvOS
PINRemoteImage-tvOSTests

Adds shared scheme:

PINRemoteImage-tvOS

          1 Warning

:warning:
This is a big PR, please consider splitting it up to ease code review.

  Generated by :no_entry_sign: Danger

🚫 CI failed with log

@garrettmoon seems like this is a common test failure in previous PRs... is it something I need to address, or just CI wonkiness?

Lame CI wonkiness (I haven't figured out a good way to make them reliable, they require iOS to report back download progress before it's done which isn't guaranteed), I'll rerun until it's successful.

🚫 CI failed with log

          1 Warning

:warning:
This is a big PR, please consider splitting it up to ease code review.

  Generated by :no_entry_sign: Danger

@jverdi mind adding a line to the CHANGELOG.md?

@garrettmoon sure, added

Thanks for the contribution @jverdi !


Use a flag for accepting stdin

If both text and stdin, append stdin after text, separated by a newline

Done


fix: init project doesn't replace stage

So I noticed that when calling initProject twice, it seems to replace some values but not all of it.
Here's how to re-create it:
import { useProject, initProject } from 'sst/project';

await initProject({ stage: 'prod' });
const project = useProject();

console.log(project);

await initProject({ stage: 'justin' });
const project2 = useProject();

console.log(project2);

What I see logged out is that everything is the same between the 2 stages except for the config.profile. But if we deleted the SST_STAGE env variable before initiating the project a 2nd time, it works as expected. I think if we are passing in a config, it should take precedent before the SST_STAGE env variable. Either way, it's weird that the profile changes but not the stage.
My use case is: I'm writing a script that let's me migrate data between different environments. E.g. Migrate User Xs data from prod to dev, so that I can debug the issue.

I'll send it to Dax


@csrf Blade Directive | Error: An input element with a type attribute whose value is hidden must not have an autocomplete attribute whose value is on or off.

Laravel Version
10
PHP Version
8
Database Driver & Version
No response
Description
I don't know if it's right to have the autocomplete attribute on the HTML tag generated by the @csrf Blade directive.
https://github.com/laravel/framework/blob/37cb3450150cf75af787dc9bcd8de08370024008/src/Illuminate/Foundation/helpers.php#L326C5-L326C5
I'm inquiring because running the generated HTML tag below on the w3c Validator  https://validator.w3.org/ throws an Error.
<input type="hidden" name="_token" value="aOZTBSeC6yErTEjpVskiG9c6YSaileoWLb6CGkrT" autocomplete="off">

Steps To Reproduce
Paste and run the generated HTML tag below by @csrf Blade directive on the w3c Validator
https://validator.w3.org/
<input type="hidden" name="_token" value="aOZTBSeC6yErTEjpVskiG9c6YSaileoWLb6CGkrT" autocomplete="off">

@elminson Oh, l see.  I wasn't aware that this was discussed already. Thanks for the closed issue references. I will do my home work next time before opening a new issue.
I'm closing this issue since it was discussed already in the referenced closed issues.


IP Flow Verify vs Outbound Connectivity to VM

Can you please elaborate a little bit more acout these two features?
Test-AzNetworkWatcherConnectivity
Test-AzNetworkWatcherIPFlow
I would think both can be used to diagnose the connectivity to a VM, so which one should be used for what use case?
what rbac permission is needed to run the command?
[Enter feedback here]

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

ID: a185234e-3ef6-6010-127c-60f3834a9f39
Version Independent ID: fd14f01e-9672-b8e7-192e-ecf2bf8bc9b3
Content: Quickstart: Diagnose a VM network traffic filter problem - Azure PowerShell - Azure Network Watcher
Content Source: articles/network-watcher/diagnose-vm-network-traffic-filtering-problem-powershell.md
Service: network-watcher
GitHub Login: @damendo
Microsoft Alias: damendo

@RonnieQuan , Test-AzNetworkWatcherIPFlow cmdlet will only inform you if communication between your VM and a destination is allowed or denied and which NSG is allowing or denying it. But even when a NSG shows a packet as allowed, there could be instances where the communication may fail due to an issue on the intermediate hop. In such cases, you can use Test-AzNetworkWatcherConnectivity cmdlet to find out the details about the issue preventing the communication to be successful.
The Test-AzNetworkWatcherConnectivity cmdlet returns connectivity information for a specified source VM and a destination. If connectivity between the source and destination cannot be established, the cmdlet returns details about the issue such as ConnectionStatus, ProbesSent, ProbesFailed, Hops with issues (user-configured NetworkSecurityRule, UserDefinedRoute etc).
Please refer:
https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-connectivity-powershell
https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-connectivity-powershell
The Test-AzNetworkWatcherIPFlow cmdlet, for a specified VM resource and a packet with specified direction using local and remote, IP addresses and ports, returns whether the packet is allowed or denied. It returns the NSG which is allowing or blocking the traffic.
Please refer:
https://docs.microsoft.com/en-us/azure/network-watcher/diagnose-vm-network-traffic-filtering-problem-powershell
https://docs.microsoft.com/en-us/azure/network-watcher/diagnose-vm-network-traffic-filtering-problem-powershell#use-ip-flow-verify
To use Network Watcher capabilities, the account you log into Azure with, must be assigned to the Owner, Contributor, or Network contributor built-in roles, or assigned to a custom role that is assigned the actions listed for each Network Watcher capability as mentioned in the below articles.
https://docs.microsoft.com/en-us/azure/network-watcher/required-rbac-permissions#connection-troubleshoot
https://docs.microsoft.com/en-us/azure/network-watcher/required-rbac-permissions#ip-flow-verify
We are closing this issue for now. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.

@GitaraniSharma-MSFT
Thank you so much for the information.
I would like to clarify one thing if you don't mind.
Test-AzNetworkWatcherConnectivity send probe, it's good to know.
How about Test-AzNetworkWatcherIPFlow? I guess it does not send probe, it only checks nsg rule.
Thanks!

@RonnieQuan , sorry for the delay in my response.
Yes, that is correct. Test-AzNetworkWatcherConnectivity sends probe to verify whether a direct TCP connection from a virtual machine to a given endpoint can be established.
Whereas, Test-AzNetworkWatcherIPFlow do not send any probe but just checks if the traffic is allowed/denied in the NSG rules.
Thank you.


Issue with @import

I can't import a file located outside of my project. I like to keep my 3rd party libraries in a libs folder. I am trying to do
@import "..........\libs\twitter\bootstrap"
I was able to modify
namespace dotless.Core.Input
{
using System.Web;
using System.IO;
public class AspServerPathResolver : IPathResolver
{
    public string GetFullPath(string path)
    {
        try
        {
            return HttpContext.Current.Server.MapPath(path);
        }
        catch (HttpException)
        {
        }

        path = path.Replace("/", "\\");
        return Path.Combine(HttpContext.Current.Request.PhysicalPath, path);
    }
}

}
Is this something you would want as a pull request or does it break other things? All the unit tests pass. It probably doesn't work in all situations but... if you make the import relative to the css file importing it works. It could be a starting point since this is probably a windows only solution.

It seems ok to me. I can make this change today, except I'll use the path seperator constant so it doesn't just work for windows.

I think the better fix is to add a new path resolver and enable a way to switch to it.
@tigraine is there an automatic way to specify that the following pandora line should be overridden
pandora.Service<IPathResolver>().Implementor<AspServerPathResolver>().Lifestyle.Transient();

so that someone could specify a different path resolver?

Only if you put another line with the service before it.
That's why most of the extensibility comes through the web.config and is conditional inside the Pandora registration.
Pandora resolves from top to bottom, first implementation registered is first implementation used.
If the first implementation requires another implementation of the same interface the second one will be used etc etc..

So we could make this an option in the web.config or steveoh could implement his own Resolver and call a line like above in his app start so that it beats dotless to it...

We could expose the pandora instance during a setup step. But through web config would also help ppl using the handler.

Hi @steveoh when you get a chance, please could you try with the latest source (or in the next release) and add an attribute to your web.config mapPathsToWeb=false.
This uses a new path resolver which just takes the current http request path and uses that like a "current directory" (essentially your suggestion after the try catch)


Do we still need syncBackend.json?

Superset version
master
Expected results
There is a file syncBackend.json and script for generating it.
However, it does not seem to be used anywhere.
If there is any need for it, please comment here. Otherwise I propose we delete syncBackend.json and the accompanying script within a week.

95% sure that the answer is no, and I also think we won't need it in the future. Global environment configurations live in superset_config.py, and we have a mean to share a subset to the frontend that works well.

Reading through the code, we only need the logic that is in there to support migrations from 2+ years ago (feb 2017), and provided that they would first upgrade to a bridge version (anywhere from pre 2017 to something between then and our next version) they'd be ok.
Also needed to support full bookmarks (the long ones, not shortened) from 2+ years ago versions.
I vote for pulling the plug on this one.


Add known materials from matlab code

Find/generate structures in CIF format for known materials in matlab code. These are the ones that are available.

[x] argyrodite, supercell: (1 1 1)
[ ] latp, supercell: (1 1 1)
[ ] na3ps4, supercell: (2 2 2)
[ ] lisnps, supercell: (1 1 1)
[ ] li3ps4_beta, supercell: (1 1 2)
[ ] mno2_lambda, supercell: (1 1 1)
[ ] lagp, supercell: (1 2 2)

When we add this we should also:

[ ] make it selectable in the dashboard


simplify create-svelte

#987
Before submitting the PR, please make sure you do the following

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[ ] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint

Changesets

[ ] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts

I think this is a bit simpler — no CSS/SASS/LESS option, and the template (soon to be templates) is authored in TS and converted to JS at build time.
Additionally, the modifiers no longer make brittle edits via code; instead we have files inside directories like
shared/+eslint-prettier

which means 'copy this if the user chose eslint but not prettier, regardless of their typescript choice'. It results in some duplication, but I think it'll prove easier to grok.
Also, since more of the work is happening at build time, the create-svelte package gets even tinier.
Not sure what's going on with the lint failure, will investigation in the morning.

FYI, lint is failing
The naming scheme seems like it could create an exponential explosion. E.g. we have four eslint configs right now. If we add a prompt for legacy mode (i.e. IE support) that used @babel/eslint-plugin I think we would need to create a +babel and -babel version (or +legacy/-legacy if we want to call it that instead) of each of the existing files so we'd have eight of them.

I hear the point re combinatorial explosion, but my sense is that it's less of an issue than it appears. Firstly, the package.json files are merged (i.e. the eslint and eslint-plugin-svelte3 dev dependencies are only declared in the +eslint directory, not +eslint and +eslint-prettier and +eslint-typescript and +eslint+prettier and +eslint+prettier-typescript and +eslint+prettier+typescript and +eslint+typescript).
I can't imagine us wanting to add a Babel option other than to support a legacy mode, in which case we wouldn't need @babel/eslint-plugin IIUC — that's only to extend the ESLint parser with support for new language features.
In cases where tools don't overlap (i.e. adding Babel without adding the ESLint plugin), no combinatorial explosion will arise; it's just like that right now because TypeScript and Prettier and ESLint do overlap. It certainly could become an issue in future but I think we can probably cross that bridge when we come to it. I still think on balance it's better to have things be declarative even at the cost of some duplication. It's definitely not clear-cut though.

Yeah I'd also say if we add a bunch more stuff and there are too many combinations, we can always revisit this decision. So I'm good with these changes.


Readme file

Update the readme file.

Add gitter badge

Readme file should be in polish also.

Fixed in #46


Updated ReadMe for readability

I tried not to change the intent at all, but to update for readability, parallel structures, verb tense, etc. Nice work. The opening description and the Mendel paragraph were beautiful!

Thanks a lot!


Throw exception on missing middleware

Hello!
Right now, Sails silently ignores if «http.middleware.order» array contains references to missing middleware. I think it's a critical defect. It should throw exceptions instead.
Consider this scenario
Developer creates a middleware named «someVeryImportantLogicToRun» which can contain some required security or logging functionality. After that he adds it to the orders array, but accidentally makes a mistake in the name: «someImportantLogicToRun». By looking on the order array and by running the application he will not notice the issue until something bad happens.
I hope it makes sense. Thank you!

Hi @slavafomin is this still an issue with the latest release?


Mayor Refactor - Compatibility with new Bamboo API and report improvements

This PR is a big refactor for all plugin it's fully tested in a bamboo evaluation environment and offer complete compatibility with the new API. Several bugs were solved in this version, and it's not compatible with the last release so I propose version 2.0.
The logo is customizable, the Allure Report Title is set by the plugin, and the report is exportable to a zip file. The history is generated properly, and the historical links work fine. Those are some of the changes that I made.
Details in commits details.

I need to create a new fork and pull request because I didn't sign my commits. Thanks!

@eroshenkoam please could you help me with this PR? Thanks!

Hi @baev, thanks to execute the required build but, it's failing when it try to download a dependency. I am not able to reproduce that issue on my machine, I can generate a jar properly,  using atlas-package after doing atlas-clean.

The bin that I generated: https://drive.google.com/file/d/1SyylGaE5-ZovT18NJ5KwJ55gS63qWUBp/view?usp=sharing
Command used: atlas-package

@lararojasmr hello sir,
thanks a lot for your efforts.
We've added the review of your PR to the plans and started executing the review/.

@lararojasmr Manuel, could you please check your email?

@lararojasmr Manuel, could you please check your email?

Thanks @cheshi-mantu. I'll make these changes, sorry I have been with a lot of work these days.

@lararojasmr Hi Manuel,
have you had a chance to review?
thanks

Yes, but let me make all the changes that you suggested. I have had a lot
of work in the past months, so I haven't had the chance to make it. But,
before 2023, I hope to have all changes done. Thanks!
Ing. Manuel Lara
Telf. +598-98-600-665 https://wa.me/59898600665
e-mail: @.***
*linkedIn: *https://ve.linkedin.com/in/ingmanuellara
*skype: *lararojas.mr
El jue, 24 nov 2022 a la(s) 09:44, Egor Ivanov @.***)
escribió:

@lararojasmr https://github.com/lararojasmr Hi Manuel,
have you had a chance to review?
thanks
—
Reply to this email directly, view it on GitHub
https://github.com/allure-framework/allure-bamboo/pull/270#issuecomment-1326474148,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADUAQ4J7SXRV7G7JXCWUJLDWJ5WLFANCNFSM57BYZ4ZA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi, I'm working to fix all your comments. Sorry for the delay!

@cheshi-mantu it's ready to merge!

@vbragin have you had a chance the updates?


Updating lock files without a full build

We've begun using cargo-fuzz in linkerd2-proxy. One thing that's been particularly difficult to manage is the Cargo.lock file for each fuzzer. Each fuzzing project is in its own distinct workspace, as we can't include the fuzzers in the repo-level workspace because cargo test --all fails with linking errors (on rust stable).
As we update dependencies in the project, we have to regenerate the Cargo.lock files for each fuzz workspace to keep things consistent and reproducible. With something like:
:; for d in $(find . -name fuzz | sort -r ) ; do echo "# $d" ; (cd $d ; cargo +nightly fuzz build) ; done

But this is slow. Doing a full build on of these can take several minutes.
I'd really like a command akin to cargo check--cargo fuzz check?--that ensures the project can compile without doing a full build & linking of the workspace.
Is there any reason this would be particularly difficult? Any pointers on how best to implement something like this?

I'd really like a command akin to cargo check -- cargo fuzz check? -- that ensures the project can compile without doing a full build & linking of the workspace.

I had the same issue. My solution is to simply run cargo check instead of using cargo fuzz build from the fuzz directory. From what I understand the cargo fuzz run and cargo fuzz build are here only to pass the instrumentation flags to the compiler. It also has the advantage of not requiring the nightly compiler.

Each fuzzing project is in its own distinct workspace, as we can't include the fuzzers in the repo-level workspace because cargo test --all fails with linking errors (on rust stable).

Have you tried adding test = false and doc = false to the already existing fuzz targets? See https://github.com/rust-fuzz/cargo-fuzz/issues/223


perf: read_ply replace pandas.read_csv engine=python with c; improve read_off header-parsing robustness

Original text before #353 was merged:

Big performance improvement by removing the need to use the slow engine="python" by reading the sliced file from an in-memory StringIO buffer.
Also fixes bug where OFF files containing more lines than num_points + num_faces tries to read potential edges as faces!
As Wikipedia says, the OFF file may contain:

points
faces (optional)
edges (optional)

Of course, this still does not encompass all possible OFF file variants described by Wikipedia, but it's an improvement.

I have rebased on top of the latest commit. The revised changes are:

perf: Speed up reading of ASCII PLY files.
style: renamed variables for clarity (e.g. color -> has_color; and count -> n_header)
feat: improve robustness for OFF headers on e.g. ModelNet40
perf: reuse already open file for reading instead of opening it twice

In particular, ModelNet40 has faulty headers:
$ head -n 1 ModelNet40/chair/train/chair_0856.off
OFF6586 5534 0

For reference, the correct format is:
OFF
6586 5534 0

Nonetheless, it is still valuable to parse the faulty header.

I rebased this PR on top of #353 which implements the pandas engine=python performance improvements for *.OFF files already.
Still, this PR adds some other useful changes, listed above.
Once this is reviewed/accepted, I can look into adding support for reading *.OFF color attributes.


[Dark Mode] Update Native UI Components for dark mode

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:
Break down in numbered steps

Open a drop-down menu
Activate the native scrollbar in emoji picker or chat

Actual Result:
Describe what you think should've happened

Focused option should be green, but it is blue
Native scrollbar should blend in, but instead it contrasts against background

havent gotten to this one yet

Closing this out as a dupe


Remote OpenVPN server proto definition. Issue #10368

[ ] Redmine Issue: https://redmine.pfsense.org/issues/10368
[ ] Ready for review

When implementing a OpenVPN server and selecting the protocol "udp on ipv4 only" i expect, that that is exaclty what is included in my client configuration file.
Since this is not what is being configured, clients which have ipv6 available will try to connect through ipv6 and since the server is not running on ipv6 they are unable to connect.
What actually is included:
remote example.org 1194 udp
What i expect to be included:
remote exmaple.org 1194 udp4
This PR adds protocol definition.
TODO: same for OpenVPN client export

from openvpn(8):
--remote host [port] [proto]
Remote host name or IP address.  On the client,  multiple  --re‐
mote  options may be specified for redundancy, each referring to
a different OpenVPN server.  Specifying  multiple  --remote  op‐
tions  for  this  purpose  is a special case of the more general
connection-profile feature.  See the   documentation
below.
          The  OpenVPN client will try to connect to a server at host:port
          in the order specified by the list of --remote options.

          proto indicates the protocol to use when connecting with the re‐
          mote, and may be "tcp" or "udp".

          For  forcing  IPv4 or IPv6 connection suffix tcp or udp with 4/6
          like udp4/udp6/tcp4/tcp6.


app.logger deployment error

The app.logger.js causes some jshint errors at the deployment.

will be in the release v1.0.0-rc.3


make sure daemonset has at least one pod ready

Fixes #32887
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[x] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[ ] Does not have any user-facing changes. This may include CLI changes, API changes, behavior changes, performance improvements, etc.

Hi @holooooo. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/ok-to-test

@holooooo: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

gencheck_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

gencheck_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test gencheck_istio

integ-distroless-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-distroless-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

gencheck_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test gencheck_istio

integ-distroless-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-distroless-k8s-tests_istio

integ-pilot-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

gencheck_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test gencheck_istio

integ-distroless-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-distroless-k8s-tests_istio

integ-pilot-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-k8s-tests_istio

integ-helm-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-helm-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

gencheck_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test gencheck_istio

integ-distroless-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-distroless-k8s-tests_istio

integ-pilot-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-k8s-tests_istio

integ-helm-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-helm-tests_istio

integ-telemetry-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

gencheck_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test gencheck_istio

integ-distroless-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-distroless-k8s-tests_istio

integ-pilot-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-k8s-tests_istio

integ-helm-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-helm-tests_istio

integ-telemetry-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-k8s-tests_istio

integ-operator-controller-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-operator-controller-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

gencheck_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test gencheck_istio

integ-distroless-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-distroless-k8s-tests_istio

integ-pilot-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-k8s-tests_istio

integ-helm-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-helm-tests_istio

integ-telemetry-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-k8s-tests_istio

integ-operator-controller-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-operator-controller-tests_istio

integ-security-multicluster-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-security-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

gencheck_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test gencheck_istio

integ-distroless-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-distroless-k8s-tests_istio

integ-pilot-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-k8s-tests_istio

integ-helm-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-helm-tests_istio

integ-telemetry-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-k8s-tests_istio

integ-operator-controller-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-operator-controller-tests_istio

integ-security-multicluster-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-security-multicluster-tests_istio

integ-multicluster-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-multicluster-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

gencheck_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test gencheck_istio

integ-distroless-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-distroless-k8s-tests_istio

integ-pilot-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-k8s-tests_istio

integ-helm-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-helm-tests_istio

integ-telemetry-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-k8s-tests_istio

integ-operator-controller-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-operator-controller-tests_istio

integ-security-multicluster-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-security-multicluster-tests_istio

integ-multicluster-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-multicluster-k8s-tests_istio

integ-security-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-security-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

gencheck_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test gencheck_istio

integ-distroless-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-distroless-k8s-tests_istio

integ-pilot-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-k8s-tests_istio

integ-helm-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-helm-tests_istio

integ-telemetry-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-k8s-tests_istio

integ-operator-controller-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-operator-controller-tests_istio

integ-security-multicluster-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-security-multicluster-tests_istio

integ-multicluster-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-multicluster-k8s-tests_istio

integ-security-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-security-k8s-tests_istio

integ-pilot-multicluster-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

analyze-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test analyze-tests_istio

unit-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test unit-tests_istio

release-test_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test release-test_istio

lint_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test lint_istio

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

gencheck_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test gencheck_istio

integ-distroless-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-distroless-k8s-tests_istio

integ-pilot-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-k8s-tests_istio

integ-helm-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-helm-tests_istio

integ-telemetry-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-k8s-tests_istio

integ-operator-controller-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-operator-controller-tests_istio

integ-security-multicluster-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-security-multicluster-tests_istio

integ-multicluster-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-multicluster-k8s-tests_istio

integ-security-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-security-k8s-tests_istio

integ-pilot-multicluster-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-multicluster-tests_istio

integ-ipv6-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-ipv6-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

so many failed test 😳 what should I do

Build fails:
+ make dockerx.pushx
mkdir -p /home/prow/go/src/istio.io/istio/out/linux_amd64/logs
mkdir -p /home/prow/go/src/istio.io/istio/out/linux_amd64/release
GOOS=linux GOARCH=amd64 LDFLAGS='-extldflags -static -s -w' common/scripts/gobuild.sh /home/prow/go/src/istio.io/istio/out/linux_amd64/ ./istioctl/cmd/istioctl ./pilot/cmd/pilot-discovery ./pkg/test/echo/cmd/client ./pkg/test/echo/cmd/server ./operator/cmd/operator ./cni/cmd/istio-cni ./cni/cmd/istio-cni-repair ./cni/cmd/istio-cni-taint ./cni/cmd/install-cni ./tools/istio-iptables ./tools/bug-report
# istio.io/istio/operator/pkg/helmreconciler
operator/pkg/helmreconciler/wait.go:31:2: imported and not used: "k8s.io/apimachinery/pkg/util/intstr"
real	0m5.838s
user	0m30.728s
sys	0m6.404s

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-mc-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-telemetry-mc-k8s-tests_istio

integ-pilot-k8s-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-k8s-tests_istio

integ-pilot-multicluster-tests_istio
5c2d3ae7bb85c9f23d83ead1ee5c341a25d28fc2
link
/test integ-pilot-multicluster-tests_istio

integ-telemetry-k8s-tests_istio
ee684aa6ec25fbb998bbe396d13b8e6872392330
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@holooooo: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
ee684aa6ec25fbb998bbe396d13b8e6872392330
link
/test integ-telemetry-k8s-tests_istio

integ-telemetry-mc-k8s-tests_istio
ee684aa6ec25fbb998bbe396d13b8e6872392330
link
/test integ-telemetry-mc-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

First time apply daemonset, desired num is 0，0-max unavailable less the 0，and also less then ready num.
It means if you get daemon set obj  by post response,or get too fast.Old logic will return ready immediately.
---Original---
From: "Morven @.>
Date: 2021/6/11 19:06:32
To: @.>;
Cc<EMAIL_ADDRESS>Subject: Re: [istio/istio] make sure daemonset has at least one pod ready (#33369)
@morvencao commented on this pull request.
If the original issue only happen in 1 node case, I don't think it's a good idea to update the current ready check logic.
If you insist, please add testing for install/upgrade cases.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

If the original issue only happens in 1 node case, I don't think it's a good idea to update the current ready check logic. Adding check for 1 node case should be sufficient.
If you insist, please add testing for install/upgrade cases.

It not only happens on one node. The case I ran into is that at installation time, there is a brief period where (NumberDesired = -1, NumberReady = 0). Current logic will consider this as ready. It looks like @holooooo also sees the case where (NumberDesired = 0, NumberReady = 0).

If the original issue only happens in 1 node case, I don't think it's a good idea to update the current ready check logic. Adding check for 1 node case should be sufficient.
If you insist, please add testing for install/upgrade cases.

It not only happens on one node. The case I ran into is that at installation time, there is a brief period where (NumberDesired = -1, NumberReady = 0). Current logic will consider this as ready. It looks like @holooooo also sees the case where (NumberDesired = 0, NumberReady = 0).

I delete expectedReady field, so there will never have -1 case.(controller manager count every available node as NumberDesired, so it also never be negative)

If the original issue only happens in 1 node case, I don't think it's a good idea to update the current ready check logic. Adding check for 1 node case should be sufficient.
If you insist, please add testing for install/upgrade cases.

It not only happens on one node. The case I ran into is that at installation time, there is a brief period where (NumberDesired = -1, NumberReady = 0). Current logic will consider this as ready. It looks like @holooooo also sees the case where (NumberDesired = 0, NumberReady = 0).

I delete expectedReady field, so there will never have -1 case.(controller manager count every available node as NumberDesired, so it also never be negative)

Ah I see. Thanks! Could you please take a look at this comment https://github.com/istio/istio/pull/33369#discussion_r650092053?


Change Cache-Control default max-age to one minute

The extremely long cache expiration doesn't match usage.
Also clean up a minor clippy lint.

@technosophos FYI

Should this be a configuration in spin.toml?

It is. Hence "default" 🙂

👯♂ - It's Friday!!! (trying to come up with an excuse...)


THC/THC.h: No such file or directory

THC is removed from recent Torch versions. I have commented the related imports, and it seems to compile well.

Could you contribute a pull request for this fix?


UnhandledPromiseRejectionWarning: Error: Unhandled method window/showMessageRequest

Getting this issue in the console when using VLS. But it only happens if project is configured with a different root option in vite.config.js.

I resolved by configuring Vetur with vetur.config.js. Maybe worth to add it to the README as a note.


Better use of diamond operator

Hi
I have simplify the use of diamond operator
ciao
matteo

Hi
someone can check this PR?
all the best
matteo baccan


New Plan Card Design

This is a UI task to implement our new design for the plan card.
It should include the following information:

Link to Figma

[ ] simplified status + date. The circle next to the status has a dynamic color based the status. if "מאושרת" then blue, else purple. See #372
[ ] button to bookmark and cancel bookmarking of the plan
[ ] map
[ ] city name
[ ] area of plan (דונם)
[ ] distance from search coordinates. this is a dynamic element: if the context of the card is not after an address search, hide this element (just like the existing behavior).
[ ] difference of housing units (דירות). if added ,the add "+". if removed, add "-" after the number. If no changes, hide this element.
[ ] plan name #377
[ ] plan tags. #369 read from the plan_tag table per plan.
[ ] alert (in orange) - no need to develop now.

Additional Requirements

[ ] Card should have a fixed height. If the tags exceed 2 lines, show only the results that can be visible, and add (X) showing the number of tags that couldn't be shown.
[ ] Card width is dynamic: In mobile mode, width is 270px, while the in tablet/desktop it is 360px

Great Job @ofirkg this is moved to Closed


Recognize "Black Sats" in ord

"Black Sats" have risen in notoriety as interesting collectible sats due to their similarities with Rodarmor rarity Uncommons, Rares, etc., and having visual appeal ending in "...999999999"
Based on definitions on Magisat and Sating, there seems to be consensus on the following:

Black Uncommon Sats are the last sats in each new block.
A Black Rare Sat is the last sat in each Bitcoin Difficulty Adjustment period. It is the sat just before a Rare.
A Black Epic Sat is the last satoshi created in the coinbase of the last block before a Halving Event.

We could also enable the more rare ones (suggested):

A Black Legendary sat could be the last sat in a cycle.
A "Black Mythic" sat could be the last sat mined.

I black sats, so I like the idea of recognizing them. Some thoughts:

Would this be considered dilutive of the "original" rarity tiers?
I want to come up with new names for each tier of black sat. I think it's confusing if there are two types of uncommons. I was thinking something like "curious, odd, anomalous, aberrant, bizarre" or "ink, pitch, jet, onyx, obsidian".
What charms should we use? I was looking through emoji, and nothing immediately stood out for me.

Love the idea of black sats being recognized <3.
Q1: Would this be considered dilutive of the "original" rarity tiers?
No. People are already collecting them and are aware of their value proposition. Legitimizing them would be a good thing.
Q2: I want to come up with new names for each tier of black sat. I think it's confusing if there are two types of uncommons. I was thinking something like "curious, odd, anomalous, aberrant, bizarre" or "ink, pitch, jet, onyx, obsidian".
A2: People are collecting and seeing value in them. Us and magic eden use the naming:
"uncommon black sat": last sat of the block
"rare black sat": last sat before difficulty adjustment
"epic black sat": last sat before halving
"mythical black sat": last sat created
I think it would be good to stick to these namings. The market and rare sat collectors are already used to identifying them by these names.
Q3: What charms should we use? I was looking through emoji, and nothing immediately stood out for me.
A3: Maybe find some other seedling for the uncommon black sats 😂.

I black sats, so I like the idea of recognizing them. Some thoughts:

Would this be considered dilutive of the "original" rarity tiers?
I want to come up with new names for each tier of black sat. I think it's confusing if there are two types of uncommons. I was thinking something like "curious, odd, anomalous, aberrant, bizarre" or "ink, pitch, jet, onyx, obsidian".
What charms should we use? I was looking through emoji, and nothing immediately stood out for me.

I agree with @Magisat's point on not being dilutive since all major marketplaces support both, and collectors find them worth collecting for their separately exciting qualities. Also, what's cooler than recognizing that the last sat ever mined will be a black/obsidian sat?
I'm not strongly opinionated on the naming, and I like your suggestions! I think @Magisat has a fair point about the prevalent existing names. However, black sats are still not recognized for inscriptions on most significant marketplaces, so the meta hasn't proliferated far enough that we couldn't intentionally align on the names.
@cbspears's suggestions are good!

Black sats have really found their place in the market.
I don't believe they are dilutive. As @cbspears mentioned, the RRI (Rodarmor Rarity Index) is KING, market respects it.
I think the current naming works—black uncommon, black rare, black epic, etc. BUT not opposed to something else that makes sense.
Other emojis: ⚫◆❖🔲♣♠
*Deezy's sathunter is currently using the "black spade" for black uncommons fwiw

To note is that the Spade emoji doesn't display the same on different devices, explorers. That's one of the challenges here is having consistent emoji display everywhere.

In general I like the idea of Ordinal.com supporting more Satributes/charms, etc. What I really don't like though is that I don't know of a way to do that without it being viewed as Casey anointing additional rarities by indexing them in the Ordinals protocol.
I view the people chiming in on this discussion as the stewards of the emerging asset class of "rare sats" which has the potential to store trillions of dollars of value decades from now.
Even if that scenario doesn't seem likely I think that we owe it to those potential people in the future to act as if it may happen. In my opinion the creator of the "rare sats" asset class should not set the precedent of tampering with the rarities that were defined upon the release of the Ordinals protocol just as the creator of Bitcoin would not tamper with the supply of BTC after Bitcoin was released.
In summary I don't think it would be wise to have Casey in any way bring more rarities "into the fold" because it would break down what was previously a clear line of Casey's rarity and the community's rarity which would in my opinion would result in weird, hard to measure affects of the psychology of rare sats being a strong store of value.
The only reasonable argument around centralization of the rare sats asset class is Casey so this is one of those cases where I just want him to do nothing and let the market do it's thing to prevent a Vitalik type narrative from emerging.

@leonidasord I'm definitely sympathetic to this argument. One thing that might help: These would be charms, not rarities. And not using the uncommon/rare/epic terminology might help make the distinction clearer.
I definitely think that I / the main implementation shouldn't support everything under the sun. Especially things, like palindromes, and all the exotic sat ranges, which have enormous supply.
But I think there has to be some path for adding new charms, since not adding anything ever seems like an unfortunate restriction.
I'm also fine just waiting on this for a bit, and seeing how things develop. My personal hunch is that the black sats will wind up being valued, because the supply is very scarce, and they feel like a mostly natural extension of the original rarity tier. So we could just wait for a few months or a year, and see if they've picked up enough steam to merit charms.

Hello Casey! Firstly, I want to express my gratitude for initiating this discussion. I am extremely excited about the potential integration of Black Sats into the Ordinals protocol, which would mark a significant full-circle moment. I would like to take this opportunity to personally address your questions and extend my thanks for starting this long-awaited conversation!
Question 1: Would this be considered dilutive of the "original" rarity tiers?
On a personal note, I have consistently held the belief that Black Sats represent the culmination of the Rare Sat Thesis, always classifying them under the Rare Sats category. I base this classification primarily on their similar supply characteristics when compared to Uncommon Sats. Since its inception, I have maintained that Black Sats are not exotic. Every beginning must have an end, just as each block on Bitcoin marks both a commencement and a conclusion.
I firmly believe that the inclusion of Black Sats into the Ordinals protocol would not be dilutive, as they possess their own distinct markets. Over the past few months, Uncommon Sats have consistently demonstrated their rarity, with the floor price on all major rare sat marketplaces reflecting this. I argue that incorporating Black Sats will simply establish a new market rarity without impacting the existing tiers. This perspective has found support in the Magic Eden marketplace, where Black Sats have seen some of the highest volumes.
In fact, I am personally convinced that this integration will enhance the value of Uncommon Sats, elevating their worth. Black Sats, by following in the provenance of Uncommon Sats, will create a focal point for both Uncommon and Black Sats, contributing to their collective value.
Question 2: I want to come up with new names for each tier of black sat. I think it's confusing if there are two types of uncommons. I was thinking something like "curious, odd, anomalous, aberrant, bizarre" or "ink, pitch, jet, onyx, obsidian".
This is a topic that both White (Co-Founder of Classified) and I debated relentlessly when conceptualizing the idea of Black Sats. We initially considered naming tiers but ultimately discarded the idea due to concerns about provenance issues and potential confusion. In the end, we opted to retain the current naming convention for sats to pay homage to the original Sat Rarity thesis. We wanted to avoid introducing too many changes that could deviate significantly from the established tier ranking.
The market comprehends the current outline of rarity tiering, and I believe that straying from it could lead to considerable confusion (this is a personal belief). I am of the opinion that, given the similarity in Sat Rarity characteristics to Uncommon Sats, where Uncommon Sats are the first and Black Sats the last, it only makes sense to continue with the conventional naming system that was initially introduced.
Question 3: What charms should we use? I was looking through emoji, and nothing immediately stood out for me.
There is only one correct answer, and it has to be the ⬛ emoji. This is something I vehemently will stand by and hope everyone else feels the same way :)
Conclusion:
Thank you so much for initiating this discussion, and I look forward to your response! Building the Black Sat rarity over the last few months has been an utterly exhausting process as I have been simulatenously co-managing medical school. It means everything to finally see the Big Dogs paying some attention to it and I can't wait to find out what we all choose to proceed foward with.

Yours Truly, 𝙱 𝙻 𝙰 𝙲 𝙺

@leonidasord I'm definitely sympathetic to this argument. One thing that might help: These would be charms, not rarities. And not using the uncommon/rare/epic terminology might help make the distinction clearer.
I definitely think that I / the main implementation shouldn't support everything under the sun. Especially things, like palindromes, and all the exotic sat ranges, which have enormous supply.
But I think there has to be some path for adding new charms, since not adding anything ever seems like an unfortunate restriction.
I'm also fine just waiting on this for a bit, and seeing how things develop. My personal hunch is that the black sats will wind up being valued, because the supply is very scarce, and they feel like a mostly natural extension of the original rarity tier. So we could just wait for a few months or a year, and see if they've picked up enough steam to merit charms.

Black sats have clearly been determined as very valuable and the market has spoken on that. My point really has nothing to do with Black sats and more that rarities should not be messed with at the protocol level in any way once they were set in January. I think it would be cool to put Black Sats on Ordinals.com, but I don't want more sat rarities being indexed in the actual protocol itself for the store of value narrative if that makes sense. I just don't see a way to achieve that with the current setup.
The Open Ordinals Institute should not be in a position where people are coming to them asking for additional rarities to be added to the protocol. It's a recipe for trouble, especially as this asset class grows. That is an unnecessary point of centralization and it will have impacts on the market, and no one would rationally argue otherwise. It is not the role of the Open Ordinals Institute to issue/anoint tokens.
Also FWIW once a market picks a name it usually sticks and Black Uncommons, Black Rares, etc. are good names IMO that won't change easily.

To be clear, The Open Ordinals institute doesn't have a say in this. Raph's work is funded by the OOI, but mine is not. The OOI is not a decision-making body, and does not guide what Raph and I work on.

@leonidasord ord.io has the verification for accounts that own inscriptions. It could, in theory, establish a voting mechanism for such additions. Yes, I agree that @casey having the final say in such matters isn't the desirable way to move forward, nor is permanent stagnation (in terms of certain features, rarity rankings, charms, etc...).
I would love to see ord.io, or even ordinals.com establish a voting mechanism with wallets holding at least one inscription (or running an ord indexer, or whatever criteria you see fit) being the eligible actors. So why don't we do that, and avoid public, unorganized debates?

Democracy is not a particularly good way to make decisions. I don't think anyone can look at existing democratic processes and think, "Wow, that's a great decision-making mechanism that we should apply more widely."

voting system that requires running an indexer, then? I doubt the uninformed average Joe runs an indexer.

I like the spirit of the idea but agree with Casey it would be a nightmare. The closest version of the idea that I could possibly see making sense would be to build some sort of abstract community rarity mechanism into the protocol and and reference explorer that wouldn't ever specify a specific rarity, rather it would allow anyone to "bring your own rarity"by letting you add the rules that you want (a math equation or a set of sats/ranges) that would allow the node operator to choose to index whatever rarities that they want.

My point really has nothing to do with Black sats and more that rarities should not be messed with at the protocol level in any way once they were set in January.

@leonidasord If these are added as charms, how would that be different from other charms that were recently added? Not disagreeing with you, just trying to understand the distinction.

My point really has nothing to do with Black sats and more that rarities should not be messed with at the protocol level in any way once they were set in January.

@leonidasord If these are added as charms, how would that be different from other charms that were recently added? Not disagreeing with you, just trying to understand the distinction.

I equally dislike all charms related to community sat rarity. They don't belong at the protocol level in my opinion. I like the charms related to the inscription part alone a lot though. It comes down to me not liking that the rare/exotic sat market now has an element to it of trying to convince Casey to anoint rarities by adding them to Ordinals at a protocol level and speculating on if it will happen or not. I've said many times that I think of these meta-protocols very similarly to blockchains and just as it would not be appropriate for people in the Ethereum ecosystem who hold a certain ERC-20 token to be campaigning Vitalik to add said token into Ethereum at the protocol level I don't wouldn't want the same dynamic here. I don't like the centralized aspect of it. One person having the power to add and remove tokens from the protocol is not a healthy dynamic to having in the market. All of these community/exotic rarities have a very healthy decentralized market right now and I don't want the creator of the protocol weighing in on which of those should be valued or not let alone adding them to the protocol. I realize I'm being the lame person in this convo, but I really have to express that I feel this dynamic that is emerging of trying to have the inside scoop on when the sat endpoint gets launched in order to be the first collection on it before a tweet goes out to the public, or trying to effectively get a token added to the protocol that you hold is not healthy. It is only human nature to do this. There is nothing wrong with people advocating for things that are in their financial interest. It is human nature to do so but it is up to the protocol creators to not let this dynamic emerge. I don't think it's healthy for the market to have this element to it.

@leonidasord Thanks for explaining. I don't think it's lame at all. I more or less agree. I was surprised to see block 9 charm get added. All other charms are either Rodarmor sat rarity or related to a specific technical detail. So, the block 9 one stood out there as an odd one. Maybe it's a good one to remove.

I've been hyping block nine sats before it was cool: https://twitter.com/rodarmor/status/1569883279326875648

@casey Fair enough!

Can confirm that Casey predicted "historical/old" sat collecting (and everything that has transpired with rare sats) to a T! It's just a matter of what belongs in the core protocol or not. To me it's yucky for all of the reasons I shared above to be adding new tokens/rarities to the core protocol once a $100M+ market has already formed around the assets. It is not the protocol or it's creators role at this stage of things to be tampering with this stuff. It's really time to start treating changes to the protocol similar to how they would be treated on a blockchain storing billions of dollars of value. In my opinion the protocol really doesn't need to change a whole lot more after the Jubilee other than building out a robust set of recursive endpoints. Stability specifically coming from the founder is going to become increasingly important as the protocol grows. I get actual anxiety reading the GitHub because I don't see a reverence for stability and the billions of dollars of value being stored. This is just my honest thoughts. If Block 9s are indexed IMO so should Blacks (using Uncommon/Rare language) and probably a few others but I don't like any of it. I will leave it to yall as I have made my points about needing to be a lot more conservative and not messing with individual token markets at the protocol level which should be non controversial.

As we carefully consider the trajectory of our protocol, the prospect of seamlessly integrating with and nurturing the ordinals community through the Jubilee initiative is a compelling avenue. Our protocol's adaptability to mold and cultivate a promising future for this community is a critical aspect of its value proposition. However, as we navigate the landscape of market expansion and sustained growth, it is crucial to pragmatically evaluate the untapped potential within the billion-dollar Sat Rarities market. These conversations are serious and deserve a serious conversation that should happen over a live discourse as opposed to text. The implications go beyond GitHub.
Sat Rarities, being an undeniable historical artifact, occupies a distinctive position in the market. The unalterable origins, especially as the "OG" Sat Rarities (those first released upon the protocol release), make it an irreplaceable element of our narrative. Recognizing and embracing this historical significance is not just a strategic move; it is a fundamental consideration in its pursuit of market dominance and innovation on Bitcoin. Any attempt to overwrite this rich history with an arbitrary narrative risks devaluing the intrinsic worth that Sat Rarities carry. Black Sats does not infringe upon that history, and correlates with it. There is no difference between incorporating it on the protocol level or not, because irrespective, people are buying the asset. Collectors are collecting. The protocol should be open to support distinct movements that educates, onboards, and entertains people while introducing them to Ordinals. Black Sats provides that alternative for Bitcoiners as we speak. No one can take that away from the community.
In aligning our strategy with the acknowledgment of the profound implications inherent in the Bitcoin Blockchain, we position ourselves to pragmatically capitalize on the truth that markets and blockchains operate transparently. Instead of concealing this reality, our approach should be proactive, leveraging the authenticity and transparency that blockchain technology inherently provides with the market activity of Black Sats.
Amidst this backdrop, the emergence of Black Sats and their associated rarity represents a formidable force that cannot be dismissed lightly. The unique qualities and scarcity of Black Sats hold significance within the rarest segments of the market, the uncommon category. Neglecting or sidelining this emerging trend would equate to overlooking a valuable opportunity to tap into a distinct segment of the market and expand the ordinals community.
This strategic shift towards recognizing and integrating the historical value of Sat Rarities, especially Black Sats, transcends being a mere business decision; it embodies a commitment to the Ordinals community. Without their active participation and engagement, the realization of the envisioned billion dollar market is hard to imagine. By acknowledging the depth of history, the transparency of the blockchain, and the weight of emerging trends, we position ourselves not just as innovators but as responsible stewards of a community-driven narrative that goes beyond conservative market dynamics.

I'm not sold on adding black sats, but I think that adding charms for sat categories that have very even distribution is completely different from endorsing a particular token. If there are bag holders of a sat category with very even distribution, the vast majority of the supply will still be unsequestered.

I'm not sold on adding black sats, but I think that adding charms for sat categories that have very even distribution is completely different from endorsing a particular token. If there are bag holders of a sat category with very even distribution, the vast majority of the supply will still be unsequestered.

Black sats are as legit in the market as any other exotic sat right now and have very good distribution. This has nothing to do with Black sats and everything to do with effectively the Vitalik figure of Ordinals crossing a line into talking about what tokens are valuable and more so which should be codified into the protocol. Vitalik saying that xyz token has good distribution and therefor we can code it into Ethereum would be pretty wild. There is a beauty in keeping the core protocol agnostic and allowing the community to build on top without needing changes to the protocol itself.
Black Uncommons have an MCAP of ~$65M right now and Uncommons have an MCAP of ~$167M. That is a real market with real market participants spending millions of hard earned dollars and it is simply not appropriate for the founder of the protocol to be weighing in on that ratio or choosing to retain the power of anointing or not anointing any tokens for any reason. A very slight change in that ratio is millions of dollars in value being creating/destroyed due to the creator of the protocol injecting themself into the market. That is simply not appropriate and an unhealthy dynamic in the market. The creator of the protocol's role is to focus on stewarding the ecosystem, not weighing in on the price dynamics like the rest of us have the luxury of being able to do. It's a large responsibility and a difficult position to be in. Again just my honest thoughts. I want to see this ecosystem thrive including its founder and that means having a conservative, principled approach to protocol development (in my opinion).

I actually think it is the opposite to be honest Leonidas. Casey has admitted to being hesitant to add Black Sats since the beginning and I think the community is dictating this one, more than a singular founder. I think it is more of recognizing what the Ordinals community represents as being worthy of being added to the protocol rather than one sole founder, and in this case, we are simply talking about charms, which allows inscriptions to be tagged directly on chain using the original protocol.
Furthermore, I do not necessarily enjoy comparing Casey to Vitalik because I believe that creators should be allowed to create. This is not Ethereum, and does not compare to the expectations that Ethereum has. We actively expanding with the value of on-chain rarities still being discovered. I do not really see the comparison being made here. Bitcoin Ordinals and Rare Sats are in their own respective category and should be handled as such without fear of repeating the past. History repeats itself only when these careful conversations do not occur. The culture on Bitcoin is different and this is not comparable to adding random shitcoins into the protocol or the "creator injecting himself into the market".
Holding the Ordinals Protocol and its founders hostage for even simple additions such as charms, which are inconsequential in terms of "on-chain value" does not really make sense. I understand the need to be conservative, but I am not afraid to push the fold for something I think can benefit the entire Ordinals community, not only in terms of financial value, but community value as well. When deciding implementations for the future, we should not alter the past, but that also does not mean that we do not embrace the future. A simple charm to recognize what sat rarity you are viewing does not really take away or diminish the value of anything. In fact, it ADDS value.
I believe that a Black Sat charm, Block 9 Charm, Block 78 charm, and Palindrome charm, are things that should be added because it is what the Ordinals and Bitcoin community believes in. Adding these charms to the protocol and officially recognizing them does not superimpose anything other than what is reality. Collectors are collecting and want to know what they are collecting. The reality is that these Sat Rarities will most likely outgrow the protocol to begin with. I strongly believe that recognizing assets that are being denominated and sold for Bitcoin, should be included into the Ordinals protocol. It makes logical sense. These are not random shitcoins that are being pumped out left and right. As you stated Leonidas, we are talking about a good chunk of Bitcoin here in terms of market share... ignoring market participants for a market evaluation of Black Sats that has roughly half the value of Uncommon Sats can create devestating and unintended consequences, especially if changes are made to include other Sat Rarity markets....
There is inherent scarcity and we should welcome all market participants with open arms and inclusion, especially for something simple like Charms. We are talking about Bitcoin Sat Rarities here, there is no comparison to other Blockchains. Especially not a centralized one. If there was an addition made for one Sat Rarity due to high demand and market evaluation, it should be made for all because the Bitcoin community supports that creation of value and without it, we are nothing.
I will provide an analogy with the Mona Lisa to demonstrate my point:
The reason the Mona Lisa is worth roughly 20,000 BTC is not because Leonardo Da Vinci stated its worth. It occurred because in August 1911 it was stolen by a former employee of the Louvre who, convinced that the painting belonged to Italy and should not remain in France, decided to steal it.
Newspapers worldwide picked up the story of the art heist and the ensuing search and ran with it for years, making the Mona Lisa the most famous painting of its day - and probably of all time.
Which raises another question:
Why might it be so valuable to someone to own such a famous painting?
Simple. Because owning the Mona Lisa would add your name to the story of the Mona Lisa.
It’s a story that started before we were born and will probably continue after we are gone.
To a select few, $850,000,000 would be a small price to pay to be remembered forever.
Black Sats are no different. Owning a Black Sat adds to the story of Black Sats and Rare Sats on Bitcoin.
It's a story that started before I joined Ordinals and will continue after I die.
Here’s the thing...
When it comes to creating value on Bitcoin, intangibles matter. The story and commmunity building that story on Bitcoin matters. Black Sats and all other Sat Rarities on Bitcoin matter. Scarcity on Bitcoin matters. Representation and demonstration of market value on Bitcoin matters.
Those are my 2 Sats. Thoroughly enjoying the conversation and excited to see what unfolds!

The Open Ordinals Institute should not be in a position where people are coming to them asking for additional rarities to be added to the protocol. It's a recipe for trouble, especially as this asset class grows. That is an unnecessary point of centralization and it will have impacts on the market, and no one would rationally argue otherwise.

I would argue that this is adding a sat rarity recognizance to the reference client which implements the protocol. However it seems that no matter how hard I try to emphasize this and encourage the market to distinguish between the protocol and the client implementation, the market insists on conflating the two.
This is just my opinion and I refer to my repeated call for better protocol definitions & documentation, or at least better communication on this topic. We see this same issue cause dispute by the market believing that the ordinals.com front page explorer is also the protocol itself and not a representation of a "lens" to view the protocol through, e.g. the JSON display debate.
I expect failure to distinguish between protocol <> implementation <> explorer will only continue to create perceived arguments & disputes over governance and consensus when most of these could be avoided.
Apologies for possibly derailing the conversation, if we want to keep discussing this it might be best to spin up another Discussion. I just thought it was a relevant place to chime in on the topic of what I believe is the protocol and what isn't.

I think I'm going to close this. We can revisit it later. My reasons are:

It's confusing to add charms/rarities which have the same name (uncommon/rare/epic/legendary) as the existing rarity tier.
I can't think of good emoji / charms.
It does feel a little dilutive to me of the existing rarity tiers.