Can Zipkin support AWS Opensearch?

Feature
Can Zipkin support AWS Opensearch?
Rationale
Elasticsearch has changed license and it is not open source project anymore, AWS Opensearch is open source project and it is almost the same as elasticsearch7.10, but it failed to use opensearch directly with Zipkin because Zipkin check the version and only accept ES 5-7.X, opensearch latest version is 1.2.

The Elasticsearch clients up to 7.12.x release could connect to Opensearch clusters, you may need to set the persistent.compatibility.override_main_response_version setting [1]:
PUT _cluster/settings
{
  "persistent": {
    "compatibility": {
      "override_main_response_version": true
    }
  }
}

In this regards, Opensearch is inplace replacement for Elasticsearch. But Elasticsearch 7.13+ would not work and dedicated Opensearch client has to be used.
[1] https://opensearch.org/blog/technical-posts/2021/10/moving-from-opensource-elasticsearch-to-opensearch/

This is great, I just tried it and it works fine.
Thanks!

Hi @kendarkfire,
I added the persistent.compatibility.override_main_response_version parameter cluster settings. Still I am unable to load zipkin index in opensearch.
Will you please help me to integrate zipkin with Opensearch.
AWS Opensearch - v1.2
zipkin - v2.23, v2.21

The override main response setting compatibility.override_main_response_version is deprecated from OpenSearch version 1.x and removed from OpenSearch 2.0.0. This setting is no longer supported for compatibility with legacy clients.

@emanzat the change is indeed deprecated, was removed and reverted later on [1], it should be there for 2.x but very likely not in 3.x.
[1] https://github.com/opensearch-project/OpenSearch/pull/3530

So what is the fix, if any, for opensearch 2.x?

@AndrewFarley I think the best option to move on is to have dedicated support for OpenSearch, since divergence between two (OS and ES) would only grow with time, @codefromthecrypt what do you think?

@reta Native OS support would be great also.  I don't know the complexity of that, which is why I felt like a skip-version-check might be a quicker and temporary fix until someone got around to adding OS support natively.

@reta Native OS support would be great also.

I think I could pick it up, if @codefromthecrypt LGTMs this new storage integration

I think maybe folks forgot we have an openzipkin/zipkin-aws image which is configured for their elasticsearch https://github.com/openzipkin/zipkin-aws/tree/master/module#elasticsearch-storage
I'll move this issue over there!


Security group information is missing when creating exoscale machine

Version - Master 12/02
Steps:

Go to hosting page
Click on Add host
Select exoscale
Put in API key and Secret Key
Select custom for Security Group and select Rancher-master
Click next

Results: Security Group information is now showing up

Expected:  Security Group info to show up

I am able to reproduce this only if I select the first security group as a custom group. If I select another one, it works just fine. I suppose that the onchange handler is not firing up. A possible fix would be to take the first custom security group when none is selected, but maybe there is a cleaner way to do that.
I see that the Amazon EC2 template does exactly the same thing. And it has exactly the same problem. I'll welcome any tip on the proper way to fix that.

Version - master 3/24
Verified fixed


get the mch namespace when create the pullsecret

Signed-off-by: hchenxa<EMAIL_ADDRESS>The PR was update the namespace to handle the e2e test in zstream of release-2.2

/assign @clyang82

/approved


InvokeBinding doesn't provide an alternative way to work directly with raw data

Expected Behavior
To be able to get binary data from Azure Blob Storage Binding, working directly with raw data for invoke binding in DaprClient is really needed.
Actual Behavior
There is no way to get raw data by calling InvokeBindingAsync and in case of receiving binary data the JSON Deserialization will raise the following exception:
System.Text.Json.JsonException: '%' is an invalid start of a value. Path: $ | LineNumber: 0 | BytePositionInLine: 0.
Steps to Reproduce the Problem
1- Setup Azure BlobStorage Binding Component
https://docs.dapr.io/operations/components/setup-bindings/supported-bindings/blobstorage/
2- Call InvokeBindingAsync to get a binary blob (E.g. PDF file) from Azure Blob Storage.
   var metadataDictionary = new Dictionary<string, string>()
    {
        { "blobName", "dummy.pdf" },
    };

    var binaryArray = await _daprClient.InvokeBindingAsync<object, byte[]>("blobComponentName", "get", null, metadataDictionary);

Release Note
As suggested in this issue #442 having a Raw method like InvokeMethodRawAsync would solve this issue. I gave it a try, and it could work fine.

I know InvokeMethodRawAsync doesn't exist anymore (#544), but if you think having a raw method (InvokeBindingRawAsync) would be an appropriate solution, then I will create a pull request for it.

I know InvokeMethodRawAsync doesn't exist anymore (#544), but if you think having a raw method (InvokeBindingRawAsync) would be an appropriate solution, then I will create a pull request for it.

Agreed, this would be something nice to add. A PR for this would be great. Can we try and agree on the method signature using this issue here? That will prevent you from doing unnecessary work.

Agreed, this would be something nice to add. A PR for this would be great. Can we try and agree on the method signature using this issue here? That will prevent you from doing unnecessary work.

Awesome! I agree too. That would be great.
My first thought was something like this :
 public override async Task<byte[]> InvokeBindingRawAsync(
        string name,
        string operation,
        byte[] data,
        IReadOnlyDictionary<string, string> metadata = default,
        CancellationToken cancellationToken = default)

But then I was thinking of having a Response Model (like InvokeBindingResponse) instead of returning only byte[], so that we can return metadata collection or the other useful information together with the data result. For example, by getting a blog from Blob Storage sometimes we need to have some metadata (like Last-Modified or Content-Type).
public sealed class InvokeBindingResponse
{
    public byte[] Data { get; set; }
    public IReadOnlyDictionary<string, string> Metadata { get; set; }
}

public sealed class InvokeBindingRequest
{
    public string Operation { get; set; }
    public byte[] Data { get; set; }
    public IReadOnlyDictionary<string, string> Metadata { get; set; }
}

public override async Task InvokeBindingRawAsync(
string name,
InvokeBindingRequest request,
CancellationToken cancellationToken = default)
What do you think?

Awesome! I agree too. That would be great.
My first thought was something like this :
 public override async Task<byte[]> InvokeBindingRawAsync(
        string name,
        string operation,
        byte[] data,
        IReadOnlyDictionary<string, string> metadata = default,
        CancellationToken cancellationToken = default)

But then I was thinking of having a Response Model (like InvokeBindingResponse) instead of returning only byte[], so that we can return metadata collection or the other useful information together with the data result. For example, by getting a blog from Blob Storage sometimes we need to have some metadata (like Last-Modified or Content-Type).
public sealed class InvokeBindingResponse
{
    public byte[] Data { get; set; }
    public IReadOnlyDictionary<string, string> Metadata { get; set; }
}

public sealed class InvokeBindingRequest
{
    public string Operation { get; set; }
    public byte[] Data { get; set; }
    public IReadOnlyDictionary<string, string> Metadata { get; set; }
}

public override async Task InvokeBindingRawAsync(
string name,
InvokeBindingRequest request,
CancellationToken cancellationToken = default)
What do you think?

@rynowak please add it to our project. Thanks! -- @mtaghavi2005  is on our team.

@rynowak please add it to our project. Thanks! -- @mtaghavi2005  is on our team.

@fabistb - done
@mtaghavi2005 - thanks, that's a good starting point. I feel pretty positively about the second example but I'd suggest a few tweaks.
Is there a reason you wanted name and `operation split up?
public sealed class InvokeBindingResponse
{
    public ReadOnlyMemory<byte> Data { get; set; }
    public IReadOnlyDictionary<string, string> Metadata { get; set; }
}

public sealed class InvokeBindingRequest
{
    public string BindingName { get; set;
    public string Operation { get; set; }
    public ReadOnlyMemory<byte> Data { get; set; }
    public IReadOnlyDictionary<string, string> Metadata { get; set; }
}

 public abstract Task<InvokeBindingResponse> InvokeBindingRawAsync(
        InvokeBindingRequest request,
        CancellationToken cancellationToken = default);

Notable changes:

I put the name and operation together, because it doesn't seem like they should be spread out like that
Used ReadOnlyMemory<byte> instead of byte[] so that fewer copies need to happen

@fabistb - done
@mtaghavi2005 - thanks, that's a good starting point. I feel pretty positively about the second example but I'd suggest a few tweaks.
Is there a reason you wanted name and `operation split up?
public sealed class InvokeBindingResponse
{
    public ReadOnlyMemory<byte> Data { get; set; }
    public IReadOnlyDictionary<string, string> Metadata { get; set; }
}

