Investigate Shared Apollo Client

Look into a shared apollo client that could be used across our packages and published on npm. Do not include actual requests. Should consist of common configuration (including authLink for signing requests) and GQL types.
Things to consider:

how to handle publishing on npm and gql versions?

After looking into this more I don think there is really much shared setup that we want to package together and share everywhere. Here are the things that we thought about including in the package and what I or we concluded about them:

common configuration. This includes the auth link and probably not much else. Other than that there are some no-fetch cache settings but I don't we want to enforce that centrally and that should be set where its used.
requests. Several people noted they wanted to be able to form these where called, which I agree with so you can specify certain fields and generally call as needed
graphql schema, instead of generating/outputting to several packages. This seemed like a good idea but kind of goes hand-in-hand with requests. If we are forming requests where the client is used, then we need to use the graphql types there. I considered putting in a shared client package and exporting for use where we make requests but we currently dont actually generate the same thing everywhere (different packages generate the gql types differently).

Really the only non-trivial thing that seems worth sharing between packages is the auth link and we decided copy-pasting between the few places we use it is fine.

Thanks for the overview, @BlairCurrey! One question, what do you mean exactly by

(different packages generate the gql types differently).

If you look at https://github.com/interledger/rafiki/blob/main/packages/backend/codegen.yml and frontend for example you'll see some options which are not enabled elsewhere ('typescript-operations' plugin, omitOperationSuffix). Thus I'm not sure that we can/should generate 1 thing and use everywhere. Although I havent looked too deeply into these differences. Even if we did want to standardize on 1 generated output, I'm not sure that its better to generate into an internal package use that package everywhere. Just directly outputting where its used seems more direct.


Can't set child process as data producer and parent process(with gevent) as data consumer?

Originally reported by: Cherrot Luo (Bitbucket: cherrot, GitHub: cherrot)

The following is my code, it looks like simply exchanging the reader and writer of Example 1.  However, the KeyboardIntterupt would cause EOFError.
#!python

import gevent
import gipc

def main():
    with gipc.pipe() as (r, w):
        p = gipc.start_process(target=process, args=(w, ))
        wg = gevent.spawn(worker, r)
        try:
            p.join()
        except KeyboardInterrupt:
            p.terminate()
            p.join()
        wg.kill()

def worker(pipe):
    while True:
        print "Got from pipe: '%s'" % pipe.get()

def process(pipe):
    while True:
        pipe.put("written to pipe")
        gevent.sleep(1)

if __name__ == "__main__":
    main()

The following is the output:
#!shell

python test.py
Got from pipe: 'written to pipe'
Got from pipe: 'written to pipe'
Got from pipe: 'written to pipe'
^CKeyboardInterrupt
Traceback (most recent call last):
  File "PATH/TO/lib/python2.7/site-packages/gevent/greenlet.py", line 523, in run
    result = self._run(*self.args, **self.kwargs)
  File "test.py", line 25, in worker
    print "Got from pipe: '%s'" % pipe.get()
  File "PATH/TO/lib/python2.7/site-packages/gipc/gipc.py", line 855, in get
    msize, = struct.unpack("!i", self._recv_in_buffer(4).getvalue())
  File "PATH/TO/lib/python2.7/site-packages/gipc/gipc.py", line 810, in _recv_in_buffer
    "Most likely, the other pipe end is closed.")
EOFError: Most likely, the other pipe end is closed.
<Greenlet at 0x7f07b00bb4b0: worker(<_GIPCReader_f06b91 fd: 3>)> failed with EOFError

Bitbucket: https://bitbucket.org/jgehrcke/gipc/issue/20

@cherrot this is expected. With p.terminate() you send a SIGTERM to the child process as of which it terminates. That also means that the write end of the pipe is being closed. The reader in your parent process sees and reports exactly that: EOFError: Most likely, the other pipe end is closed..


Update dependencies to latest

React Boilerplate
This is for the issue: #2129 Next Version Release

Deploy preview for react-boilerplate failed.
 Right now, merging this would break the project.
Almost all your changes are just code reformatting. Seemingly automated by prettier.
You've only updated version numbers in package.json. Where are the changes to the code required by these updates?
You need to follow the contribution guidelines and read about how to update the project dependencies. You'll find that there are quite a few things you need to do to ensure your PR the high-quality of this codebase.


new router implementation?

Are  there any plans branches to support new router https://angular.github.io/router/?

Thanks for the request, we haven't looked into the new router yet.  Does it work with this library, or is there integration issues?

Closing in favor of #176


Parquet: Fix string display for f32/f64 zero values

Which issue does this PR close?

Closes #5045
Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

What is the issue with 0E0? I agree it looks a little odd, but it isn't incorrect?

What is the issue with 0E0? I agree it looks a little odd, but it isn't incorrect?

Yeah I wasn't sure if this was intended or not. It felt like a bug since the code seemed to suggest it used the E notation for very large positive/negative numbers, and 0E0 just happened to be caught up in it accidentally.
When I was implementing f16 (https://github.com/apache/arrow-rs/pull/5003) I wasn't sure if we should display 0E0 to be consistent or just have it display 0.0 anyway
If this is behaviour is fine then can close the PR

I don't have a good enough sense of what people are using the record API for to be comfortable making breaking changes to it

No problem, closing as no need to change


Upgrade chokidar 3.4.2 to 3.5.2

chokidar 3.4.2 to 3.5.2 upgrade for Mac ARM support version
glob-parent chokidar's dependency upgrade to pass security vulnerability 5.1.2

Thanks for the PR :) Solved by #699


Teams App/Bot takes a long time to appear in a created team (if it even appears) and then keeps removing/adding itself from the team when signing out and in

We have issues with Microsoft Teams when using the Graph API. We are testing Teams with a Microsoft 365 Developer Program account.

When creating a Team and adding an App/Bot to it with the Graph API within the create call, sometimes the Bot isn't added to the Team, and it isn't displayed in the Apps section and therefore the App/Bot is not mentionable.

When waiting for ten minutes or so, sometimes the App/Bot shows up in the Team and sometimes it never shows up.

Signing out/in into Team sometimes helps to make the App/Bot show up. Hard refreshing and clearing the cache doesn't help to make the Bot show up in a Team.

After creating a new team (with an App/Bot added by the create team Graph API call) and signing out/in into Teams, the App/Bot in most cases does show up for this Team.

Sometimes the App/Bot gets removed from a random Team (where it was present before), when signing out and in.

GIF showcasing the issues:

The screenshots below shows that when a team is created, the Bot isn't added to the team. But after signing out and in, the bot sometimes shows up immediately.

We are checking the issue. We will get back to you shortly.

This is the C# Graph code to create the Team and add the App:
GraphServiceClient graphClient; // Construct & authenticate towards your tenant here first
string teamOwner = "Fill in a user email address from the tenant (case sensitive)";

var team = new Microsoft.Graph.Team()
{
    DisplayName = teamName,
    Members = new TeamMembersCollectionPage()
    {
        new AadUserConversationMember()
        {
            Roles = new List<string>()
            {
                "owner"
            },
            AdditionalData = new Dictionary<string, object>()
            {
                {<EMAIL_ADDRESS>$"https://graph.microsoft.com/v1.0/users('{teamOwner}')" }
            }
        }
    },
    AdditionalData = new Dictionary<string, object>()
    {
        {<EMAIL_ADDRESS>"https://graph.microsoft.com/v1.0/teamsTemplates('standard')" }
    }
};

var createdTeamResponse = await graphClient.Teams.Request().AddResponseAsync(team);

When Creating a new Team (with an App/Bot added by the create team Graph API call) and signing out/in, there seems to be a bug that causes the App/Bot to alternate between showing and not showing in the existing Teams.
So the Teams that had the bot/app before, do not anymore after this scenario.
Those that didn't have the bot/app, do have it after this scenario.
When only signing out/in, this alternating behaviour doesn't happen.

To provide an update, even if our App/Bot doesn't appear as installed and the users can't mention it (to talk to it), the App/Bot is still able to send a proactive message to the conversation, and from that moment it immediately appears in the list of Apps and the users can mention it.

Thanks for the update @JordyGit .

Any updates on this? It's still affecting our use case in a bad way. We can't release our feature this way...
We need our app/bot being added to the Team without issues, because now the Team gets created and no app/bot appears. It's very annoying and there is no workaround or logic on how to avoid or bypass the issue.

@JordyGit - We are checking the status of the bug with engineering team. We will inform you once we have any update. Thanks!

@JordyGit - Engineering team need the following details to investigate. Could you please provide those?

Client request Id and timestamp of the app installation request.
Client request Id and timestamp of the GET app installation request which shows that app wasn't installed.
If the inconsistency is between Teams client and graph API, please clarify that.

The inconsistency is between Teams client and graph API.
We create a Team with the Bot added to it with this piece of code: https://github.com/MicrosoftDocs/msteams-docs/issues/6738#issuecomment-1224022747
From then the Team behaves like in these screenshots/GIF in Teams: https://github.com/MicrosoftDocs/msteams-docs/issues/6738#issue-1347683781
We didn't try the GET app installation request as we shouldn't need it, it should just be installed from our first Create Team call.
In application insights I can see a few create team & channel Graph calls that our service did for someone having the issue. I can see the next ids, but I can't be sure the issue happening in this exact call and not sure if those ids help you? Local time is Belgium UTC +1.

I can only give that piece of code, by using that you should be able to reproduce the issue: https://github.com/MicrosoftDocs/msteams-docs/issues/6738#issuecomment-1224022747

@JordyGit - We are checking the status of the bug with engineering team. We will inform you once we have any update.

Its been long and keeping in mind that multiple updates has happened for MS Teams, please let us know if you are still encountering this issue or not? Thanks!


Updates for Scala 2.13

Includes everything from https://github.com/sangria-graphql/sangria-streaming-api/pull/3, including @ingemaradahl's commits from https://github.com/sangria-graphql/sangria-streaming-api/pull/2.
No errors from:
sbt ++2.11.12 mimaReportBinaryIssues
sbt ++2.12.10 mimaReportBinaryIssues

…so we can publish as 1.0.1.

@yanns Mind if I go ahead and publish this so I can get the sangria-monix PR lined up?

@travisbrown  please do. thx!


Add Kafka output (v2)

This version fixes the test cases that I had missed were broken.
Is there a reason for not running the test suite on pull requests by the way?

Edit: Nevermind, I see that they're being run now!

It seems to have hanged without showing me the logs anymore, but the tests pass locally, hm...

I found the issue, the input_socket input was being blocked waiting for data.  I guess it might not have been found locally because the dnsdist version I have running acts slightly differently from the one in the CI run.
I also found that the input_tcpclient functionality is broken, receiver.py tries to start it from input_socket rather than input_tcpclient, so that should be fixed as well.