public sealed class InvokeBindingRequest
{
    public string BindingName { get; set;
    public string Operation { get; set; }
    public ReadOnlyMemory<byte> Data { get; set; }
    public IReadOnlyDictionary<string, string> Metadata { get; set; }
}

 public abstract Task<InvokeBindingResponse> InvokeBindingRawAsync(
        InvokeBindingRequest request,
        CancellationToken cancellationToken = default);

Notable changes:

I put the name and operation together, because it doesn't seem like they should be spread out like that
Used ReadOnlyMemory<byte> instead of byte[] so that fewer copies need to happen

@msfussell FYI

@msfussell FYI

hey @mtaghavi2005 - under normal circumstances, I'd prefer to let you send the PR since you offered it. However, for scheduling reasons it would be best I can just take care of this quickly so that we can turn it out. Sorry!

hey @mtaghavi2005 - under normal circumstances, I'd prefer to let you send the PR since you offered it. However, for scheduling reasons it would be best I can just take care of this quickly so that we can turn it out. Sorry!

@fabistb - done
@mtaghavi2005 - thanks, that's a good starting point. I feel pretty positively about the second example but I'd suggest a few tweaks.
Is there a reason you wanted name and `operation split up?
public sealed class InvokeBindingResponse
{
    public ReadOnlyMemory<byte> Data { get; set; }
    public IReadOnlyDictionary<string, string> Metadata { get; set; }
}

public sealed class InvokeBindingRequest
{
    public string BindingName { get; set;
    public string Operation { get; set; }
    public ReadOnlyMemory<byte> Data { get; set; }
    public IReadOnlyDictionary<string, string> Metadata { get; set; }
}

 public abstract Task<InvokeBindingResponse> InvokeBindingRawAsync(
        InvokeBindingRequest request,
        CancellationToken cancellationToken = default);

Notable changes:

I put the name and operation together, because it doesn't seem like they should be spread out like that
Used ReadOnlyMemory<byte> instead of byte[] so that fewer copies need to happen

@rynowak  Thanks, sounds great! About BindingName I thought it is not going to be sent to the other Party, so it may not belong to the Request Object. It would be somehow much more similar to ExecuteStateTransactionAsync than InvokeMethodWithResponseAsync from the signature perspective. Because for both we need to firstly select the component block, and then we can pass our request to it.  It was just my thought, but generally, I don't have any problem with this change at all :)

@fabistb - done
@mtaghavi2005 - thanks, that's a good starting point. I feel pretty positively about the second example but I'd suggest a few tweaks.
Is there a reason you wanted name and `operation split up?
public sealed class InvokeBindingResponse
{
    public ReadOnlyMemory<byte> Data { get; set; }
    public IReadOnlyDictionary<string, string> Metadata { get; set; }
}

public sealed class InvokeBindingRequest
{
    public string BindingName { get; set;
    public string Operation { get; set; }
    public ReadOnlyMemory<byte> Data { get; set; }
    public IReadOnlyDictionary<string, string> Metadata { get; set; }
}

 public abstract Task<InvokeBindingResponse> InvokeBindingRawAsync(
        InvokeBindingRequest request,
        CancellationToken cancellationToken = default);

Notable changes:

I put the name and operation together, because it doesn't seem like they should be spread out like that
Used ReadOnlyMemory<byte> instead of byte[] so that fewer copies need to happen

@rynowak  Thanks, sounds great! About BindingName I thought it is not going to be sent to the other Party, so it may not belong to the Request Object. It would be somehow much more similar to ExecuteStateTransactionAsync than InvokeMethodWithResponseAsync from the signature perspective. Because for both we need to firstly select the component block, and then we can pass our request to it.  It was just my thought, but generally, I don't have any problem with this change at all :)

hey @mtaghavi2005 - under normal circumstances, I'd prefer to let you send the PR since you offered it. However, for scheduling reasons it would be best I can just take care of this quickly so that we can turn it out. Sorry!

@rynowak No problem. That's totally fine. I appreciate your great support.

hey @mtaghavi2005 - under normal circumstances, I'd prefer to let you send the PR since you offered it. However, for scheduling reasons it would be best I can just take care of this quickly so that we can turn it out. Sorry!

@rynowak No problem. That's totally fine. I appreciate your great support.

Hi,
I was wondering if this change is published into nuget.
I'm currently using Dapr.AspNetCore 1.4.0 and I'm still getting System.Text.Json.JsonReaderException : '0xFF' is an invalid start of a value on receiving raw files.
I'm using the Dapr LocalStorage binding and I can successfully save the file with the following command:
                await _daprClient.InvokeBindingAsync(_storageOptions.Type, "create", imageBytes, new Dictionary<string, string> {
                    {"fileName", "test.jpg"}
                });

but when I want to read it I get exception that it cannot deserialize it.
                    imageOriginalBytes = await _daprClient.InvokeBindingAsync<string, byte[]>(_storageOptions.Type, "get", null, new Dictionary<string, string> {
                        { "fileName", $"test.jpg" ?? "" }
                    });


HIP-01: Syntactic sugar for function signatures

Simple Summary
Computing function signatures is a bit of a hassle and having them displayed as hardcoded values increases the technical debt.
Some syntactic sugar could be added to the language itself (e.g. FUNC_SIG('set(uint256)')) that will allow developers to compute function signatures directly within the source code.
Motivation
Function signatures are currently hardcoded in Huff contracts, which means that set(uint256) will be displayed as 0x60fe47b1. This current solution is not very practical, since developers may have to use an external tool to compute the full keccak-256 hash, trim the extra bytes manually to get the function signature itself, copy / paste it into the source code and eventually add a comment to remember where this value is coming from.
Here is a snippet of the current situation:
#define macro MAIN() = takes(0) returns (0) {
  0x00 calldataload
  0xe0 shr
  dup1
  0x60fe47b1 // signature of `set(uint256)`
  eq
  set jumpi
  dup1
  0x6d4ce63c // signature of `get()`
  eq
  get jumpi
  set:
    SET()
  get:
    GET()
}

Specification
Via the new FUNC_SIG keyword, developers would be able to compute function signatures directly in their Huff contracts.
Here is a proposed implementation:
#define macro MAIN() = takes(0) returns (0) {
  0x00 calldataload
  0xe0 shr
  dup1
  FUNC_SIG('set(uint256)')
  eq
  set jumpi
  dup1
  FUNC_SIG('get()')
  eq
  get jumpi
  set:
    SET()
  get:
    GET()
}

The compiler will interpret the helper function FUNC_SIG and replace it with the correct function signature. For example:

FUNC_SIG('set(uint256)') will become 0x60fe47b1
FUNC_SIG('get()') will become 0x6d4ce63c

Notes
A similar helper function could be added to get the hash of events: EVENT_HASH('...').

Implemented in #148 :smile:


Call is Treated as Callonce When Placed Above Callonce in .feature (BUG)

Re-opening as previous ticket was improperly closed without examining the working example provided.
See attached "working example"
callonce.zip

unable to understand actual and expected results. putting on hold and requesting community help.

Updated original description as working example was poorly put together.

my comment on your other issue applies to this one as well: https://github.com/intuit/karate/issues/183#issuecomment-331040204

closing due to inactivity


Error while installing: libpipewire-module-access.7.gz

If you Completed all troubleshoot options, check below

[*]  Did you Follow all installation instructions carefully from here?
[*]  Did you check All troubleshoot options from here?

Desktop (please complete the following information):

Distro: Neon / Ubuntu 22.04
Desktop: KDE Plasma 6.0.4
Version: 22.04
PipeWire Related packages Version: [pipewire, wireplumber, libcamera, etc.]
pipewire --version: libpipewire 1.0.7
Kernel version: 6.5.0-35-generic (64-bit)

Describe the bug
Pipewire won't upgrade with this error:
Package failed to install:
Error while installing package: trying to overwrite '/usr/share/man/man7/libpipewire-module-access.7.gz', which is also in package pipewire-bin 1.0.7-1~ubuntu22.04
To Reproduce
Steps to reproduce the behavior:
Just try upgrading the system either with Discover (GUI) or from the console 'pkcon -v update'.
Additonal Information (If applicable):
Also Reported here (not by me): https://bugs.kde.org/show_bug.cgi?id=487663

see : https://askubuntu.com/questions/176121/dpkg-error-trying-to-overwrite-file-which-is-also-in
and come back if not fixed

Thanks, but I don't get it.
I have 144 packages to upgrade and because of that error I described, it won't install.
Should I uninstall something first? What?
OR
Should I use the "--force-overwrite" trick? That would be dangerous, wouldn't it?
KDE team won't help, because they "don't support third party PPAs".
So the problem is with your PPA?
I installed pipewire from your PPA long time ago and up until now, everything's been fine.
Please tell me what to do to get the upgrade working again.
If it helps, here is "apt-cache policy pipewire-bin":
pipewire-bin:
Installed: 1.0.7-1~ubuntu22.04
Candidate: 1.0.7-1~ubuntu22.04
Version table:
*** 1.0.7-1~ubuntu22.04 100
100 /var/lib/dpkg/status
0.3.48-1ubuntu3 500
500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
0.3.48-1ubuntu1 500
500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
And: "apt install pipewire-bin":
The following packages have unmet dependencies:
libpipewire-0.3-modules : Depends: libpipewire-0.3-0 (= 1.0.7-1~ubuntu22.04) but 1.0.7-3~ubuntu22.04 is to be installed
pipewire : Depends: pipewire-bin (= 1.0.7-1~ubuntu22.04) but 1.0.7-3~ubuntu22.04 is to be installed
pipewire-alsa : Depends: libpipewire-0.3-0 (= 1.0.7-1~ubuntu22.04) but 1.0.7-3~ubuntu22.04 is to be installed
pipewire-bin : Depends: libpipewire-0.3-modules (= 1.0.7-3~ubuntu22.04) but 1.0.7-1~ubuntu22.04 is to be installed
pipewire-jack : Depends: libpipewire-0.3-0 (= 1.0.7-1~ubuntu22.04) but 1.0.7-3~ubuntu22.04 is to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
'apt --fix-broken install' does nothing.

remove /usr/share/man/man7/libpipewire-module-access.7.gz manually
and try to install

Still no luck. Same error even if the file was not there.
Finally I tried repair with: sudo apt --fix-broken install -f -o Dpkg::Options::="--force-overwrite"
And it worked. Pipewire and Easy Effect both work normally. I hope I didn't break anything.
It did this:
$ sudo apt --fix-broken install -f -o Dpkg::Options::="--force-overwrite"

The following additional packages will be installed:
  libpipewire-0.3-modules pipewire pipewire-alsa pipewire-jack pipewire-pulse
Suggested packages:
  libpipewire-module-x11-bell
The following packages will be upgraded:
  libpipewire-0.3-modules pipewire pipewire-alsa pipewire-jack pipewire-pulse
5 upgraded, 0 newly installed, 0 to remove and 138 not upgraded.
9 not fully installed or removed.

Preparing to unpack .../libpipewire-0.3-modules_1.0.7-3~ubuntu22.04_amd64.deb ...
Unpacking libpipewire-0.3-modules:amd64 (1.0.7-3~ubuntu22.04) over (1.0.7-1~ubuntu22.04) ...
Setting up libpipewire-0.3-modules:amd64 (1.0.7-3~ubuntu22.04) ...
Setting up pipewire-bin (1.0.7-3~ubuntu22.04) ...

Preparing to unpack .../pipewire-jack_1.0.7-3~ubuntu22.04_amd64.deb ...
Unpacking pipewire-jack:amd64 (1.0.7-3~ubuntu22.04) over (1.0.7-1~ubuntu22.04) ...
Preparing to unpack .../pipewire-alsa_1.0.7-3~ubuntu22.04_amd64.deb ...
Unpacking pipewire-alsa:amd64 (1.0.7-3~ubuntu22.04) over (1.0.7-1~ubuntu22.04) ...
Preparing to unpack .../pipewire_1.0.7-3~ubuntu22.04_amd64.deb ...
Unpacking pipewire:amd64 (1.0.7-3~ubuntu22.04) over (1.0.7-1~ubuntu22.04) ...
Setting up pipewire:amd64 (1.0.7-3~ubuntu22.04) ...

Preparing to unpack .../pipewire-pulse_1.0.7-3~ubuntu22.04_amd64.deb ...
Unpacking pipewire-pulse (1.0.7-3~ubuntu22.04) over (1.0.7-1~ubuntu22.04) ...
Setting up pipewire-pulse (1.0.7-3~ubuntu22.04) ...
Setting up pipewire-jack:amd64 (1.0.7-3~ubuntu22.04) ...
Setting up pipewire-alsa:amd64 (1.0.7-3~ubuntu22.04) ...

Then I could install the entire remaining update.
Thanks.

see : https://askubuntu.com/questions/176121/dpkg-error-trying-to-overwrite-file-which-is-also-in and come back if not fixed

Apt would still think the file is there, though.

see : https://askubuntu.com/questions/176121/dpkg-error-trying-to-overwrite-file-which-is-also-in and come back if not fixed

Can confirm another user fixed this by using dpkg, with my assistance:
https://discuss.kde.org/t/cant-start-plasma-probably-broken-pakage-i-cant-overcome/16563.
I will assume I will see this error myself when I unpack my PC after moving and update it.

Just had the same issue, and tried to run this last command, the issue for that package was not there, but then another appeared.
Unpacking pipewire-bin (1.0.7-3~ubuntu22.04) over (1.0.2~1707732619~22.04~b8b871b) ...
dpkg: error processing archive /var/cache/apt/archives/pipewire-bin_1.0.7-3~ubuntu22.04_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/pipewire-pulse.1.gz', which is also in package pipewire-pulse 1.0.2~1707732619~22.04~b8b871b
Errors were encountered while processing:
 /var/cache/apt/archives/pipewire-bin_1.0.7-3~ubuntu22.04_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


Linux support?

Am I reading the code correctly that you only support running in Windows?
[<System.Runtime.Versioning.SupportedOSPlatform("Windows")>]   let powershell () = new PowerShellBuilder()
I've love to be able to use this library to build F# apps to manage Proxmox VE resources from each host in the cluster. I'm looking at pulumi but also scouting around for type providers for something more direct (and of course considering rolling my own). So I wanted to confirm that the code here is Windows-only, and also inquire about whether you had considered cross platform support.
Thanks!

Hi, @houstonhaynes !
That CE is for PowerShell Legacy (.NET Framework).
Normally, macOS and Linux (and Windows) use tha following CE for PowerShell Core:

https://github.com/tatsuya-midorikawa/Owl.cli/blob/main/src/Owl.cli/Pwsh.fs

However, since only macOS is supported yet, I will try to Linux support in the near future.
Thanks!


Add scroll-to-bottom event in dropdowns

Used to trigger the "infinite scroll" functionality that's a part of [CHEC-824]

Where'd the deploy preview go>?

Seems the Netlify extension was removed, and is acting a little weirdly with this existing PR. Here's the preview:
https://5f3c33f79d36b9000718ce49--chec-ui.netlify.app/


Modal: Add the ability to render cardless content

Modal: Add the ability to render cardless content

This update adds the ability to render the children content of
Modals without it's standard Card UI-based container. All that's
required is to pass the seamless prop, which is set to false
by default.
Resolves: https://github.com/helpscout/blue/issues/140