Build failure on Mac M1

Environment
MacOS M1
Ventura 13.4 (22F66)
rustup 1.26.0 (5af9b9484 2023-04-05)
rustc 1.70.0 (90c541806 2023-05-31)
toolchain stable + wasm32-wasi
Behavior
cargo install --path ./app ambient inside root directory branched main
Caution
   Compiling ambient_sys v0.3.0-dev (/Users/apollo/work/ambient/Ambient/crates/sys)
   Compiling sentry-backtrace v0.27.0
   Compiling nalgebra v0.30.1
   Compiling puffin v0.14.3
   Compiling jpeg-decoder v0.3.0
   Compiling zune-inflate v0.2.54
error[E0786]: found invalid metadata files for crate `rayon`
  --> /Users/apollo/.cargo/registry/src/github.com-1ecc6299db9ec823/jpeg-decoder-0.3.0/src/lib.rs:37:1
   |
37 | extern crate rayon;
   | ^^^^^^^^^^^^^^^^^^^
   |
   = note: invalid metadata version found: /Users/apollo/work/ambient/Ambient/target/release/deps/librayon-4aee29c84eafc803.rmeta

   Compiling fdeflate v0.3.0
error[E0599]: no method named `par_chunks_mut` found for struct `Vec<u8>` in the current scope
   --> /Users/apollo/.cargo/registry/src/github.com-1ecc6299db9ec823/jpeg-decoder-0.3.0/src/worker/rayon.rs:207:10
    |
207 |         .par_chunks_mut(line_size)
    |          ^^^^^^^^^^^^^^ help: there is an associated function with a similar name: `as_chunks_mut`

Some errors have detailed explanations: E0599, E0786.
For more information about an error, try `rustc --explain E0599`.
error: could not compile `jpeg-decoder` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
error: failed to compile `ambient v0.3.0-dev (/Users/apollo/work/ambient/Ambient/app)`, intermediate artifacts can be found at `/Users/apollo/work/ambient/Ambient/target`

fresh reinstallation solved the issue


Unknown client version: 326440

This message popup when i start my tera. I can go to my settings but mu UI is nowhere to be found, even when i try to trigger something by using skills.
Is there a fix for this?
kinds regard,
abrakadabra01

I have the same problem. Please help

open in TCC \resources\data\opcodes
delete all
copypaste resources\data\opcodes from ShinraMeter


Intellisense no longer finds AL specific Values when start writing with uppercase

Describe the bug
When I start writing a new word for excample "rec" VS Code only suggests templates and not "Record". I would have to write "Rec" to get "Record" suggested. This works for all values.
To Reproduce
Create a new Variable in a procedure and start writing "rec" after ":".
{
    Caption = 'Buffer';
    TableType = Temporary;

    fields
    {
        field(1; "Line No."; Integer)
        {
            Caption = 'Line No.';
        }
        field(10; "Item No."; Code[20])
        {
            Caption = 'Item No.';
            TableRelation = Item;

            #region OnValidate
            trigger OnValidate();
            begin
                if "Item No." = '' then
                    ResetItemFields()
                else
                    CopyFromItem();
            end;
            #endregion OnValidate
        }
        field(11; Description; Text[100])
        {
            Caption = 'Description';
        }
    }

    keys
    {
        key(PK; "Line No.")
        {
            Clustered = true;
        }
    }

    #region CopyFromItem
    local procedure CopyFromItem();
    var
        Item: Record Item;
    begin
        Item.Get("Item No.");

        Description := Item.Description;
    end;
    #endregion CopyFromItem

    #region ResetItemFields
    local procedure ResetItemFields();
    begin
        Description := '';
    end;
    #endregion ResetItemFields
}

Expected behavior
No difference between starting a word uppercase or lowercase.
Screenshots
rec:

Rec:

5. Versions:

AL Language: 6.1.359074

Business Central: AT Business Central 17.0 (Plattform 17.0.17020.18049 + Anwendung 17.0.16993.0)

Though I am using the very same AL Language version and I have copied your codeunit, I cannot reproduce your issue. It might be related to some other extension or a setting, or maybe the VS Code version. My VS Code version is 1.50.1.

My VS Code Version is 1.50.1.
Thank you for the response, I checked it again and disabled all other extensions and discovered the one which issues this.
So this is not a problem of the AL Language Extension


Sorry but a little bit confused...

Thanks for your great job! I will order a GTN 1000 shortly which most probably will arrive with newer firmware/PCB, so not able to communicate status through RS 485 port.
In your files, there are some description to connes a WEMOS to the display port or the WIFI TTL port.
Does it means the status and power control could be achieved through these connections instead of the RS 485 port?
Thanks in advance!
Eric

You have to connect/use both. The display port / WiFi dongle port is used to retrieve the current status and change the inverter settings. The RS485 port must be used to request a power demand. The retrieval of the status frame via the RS485 port isn't possible anymore. The RS485 will accept/receive instructions but won't respond/transmit.

Thanks for your prompt feedback.
Ok, so I will have to connect 2 devices, one for each function?
Which yaml files should be used in such case?
Could the same ESP 32 be used for both connection?
And last, which version is preferred: wifi or display?

You can handle both jobs with the same ESP using two different UARTs / sets of GPIOs. A ESP32 supports three hardware UARTs. A ESP8266 has a single hardware UART. The second one will be software emulated using SoftwareSerial automatically. If you have the choice pick a ESP32 for improved stability.

I've no preference (with or without display). The display dies after a while pretty often. May be the WiFi version is the better choice at the moment.

Thanks, I think now I have to figure how to code this under esphome! Still discovering this!

There is an example YAML configuration per setup at the root directory of this project. Feel free to ask more questions if they aren't self explaining.

Yes, I was just checking the examples and I believe the one I need is this one: esp8266-display-display-version-limiter-example.yaml for LCD version of the inverter.
I suppose it is easy to replace the ESP8266 by an ESP 32, just changing the GPIO and board type?
I suspect there is no examples for ESP32 with dual interfaces?

I suppose it is easy to replace the ESP8266 by an ESP 32, just changing the GPIO and board type?

Correct. For example:
# remove
esp8266:
  board: d1_mini

# add
esp32:
  board: esp-wrover-kit

And adapt the GPIOs slightly:
  tx_pin_ttl_wifi: GPIO4
  rx_pin_ttl_wifi: GPIO5
  tx_pin_rs485: GPIO14
  rx_pin_rs485: GPIO12

Perfect! Many thanks!


Inline TryFromBytes derive for variant structs

I didn't update the goldens because it was too hard

The goldens?