Changes Unknown when pulling 1b0178daee665a5f492113dc892d85b409df4591 on Modal/seamless into ** on master**.


CommaOK-able ops should return entangled bool.

Things like reading from a map and receiving from a channel return either one or two values, depending on the LHS. If it's two, the second one is a bool that, if true, the operation succeeded (whatever that means) and the the first return value is its result, and, if false, the operation failed and the first return value is just the zero value for its type.
So zero values are tricky in SGo, since not all types have one. A nice to this behavior, that still would feel Go-ish, is to make "commaOK" to be "backslashOK" instead, so that the variable in the left remains uninitialized until the OK. BackslashOK-able expressions that only return one value would be forbidden when its type is not zeroable.
Requires #4 and would fix #3.

Missing this: "BackslashOK-able expressions that only return one value would be forbidden when its type is not zeroable."


Completion system redesign

I have an idea of a new completion system that is lot more powerful than the current (and even than that of Zsh).
It would be implemented fully in Elvish script.
Concept

The user shouldn't spend time on switching between modes, so the completion should be integrated into INSERT mode: edit:insert:start-completion, edit:insert:jump-right-completion, edit:insert:trigger-completion-filter, edit:insert:exit-completion.
Also, it should add a preview window (similar to the preview of ranger and fzf).

Advantages

Faster typing.
More information for the user about each completion candidate.
More flexible and powerful completion API (more customization possibilities).
Solving #148, #395, #337, #396 in Elvish script.
Implementing custom commands that sorts candidates by usage frequency (similarly how the current directory history mode does).

Elvish script API for readline
It would use $edit:-dot for getting the cursor position, and $edit:current-command for getting the readline content (and inserting the completion).
However, it requires more readline API features:

#548, #549, #550 for displaying completions automatically.
#507 for previewing the completed command (similarly to the current underlined completion preview)

Displaying the completion candidates

Each candidate should have a tag, and a description. It should be formatted similarly how tagged paragraphs are formatted in man pages.
Example completions:

options: &tag="--git" &description="list each file's Git status, if tracked"
commits: &tag="3ba2c02" &description="Added man page".
filenames: &tag="todo.txt" &description="UTF-8 Unicode text"

It should support markup. Two ideas:

escape sequences
special syntax (my preferred solution)
e.g. {bold}--input{-bold}={italic}file.txt{-italic}
One advantage of this solution is that it would enable nonbreaking whitespaces: Execute {nobreak}git push origin{-nobreak} in a shell.

Each candidate should have a preview. Only the preview of the selected item should be displayed.
It should support sections (similarly as Zsh) to separate candidates by type.[local branch]
master dev new-feature

[remote branch]
origin/master origin/dev origin/new-feature

[filename]
file1.txt file2.txt file3.txt

Reading candidates

The edit:completion-preview-delay variable should contain the number of miliseconds before running the preview script.
The edit:completion-preview-function variable should contain a shell function that produce the preview text. The function would have two options: &height &width.
The shell should read candidates with a command similar to edit:-narrow-read. It would take the candidates, and a function that is launched if a candidate is accepted.

What do you think about this idea?

@xiaq What's your opinion on this idea?
Why hasn't it even got a label?
You ideas sound good to me, but sound more like a wish list than a concrete proposal. You seem to have some concrete ideas, but I don't fully understand how this would look in implementation. Maybe a snippet of how you would envision some moderately complex completion (say, git subcommands/options) using your proposal would help.

@notramo Hi, sorry for the delay in response! I've been refactoring the editor for the past week and I tend to delay response to issues, especially bigger ones, when I am in "sprint mode". I do try to make sure that issues are triaged when not in sprint mode, but please feel free to nag me when you are seeing delay in responses.
Hopefully, the refactor work should pave the way for adding more editor features and APIs!
It is a bit hard to navigate your proposal as it contains many things. Here are my answers, which I hope address most of your proposal:

You seem to be proposing that automatic contextual completion should be the default (or maybe only). This is an attractive idea, but I am a skeptical because some completions can be expensive:

Filename completions on network drives, or command completion when PATH contains a directory in a network drive;

Completion of package names in package managers, which likely requires querying some database.

We also have no control over what user-supplied completions can do, they can do arbitrarily expensive stuff.

We can run completions asynchronously in the background, but I don't like the idea that Elvish can take up resources when the user hasn't explicitly asked to. My proposal is that Elvish exposes a user-customizable whitelist of completions that can happen automatically.

You have proposed that the completion system should be implemented entirely in Elvish, and you have proposed many new APIs (which all make a lot of sense - thank you!). I do share the vision that the Elvish editor becomes an "editor framework" some day and all the high level stuff become doable in pure Elvish script. However, we still has a long way to go:

Even with all the APIs you proposed, the API interface is not sufficient to implement the completion mode in Elvish. In particular, the API provides little low-level access to the UI; you cannot control, for example, how the completion list is rendered or how the scrollbar is rendered.

Accurate completions require parsing Elvish code. There is no API for the Elvish parser or AST yet.

The Elvish interpreter is not at all optimized, so the equivalent Elvish implementation of completion mode will be much slower than the Go implementation and takes up much more memory.

By the way, although I completely dig the idea that there should be enough APIs for the completion mode to be implementable in pure Elvish script, we will probably still be shipping a Go-implemented completion mode in the elvish binary. Go is a pretty decent language for implementing editor features, and no matter how optimized Elvish becomes it's unlikely to outperform Go code.

You have proposed an extended API for completion candidates. This is partially also there in the edit:complex-candidate API (see doc, look for "complex candidate"). This is purely a fault of me not documenting the API well. The major thing that is now missing compared to your proposal is a mechanism for adding types to candidates, which is something I plan to do.

@xiaq The API functions I suggested would work on a lower layer of the completion system than you think. For example, the solution for avoiding resource expensive autocompletions should be implemented in Elvish script. The readline character input hook would be called every time the user types a character, but the completion system (the Elvish part of it) could decide if it calls the completion function or not.

Even with all the APIs you proposed, the API interface is not sufficient to implement the completion mode in Elvish. In particular, the API provides little low-level access to the UI; you cannot control, for example, how the completion list is rendered or how the scrollbar is rendered.

I think, terminal drawing shouldn't have an API:

It would be very slow.
Very few people would use it, so it would be an unneeded part of code that only increases complexity and bugs, and hardens maintainability. I think, if someone needs modifying it for personal tastes, the Go code should be edited.
In the HTML front-end you could have a completion list drawn with lines, and other fancy stuff instead of characters. It could be printed even with variable width font for easier readability. This applies to the scrollbar too. Even the prompt, and the typed command could be written with variable width font, since it isn't locked into a cell table.

Instead of controlling how the editor draws to the screen, it should be controlled like: "draw a completion list: ...", "draw autosuggestion: ...", "run this command if the user press a key: ...". (This is what I proposed in the many issues I opened.) This wouldn't conflict with the web front-end.

Accurate completions require parsing Elvish code. There is no API for the Elvish parser or AST yet.

I think it isn't required for starting implementing the new completion system. It should be implemented later. I opened #592.

The Elvish interpreter is not at all optimized, so the equivalent Elvish implementation of completion mode will be much slower than the Go implementation and takes up much more memory.

Yes, but I think the completion don't require too much operation. The main performance hit is that a new array is created every time instead of modifying the current. This can be slow on big arrays, however modifying it would require nearly the same computation regardless how big is the array.

You have proposed an extended API for completion candidates. This is partially also there in the edit:complex-candidate API (see doc, look for "complex candidate").

I have know about it. The lack of documentation wasn't a big problem, it was easy to discover how it works. It lacks the following things.

Specifying a function that is called, if the user exits completion mode after selecting a candidate. This could be used to split / from the end of directory paths, if completion mode is closed, or restarting the completion.
Specifying the entire text displayed instead of &display-suffix, that only inserts text after the completion candidate. This could be used to display only the basename of directories/files in the completion menu.
Inline markup.
Automatically organizing completion candidates into a formatted list. This line is taken from xiaq/edit.elv completion for the go command:  edit:complex-candidate $text &display-suffix=' '(spaces (- 14 (wcswidth $text)))$desc
Sections.
Preview.

Instead of controlling how the editor draws to the screen, it should be controlled like: "draw a completion list: ...", "draw autosuggestion: ...", "run this command if the user press a key: ...". (This is what I proposed in the many issues I opened.) This wouldn't conflict with the web front-end.

That API doesn't exist yet either... :)

I think it isn't required for starting implementing the new completion system. It should be implemented later. I opened #592.

I am not sure how much of the completion mode you would like to see implementable in Elvish. If your answer is "all of it", then a full-fledged parser API is required. In #592 you are proposing an API to enable some new kinds of history-based completions, but consider what the completion mode is capable today:

It needs to know that in echo $<Tab> you are completing a variable, in e<Tab> you are completing a command.

It needs to know that in echo "a b c" 'x y' <Tab> the command being completed is called echo, and the existing arguments are strings a b c and x y.

(I filed #594 for that.)
Can you file another issue for adding more properties to candidates?

@xiaq What do you think about instead of inserting completions with edit:current-command, there would be an array of the items that should be completed by the completer function. It would contain the same strings that are now passed to the completer function as arguments, and if some of these strings are modified, the editor would know where is that item located in the readline buffer, and replace it with the modified content. It wouldn't contain e.g. variable names, so these things would be completed by the editor (same behavior as currently), and the completion function is not called when completing these items.
This solution can be implemented without using a parser API, which would simplify a lot in the Elvish script completion system.

@notramo, I don't understand what you are proposing. Can you give an example?
Also, I tried to reread your original post; I think most of those are now covered by existing issues. Aside from what have been mentioned, I just filed #644 to cover richer metadata in candidates.
But the existing issues may still fall short of your original vision. If there are things that haven't been covered, I recommend that you do two things:

Break your proposal into smaller feature requests, if the existing features haven't covered them. I know this will make it harder to have a coherent picture of what we want for the completion mode; I have made some GitHub issues tags, including module:edit/completion, to help organize related issues.

Give examples of how you think completion can better work. Ideally, come up with terminal mockups for the UI, and pseudo code for the API. I have noticed that we all have slightly different terminologies to describe UI features and it makes discussion of complex features difficult. UI mockups and API examples will make such it much easier to understand ideas.

I hope that's helpful! Now I'm going to start tagging existing issues with the new tags I just made...

@xiaq Currently, the completer command has a signature that specifies the variables that will store its arguments while the function is running. It is possible to specify a rest argument (with @). If only one argument is specified, and it is a rest argument, it will store all arguments passed to that function. This array (created with the rest argument) don't contains $variables, shell syntax characters ({}() etc.), and only contains the arguments of the current command (so the parser filters out the other side of a pipeline |, or next command ; etc.).
In my idea, this filtered array wouldn't be passed to the completion function, instead the completion function would accept no arguments, and this array would be in the edit: namespace. It have to be writable. It would contain only the strings that would be passed to the completion function if the user hits Tab with the current cursor position. The parser would store for each element the readline buffer position where that element starts. If an element is modified in this array, the editor changes the text in the readline buffer according to the position given by the parser.
readline buffer (the cursor is at the end of the line):
~/code/neph >>> exa --git -l; kak $variable src/neph.cr src/ne│

the content of the e.g. edit:argument-list array:
[ 'kak' 'src/neph.cr' 'src/ne' ]

(so the exa command is filtered out entirely, and the $variable also)
change this array:
edit:argument-list[3] = 'src/neph/parser.cr'

then the readline buffer changes (the change is inserted - we changed the last element of the array, so it is inserted at the end):
~/code/neph >>> exa --git -l; kak $variable src/neph.cr src/neph/parser.cr│

@notramo It's not clear to me what advantages your proposed API has; it seems to worse than what we have now. Also, when should edit:argument-list[3] = ... be executed? The completer should propose a list of candidates, not modify the buffer directly.

@xiaq Sorry, I have described it with mistakes.
The completion function wouldn't modify the array.
The Elvish script completion system would modify it when a candidate is accepted. (The edit:argument-list[3] ... command is also called from the completion system, not the completion function.) The way how completion functions work wouldn't change, because the completion system can read out this array, and pass to the completion function as arguments.
Sorry for the wrong description.
I know my proposal is quite complex, so I have created a mind map. I hope it helps understanding the idea.

@notramo, I see what you are proposing now. But I don't see any advantage with this approach:

edit: is essentially a global variable. If you make completers manipulate edit:, they are less reusable and harder to test (it is too early to talk about automated testing in Elvish now, but good practices in software engineering still apply).

Still, I think it is too much flexibility to allow the completer to specify an arbitrary callback when a candidate gets accepted. It's better to keep the behavior of accepting a candidate uniform.

The only advantage I see is that it enables one to move more of the completion mode from Go to Elvish with relatively little new API. But that comes at the cost of a worse API for authors of completers. I would like to be able to implement completion mode in Elvish one day, but it doesn't warrant breaking other things. For most people, whether the completion mode is written in Go or Elvish should be an implementation detail.

@xiaq It wouldn't break existing completions. I later realized that the Elvish script completion system could work with the currently existing completion libs, without breaking compatibility, but also enables implementing more flexible completions in the same system, along with the current.
If I didn't described it clearly in the previous comment: completers don't manipulate the argument array in edit:argument-list. They only outputs the candidates. The completion system would modify this array.


Implement new schema

Closes #31 and also closes #29

No it's ready to merge. Should we also create a corresponding release?

Great. Please merge and release this at 0.2.0.


Fix security vulnerability: Remove uglifyjs, use terser plugin

So recently github showed a banner inside the repo about found security vulnerability in serialize-javascript package versions less than 2.1.1. This is not directly affected us because we weren't using this in the runtime, but still I thought would be good to get rid of this banner.
serialize-javascript package version 1.7.0 was used by uglifyjs-webpack-plugin, which by itself is deprecated and replaced by terser-webpack-plugin.
The configuration I used was taken from config in react-scripts package:
https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/config/webpack.config.js#L217
So, this PR:

Updates dependencies
Replaces uglifyjs-webpack-plugin with terser-webpack-plugin

Btw, after replacing uglify with terser build size decreased a little bit :P (most noticeable is vendors chunk which went down from 2.56 to 1.44 mb) and other files' sizes decreased by 20-50%

Travis automatic deployment:
https://pr327--safereact.review.gnosisdev.com

Travis automatic deployment:
https://pr327--safereact.review.gnosisdev.com


Add yaydoc.yml file for yaydoc

Yaydoc will need a yaml file named .yaydoc.yml with various configuration.

@pri22296 Just to clarify, why was the PR closed? Is the issue not valid?

@iamareebjamal The docs for this repo would be generated together with other open-event projects as a single site. .yaydoc.yml is not required for each and every project. Hence this PR was closed as this repo does not need to override any default settings(such as generating javadocs). Closing this issue though. Thanks for reminding.


合并主分支

Please do not create a Pull Request without creating an issue first.
What is the purpose of the change
XXXXX
Brief changelog
XX
Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[ ] Run mvn -B clean package apache-rat:check findbugs:findbugs -Dmaven.test.skip=true to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 8 committers have signed the CLA.:x: KomachiSion:x: 985492783:x: xuxiaowei-com-cn:x: Sunrisea:x: stone-98:x: eltociear:x: Sitosoym:x: Bo-QiuYou have signed the CLA already but the status is still pending? Let us recheck it.


Support for static prefix on dynamic paths

Describe the bug
Currently TanStack Router supports dynamic path segments in the form /$var/. However it is sometimes useful to have a static prefix (or suffix) that is used as part of the matching. For example youtube.com/@ChannelName.
This is a feature request for Router to support the form /prefix$var/ (or some other way of having a static prefix mixed with a dynamic variable). Optionally it would be nice to also support suffixes, perhaps in the form /prefix$var$suffix/?
Your Example Website or App
https://stackblitz.com/edit/tanstack-router-jwzga9?file=src%2Fmain.tsx
Steps to Reproduce the Bug or Issue
new Route({
  path: '/prefix$var',
  component: function User({ useParams }) {
    const params = useParams();
    return
Hello {params.var}!
;
  },
});

This will not be recognized as a dynamic route and var will not be available in params
Expected behavior
var would be available in params
Screenshots or Videos
No response
Platform
N/A
Additional context
No response

Now that things are pretty stable, I'd like to see this PR updated.

I updated the PR to remove the merge conflicts but didn't do an in-depth look at what's changed in the last 4 months

Any update on this?

this was closed: https://github.com/TanStack/router/pull/709
would need to be redone

Any updates?

My understanding is that while this feature is something they are willing to support, it is not a high priority and nobody on the core team is working on it. (I am not a maintainer and have no real knowledge of their priorities)
I originally suggested it since it'd be useful in a project I was working on, but I have since dropped that project and am not actively using TanStack router, therefore I do not have time to implement this feature myself.
If somebody is looking for this feature, I recommend filing a PR implementing it yourself. The previously mentioned PR may be helpful as a starting point, but I imagine a lot has changed since I made it.

@FugiTech is absolutely correct. core team is not working on this feature but we are happy to accept PRs. if anyone is interested in implementing this, reach out to us e.g. via discord

Hey would love to chime in here as this is currently kinda a roadblocker for me to potentially migrate our platform to Start as we have /@username paths.
What about support [param] in addition (or instead) of $param? which could make it easier to distinguish where a dynamic param starts and ends so would make suffixed kinda trivial I think and also allow for even more advanced paths like /foo-[firstname]-[lastname]-bar or whatever, tho I personally currently don't see a need for those ^^
Maybe this has already been discussed and $ might have it's benefits over [] with file based routing?

Trying to implement something, at least hacky as an example tho so far I'm failing pretty ungracefully 😅
Also one thing I realized in this /prefix-[param1]-[param2] proposal the Segment type would probably need to be extended something like
export interface Segment {
  type: 'pathname' | 'param' | 'wildcard'
  value: string
  params?: Record<string, string>
}

or a discriminated union, so that the example path with a route like /prefix-p2-p2 would generate a segment like
{
   'type': 'param',
   'value': 'prefix-p2-p2',
   'params: {
     'param1': 'p1',
     'param2': 'p2'
   }
}