The derive macro output tests (I call them goldens because they're effectively golden files)

I didn't update the goldens because it was too hard

@joshlf Told ya so. 😛 We really need to make updating these as easy as TRYBUILD=overwrite.

I didn't update the goldens because it was too hard

@joshlf Told ya so. 😛 We really need to make updating these as easy as TRYBUILD=overwrite.

My hope is that https://github.com/google/zerocopy/pull/1711 will make this much less painful.

I didn't update the goldens because it was too hard

Updated them and pushed.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 88.01%. Comparing base (38e64d2) to head (fbc7541).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1709      +/-   ##
==========================================
- Coverage   88.36%   88.01%   -0.35%
==========================================
  Files          16       16
  Lines        5810     5833      +23
==========================================
  Hits         5134     5134
- Misses        676      699      +23

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


NuGet metadata properties is not up to date with the NuGet targets

Issue description
https://docs.microsoft.com/en-us/dotnet/core/tools/csproj#nuget-metadata-properties is not up to date with https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets
More specifically;
https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#packing-an-icon-image-file
Should we maybe avoid duplication and link directly to the NuGet docs?
edit by @mairaw: added topic details

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

ID: cb4428fc-215c-78e1-5ff0-fe73f7a08260
Version Independent ID: 6741b1de-38a4-fbb1-d79d-acc47d549a2d
Content: Additions to the csproj format for .NET Core - .NET Core CLI
Content Source: docs/core/tools/csproj.md
Product: dotnet-core
Technology: dotnet-cli
GitHub Login: @mairaw
Microsoft Alias: mairaw

The plan is to actually create an entire reference for the SDK-style project and remove this information from this page, so I believe we'll need to keep the NuGet properties in our docs.
It would be weird to have all but the NuGet tags in the reference once we create that reference.
Thoughts?

We haven't started this work yet so I don't have the author's name. But you can always ping me.

Sounds good.
I'll communicate to the team to take the dotnet docs in account when making changes to docs that impact the CLI/SDK.

Sounds great @nkolev92! I think this is a good workflow.

Any progress on this? I just fell into the "trap" of following the outdated part of this doc which lead me to https://aka.ms/deprecateIconUrl when trying to upload a package to nuget.org.

Closing this, as csproj.md was updated with PackageIcon/PackageIconURL information by #19745, and the project SDK doc that will replace csproj.md already links to https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets


#0: Remove alignment requirements for Row Major tensors

Ticket
Problem description
Currently its required that RowMajor tensor size must be aligned to 4 bytes, because the data is transferred to device as a vector of uint32_t. This creates limitations in TTNN and complicates handling of Row Major tensors.
This PR is a prerequisite for https://github.com/tenstorrent/tt-metal/pull/15028
Thanks to @abhullar-tt for helping with lifting those restrictions.
What's changed
Modify Metal API allowing to send an arbitrary vector to device
Modify PageConfig removing alignment restrictions
Remove conversions to/from vector<uint32_t> for sending tensor to/from device
Remove asserts on buffer alignment for row major
Enable previously disabled tensor tests
Checklist

[ ] Post commit CI passes
[ ] Blackhole Post commit
[ ] Model regression CI testing passes
[ ] Device performance regression CI testing passes
[x] New/Existing tests provide coverage for changes

@TT-BrianLiu We will have a general effort of removing all extra paddings throughout the codebase for both Tile and RowMajor once we get this PR and TensorLayout in Tensor merged

@tt-aho The conversation about memcpy is irrelevant to this PR. The PR just adds handling on n % 4 != 0 into the same function in the same paradigm. I created an issue for re-evaluation of memcpy_to_device: https://github.com/tenstorrent/tt-metal/issues/15275.
Let's move forward with this PR

@sminakov-tt the conversation I linked to is relevant, as the change to memcpy_to_device may cause issues due to mixing temporal and non-temporal stores to hugepage.

@tt-aho Thanks for clarifying! @pgkeller Can you elaborate more on temporal /non-temporal stores?

@tt-aho Thanks for clarifying! @pgkeller Can you elaborate more on temporal /non-temporal stores?

discussed w/ @sminakov-tt , data can be stored to stack and copied to destination

any reason to prefer uint8_t over std::byte?

@cfjchu There's no specific reason, uint8_t seems to be used more often in the codebase


Unable to receive offline data after reconnecting after disconnection

The persistent sessions set by the client have been successful. After the client disconnects and reconnects, there is no need to subscribe here. As long as there is a corresponding topic published, you can receive the relevant information from the previous subscription. However, after the disconnection and reconnection, you cannot receive the content published by the corresponding topic during the disconnection period

I have the same issue. Any updates?

Hello, I've got the same issue, with V5 protocol.
V311 is working fine with persistent sessions, while V5 never receives anything.


App.Before looks like it executes before sub commands but comments say it executes after

Which is correct. If after I'd like a good way to set global options on my app before my subcommands execute like for instance:
command -v subcommand --flag value
so that I can take -v and turn on verbose logging for all of the subcommands without reepeating the code. Or is there a way to do this already?

Hi @gaffo
App.Before will run before any subcommands which is also what the comments state (https://github.com/codegangsta/cli/blob/master/app.go#L41-L44). Were there other comments you were looking at?

Also see https://github.com/codegangsta/cli/issues/325


New emails

Is there a Jira task for this we can put in the PR title?

Is there a Jira task for this we can put in the PR title?

Yes, I will update title correctly, I created this PR as a draft and didn't update it when it was ready


cstring_array_from_char_array returns NULL for empty char array

When using geodb for a country without postal codes, I stumbled on a case where a call to cstring_array_from_char_array with an empty str led to core dump (str->n==0). This patch fixes an issue.

Fixed in a different way with https://github.com/openvenues/libpostal/commit/e1f258171fb4a6d415d40241be00d7eda43f6110 (shouldn't return NULL if the input is an empty char_array, can just return an empty cstring_array).

Tried that before suggesting the fix in PR. At first, I also added if (str->n > 0) at the same place, as you did. Unfortunately, that resulted in a different crash:
#0  sparkey_hash_close (reader_ref=reader_ref@entry=0x2330340) at hashreader.c:105
105	  if (reader->open_status != MAGIC_VALUE_HASHREADER) {
(gdb) backtrace
#0  sparkey_hash_close (reader_ref=reader_ref@entry=0x2330340) at hashreader.c:105
#1  0x00007ff42956021b in geodb_destroy (self=0x2330320) at geodb.c:25
#2  0x00007ff429560610 in geodb_init (dir=dir@entry=0x61ceb0 "postal-data/EE/geodb") at geodb.c:155
#3  0x00007ff429560669 in geodb_load (dir=dir@entry=0x61ceb0 "postal-data/EE/geodb") at geodb.c:160
#4  0x00007ff429560933 in geodb_module_setup (dir=dir@entry=0x61ceb0 "postal-data/EE/geodb") at geodb.c:233
#5  0x00007ff429543bba in libpostal_setup_parser_datadir (datadir=0x4117f7 "postal-data/EE") at libpostal.c:1134

Hm, so I think it's better to fix the actual cause of that crash (probably some assumption that the saved array length is non-zero) than to change the expected behavior of a util function that may be used elsewhere. Also not sure if it's a great idea to have geodb->postal_codes be NULL in case it gets used somewhere in the future. Usually prefer to have pointers be non-NULL after initialization unless NULL has a specific meaning.
Guessing the problem would be this line: https://github.com/openvenues/libpostal/blob/master/src/geodb.c#L93. When postal_code_str_len is 0, that would translate into a call to char_array_new_size(0) which in turn would end up calling malloc(0), which is implementation-defined in C99 and can return NULL on some systems, thus causing char_array_new_size to return NULL and the whole initialization to fail.
The change in https://github.com/openvenues/libpostal/commit/1398df1260ed9d6a76c2c097e8d41223e58a2f5e guarantees that any call to *_array_new_size(0) will malloc at least 1 byte. Try pulling latest and running it again.
Also added a change in https://github.com/openvenues/libpostal/commit/df89387b5c6472335df9ce387de15f5f1b65af20 that should make crashes like that more graceful. That sparkey error is not very indicative of what's going on. When initialization of certain structs fails, libpostal will abort and use their destructors to clean up, where said destructors are all just written to check for NULL member pointers before deallocating them. However, most of the time the initial structs were allocated with malloc, so some of the member pointers would be uninitialized garbage memory if initialization failed early, causing crashes during cleanup. The latest change use calloc for such cases so the memory for the parent struct is zeroed out and thus the member pointers will be set to NULL before any of the subsequent initialization.

Agreed, utilities have to be modified very carefully.
However, the latest version still breaks on zero postcodes. Namely, it fails on https://github.com/openvenues/libpostal/blob/master/src/geodb.c#L103 since with the latest version of cstring_array_from_char_array the index returned by cstring_array_num_strings is one for the case where number of postal codes (str->n) was zero.
The version below fixes the issue somewhat differently:
cstring_array *cstring_array_from_char_array(char_array *str) {
    if (str == NULL) return NULL;
    if (str->n == 0)
        return cstring_array_new();

    cstring_array *array = malloc(sizeof(cstring_array));
    if (array == NULL) return NULL;

    array->str = str;
    array->indices = uint32_array_new_size(1);

    uint32_array_push(array->indices, 0);
    char *ptr = str->a;
    for (uint32_t i = 0; i < str->n - 1; i++, ptr++) {
        if (*ptr == '\0') {
            uint32_array_push(array->indices, i + 1);
        }
    }
    return array;
}

Corresponding PR is submitted below or you could test and review it from the code above.

Ah ok, thought num_strings was returning indices->n - 1 but the special cases of length zero and length one are handled elsewhere. That should be fine to merge.


Update README.md

PR Description 📜
Updated readme.md file as it had 34 and 35 games twice.
Fixes #712

Thank you soo much for contributing to our repository 💗

Thank you @SimranLahrani842 ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Thank you  @SimranLahrani842 , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


Inferno King Grimm

make compatibility if possible please?

Unfortunately, compatibility with Inferno King isn't something I can feasibly do. It's programmed with a completely different base - with the way Nightmare & Void is made, I'd have to basically remake and redesign the mod from the ground up but for IKG.


⚠ GitLab Server has degraded performance

In 509f861, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 11617 ms

Resolved: GitLab Server performance has improved in 0e3c57d.


Add a delay between sending alerts

Summary
Add a delay between sending alerts
Basic example
If you could make this happen, make it an option in main config and also another parameter to control the delay for which the alert is sent in milliseconds after the previous alert was sent.
Motivation
I have many of my alerts (over 60) set at once per bar on tradingview on daily charts. That means every day at market open i get multiple alerts that I want to have, but some of them don't reach telegram because of these errors
Jun 25 15:30:08 web pipenv[659]: WARNING:waitress.queue:Task queue depth is 1
Jun 25 15:30:09 web pipenv[659]: WARNING:waitress.queue:Task queue depth is 2
Jun 25 15:30:11 web pipenv[659]: WARNING:waitress.queue:Task queue depth is 3
Jun 25 15:30:11 web pipenv[659]: [X] Telegram Error:
Jun 25 15:30:11 web pipenv[659]: > Timed out

So Im guessing both flask/waitress and telegram times-out because of spam
One solution I've found is to host another webhook or make another bot but thats tedious and makes it hard to manage my 300+ alerts plus friends that are using the same webhook
Thank you for reading this, and thank you again for this awesome tradingview webkook for telegram

Hi,
It would be a better idea to wrap it around try and except. Hope that helps.

Due to inactive I am closing this issue.


refactor geocoder into more generic pieces

This would allow for more geocoders to be written in the future and keep all the google specific stuff isolated from any other geocoder implementations.

Was this issue completely addressed in #96 ?

In the sense that the Google geocoder is its own classes again, yes.
The only generic piece is the job decoder. Everything else is Google specific

In the sense that the Google geocoder is its own classes again, yes.
The only generic piece is the joson decoder. Everything else is Google specific

In the sense that the Google geocoder is its own classes again, yes.
The only generic piece is the joson decoder. Everything else is Google specific

Phone is causing problems with a simple reply


More custom-build-name stuff

Extend the custom names into the SNAPSHOT and REPO variables, to fully isolate images across builds.
NOTE WELL that if you set BUILDER_NAME=foo, then instead of getting an image named e.g. ambassador:latest, you'll now get foo:latest. make export will show you the correct information, of course.

Could you add the variable to the output of make env?

Updated the help. Help changes might be easier commit-by-commit?


Migrate Analytics Data

We are migrating our previous analytics from Google to our own solution. The current database has records for every assets, even those that haven't been viewed. We will only be counting records for those assets that have a view.

WDLL
We will export that data out of SS3 after migration is completed, then import into SS4. The export process will account for file vs. work views, and the changes in identifiers.

rake task to export existing statistics out of SS3 in an appropriate format (CSV, json, etc) that includes:
1 . Work views: the sum of all work views and views of any contained files for a given day
2. Downloads: downloads for each file for a given day
import task for SS4 that takes the exported file and imports the data into the database

the import task should account for noid-to-UUID translation


[Concurrency,docs] Update task local docs to use latest structured co…

This is a docs only change, adjusting the documentation ( https://developer.apple.com/documentation/swift/tasklocal ) to use the latest take on our unstructured Task APIs.

@swift-ci please smoke test

resolves rdar://80863888


x should be an Object

x should be an Object to use isAcceptable method

Thanks for the PR @MagiCarbon, but you're actually new-ing up x.isAcceptable, which would be undefined. You'd need to add parens following the new x (i.e. new x()).
Can you instead just make the bound name ZipCodeValidator and just create a separate variable named x and assign it a new ZipCodeValidator()?

hello, i've added the parentheses. sorry about that mistake.


Latin America Repository

perhaps it is of your interest, I leave the link We're also looking for Maintainers, it's a titanic task to keep up to date all countries. If you know posible volunteers please refer us.

Thanks for the link. Unfortunately, I'm unable to help parse the data manually -- all of the data in this repository is automated from electronic sources.
Rather than manually updating the data in your repository, I encourage you to direct your volunteers' resources towards keeping the relevant Wikipedia pages up to date. Not only is Wikipedia accessible to millions more than a GitHub repo, but Wikipedia pages with well-formatted tables can be automatically scraped for data. For example,  for Latin America, I'm able to automate data logging for Argentina, Bolivia, Chile and Peru from Wikipedia pages. This is an example of a well-formatted data source: https://en.wikipedia.org/wiki/2020_coronavirus_pandemic_in_Argentina#Statistics

Thanks for answer, I see.

Hi @ZurMaD, I just wanted to let you know that we are now using your dataset as one of our data sources. Great job persevering! Let me know if there's anything you need from my end in terms of collaborating further.

Thanks, I'll keep in mind, I'll share news if there's changes.


Automatically stop all live mocks at the end of each test case

If the user is using XCTest with OCMock, this registers a test observer that takes care
of stopping all live mocks appropriately.
For mocks that are created in +setUp, those will get stopped at the end of the suite.
For mocks that are created in -setUp or in test cases themselves, those will get
stopped at the end of the testcase.
While these mocks are being stopped and testcases/suites are being torndown, messages
sent to mocks are not going to trigger the exception about calling a mock after it has
had stopMocking called on it. This allows objects that may refer to mocks in dealloc
methods to be cleaned up in autoreleasepools or due to stopMocking being called
without the mocks throwing exceptions.
This should greatly simplify cleaning up mocks and remove a lot of potential leakage.
It also makes sure that class mocks that mock class methods will not persist across tests.

I think we could link this to issue #208

On Thu, Mar 26, 2020 at 10:43 AM imhuntingwabbits<EMAIL_ADDRESS>wrote:

@imhuntingwabbits commented on this pull request.
In Source/OCMock/OCMockObject.m
https://github.com/erikdoe/ocmock/pull/394#discussion_r398767673:

   }

}
+}

+#pragma mark  Mock cleanup recording
+
++ (void)recordAMockToStop:(OCMockObject *)mock {

[gCurrentMocksToStopRecorder addObject:mock];
+}

++ (void)removeAMockToStop:(OCMockObject *)mock {

[gCurrentMocksToStopRecorder removeObject:mock];
+}

++ (void)stopAllTestCaseMocks {

for (OCMockObject *mock in gTestCaseMocksToStop)

This needs to be customizable. It's not unusual for clients with high
concurrency to clean up mocks after the tests have finished.

Can you expand on what you mean with regards to customizable? Given that
this is a NSHashTable with weak pointer mapping, and it runs after the
tearDown methods are called should deal with most concerns. Can you give me
a concrete use case that you've seen where this wouldn't work?

The minimum bar is disabled, the nice to have bar would be I can invoke some method that opts instances out of this behavior.
Not all mocks are main thread (as xctest defines it) bound, mocks can (and in some cases are) validated off the main queue out of band with the tests.
You can't force those use cases in to the paradigm at the suite level or the test case level. Not everyone cares about XCTests run loop and some use cases register custom observers of their own to allow the threads to coalesce.

To be honest, I am not in favour of adding such invasive new behaviour to OCMock at this stage, especially not as on-by-default. While I have no data to back this up, I assume that most codebases using OCMock these days are several years old and have grown over time. Making the change suggested in this PR has the potential of causing any number of hard to diagnose issues in existing test stuites, as @imhuntingwabbits mentions.
I have kept #208 open as an enhancement, because I see how having a list of all mocks can help developers diagnose issues with their tests, discovering release cycles or a lingering mock for class methods for example. I can even see how a stopAllMocks method could be used, even though that would be trivial to implement if OCMock maintained a list of mocks, and even though it might be preferrable to fix the underlying issue rather than just stopping the mocks. The cases where you manually need to stop a mock should be rare.
If you were to change this PR to simply maintain a list of mocks, please double-check the coding conventions, e.g. no prefixing of global variables.


Allow defining signal per-injection

Solves #19

Hey @ahopkins, I'm having an issue with these tests, and I'm guessing that resetting and finalizing the signal router doesn't mix well with the testing client.
The logs can be seen here:

As you can see from the code here only the first log is output, and the second one isn't while serving a request. Thoughts on this?

Managed to work around it in https://github.com/sanic-org/sanic-ext/pull/127/commits/c43dea7af73fb96de9719d3c30c045a0e03c2dab, only we can't register signals dynamically

@prryplatypus Doesn't look like that will work. Global variables is not the solution.

What is the problem? Why can we not just register it as a tuple, then have a signal factory that takes the event as an input?

I don't think there's any global variables in the workaround!
The issue seems to be that the signals don't get properly registered if it is done from within another signal handler.
As you can see from the logs, the signals technically got registered, but when a request was served, it acted as if no injection signal handlers had been defined.
Therefore what the workaround does is define both signal handlers always and within them only look for injections if there is any defined for their signal they are handling.

Per discussion with @ahopkins, we're going to reduce the scope of this PR for now and simply make it a config value that applies to all injections. This can change in the future when we make it easier to dynamically add signal handlers from within other signal handlers.
All changes up to now reverted in https://github.com/sanic-org/sanic-ext/pull/127/commits/1d96f4a3b8deaca85b5318758bb7cca24270f8ee.


Add Conditional Routing to Your Integration Flow

Tutorial URL: https://developers.sap.com/tutorials/cp-integration-add-conditional-routing.html
STEP 6 Check the mail received:
You should have received the following mail:

I do not receive the mail like that.  I still have the order-element inside the order. How do you remove that?  There is not step in that tutorial that explains that.    When later configure this to convert to CSV-format the code-value is not in the payload!
This is my mail result =
<orders xmlns:dis="http://camel.apache.org/cxf/jaxws/dispatch" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <order> <orderID>BS00010023</orderID><order xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">KWADRIT<orderID>BS00010023</orderID></order> <OrderDate>11.04.2019</OrderDate> <

Hello,
We are working on overhauling the entire tutorial series and will publish the updates shortly. Apologies for the delay in response.
Thanks & Best Regards, Gautham

Thank you for your feedback. The issue seems to be resolved, so I am closing the issue.
If you still have questions, feel free to reopen the issue.


bug: chart labels are not updated properly if parsing object data

Expected Behavior
Chart data labels should be updated without problems.
Current Behavior
When I update a chart that uses parsing with xAxisKey and yAxisKey with existing data using a new set of data, it merges new labels with old ones instead of cleaning old labels.
Possible Solution
Clear labels array when setting new data in the case of array data and object data (not primitive).
Steps to Reproduce
https://codepen.io/catchabus/pen/abwdOBQ?editors=1111
Environment

Chart.js version: 3.5.0
Browser name and version: Google Chrome 92.0.4515.159 (Official Build) (64-bit)
Link to your project:

As stated in the template please provide a working example of your problem

Provide a link to a live example. Bug reports MUST be submitted with an
interactive example (https://codepen.io/pen/?template=BapRepQ).

As stated in the template please provide a working example of your problem

Provide a link to a live example. Bug reports MUST be submitted with an
interactive example (https://codepen.io/pen/?template=BapRepQ).

I added a working example. Thanks for pointing out!

A "workaround" that hides the unused labels is to use bounds: 'data'. This probably does not work if there are same labels in both sets.
https://codepen.io/kurkle/pen/jOwrMPX


oslc-client uses a dependency with modified AGPL license

StandardError.js is released under a Lesser GNU Affero General Public License. There is no such license, it was made by the author by merging LGPL and AGPL clauses to create a franken-LAGPL. oslc-client shall stop using this library until GNU releases such a license and it becomes OSI/FSF-approved or the author switches to EUPL, for example.

I think that even if https://github.com/moll/js-standard-error/issues/4 is resolved with a switch to EUPL, this will still require further action from us and require a license of this lib to be changed to one of:

‘Compatible Licences’ according to Article 5 EUPL are:
— GNU General Public License (GPL) v. 2, v. 3
— GNU Affero General Public License (AGPL) v. 3
— Open Software License (OSL) v. 2.1, v. 3.0
— Eclipse Public License (EPL) v. 1.0
— CeCILL v. 2.0, v. 2.1
— Mozilla Public Licence (MPL) v. 2
— GNU Lesser General Public Licence (LGPL) v. 2.1, v. 3
— Creative Commons Attribution-ShareAlike v. 3.0 Unported (CC BY-SA 3.0) for works other than software
— European Union Public Licence (EUPL) v. 1.1, v. 1.2
— Québec Free and Open-Source Licence — Reciprocity (LiLiQ-R) or Strong Reciprocity (LiLiQ-R+)

EPL would probably be the best but still may be a bit tricky to do.


Allow reassignment of exec.Cmd Stdout and Stderr

Sometimes the command that's executed can print unnecessary things to standard output and standard error. For example, on my system xdg-open first prints a segfault, then says no method is available for opening the file, but the file is opened in my browser anyway.
So it'd be nice to be able to reassign the executed command's Stdout and Stderr to something other than the defaults.

SGTM. Thanks.


Add VDC wallet info to the VDC dashboard and the deployer

Allow the user to see the info of the prepaid wallet

Verified on development_vdc

Verified on development_vdc


Adaptive output and contextual dialogue capabilities of text-generation-inference

System Info
System Info
HL-SMI Version: hl-1.11.0-fw-<IP_ADDRESS>
Driver Version: 1.11.0-e6eb0fd

Information

[X] The official example scripts
[ ] My own modified scripts

Tasks

[ ] An officially supported task in the examples folder (such as GLUE/SQuAD, ...)
[ ] My own task or dataset (give details below)

Reproduction
Deploy the Llama-2-7b-chat-hf model through text-generation-inference, but there is no adaptive output when using the following command, instead the input and output size are max_new_tokens.
curl <IP_ADDRESS>:8080/generate_stream -X POST -d '{"inputs":"What is Deep Learning?","parameters":{"max_new_tokens":200}}'     -H 'Content-Type: application/json'

Also, how to implement chat functionality with context? Similar to GPT4, it can adaptively output appropriate content and has the ability to dialogue with context.
Expected behavior

adaptive output
dialogue with context

@MLikeWater What do you mean exactly by adaptive output?


geographic_info: 1.0.5-1 in 'humble/distribution.yaml' [bloom]

Increasing version of package(s) in repository geographic_info to 1.0.5-1:

upstream repository: https://github.com/ros-geographic-info/geographic_info.git
release repository: https://github.com/ros2-gbp/geographic_info-release.git
distro file: humble/distribution.yaml
bloom version: 0.11.2
previous version for package: 1.0.4-6

This pull request has been mentioned on ROS Discourse. There might be relevant details there:
https://discourse.ros.org/t/preparing-for-humble-sync-and-patch-release-2023-04-28/31105/3


Create python-app.yml

It looks like you forgot to adapt the template to our needs. You can commit my suggestions in the github web interface, or push other ones, as you prefer.

that's the first time I'm doing it, I made the commit on github but I didn't had it in local so I couldn't modify it properly at the time


documentation for Mechanize::Agent#allowed_error_codes

The changelog mentions addition of Mechanize::Agent#allowed_error_codes.
However, I was unable to locate this feature or its usage in the docs or guides.
How does one go about updating these docs?
I am currently using this feature like this and it is working:
    @agent  = Mechanize.new do |mech|
      mech.agent.allowed_error_codes << 503
    end

@drbrain @tenderlove What can we do to update the doc on docs.seattlerb.org in a timely manner?  It is currently so outdated.

There is also mechanize.rubyforge.org, but as you know rubyforge will be shut down eventually.
Should we point to http://www.rubydoc.info/gems/mechanize/Mechanize for now?

Aside from where to host our latest docs, I slightly improve rdoc for the attribute in b1fcc004.

There is also mechanize.rubyforge.org, but as you know rubyforge will be shut down eventually.
Should we point to http://www.rubydoc.info/gems/mechanize/Mechanize for now?

I think so yes. I've change the GitHub Homepage URL and I think we can tweak the README too


[SPARK-46205][CORE] Improve PersistenceEngine performance with KryoSerializer

What changes were proposed in this pull request?
This PR aims to improve PersistenceEngine performance with KryoSerializer via introducing a new configuration, spark.deploy.recoverySerializer.
Why are the changes needed?
Allow users to choose a better serializer to get a better performance in their environment. Especially, KryoSerializer is about 3x faster than JavaSerializer with FileSystemPersistenceEngine.
================================================================================================
PersistenceEngineBenchmark
================================================================================================

OpenJDK 64-Bit Server VM 21.0.1+12-LTS on Linux 5.15.0-1051-azure
AMD EPYC 7763 64-Core Processor
1000 Workers:                                    Best Time(ms)   Avg Time(ms)   Stdev(ms)    Rate(M/s)   Per Row(ns)   Relative
-------------------------------------------------------------------------------------------------------------------------------
ZooKeeperPersistenceEngine with JavaSerializer            1100           1255         150          0.0     1099532.9       1.0X
ZooKeeperPersistenceEngine with KryoSerializer             946            967          20          0.0      946367.3       1.2X
FileSystemPersistenceEngine with JavaSerializer            218            223           4          0.0      217851.5       5.0X
FileSystemPersistenceEngine with KryoSerializer             79             87          12          0.0       78611.1      14.0X
BlackHolePersistenceEngine                                   0              0           0         42.0          23.8   46191.1X

Does this PR introduce any user-facing change?
No. The default behavior is the same.
How was this patch tested?
Pass the CIs with the new added test cases.
Was this patch authored or co-authored using generative AI tooling?
No.

I'm going to update the benchmark files.

https://github.com/dongjoon-hyun/spark/actions/runs/7066098422 (Java 17)
https://github.com/dongjoon-hyun/spark/actions/runs/7066103306 (Java 21)

Could you review this when you have a chance, @yaooqinn , @beliefer , @LuciferYang ?

Thank you so much, @beliefer .
Merged to master for Apache Spark 4.0.0.


Dockerfile missing ?

running 'make' says  ./GDPR/Dockerfile : no such file or directory.

Hi,
Yes, the Docker install was contributed but I never used or understood it myself.  So, let us say it is currently deprecated.  I do an install using MAMP and git cloning. https://github.com/CommonAccord/cmacc-host/blob/master/README.md


Added Support to ECC certificates

Removed unnecessary guards to allow ECC keys to be used in addition
to RSA keys. No other change was necessary in order to support ECC certificates.
The CA unit tests were extended to feature ECC certificates
Extended CSR unit tests to use ECC keys
Extended X509/verification tests to use ECC key certificates

I agree that it would be nice to have as little replicated tests as possible. But reworking the x509 and verification tests to value parametrized would represent a large amount of work without adding much value right now. Maybe we can do in the future, out of the scope of this PR.


New version: TeamSpeakSystems.TeamSpeakClient version 3.6.0

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/109808&drop=dogfoodAlpha

@Trenly what was the dependency needed for last time in #81758 ? The PR validated fine here.

I'm not sure. #81758 was just to update the dependency that was already there since the VCRedist packages were renamed/restructured


is it alive?

How should it work? Only shows template message on pressing the extension button

This was just a test/proof-of-concept, but someone else made a proper extension at https://chrome.google.com/webstore/detail/set-character-encoding/bpojelgakakmcfmjfilgdlmhefphglae


[SSR] Material Bread x NextJS

Describe your feature request
Provide Support React SSR using NextJS

Here the repo https://github.com/hedikasmanto/material-bread-next-example
and ListItem / Hoverableissue u can found on #292

@hedikasmanto This works great! I created a PR for fixing the Hoverable layout #297. I'd love to include your example repo in the documentation, would that be ok?

Yes.. Please include the example in the documentation, and I will close this issue


Internal Server Error When Fetching Logs From Inline Workflows

Pre-requisites

[X] I have double-checked my configuration
[X] I can confirm the issues exists when I tested with :latest
[ ] I'd like to contribute the fix myself (see contributing guide)

What happened/what you expected to happen?
What happened?
When I run a workflow that contains an inline component, I cannot view the logs for that container. The Argo UI shows an "Internal Server Error". However, when I check the minio browser, I can find the main.log file and retrieve it's contents without any issues.
This issue only occurs on inline components. When running other types of templates, I don't see this issue.
For example, these workflows run fine and I can see the logs in the Argo UI:
hello-world
steps
But, these workflows recreate the issue:
steps-inline-workflow
dag-inline-workflow
This issue also occurs with actual artifacts coming from containers. For example I can run a simple argosay container and generate a .txt file that shows up in the Argo UI. However if I move that container into an inline definition, the logs, and the artifact itself throw errors in the UI (while showing up just fine in minio).
What you expected to happen?
I expected the logs and the artifacts to be accessible from the Argo UI despite the container being defined as inline.
Version
3.4.1 and latest
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-
  labels:
    workflows.argoproj.io/archive-strategy: "false"
spec:
  entrypoint: main
  templates:
  - name: main
    steps:
      - - name: a
          inline:
            container:
              image: argoproj/argosay:v2
              args: [ echo, hello, /mnt/file.txt ]
            outputs:
              artifacts:
                - name: file
                  path: /mnt/file.txt
                  archive:
                    none: { }

Logs from the workflow controller
time="2022-10-14T18:50:19.077Z" level=info msg="Update leases 200"
time="2022-10-14T18:50:24.082Z" level=info msg="Get leases 200"
time="2022-10-14T18:50:24.087Z" level=info msg="Update leases 200"
time="2022-10-14T18:50:29.093Z" level=info msg="Get leases 200"
time="2022-10-14T18:50:29.097Z" level=info msg="Update leases 200"
time="2022-10-14T18:50:34.101Z" level=info msg="Get leases 200"
time="2022-10-14T18:50:34.106Z" level=info msg="Update leases 200"
time="2022-10-14T18:50:36.217Z" level=info msg="Processing workflow" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:36.221Z" level=info msg="Get configmaps 200"
time="2022-10-14T18:50:36.221Z" level=info msg="resolved artifact repository" artifactRepositoryRef="quilter-dev-sergiy/#"
time="2022-10-14T18:50:36.221Z" level=info msg="Updated phase  -> Running" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:36.221Z" level=info msg="Steps node hello-world-62qpl initialized Running" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:36.221Z" level=info msg="StepGroup node hello-world-62qpl-2899326954 initialized Running" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:36.222Z" level=info msg="Pod node hello-world-62qpl-75685911 initialized Pending" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:36.226Z" level=info msg="Create events 201"
time="2022-10-14T18:50:36.246Z" level=info msg="Create pods 201"
time="2022-10-14T18:50:36.247Z" level=info msg="Created pod: hello-world-62qpl[0].a (hello-world-62qpl--75685911)" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:36.248Z" level=info msg="Workflow step group node hello-world-62qpl-2899326954 not yet completed" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:36.248Z" level=info msg="TaskSet Reconciliation" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:36.248Z" level=info msg=reconcileAgentPod namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:36.248Z" level=info msg="Workflow to be dehydrated" Workflow Size=1661
time="2022-10-14T18:50:36.255Z" level=info msg="Update workflows 200"
time="2022-10-14T18:50:36.255Z" level=info msg="Workflow update successful" namespace=quilter-dev-sergiy phase=Running resourceVersion=494580351 workflow=hello-world-62qpl
time="2022-10-14T18:50:36.263Z" level=info msg="Create events 201"
time="2022-10-14T18:50:36.268Z" level=info msg="Create events 201"
time="2022-10-14T18:50:39.111Z" level=info msg="Get leases 200"
time="2022-10-14T18:50:39.115Z" level=info msg="Update leases 200"
time="2022-10-14T18:50:44.119Z" level=info msg="Get leases 200"
time="2022-10-14T18:50:44.123Z" level=info msg="Update leases 200"
time="2022-10-14T18:50:46.248Z" level=info msg="Processing workflow" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.249Z" level=info msg="Task-result reconciliation" namespace=quilter-dev-sergiy numObjs=0 workflow=hello-world-62qpl
time="2022-10-14T18:50:46.249Z" level=warning msg="workflow uses legacy/insecure pod patch, see https://argoproj.github.io/argo-workflows/workflow-rbac/" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.249Z" level=info msg="node changed" namespace=quilter-dev-sergiy new.message= new.phase=Succeeded new.progress=0/1 nodeID=hello-world-62qpl-75685911 old.message= old.phase=Pending old.progress=0/1 workflow=hello-world-62qpl
time="2022-10-14T18:50:46.249Z" level=info msg="Step group node hello-world-62qpl-2899326954 successful" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.249Z" level=info msg="node hello-world-62qpl-2899326954 phase Running -> Succeeded" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.249Z" level=info msg="node hello-world-62qpl-2899326954 finished: 2022-10-14 18:50:46.249907957 +0000 UTC" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.249Z" level=info msg="Outbound nodes of hello-world-62qpl-75685911 is [hello-world-62qpl-75685911]" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.249Z" level=info msg="Outbound nodes of hello-world-62qpl is [hello-world-62qpl-75685911]" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.249Z" level=info msg="node hello-world-62qpl phase Running -> Succeeded" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.250Z" level=info msg="node hello-world-62qpl finished: 2022-10-14 18:50:46.249998697 +0000 UTC" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.250Z" level=info msg="Checking daemoned children of hello-world-62qpl" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.250Z" level=info msg="TaskSet Reconciliation" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.250Z" level=info msg=reconcileAgentPod namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.250Z" level=info msg="Updated phase Running -> Succeeded" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.250Z" level=info msg="Marking workflow completed" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.250Z" level=info msg="Marking workflow as pending archiving" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.250Z" level=info msg="Checking daemoned children of " namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.250Z" level=info msg="Workflow to be dehydrated" Workflow Size=2376
time="2022-10-14T18:50:46.256Z" level=info msg="Create events 201"
time="2022-10-14T18:50:46.256Z" level=info msg="cleaning up pod" action=deletePod key=quilter-dev-sergiy/hello-world-62qpl-1340600742-agent/deletePod
time="2022-10-14T18:50:46.259Z" level=info msg="Update workflows 200"
time="2022-10-14T18:50:46.260Z" level=info msg="Workflow update successful" namespace=quilter-dev-sergiy phase=Succeeded resourceVersion=494580468 workflow=hello-world-62qpl
time="2022-10-14T18:50:46.261Z" level=info msg="Delete pods 404"
time="2022-10-14T18:50:46.263Z" level=info msg="DeleteCollection workflowtaskresults 403"
time="2022-10-14T18:50:46.263Z" level=warning msg="failed to delete task-results" error="workflowtaskresults.argoproj.io is forbidden: User \"system:serviceaccount:quilter-dev-sergiy:argo\" cannot deletecollection resource \"workflowtaskresults\" in API group \"argoproj.io\" in the namespace \"quilter-dev-sergiy\"" namespace=quilter-dev-sergiy workflow=hello-world-62qpl
time="2022-10-14T18:50:46.264Z" level=info msg="archiving workflow" namespace=quilter-dev-sergiy uid=bf991edf-8f3c-476e-9e53-9eb88785748d workflow=hello-world-62qpl
time="2022-10-14T18:50:46.265Z" level=info msg="Create events 201"
time="2022-10-14T18:50:46.268Z" level=info msg="Create events 201"
time="2022-10-14T18:50:46.268Z" level=info msg="cleaning up pod" action=labelPodCompleted key=quilter-dev-sergiy/hello-world-62qpl--75685911/labelPodCompleted
time="2022-10-14T18:50:46.273Z" level=info msg="Create events 201"

Logs from in your workflow's wait container
time="2022-10-14T18:50:40.662Z" level=info msg="S3 Save path: /tmp/argo/outputs/logs/main.log, key: hello-world-62qpl/hello-world-62qpl--75685911/main.log"
time="2022-10-14T18:50:40.662Z" level=info msg="Creating minio client using static credentials" endpoint="minio:9000"
time="2022-10-14T18:50:40.663Z" level=info msg="Saving file to s3" bucket=my-bucket endpoint="minio:9000" key=hello-world-62qpl/hello-world-62qpl--75685911/main.log path=/tmp/argo/outputs/logs/main.log
time="2022-10-14T18:50:40.671Z" level=info msg="Save artifact" artifactName=main-logs duration=8.212867ms error="<nil>" key=hello-world-62qpl/hello-world-62qpl--75685911/main.log
time="2022-10-14T18:50:40.671Z" level=info msg="not deleting local artifact" localArtPath=/tmp/argo/outputs/logs/main.log
time="2022-10-14T18:50:40.671Z" level=info msg="Successfully saved file: /tmp/argo/outputs/logs/main.log"
time="2022-10-14T18:50:40.677Z" level=info msg="Create workflowtaskresults 403"
time="2022-10-14T18:50:40.678Z" level=warning msg="failed to patch task set, falling back to legacy/insecure pod patch, see https://argoproj.github.io/argo-workflows/workflow-rbac/" error="workflowtaskresults.argoproj.io is forbidden: User \"system:serviceaccount:quilter-dev-sergiy:default\" cannot create resource \"workflowtaskresults\" in API group \"argoproj.io\" in the namespace \"quilter-dev-sergiy\""
time="2022-10-14T18:50:40.695Z" level=info msg="Patch pods 200"
time="2022-10-14T18:50:40.700Z" level=info msg="Alloc=11442 TotalAlloc=17630 Sys=22738 NumGC=5 Goroutines=12"

workflowtaskresults.argoproj.io is forbidden: User "system:serviceaccount:quilter-dev-sergiy:default" cannot create resource "workflowtaskresults" in API group "argoproj.io" in the namespace
This indicates that you are missing some permissions on your service account.

@terrytangyuan thanks for the quick response! I fixed that permissions issue on my service account, but unfortunately the issue I described has not been resolved :(
Here are the new logs from the wait container after the permissions fix has been applied:
time="2022-10-14T19:27:36.949Z" level=info msg="Creating minio client using static credentials" endpoint="minio:9000"
time="2022-10-14T19:27:36.949Z" level=info msg="Saving file to s3" bucket=my-bucket endpoint="minio:9000" key=hello-world-k77cd/hello-world-k77cd--2870507246/main.log path=/tmp/argo/outputs/logs/main.log
time="2022-10-14T19:27:36.959Z" level=info msg="Save artifact" artifactName=main-logs duration=9.670205ms error="<nil>" key=hello-world-k77cd/hello-world-k77cd--2870507246/main.log
time="2022-10-14T19:27:36.959Z" level=info msg="not deleting local artifact" localArtPath=/tmp/argo/outputs/logs/main.log
time="2022-10-14T19:27:36.959Z" level=info msg="Successfully saved file: /tmp/argo/outputs/logs/main.log"
time="2022-10-14T19:27:36.969Z" level=info msg="Create workflowtaskresults 201"
time="2022-10-14T19:27:36.970Z" level=info msg="stopping progress monitor (context done)" error="context canceled"
time="2022-10-14T19:27:36.970Z" level=info msg="Deadline monitor stopped"
time="2022-10-14T19:27:36.971Z" level=info msg="Alloc=10930 TotalAlloc=17048 Sys=22482 NumGC=5 Goroutines=12"

For a little more info, here is the traceback that the Argo UI provides when trying to access the artifact:
Stack Trace
TypeError: Cannot read properties of undefined (reading 'archiveLocation')
    at http://localhost:8081/main.818cf538d746370f7ba5.js:291:828309
    at os (http://localhost:8081/main.818cf538d746370f7ba5.js:261:83209)
    at gl (http://localhost:8081/main.818cf538d746370f7ba5.js:261:102288)
    at t.unstable_runWithPriority (http://localhost:8081/main.818cf538d746370f7ba5.js:269:3844)
    at Vo (http://localhost:8081/main.818cf538d746370f7ba5.js:261:45024)
    at ml (http://localhost:8081/main.818cf538d746370f7ba5.js:261:102047)
    at Xs (http://localhost:8081/main.818cf538d746370f7ba5.js:261:93596)
    at http://localhost:8081/main.818cf538d746370f7ba5.js:261:45315
    at t.unstable_runWithPriority (http://localhost:8081/main.818cf538d746370f7ba5.js:269:3844)
    at Vo (http://localhost:8081/main.818cf538d746370f7ba5.js:261:45024)
Component Stack

    in Unknown
    in t
    in t
    in Unknown
    in t
    in t
    in t
    in div
    in Unknown
    in t
    in t
    in Unknown
    in t

I can reproduce it with examples/dag-inline-workflow.yaml
 in K3D setup.
Fixed: https://github.com/argoproj/argo-workflows/pull/9853

@ibotdotout thanks so much for the quick fix, your screen captures are exactly what I saw. Appreciate the fast response!
One request: could you double check that the artifacts generated in inline workflows are also fixed? I observed that both the logs, and the artifact files suffered from the issue (see the custom workflow in the description). Hopefully the same fix applied to both issues.

@ibotdotout thanks so much for the quick fix, your screen captures are exactly what I saw. Appreciate the fast response!
One request: could you double check that the artifacts generated in inline workflows are also fixed? I observed that both the logs, and the artifact files suffered from the issue (see the custom workflow in the description). Hopefully the same fix applied to both issues.

Thanks for pointing out, I missed this case. Checked and updated the fixed in PR https://github.com/argoproj/argo-workflows/pull/9853.


TCP support

This implements TCP support in the way I described in #34.
Brief summary:

I've done this in a backwards-compatible way, with UDP as the default network protocol.
To use TCP, call client.SetNetworkProtocol(osc.TCP) or server.SetNetworkProtocol(osc.TCP).
Incidental: I added a server.CloseConnection function to facilitate testing and give users the ability to forcibly stop a running server.

ListenAndServe includes defer server.CloseConnection(), ensuring that the connection it creates is closed in the event of an interruption or error.

I also made some adjustments and improvements to the tests and examples. I did some thorough testing involving this branch of go-osc and a similar branch of JavaOSC where I've just finished implementing TCP support. I tested all the permutations of TCP vs. UDP, Go client vs. Java client, Go server vs. Java server, and everything is looking great, as far as I can tell.
Feedback welcome, of course. I realize this is a big change set! Let me know if there's anything I can do to make reviewing it easier.
Thanks for all the excellent work on go-osc!

Hi again @daveyarwood,
I had some time on a flight last night to have a go at this. This is what I came up with: https://github.com/daveyarwood/go-osc/compare/tcp-support...glynternet:gh/functional-options
Using functional options (kind of Go's solution to method overloading) we can keep the implementations of the server a little more abstracted away from the network protocol.
This way we can not have to add an extra ServeTCP function. It would retain backwards compatibility with most uses but would require some people to change their use if they're directly using the Receive method. Perhaps if @hypebeast is interested we could add some semantic versioning to the repo?
I'd also be happy to upgrade it to use go modules, which has much better support for versioning.
Functional options: https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis
I've only done it for the server, not the client, this would be a follow up.
Can you let me know what you think and i'll be happy to make the rest of the changes to support it for the client.

Wow, I really like this idea! I'm new-ish to Go and hadn't heard of functional options. I'm totally sold on this approach.
The one thing I would suggest is that perhaps
type Option func(*Server)

should be
type Option func(*Server) error

I can imagine some configuration option that potentially results in an error, and we would want NewServer to return an error if the option does.
I guess it would be a breaking change to change the return type of NewServer from *Server to (*Server, error), but perhaps that would be something that we could do if we move toward semantic versioning?

Glad you're into it.
I agree with Option returning an error.
I won't be able to have another go at any of this for another couple of weeks, to be honest.
Do feel free to merge what I've done and have a go at tidying it up plus implementing for the client. If you've also not got the time then I'll try to finish it all up in a couple of weeks.

I can find some time to work on it. Thanks for the work you've done so far!

OK, I followed @glynternet's lead and did a similar thing for the client. I like where we've arrived on this. Ready for re-review.

@daveyarwood any chance you could please split this PR up into separate orthogonal components?

Debugging Dispatcher and non-tcp examples functionality.
Message Randomisation (could be combined with above)
TCP Support (with supporting addition to debugger etc.)

I'm hoping that we can be mindful of @hypebeast 's time and efforts. This PR is almost 1000 lines of changes as it is and I feel it would be best if we can get it through in smaller parts.
I will, unfortunately, be taking a long-distance flight this weekend <- silver lining being that I should be able to take a look at some/all of this now that we have the TCP mechanism looking how we'd like it.

@glynternet I'm happy to do that, but as a series of PRs that build upon previous ones. Would that be OK? I certainly think it would make reviewing my changes easier, because the diff of each PR would be small and easy to read and discuss.
My concern is that if I tried to make a handful of completely separate PRs, it might lead us into merge conflict hell.

OK - I took the time to break this PR apart into several smaller PRs.
Review and merge in this order:
#39 Test improvements; add server.CloseConnection method
#40 Add a random string argument to message dispatch/receive tests
#41 Improve example server and client for better debugging
#42 TCP support
As each PR is merged, the diffs of the ones that follow will get smaller, because each one builds on the last (technically, I was able to branch #41 right off of master, so if you want, you can review and merge that one earlier)
Closing this PR now, as it's a near duplicate of #42.


[enhancement] detect utmp access privilege

server should detect utmp access privilege before update utmp database.

verified.


cargo fix: Pass --all-targets to cargo fix by default

This'll help fix as much code as possible, including tests!
Closes #5795

r? @matklad
(rust_highfive has picked a reviewer for you, use r? to override)

I think you mean fixes #5739.
Are there precedents of irregularity in compile option passing between commands?

I think you mean fixes #5739.

Oops, indeed!

Are there precedents of irregularity in compile option passing between commands?

I remembered yesterday that cargo fix works on the whole project, so sort of!

@bors: r+

:pushpin: Commit ff8a95e296c203f614d60aa6ed454129c2627476 has been approved by alexcrichton

:hourglass: Testing commit ff8a95e296c203f614d60aa6ed454129c2627476 with merge af6e295d209dd9c9010017f83ff1ef22d6a16181...


An uncaught throwable was detected in the writing thread: Attempt to get length of null array

After updating the version (2.10 -> 2.11), the connection is broken with the message "An uncaught throwable was detected in the writing thread: Attempt to get length of null array" after a few seconds. In this case, two identical methods are called simultaneously .onUnexpectedError and .onError. This is not good.

Reportedly, PR #222 fixes this issue. nv-websocket-client 2.12 including #PR 222 has been released.


Add LM Studio Support

I really like this project, but I prefer to run my local models through LM-Studio rather than Ollama. Primarly because of their simple-to-use GUI that tells me exactly, what models can run / what quantitation I need to run these models on my GPU. If you guys have time, please add LM Studio support to this project. Thanks in advance.

I haven't used it, will take a look.  Community contributions are also very welcome if anyone feels inspired to dive into the source or ask Devin to do it 😜

https://github.com/wandb/openui/issues/91#issuecomment-2099240831
File server.py in the folder backend/openui - line 68
Set the base_url to whatever you wish.
openai = AsyncOpenAI(
    base_url="https://YOUR-URL/v1"
)  # AsyncOpenAI(base_url="http://<IP_ADDRESS>:11434/v1")
ollama = AsyncClient()
router = APIRouter()
session_store = DBSessionStore()
github_sso = GithubSSO(
    config.GITHUB_CLIENT_ID, config.GITHUB_CLIENT_SECRET, f"{config.HOST}/v1/callback"
)

#91 (comment)
File server.py in the folder backend/openui - line 68
Set the base_url to whatever you wish.
openai = AsyncOpenAI(
    base_url="https://YOUR-URL/v1"
)  # AsyncOpenAI(base_url="http://<IP_ADDRESS>:11434/v1")
ollama = AsyncClient()
router = APIRouter()
session_store = DBSessionStore()
github_sso = GithubSSO(
    config.GITHUB_CLIENT_ID, config.GITHUB_CLIENT_SECRET, f"{config.HOST}/v1/callback"
)

Did not work for me. Could you please explain further? I set it like this

But got:

Update
I managed to make it work with lmstudio, follow the instructions below:

open the server.py in the backend directory of your openui folder
modify from lines 68, just copy and paste these:

openai = AsyncOpenAI(
base_url="http://localhost:1234/v1"
)

now type:

(openui) H:\openui\backend>set OPENAI_API_KEY=http://localhost:1234/v1
(openui) H:\openui\backend>echo %OPENAI_API_KEY%
http://localhost:1234/v1

start your local server in lmstudio (chat python) with a model loaded on.

(openui) H:\openui\backend>python -m openui

ENJOY


Critical vulnerabilities reported for cypress/factory

Hello,
I'm using the latest cypress/factory:4.0.2 image to run our tests in CI/CD pipelines. When building our image we are also scanning it for known security vulnerabilities with wiz.
I am using the following Node, Chrome and Cypress versions:
ARG NODE_VERSION='20.14.0'
ARG CHROME_VERSION='126.0.6478.55-1'
ARG CYPRESS_VERSION='13.11.0'

It finds a lot of outdated versions and security issues:
Evaluated policies: Default secrets policy, Default sensitive data policy, Default vulnerabilities policy
Failed policy: Default vulnerabilities policy
Vulnerable packages: CRITICAL: 6, HIGH: 29, MEDIUM: 64, LOW: 41, INFORMATIONAL: 0
    Total: 140
Vulnerabilities: CRITICAL: 6, HIGH: 35, MEDIUM: 149, LOW: 176, INFORMATIONAL: 7
    Total: 373, out of which 45 are fixable
Directories scanned: 25829, Files scanned: 210985
Scan results: FAILED. Container image does not meet policy requirements

Here's a text file with all the scan results:
scan-cypress.txt

Right, but Cypress uses some node modules that have Critical issues:
Name: underscore, Version: 1.6.0, Path: /root/.cache/Cypress/13.11.0/Cypress/resources/app/node_modules/underscore/package.json
            Failed policy: Default vulnerabilities policy
            CVE-2021-23358, Severity: CRITICAL, Source: https://github.com/advisories/GHSA-cf4h-3jhx-xvhq
                CVSS score: 7.2, CVSS exploitability score: 1.2
                Fixed version: 1.12.1

Name: loader-utils, Version: 1.4.0, Path: /root/.cache/Cypress/13.11.0/Cypress/resources/app/node_modules/loader-utils/package.json
            Failed policy: Default vulnerabilities policy
            CVE-2022-37601, Severity: CRITICAL, Source: https://github.com/advisories/GHSA-76p3-8jx3-jpfq
                CVSS score: 9.8, CVSS exploitability score: 3.9
                Fixed version: 1.4.1
                Has public exploit
            CVE-2022-37599, Severity: HIGH, Source: https://github.com/advisories/GHSA-hhq3-ff78-jv3g
                CVSS score: 7.5, CVSS exploitability score: 3.9
                Fixed version: 1.4.2
            CVE-2022-37603, Severity: HIGH, Source: https://github.com/advisories/GHSA-3rfm-jhwj-7488
                CVSS score: 7.5, CVSS exploitability score: 3.9
                Fixed version: 1.4.2
                Has public exploit

Name: flat, Version: 4.1.1, Path: /root/.cache/Cypress/13.11.0/Cypress/resources/app/node_modules/flat/package.json
            Failed policy: Default vulnerabilities policy
            CVE-2020-36632, Severity: CRITICAL, Source: https://github.com/advisories/GHSA-2j2x-2gpw-g8fm
                CVSS score: 9.8, CVSS exploitability score: 3.9
                Fixed version: 5.0.1

@sergiubologa
I can only give the same comment that I gave in the other issue:

These are not vulnerabilities which can be fixed directly by cypress/included Docker images. Any fixes would need to come from the upstream repo https://github.com/cypress-io/cypress. The Cypress binary is installed as-provided and it is not manipulated by the Cypress Docker image process.

Thank you

There are separate issues for each of the vulnerabilities you mention:

https://github.com/cypress-io/cypress/issues/28207
https://github.com/cypress-io/cypress/issues/28208
https://github.com/cypress-io/cypress/issues/28196
https://github.com/cypress-io/cypress/issues/28193
https://github.com/cypress-io/cypress/issues/27763

I'm going to close this issue now as the follow-up needs to be done through https://github.com/cypress-io/cypress. As soon as any new Cypress version is released, a new cypress/included Cypress Docker image version is also released. So if there are vulnerability fixes they are dealt with as best and as fast as possible.

@sergiubologa
I have linked the existing reports back to this issue. You can subscribe to the issues if you want to follow their resolution.


PLAT-77708: Reassigned several newly supported languages

Checklist

[x] I have read and understand the contribution guide
[x] A CHANGELOG entry is included
[x] At least one test case is included for this feature or bug fix
[x] Documentation was added or is not needed
[ ] This is an API breaking change

Issue Resolved / Feature Added
The system font now supports more language scripts
Resolution
Updated several languages to get "non-latin" overrides so they get the correct font assignments.
Also added a basic font/language checking sample in QA Sampler.

@webOS101, you'll need to clarify what your difficulties are. The fallbacks are indeed applied in the fonts definition file, and locale-specific fonts are applied in fontGenerator. What are you seeing? Do you see a better way to "couple" things?

Aren't certain font or CSS properties applied depending on whether it's a latin or non-latin locale?

That is correct.

So, when the new fonts are not used, the following locales:  'el', 'bg', 'mk', 'mn', 'ru', 'uk', 'kk' will now render differently, will they not?

They will indeed be rendered differently.
Followup question: What scenario are you referring to where the new fonts will not be used?

I was thinking of cases of using Moonstone in the browser.

You're describing a scenario which: runs a moonstone app in a generic Chrome browser, without LG TV fonts, but with a locale specified as one of the above, and are concerned that Miso or Museo Sans (the old fonts) don't have the correct glyphs available. The OS will provide the specific missing glyph in this case.

:nothingtodohere:  :shipit:


Fix proper includes

Fixed an issue with proper includes not checking that the size of the containing list is larger than the included list.  Test cases are added for both "properly includes" and "properly included in", though they share the same common logic.

Sorry for the delay in approving this. Thanks for the contribution!


Update README.md

This will fail building due to an issue with a dependency of nebulet and cretonne.


CI: Use Docker for CI

Changes

Under tests/docker, added two dockerfiles that builds docker images for testing cps-config. The two dockerfiles are for ubuntu and rockylinux currently. More platforms can be added later.
In GitHub Actions workflow, switched from building and testing directly within the workflow to building and using docker images.
Partly to demonstrate the benefits of this approach, added testing for rockylinux within CI pipeline.
Because the CI pipeline is no longer testing ubuntu specifically, rename the pipeline to "test", expecting that in the future, more workflows, like "lint", would be added.

Benefits

Developers would be better able to reproduce CI results without repetitively pushing and triggering GitHub Actions.
A single GitHub Actions workflow file would be able to run tests on multiple distributions seamlessly, where all the platform-specific behaviors are handled within dockerfiles for each distribution.
In the future, other CI workflows, like running clang-tidy on the codebase, might be interesting. With docker, we will be able to reuse platform-specific setups and have one workflow file per type of check.
Docker builds can be cached. This could lead to much faster CI pipeline builds.

Limitation and future work

It is not entirely clear to me whether docker build cache includes ccache mounted with type=cache. Intuitively, it should, but I couldn't find official docs that say so. It that is not cached, this would be a step back from the previous CI setup. In that case, a future PR that caches ccache artifacts would be needed.
Currently building the dockerfile also builds cps-config. This might not be necessary for some workflows. It might be interesting to do that as part of the workflow rather than the image build process.
It would be nice to document local workflows to test cps-config with those dockerfiles, even if it's "go look at what is being used in test.yml". But that would fit into docs/dev.md which is currently WIP in #42. I will follow up with a docs PR once docs/dev.md is merged.

Testing
I have tested in my own repository, but it's after all just an approximation. Thus, I have created #47 to test that this CI pipeline correctly fails when there is a test failure.

#47 fails as expected. Failing CI run: https://github.com/cps-org/cps-config/actions/runs/8227179114/job/22494683293.

The Images could be built on a timer, or when a user manually updates them, and then we just re-use those images.

Not sure if I followed you correctly, are you saying that we publish to cps/cps-config or something on DockerHub and then in our CI just use the image to build CPS?
Please correct me if I'm wrong, but I don't think that would have any performance benefit over the workflow in this PR. Docker builds are cached by GH Actions by layer. If we don't change build dependencies, for example, docker/build-push-action@v5 or the cache-from: type=gha configuration specifically, will just pull the layers from GH Actions cache. This wouldn't be different from pulling the published image from a registry.
Further, the benefit of this is that it automatically detects when a layer is changed, e.g. adding/removing dependencies, and correctly invalidates the cache. If we publish the image, a PR that requires a new dependency, or one that updates the image from Ubuntu 22.04 to 24.04, is guaranteed to fail.

I'm concerned that as we add more OSes and tests that the CI time is going to get really long.

They are parallel so they probably wouldn't be too long. My concern is using too much cache to a point of GHA stopping us from doing so. But you are right, and I would propose:

Have dockerfiles for a bunch of distros that we care about: ubuntu, rhel-like, fedora, debian, arch, etc.
Have the CI run only 1-2
Have a local workflow where a full platform compatibility test can be manually triggered. That would likely happen right before a release or something

Since the project is quite small now, I'm OK with taking a step back on ccache support to improve test coverage. If this PR merges, @lunacd, can you make an issue to revisit compile caching support?

I googled a bit and found this issue: https://github.com/moby/buildkit/issues/1512. The issue isn't directly related to this, but from the comments, it seems that cache-to only saves layer cache, not mounted cache. I'll make an issue to revisit this. Wouldn't be hard to get. We just have to manually manage volume/bind.

Ah, I'm demonstrating what I don't understand! It look like it's doing exactly what I hoped for then, this requires a bit more manual intervention on GitLab, so I was expecting more intervention on GitHub as well. Please disregard my comments, this all looks good from my point of view.

Changes:

dockerignore *.md
Removed some unnecessary boilerplate comment in GH Actions workflow file


Support skip x509 check when deploy to vsphere

Feature Request

When using ui to deploy tce in vsphere, after i input the username/password info and connect, an error mesage show up
Failed to connect to the specified vCenter Server. Post "https://<ip>/sdk": x509: certificate signed by unknown authority

I would like an option in UI to skip check for x509 cert in this situtaion
Describe alternatives you've considered

Additional context

I've created an issue in tanzu-framework since the ui code is all upstream from there

[ ] https://github.com/vmware-tanzu/tanzu-framework/issues/1028

We can track that issue here and we will bump the version of tanzu framework we ship to capture those changes

Code has been merged to main. We have added a checkbox to the UI that is unchecked by default. When checked, user is electing to bypass SSL Thumbprint verification during authentication with their vCenter and all subsequent operations for creating clusters.
https://user-images.githubusercontent.com/13439013/140963165-7eebdc01-15f6-4ed9-908a-a90d85865137.png

@hangyan or @jpmcb the ability to skip x509 check was merged in Nov. Please feel free to close this issue as I am unable to do so. Thanks!

We haven't bumped our version of tanzu framework yet to capture those changes so we will keep this open. This was incorrectly labeled stale and we're working on modifying the stale or to ignore issues like this one that correlate to long running tanzu framework changes

We haven't bumped our version of tanzu framework yet to capture those changes so we will keep this open. This was incorrectly labeled stale and we're working on modifying the stale bot to ignore issues like this one that correlate to long running tanzu framework changes

Ah got it, thanks!

We've bumped to v0.16.0 of tanzu-framework and this should be apart of the v0.11.0 release of TCE. Ref PR: https://github.com/vmware-tanzu/community-edition/pull/3149

Now that we've moved back to v0.11.1, is it still fixed?
Assigned to @jpmcb to validate.

Built off of main and I see the skip verify option:

❯ make version
BUILD_VERSION: v0.11.0-fake.3
CONFIG_VERSION: v0.11.0
FRAMEWORK_BUILD_VERSION: v0.11.1
XDG_DATA_HOME: /home/jmcb/.local/share


simple way to show activity of job

Coverage remained the same at 19.33% when pulling ff670ec079f54cea2b04e0e554a10dc421fc3278 on logActivityOnJobs into 90faaf4d21a54c6f963eec8335a6a69580e24c2b on master.


[BUG] Incapability for Dark mode

Theme Bugs on Dark Mode :(
Hey! I think you should add a dark mode theme too on the website, people who use forced dark modes can really find the website very ugly compared to light mode.
To Reproduce
Steps to reproduce the behavior:

Force your browser to make every site dark mode.
Visit the Arito site

Expected behavior
For dark mode users, it's expected that the site should either automatically change to the dark theme or at least have a button to switch between dark/light modes :)
Screenshots

Smartphone:

OS: [Android OS]
Browser [Firefox Nightly for Developers]
Version [Latest]

Solutions

You can add a button to switch b/w dark & light modes.

You can use prefers-color-scheme property of CSS.

THE BEST ONE! add both options 1 & 2.

Thanks for raising this issue! It is something I didn't thought of.

@Petrosdevri Yeah sure I will be making the necessary images & illustration for dark mode, and then inform you about them!

If there are specific-dark mode images, maybe I can help you guys with css too! I'm good with color combos :)

@Mr-warriyo Cool then! You should then share some good color themes for dark mode, you can find the main color theme of the app in basic.css, there are variable declared for them!

If you can, then use the dev tools to replace the colors of the app with the colors you have decided for dark mode, and then share the app's screenshots here and we will discuss which one looks good.
We need to remember that this app is having a fun-happy kinda environment, so we shouldn't make it so dark that it looks dull and sad.

I have been reported multiple times about this issue now!
We need to work on this on high priority!
Screenshot

These are some of the shades that could be used (I uploaded the image only to show the colors, not the design):

:root {
--dark-grey: #212121;
--light-dark-grey: #545454;
--grey: #757575;
--light-grey: #9e9e9e;
--gradient: linear-gradient(90deg, var(--light-dark-grey), var(--light-grey));
--silver: #cfcfcf;
}
If you want to focus on blue shades instead of dark ones here is an alternative view:

:root {
--dark-blue: #09091b;
--light-dark-blue: #102a43;
--blue: #004aad;
--light-blue: #4d94ff;
--gradient: linear-gradient(90deg, var(--light-dark-blue), var(--light-blue));
--very-light-blue: #99c2ff;
}

Hey @Petrosdevri , I think we first need to have a dark background, and all the text and buttons will be of white color.

Great idea, we can go for it.

Sure then, I will work on it

@prakhartiwari0  I would like to inquire about the availability and assignation of the issue , and if it is currently unassigned, may I proceed to take on the task?

@vinay-devs Actually what we need to discuss is how to change the background image while switching to dark mode. I think we need to replace the image with SVG code and use hsl() to define the colors.
If you have any suggestions about how it can be done, please share them, we will be happy to know them.
Happy Contributing!

@HIMANSHIKSHARMA We need to work on it, currently the need is to decide how to change the light background into a dark one, should we change the image? Should we change the background image's address to a new one or not? That new one will obviously be dark. Or what else can be done?
Or should we drop this feature? I am not sure and need help with all this.

@HIMANSHIKSHARMA We need to work on it, currently the need is to decide how to change the light background into a dark one, should we change the image? Should we change the background image's address to a new one or not? That new one will obviously be dark. Or what else can be done?
Or should we drop this feature? I am not sure and need help with all this.

You can use vectors instead, thus it'll be much easier to change the colour scheme.

Do you mean Vector Graphics/SVG?

Do you mean Vector Graphics/SVG?

exactly.

@maozdemir Got it, I will look into that and how to implement it :)

@prakhartiwari0
I would like to help you with adding a feature for switching mode (light/dark), If you desire or require assistance from me in this matter...

Can you assign me this under GSSOC'23?


Renames OptCode to Opcode

In the spec, Opcode is a single word (not optcode). This corrects and
adds a verification which was at the context I noticed the naming
glitch. Advice on that verification welcome!

thanks for the look @mathetake


create events

@tdq45gj there are a lot of file permissions changes in here. Not everything needs to be executable; can you revert all of the permissions changes?

@tdq45gj there are a lot of file permissions changes in here. Not everything needs to be executable; can you revert all of the permissions changes?

Hi, Graham. Seems that Kent made some modifications. But I am not sure about the file permissions, could you explain about it a little bit?


Options doesn't work with Typescript and Webpack 3

I'm Using Webpack 3.10.0, Typescript 2.6.2, worker-loader 1.1.0.
webpack.config
module: {
            rules: [
                { ... } ,
                {
                    test: /\.worker\.js$/,
                    use: {
                        loader: 'worker-loader',
                        options: {
                            name: 'webWorker.[hash].worker.js',
                            publicPath: '/scripts/'
                        }
                    }
                }
            ]
        }

App.ts:
import Worker = require("worker-loader!./Worker");

Worker.ts:
const ctx: Worker = self as any;
// Post data to parent thread
ctx.postMessage({ foo: "foo" });
// Respond to message from parent thread
ctx.addEventListener("message", (event) => console.log(event));

It compiles, but the file is outputted under  f88912265db2b5d37cdb.worker.js filename, and the path doesn't include /scripts/ part.
I've tried to change import statement to include options as params as follows (based on #117 )
App.ts:
import Worker = require("worker-loader?name=scripts/worker.js!./Worker");

Above import throws following error:
Cannot find module 'worker-loader?name=scripts/worker.js!./Worker'. but after all it compiles properly and javascript works, hence I'm not allowed to leave error message in console.
I'd like to make options section working with Typescript OR get rid of "Cannot ind module" ERROR.

Fixed
For anyone reading this, #117 DO fixes the problem.
Just make sure to have your definition file up to date with import statement:
App.ts
import Worker = require("worker-loader?publicPath=scripts/&name=worker.js!./Worker");

workers/index.d.ts
declare module "worker-loader?publicPath=scripts/&name=worker.js!*" {
    class WebpackWorker extends Worker {
        constructor();
    }
    export = WebpackWorker;
}

To be closed, sorry about that.