My last attempt failed by producing an (infinite) redirection loop appending the path params over and over again 😭 😅

I really do want to support this. I'm just not sure what it would take on the type side just yet. I admittedly have been focused on other things. @chorobin @schiller-manuel and @SeanCassiere might continue to gain insights here, but until I ship Start beta, I can't really dive in here 100% yet.

Okay I see, really appreciate your comment 🙏🏼

Got a very first version hacked together, works with prefix: @[username], suffix: [username]@ and both: @[username]@, though currently only ONE dynamic param per path segment like shown here, so does NOT (yet) support things I've shown before like /prefix-[param1]-[param2], think this would require some more (potentially breaking) changes.
Also currently NO Typescript support and I'm not sure I can fix that myself 😇
Gonna play a little more with it and then prepare a (draft) PR (probably not tomorrow) so team could have a look whenever they have capacity.

I'm all for this being implemented, but in the meantime, it shouldn't be a hard blocker. Here's a tested workaround:
// routes/$username.tsx

import { createFileRoute, notFound } from "@tanstack/react-router";

export const Route = createFileRoute("/$username")({
  component: RouteComponent,
  beforeLoad: ({ params: { username } }) => {
    // You can use your own check of course
    if (!username.startsWith("@")) {
      notFound({ throw: true });
    }
  },
});

function RouteComponent() {
  const params = Route.useParams();
  const username = params.username.substring(1);
  return `Hello ${username}!`;
}

You could also put it in your context.

@cyphase how would Router handle this if I have multiple dynamic routes at the root?
I opened a draft #2734 which would support this properly, allowing for /@[username] & /$param (or /[param]) at root level


Runtime error when is only debug flags in the code

If you try to run code with only debug flags and no braces (e.g. #dl) you get the following runtime error:
/Users/eamon/projects/Brain-Flak/stack.rb:51:in `include?': no implicit conversion of nil into String (TypeError)
    from /Users/eamon/projects/Brain-Flak/stack.rb:51:in `is_opening_bracket?'
    from /Users/eamon/projects/Brain-Flak/Interpreter.rb:135:in `step'
    from brain_flak.rb:60:in `<main>'

This error occurs when the interpreter attempts to determine if the program starts with an opening bracket but discovers there is no program.  It passes a nil object to the method is_opening_bracket, which then tries to convert that to a string.  This error occurs on both the debug-flag-dev and master branches.  This error only occurs with debug mode on.

  It throws our good friend the Error at character 1: Invalid character ''..


Persist docker Images through multiple docker:dind containers?

I am to scale multiple dind containers using docker-compose command.
docker-compose.yaml
version: '3.8'

networks:
  net:
    driver: bridge

volumes:
  dind-images:

services:
  # DinD Container Configuration
  agent:
    image: docker:dind
    volumes:
      - 'dind-images:/var/lib/docker/image'  # Persist docker images through dind containers
    privileged: true
    tty: true
    networks:
      - net

and I am running this compose file with:
docker-compose up -d --scale agent=4

I am mapping /var/lib/docker/image to a volume called dind-images through multiple dind containers the problem is whenever I try to run docker image pull image_name in one of them, then run docker image ls I only get the image name listed in the only dind container I used pull command on but won't show on other containers.
WHEN I RESTART CONTAINERS WITH docker-compose down|up I CAN SEE IMAGES ON ALL OF THEM
Am I missing something and would that affect the next runs?

When I run docker image pull image_name on the other containers it takes only a second to pull (which means that it finds the image data) but when I run docker image ls it doesn't show the image).

I feel like there is other data I need to include in volumes but I don't know what exactly.

Pulling image on 1st dind container:

Pulling Image after downloading image from 1st dind container:

You cannot share any of /var/lib/docker between multiple Docker servers simultaneously; it is not designed to do that.

Closing since this seems resolved, if you need further help you could also try asking over at the Docker Community Forums, Docker Community Slack, or Stack Overflow


added filename prompt

New features:

Filename prompt for download

Fixes:

Fixed typos in index.html

Updates

Updated Readme.md with latest information.

@all-contributors please add @rohitkumarankam  for Tools, Design


fix: uri encodings

There are two problems at play here:

If you open a buffer that doesn't have a corresponding file written to disk (i.e., nvim some_new_asm_file.s), the server will crash. This is because we attempt to canonicalize the path associated with a request. This canonicalization can fail if the path is malformed, or if it just points to a file that doesn't exist. I've refactored get_config to handle this case. If a path cannot be canonicalized, it is still returned and a warning is issued to the log.
First reported in this post on r/emacs. I wasn't aware of this until now, but the lsp spec is actually incredibly vague regarding what constitutes a valid URI. From the spec itself:

Care should be taken to handle encoding in URIs. For example, some clients (such as VS Code) may encode colons in drive letters while others do not. The URIs below are both valid, but clients and servers should be consistent with the form they use themselves to ensure the other party doesn’t interpret them as distinct URIs. Clients and servers should not assume that each other are encoding the same way (for example a client encoding colons in drive letters cannot assume server responses will have encoded colons). The same applies to casing of drive letters - one party should not assume the other party will return paths with drive letters cased the same as itself.
file:///c:/project/readme.md
file:///C%3A/project/readme.md

I don't understand why percent encoding perfectly valid ascii is a good idea, but it looks like some lsp-clients do this. Obviously canonicalization of a path such as C%3A/project/readme.md will fail. We already have url_escape pulled in as a dependency (originally for some of the z80 stuff from awhile back), so in theory this PR should solve the issue. I'm still struggling to set up emacs locally to reproduce the issue and make sure this fixes it, so that's why this is marked as a draft for now.

Update: Fix verified with the help of @PaulRitaldato1


Implement clang-format stylesheet.

We need to get up and running on clang-format based on our current code style. Some stuff keeps passing in PRs when it shouldn't and really it'd be great to automate this with clang-format.

Hey @RubyNova
I use this clang-format file in my c++ projects. Kindly review this file and associated codebase formatting, and let me know if this one works for you. I'll send a PR to add the file.

Thanks, I'll check it out.

Picking this up next as formatting is currently hellish 🗡
Based on Microsoft (.NET) formatting with a few tweaks as we go
-Option to run formatter via CMake
-Option to check formatting via CI (which will fail the build if anything is found)


accountingService, checkoutService, frauddetectionService: is stuck on pod initializing

Has anyone encountered an issue on accountingService, checkoutService, frauddetectionService components stuck on pod initializing? I see that these three components depend in kafka. Whenever I try to connect to kafka service via curl it says connection refused. But the kafka pod is running and no logs are being produced.

kafka pod
Requests:
  memory:  500Mi
Environment:
  OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE:  cumulative
  KAFKA_HEAP_OPTS:                                    -Xmx200M -Xms200M
  OTEL_RESOURCE_ATTRIBUTES:                           service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo
  OTEL_SERVICE_NAME:                                   (v1:metadata.labels['app.kubernetes.io/component'])
  OTEL_COLLECTOR_NAME:                                my-otel-demo-otelcol
  OTEL_EXPORTER_OTLP_ENDPOINT:                        http://$(OTEL_COLLECTOR_NAME):4317
  SHIPPING_SERVICE_PORT:                              8080
  KAFKA_ADVERTISED_LISTENERS:                         PLAINTEXT://my-otel-demo-kafka.otel-demo.svc.cluster.local:9092
Mounts:
  /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-g27mk (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  kube-api-access-g27mk:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>

accountingService
Name:             my-otel-demo-accountingservice-857d98d99-lllmv
Namespace:        otel-demo
Priority:         0
Service Account:  my-otel-demo
Started:      Wed, 20 Dec 2023 07:49:22 +0000
Ready:          False
Restart Count:  0
Environment:    <none>
Mounts:
  /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-kmz4x (ro)
Containers:
  accountingservice:
    Container ID:
    Image:          xxxxxxx.azurecr.io/demo@sha256:c56aa837ccced8b8157a7e7bd377b8490c3699a45d9d77500053c87723aeceff
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Limits:
      memory:  20Mi
    Requests:
      memory:  20Mi
    Environment:
      OTEL_COLLECTOR_NAME:                                my-otel-demo-otelcol
      KAFKA_SERVICE_ADDR:                                 my-otel-demo-kafka.otel-demo.svc.cluster.local:9092
      OTEL_SERVICE_NAME:                                   (v1:metadata.labels['app.kubernetes.io/component'])
      OTEL_EXPORTER_OTLP_ENDPOINT:                        http://$(OTEL_COLLECTOR_NAME):4317
      OTEL_RESOURCE_ATTRIBUTES:                           service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demo
      OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE:  cumulative
      SHIPPING_SERVICE_PORT:                              8080
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-kmz4x (ro)
Conditions:
  Type              Status
  Initialized       False
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  kube-api-access-kmz4x:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>

I did a clean install of the latest demo chart and everything started up correctly. Which chart version are you running and what version of k8s?

Hi, please refer to details below. I'm still not exploring this as of the moment. I did disable both grafana, jaeger and enabled prometheus and otel chart only. As I did have a different backend
Chart version: 0.27.0
K8s version: 1.26.6

Can you share your values.yaml?

I think I've already discovered the problem. So our organization does not allow us to download these images we have a separate azure pipeline that does the pulling, tagging and pushing images to the private ACR. The problem I'm encountering is that the last image is being applied on all the different containers that comes from the repo ghcr.io/open-telemetry/demo. Here is what it looks like in ACR:
[
  {
    "digest": "sha256:05dbfec30ad5dc0418220467f871c4ec7a0c7d51616aad77b1a2c600ebb87bfb",
    "tags": [
      "my-otel-demo-adservice"
    ],
    "timestamp": "2024-01-09T06:51:32.3309429Z"
  },
  {
    "digest": "sha256:46d0ecb07789be7593ad7a06579d01e4e930766847ac13da6c81768a29a35493",
    "tags": [
      "my-otel-demo-cartservice"
    ],
    "timestamp": "2024-01-09T06:51:36.6962476Z"
  },
  {
    "digest": "sha256:4dab7dd445362bef8dca6757a08d3066ce6e4ad5c0d614e478449fce6c1b866a",
    "tags": [
      "my-otel-demo-accountingservice"
    ],
    "timestamp": "2024-01-09T06:51:24.4688051Z"
  },
  {
    "digest": "sha256:65204b11c6f0e675af98d75a68130886fc2e26ef022bed1592855223ee21fa9c",
    "tags": [
      "my-otel-demo-kafka"
    ],
    "timestamp": "2024-01-09T06:51:57.4823549Z"
  }
]

As you can see here the last digest for my-otel-demo-kafka is applied to all the containers.

the demo chart allows setting the image for each service.
You can set default image configuration here: https://github.com/open-telemetry/opentelemetry-helm-charts/blob/c8399b363fdfb1cea90ab4382249a717ba56b628/charts/opentelemetry-demo/values.yaml#L19-L25
Or you can set specific service image details, like here: https://github.com/open-telemetry/opentelemetry-helm-charts/blob/c8399b363fdfb1cea90ab4382249a717ba56b628/charts/opentelemetry-demo/values.yaml#L55C7-L55C12

Thanks for the advice I've found a way to get the images through acr


Cannot contine to prune images

When running docker image prune -a
You cannot continue as when you type Y to accept, it says "Command not Allowed"

It is a bit hard to limit the input. I plan to release the power of the terminal, but people have to enable this feature via an environment variable, it won't enable by default.

It is a bit hard to limit the input. I plan to release the power of the terminal, but people have to enable this feature via an environment variable, it won't enable by default.

Is this feature released?


[Feature]: Add support for quick installation for Home, Education and other Windows editions.

Is your proposal related to a problem?
There is no option to install something else than Windows Pro or Enterprise.
Describe the solution you'd like.
I would like to do Home licence installation from docker compose, without using manual install.
Describe alternatives you've considered.
Manual installation.
Additional context
Modern Windows since vista contain multiple editions in one image. Sometimes ei.cfg file may be needed to be replaced, and that's all.
Also for End of Life OSes I would add option to install these from iso with slipstreamed updates.

But still Windows 7 Ultimate, Windows Vista business and 10 Education is missing.
Also it would be nice if EoL OSes would be installed with all updates.


performance optimization: first steps

these 2 commits improve just one function (see its description for details), but the result is impressive - the function became twice faster. and this noticeably affected the whole rendering.
before changes:

after this changes:

and this is what I noticed just looked over the sources... I will look more and likely find more similar prominent places that can be easily optimized. this is just the first step.

Yes, for larger number of elements a QHash should be much faster than a QMap. And not searching twice is obviously faster.
Some time ago we measured performance of different containers (#246).
The outcome was, that Qt containers are in some cases slower than C++ std:: variants.
And at many locations there is no strict need to use the Qt containers. It is just cleaner to have it less mixed.
But there might be some performance to gain from that also.
My personal experience is that I do not suffer from rendering performance. I always struggle with file-IO performance (world is stored on network drive). Therefore it is one of my goals to improve file reading, rendering speed was neglected during the last years.

first of all, I have no plans to achieve the maximum possible performance or smooth rendering (I'm also fine with delays), I just noticed the "bad place", and think such obvious things must be fixed/optimized, especially when it costs nothing (just a few lines must be changed with no consequences).

The outcome was, that Qt containers are in some cases slower than C++ std:: variants.
And at many locations there is no strict need to use the Qt containers. It is just cleaner to have it less mixed.

I completely agree, code is written in Qt - let's use Qt containers unless there is a strict reason do not so. and those Qt containers may be slower it is expected for me - Qt metaobject system definitely leaves some footprint on performance.


Feature Request: 'correct spell' item selection use popup

Suggestion
'correct spell' item selection use popup
Zl/ZL
Pros:

command line no expand
huge count items' selecting at elegance

Cons:

fallback to command line at popup no support env.

Hi, @tsuyoshicho !
If popup_menu () is enabled, you can use popup now.
Please update plugin and try it!
#28

Thanks!! I try it.

OK, Good It.


Added ability to set Tint Color for Slider using RGBA

It's working fine with track. The problem is the trackBackground. For some reason is using the default because the value of trackBackground is equal to "Nil".

Hi Murray,
Is there any problem with the code? Because you are asking for that feature on your description.
Let me know

Hi @muZZkat
What about this pull request? Seems that @mavris code is fine


[Bug report] Missing license for svg files

Version
main branch
Describe what's wrong
These two svg files are under an unknown license. Do we know where they come from?
./web/src/lib/icons/svg/doris.svg
./web/src/lib/icons/svg/hive.svg
Error message and/or stacktrace
N/A
How to reproduce
Files are not listed in LICENSE.
Additional context
No response

Just to be clear, we need to know:

Where did these files come from?
How are they licensed?
If it a ALv2 compatible license, then it should be mentioned in LICENSE and LICENSE.bin

@justinmclean hi justin, the two svgs is come from https://hive.apache.org/ and https://doris.incubator.apache.org/

Is that ok when we mention http://www.apache.org/licenses/LICENSE-2.0 in header of hive.svg and doris.svg file? @justinmclean

@LauraXia123, Where exactly did the svg files come from? And how do you know they are licensed under the Apache license? Just because you copied it from an ASF site doesn't mean they are under the Apache license as a) generally only code is under that license and b) that may not be the original source.

Is that ok when we mention http://www.apache.org/licenses/LICENSE-2.0 in header of hive.svg and doris.svg file? @justinmclean

No it is not OK. We can not add a license header to a file we did not create.


1.2.0 Failed to communicate with device.

1.2.0  Jitterbug Lite, installed by altstore.
Tried and repaired many times, but still the same message:
Failed to communicate with device. Make sure the device is connected and unlocked and that the pairing is valid.
I used it on one device and want to run UTM.
Please, help me.

Same

From the release notes

Jitterbug Lite is the same app without any of the VPN features which require special entitlements only available to paid Apple Developer accounts.

Lite will NOT work with one device.


Integrated terminal freezes when ever a program goes to infinite loop.

Version 1.5.2
Commit 66f37fd2a99eb9d628dd374d81d78835b410c39b

OS Version: Ubunutn 15.10

Steps to Reproduce:

Write a C program which outputs to integrated terminal in infinite loop.
Run that program in integrated terminal, terminal freezes.

Duplicate https://github.com/Microsoft/vscode/issues/11805


⚠ Bofrost.at has degraded performance

In c105493, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2025 ms

Resolved: Bofrost.at performance has improved in 3b369aa after 310 days, 9 hours, 42 minutes.


Image truncation or leakage parameter missing?

Hi,
I've been trying to find how truncated images are handled but could not find any parameter that is containing that information after the shower image analysis. Does anybody know where is this implemented or wether there is no implementation at all?
Thanks

Right now it has not yet been merged into the main ctapipe code -there are only some basic mathods in @tino-michael's repo, including edge-pixel rejection. If you'd like to help, its appreciated! It's not clear to me yet what method is best.  The easiest of course is just putting a cut on the hillas centroid distance.

Sorry, I could not find anything in any of the branches of the repo, @tino-michael could you point me to the modified files?

It's not a branch in my ctapipe fork, it's in my ImageCleaning module in a separate repo:
https://github.com/tino-michael/tino_cta/blob/master/tino_cta/ImageCleaning.py

Got implemented in #783, function is ctapipe.image.leakage


feat(web): crane metrics config

Added metrics (crane only) config to image and instance editors.

Codecov Report
Patch coverage has no change and project coverage change: -0.03% :warning:

Comparison is base (635bf4a) 25.49% compared to head (3e7157b) 25.46%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #797      +/-   ##
===========================================
- Coverage    25.49%   25.46%   -0.03%
===========================================
  Files           60       60
  Lines         5703     5709       +6
===========================================
  Hits          1454     1454
- Misses        4147     4152       +5
- Partials       102      103       +1

Files Changed
Coverage Δ

golang/internal/mapper/grpc.go
64.63% <0.00%> (-0.80%)
:arrow_down:

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


Make test images step in pipeline is no longer doing useful work

This feels like an example of code rot.
This step builds firecracker and jailer binaries. However later in the pipeline we utilize make deps which downloads the latest firecracker and jailer binaries from release S3 bucket.
I would prefer removing the test-images target and step from the pipeline. This should speed up builds and makes pipeline runs consistent with local development.

I think, we are testing the SDK against Firecracker's release versions and it's main branch. The container is for the latter.

@kzys, I see the step now which uses the main branch binaries. I was wrong.


[FLOC-4391] Update to docker-compose 1.7.1 use the latest compose file format

Fixes: https://clusterhq.atlassian.net/browse/FLOC-4391
The problem:

Our cloudformation template installs the :latest version of docker-swarm.
A new version of docker-swarm was released recently  1.2.1 (2016-05-03).
Our cloudformation template installs an old version of docker-compose
Our tutorial and tests both use docker-compose v1 configuration file format rather than v2.
The old docker-compose and the  latest docker-swarm no longer create volumes (via volume plugin) on-demand.

Updating to latest docker-compose and using the v2 compose file format allows us to specify the volumes and the plugin options in a separate section of the config file.
And with this, docker-compose will now create the listed volumes before starting the services.
I also encountered https://clusterhq.atlassian.net/browse/FLOC-4392 (flocker-docker-plugin leaks file descriptors) while working on this.
Here are the results of the  updated installer test:

http://ci-live.clusterhq.com:8080/job/ClusterHQ-flocker/job/compose-file-v2-FLOC-4391/job/_run_admin_test_test_installer/1/

Looks good, @wallrj . Please go ahead after pending CI checks complete and changing CLOUDFORMATION_TEMPLATE_URL. Thanks!


Execute different commands depending on key pressed

Real world example:
I have emoji list that I want to search and copy or open emojipedia.org for that emoji.
Solution:
Let the user define a cmd that will be executed if certain key is pressed, for example when Enter pressed execute cmd_ENTER if Shift+Enter is pressed execute cmd_SHIFT_ENTER. I'm not sure what more elegant implementation would be just throwing ideas.

You can define cmd_alt/exec_alt now. alt+enter to run it.


Fix incorrect use of standard terminology

replace the incorrect use of a standard term ("Azure Cosmos DB connection string") with the correct term for this document's usage, i.e. "SQL connection string""
use the term "SQL connection string for Azure Cosmos DB" to distinguish the particular type of SQL connection strings used in this document from other SQL connection strings used by Azure Synapse Analytics
show the syntax of connection strings that, by standard, are referred to as "Azure Cosmos DB connection strings"
shows what fields should map into the format of a "SQL connection string for Azure Cosmos DB"
add information that the region field of the "SQL connection string for Azure Cosmos DB" is optional, and describe the default behavior

The term "Azure Cosmos DB connection string" has a standard meaning for users of Azure Cosmos DB. The usage of that term in this document is incorrect and confusing. In this document, the standard term is being used to mean a "SQL connection string". Although the document does provide the syntax for the SQL connection string, the document does not provide enough cues to let the reader know that what this document calls an "Azure Cosmos DB connection string"  is not an actual "Azure Cosmos DB connection string". In addition, the nature of these both being connection strings means that a casual reader might not notice the subtle differences.
One reason the current use of the term "Azure Cosmos DB connection string" is particularly problematic is that all the other documents that are part of this series that explains how to combine Azure Cosmos DB with Azure Synapse Analytics use the correct meaning for that term. Only in this document is the term being used to mean something different, something non-standard.

@mromanch : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off