Illegalmap breaks clickable chat commands

Whenever there is two clickable chats (for example extra stats after dungeon and join party) only the most recent one works.
I think the issue started occuring somewhere around the 1.2.0 or 1.2.1 update

Fixed by disabling autoscan


Create dotnet.yml

Note: please don't merge this PR...yet. I'm using it as a placeholder to investigate GH Actions automated build.


Poor design interface

Using this api is just pure pain. I have to go through your whole source code to find out a bug I am facing, and I am in pain reading your code. Anyway, it's better to make my own plugin

Can't you read?  I have zero knowledge of java, what I did was copy and paste someone else code. If you can make a better plugin, please provide a better plugin for the community. When I was writing this plugin there are no ironsource plugin, at that time it was better than nothing.

Can't you read? I have zero knowledge of java, what I did was copy and paste someone else code. If you can make a better plugin, please provide a better plugin for the community. When I was writing this plugin there are no ironsource plugin, at that time it was better than nothing.

It is not related to java code, it is on dart interface.
ex: I know it's copy, paste, but you are using this plugin right?
Don't you think It is too boilerplate code?
if I want to init the plugin, the Listener arguement is  'required'  and I have to implement 22 callback in my view.

Oh, I was planning to use this plugin, but ironsource app require approval to show ads. And my apps is not eligible. so in the end this plugin was useless and I don't use this plugin I am using unity ads now.
Last time I check I have to email them. (ironsource) to show ads in my apps. Is your app is the same?


Nix package doesn't let me verify even with correct password.

Is there an existing issue for this?

[X] I have searched the existing issues

Operating system
Fedora v36
Installation method
Package Manager (from OS)
Betterlockscreen & Dependency-Versions
- Betterlockscreen: 4.0.4
- i3lock: 2.13.c.4
- ImageMagick: ?
- dunst (if used): 1.9.0
- feh (if used): 3.8

Bug description
When I try to unlock the screen on Fedora v36 (using the nix package) it does not let me and says Login Failed! each and every time. This works as expected when downloading the binary manually from github.
Steps to reproduce

Use Fedora v36
Install betterlockscreen using nix-env -i betterlockscreen
Lock screen with betterlockscreen -l
Attempt password verification
No worky

Relevant log output
No response

As we are just using i3lock-color (bash-wrapper setting options) I would suggest to report it there, even I think it is system/configuration-related. Is it started as the correct user? Did you verify keyboard-layout it correct?

Is this still relevant for you, or maybe you forget to answer/close it?


chore: bump x/sync to 0.7

Note that this version changes the behavior of semaphore slightly. After https://cs.opensource.google/go/x/sync/+/14be23e5b48bec28285f8a694875175ecacfddb3 the semaphore package will reliably raise errors for both go routines
change the test to test for a substring to be more relaxed in case that behavior gets reverted

Thank you @siretart


Fix macOS builds

Complements #4068, Fixes #4067

@msimberg Not a problem on my end.

@parsa I've pushed a couple of commits. If you have time to try this out on macOS that would be great!

@msimberg Works. Thank you!


[Experimental] Capture peak usage of JVM mem pools

With this commit we store peak usage of all JVM memory pool at the end
of a benchmark. We will start with this limited scope to get more
insights on the usefulness of this feature and might expand this later:

Capture peak usage also at other times during the benchmark
Store peak usage also per race or show it in the summary report

We consider this feature experimental and as such it is intentionally
undocumented. It may change in incompatible ways or disappear at any
point.

Thank you for the review! :)


How to use with environment variables?

Any documentation on how it maps env variables to config values?

I'm also confused when try to use environment variables

Documentation don't have any information about it.

At first I exported env var:
export MY_SERVICE_URI=http://localhost:9900/

Then try to use it...
There is my code snippet:
ConfigurationSource envSource = new EnvironmentVariablesConfigurationSource();
ConfigurationProvider provider = new ConfigurationProviderBuilder()
                .withConfigurationSource(envSource)
                .build();

provider.getProperty("my.service.uri", String.class); // then throws exception...

Hi @Paxa!
I was debugging and found env vars resolving are case sensitive.
For the example above it means MY_SERVICE_URI  env will resolve as MY.SERVICE.URI .

THanks alot for explaining! Appreciate it

I was debugging and found env vars resolving are case sensitive.
I wish it was configurable


docker pull tutum/wordpress fails on overlayfs

With error:
5025a6da41dd: Error pulling image (latest) from docker.io/tutum/wordpress, ApplyLayer exit status 1 stdout:  stderr: chtimes /app/.git: no such file or directory

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

It seems like it fails everywhere, it fails in archive.UnpackLayer function.

Pretty sure it's the opq whiteouts that are causing this. Its kind of a known issue but I wasn't aware that its so easy to reproduce or that it could fail a pull.
If someone sees the same thing happening to their images, then quick workaround is to rebuild it and if you rebuild on aufs try to avoid rm -rf /dir and adding new files to that dir in the same layer.


Response validation changes

I have added changes as per the requirements I have understood, please confirm if changes are implemented correctly. Code is building, will confirm how to test it.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@6a059e8). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             master     #21   +/-   ##
========================================
  Coverage          ?   48.8%
========================================
  Files             ?      35
  Lines             ?    2512
  Branches          ?       0
========================================
  Hits              ?    1226
  Misses            ?    1085
  Partials          ?     201

Continue to review full report at Codecov.

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


Extended payload

Extends the payload (see #4).
TODO:

[ ] Send a message, when Thunderbird closes.
[ ] Update seenMessages (background.js), whenever the settings (simple|extended and foldersToCheck) changes.
[ ] Update documentation.
[ ] Write an example script.

HELP WANTED:

[ ] How do I intercept the closing of Thunderbird?

Please provide the script example so it's easier for me to test the PR. Thanks!

The last commit https://github.com/electrotype/thunderbird-addon-scriptable-notifications/pull/5/commits/e560c9b5094fe4fb0a2ce7e2f000b6cf42699946 has a Python script which logs the extended payload to a file in the user's home directory. The file has the same basename as the script and the suffix ".log". I hope this helps.
I also noticed that the current implementation sends a "read" event, if a message is toggled from read to new (it does not send a new event) and then back again to "read".

Should a "unread" event sent?
Should the second "read" event be suppressed?

I'll have a look at the PR this weekend!

The documentation will have to be fixed to.

Another thing: I do not see an issue about making the "native script" section closable (is that about the "save button" as we discussed?), but it must be open the very first time the user sees the options page... You could use the optionsPageHasBeenShown local storage variable in order to know that.

The documentation will have to be fixed too.

Indeed. I can certainly do it. But don't you want to do that? The reason I ask, is that often people have different ideas and styles of writing documentation. I can try to mimic that, but more often than not, it does not satisfy the original authors resulting in many iterations to get it right. In the end it would have been faster and less work (even for the original authors!), if the original authors were to extend the documentation themselves in the first place.

Ok, I'll update the documentation once the feature is merged.

:bow:

As far as I am concerned, this PR is finished. The only possible open issue from my side is, if the message sent on saving the options should not be empty (https://github.com/electrotype/thunderbird-addon-scriptable-notifications/pull/5#discussion_r1007048030).
Thank you for your help and guidance!

Merged! I'll leave a comment here when the doc is done and the new version is deployed.
Thanks for this feature sphh!

Do you have an user account on https://addons.thunderbird.net ?
Do you want me to add you as one of the developers for the extension, there? If so, I would need the email address associated with your account.

Version 4.0 is now available publicly:
https://addons.thunderbird.net/en-CA/thunderbird/addon/scriptable-notifications/

Do you have an user account on https://addons.thunderbird.net ?

No, since I am not good in doing JavaScript (and Thunderbird) stuff.

Version 4.0 is now available publicly:

Your documentation is so much better, than what I would have written. Thanks!
And also thanks for your willingness to accept this, for your guidance, comments and your hawk eye to spot mistakes. It was a pleasure to to do this PR.
PS: Have you seen my last comment about the quoting in the payload?

PS: Have you seen my last comment about the quoting in the payload?

No I don't?
Please feel free to make any new PR if you see something that should be fixed. I'm still using the simple mode so I may not find issues related to the extended one  by myself.
Cheers!

What is the proper way to define a dictionary in JavaScript: With or without quoted keys?

The proper "dictionary" structure in js is called Map: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map
You need to quote the string keys.
But plain objects have been used as a way to create a dictionary too: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map#objects_vs._maps
And when defining a js object you don't have to quote the keys, I'm pretty sure, except if there are spaces in them (and maybe some other spacial characters?). But you can always quote them.

I see. Thanks.
If you want for consistency reasons the quotes around the keys to be removed in the payload used to testing – or all keys in all other "dictionaries" to be quoted –, please tell me so and I will make a (new) PR with these changes. I don't mind either way (or if you think, that no changes are needed).


Update Travis Ruby version to 2.1.7

has_scope 0.7, which is now allowed by newer versions of inherited_resources, requires Ruby 2.1.7.

Coverage remained the same at 99.095% when pulling 3341da5d2b1e0a1c293878cd9af1f19f04d9fa34 on tf:ruby-2-1-7 into 2450064d3205680b79c49eee3af5181d70bb77ba on codevise:master.


Add PlanetIQ gnssro data from x0049

Description
Add PlanetIQ gnssro data with satelliteIdentifier numbers 267 and 268.  The test is done with x0049 data at 12hr, 07 Aug 2023.
New x0049 data are in
/discover/nobackup/projects/gmao/obsdev/jjin3/archive/x0049.x49swell/
New IODA obs and geoval files are in /discover/nobackup/jjin3/jedi/For_others/x0049.x49swell/swell/
Note, these files are made by Swell and there is one second time-bump-up within these files.

Here are some statistics:

total number of data = 714974
=====================================================
Pass QC in GSI, but not in JEDI
number of obs 22
=====================================================
Pass QC in JEDI, but not in GSI
number of obs 2
=====================================================
Pass QC in JEDI, err_diff |(JEDI_err - GI_err)/GSI_err| > 0.1
number of obs 127504
=====================================================
Sat_ID, nn_obs passed GSI QC, nn_obs_passed UFO QC
  003                23269                23269
  005                25433                25433
  042                10791                10791
  043                 4400                 4400
  044                10104                10104
  267               127442               127426
  269                50987                50984
  751                49190                49189
  752                49701                49701
  753                52324                52324
  754                51503                51503
  755                45506                45506
  825                 8511                 8511

total number of data = 714974
=====================================================
Pass QC in GSI, but not in JEDI
  obstype, 751
  obstype, 269
  obstype, 269
  obstype, 269
  obstype, 269
  obstype, 269
number of obs 6
=====================================================
Pass QC in JEDI, but not in GSI
  obstype, 269
  obstype, 269
number of obs 2
=====================================================
Pass QC in JEDI, err_diff |(JEDI_err - GI_err)/GSI_err| > 0.1
number of obs 78
=====================================================
Sat_ID, nn_obs passed GSI QC, nn_obs_passed UFO QC, difference (UFO-GSI)
   003                23269                23269                    0
   005                25433                25433                    0
   042                10791                10791                    0
   043                 4400                 4400                    0
   044                10104                10104                    0
   267               127442               127442                    0
   269                50987                50984                   -3
   751                49190                49189                   -1
   752                49701                49701                    0
   753                52324                52324                    0
   754                51503                51503                    0
   755                45506                45506                    0
   825                 8511                 8511                    0
Total:               509161               509157                   -4
=====================================================

kx = 269 has been already added to develop - see closed PR: #367

@gmao-jjin3 : I think you will need to be careful here w/ the passedBenchMark counts ... changing that implies changing the reference in SWELL ... which right now is x0048. I don't opposed changing the reference to x0049 - indeed I have now a times series of IODA files from x0049, but this will require revising the benchmark counts for other data - esp, the conventional obs since x0049 avoids data duplication - a knob you put in GSI. We can talk about this in this coming week.


Receiving a 502 error does not trigger an error message

Description
When a 502 error is triggered while submitting an analysis request, the web app does not show any error message
Steps to reproduce
Add the GREIN dataset "GSE121212" twice to a request.

handled with error message at FE


Wrong push_constant block name

when I write such compute shader, expecting to get the push_constant block name as "pushConstantName", but finally get "PushConstantType".
#version 450

layout (local_size_x = 256) in;
layout (push_constant) uniform PushConstantType
{
    int a;
} pushConstantName;

void main()
{
}
...

As you can see, in the  yml file, the type name of the push_constant block is the same as the name of the block, so, I think there is something wrong with the reflection.
%YAML 1.0
---
all_type_descriptions:
  - &td0
    id: 11
    op: 21
    type_name:
    struct_member_name: "a"
    storage_class: 0 # UniformConstant
    type_flags: 0x00000004 # INT
    decoration_flags: 0x00000000 # NONE
    traits:
      numeric:
        scalar: { width: 32, signedness: 1 }
        vector: { component_count: 0 }
        matrix: { column_count: 0, row_count: 0, stride: 0 }
      image: { dim: 0, depth: 0, arrayed: 0, ms: 0, sampled: 0, image_format: 0 } # dim=1D image_format=Unknown
      array: { dims_count: 0, dims: [], stride: 0 }
    member_count: 0
    members:
  - &td1
    id: 12
    op: 30
    type_name: "PushConstantType"
    struct_member_name:
    storage_class: -1 # NOT APPLICABLE
    type_flags: 0x10080000 # STRUCT EXTERNAL_BLOCK
    decoration_flags: 0x00000001 # BLOCK
    traits:
      numeric:
        scalar: { width: 0, signedness: 0 }
        vector: { component_count: 0 }
        matrix: { column_count: 0, row_count: 0, stride: 0 }
      image: { dim: 0, depth: 0, arrayed: 0, ms: 0, sampled: 0, image_format: 0 } # dim=1D image_format=Unknown
      array: { dims_count: 0, dims: [], stride: 0 }
    member_count: 1
    members:
      - *td0
all_block_variables:
  - &bv0
    name: "a"
    offset: 0
    absolute_offset: 0
    size: 4
    padded_size: 16
    decorations: 0x00000000 # NONE
    numeric:
      scalar: { width: 32, signedness: 1 }
      vector: { component_count: 0 }
      matrix: { column_count: 0, row_count: 0, stride: 0 }
    array: { dims_count: 0, dims: [], stride: 0 }
    member_count: 0
    members:
    type_description: *td0
  - &bv1
    name: "PushConstantType"
    offset: 0
    absolute_offset: 0
    size: 16
    padded_size: 16
    decorations: 0x00000000 # NONE
    numeric:
      scalar: { width: 0, signedness: 0 }
      vector: { component_count: 0 }
      matrix: { column_count: 0, row_count: 0, stride: 0 }
    array: { dims_count: 0, dims: [], stride: 0 }
    member_count: 1
    members:
      - *bv0
    type_description: *td1
all_descriptor_bindings:
all_interface_variables:
module:
  generator: 13 # Google Shaderc over Glslang
  entry_point_name: "main"
  entry_point_id: 4
  source_language: 2 # GLSL
  source_language_version: 450
  spirv_execution_model: 5 # GLCompute
  shader_stage: 0x00000020 # CS
  descriptor_binding_count: 0
  descriptor_bindings:
  descriptor_set_count: 0
  descriptor_sets:
  input_variable_count: 0,
  input_variables:
  output_variable_count: 0,
  output_variables:
  push_constant_count: 1,
  push_constants:
    - *bv1 # "PushConstantType"
...

trying this with ToT it seems this has been since fixed


Improvements to pagination and search in generic data table

Checklist

[x] I tested all changes and all related features with different users (student, tutor, instructor, admin) on the test server https://artemistest.ase.in.tum.de.
[x] ~Server: I added multiple integration tests (Spring) related to the features~
[x] ~Server: I added @PreAuthorize and check the course groups for all new REST Calls (security)~
[x] ~Server: I implemented the changes with a good performance and prevented too many database calls~
[x] ~Server: I documented the Java code using JavaDoc style.~
[x] ~Client: I added multiple integration tests (Jest) related to the features~
[x] ~Client: I added authorities to all new routes and check the course groups for displaying navigation elements (links, buttons)~
[x] Client: I documented the TypeScript code using JSDoc style.
[x] Client: I added multiple screenshots/screencasts of my UI changes
[x] Client: I translated all the newly inserted strings into German and English

Motivation and Context
This PR addresses the points raised in issue #1072. Even though the issue was originally labeled as a bug, it really is more of a feature or enhancement request. All suggestions sound reasonable and expedient to me and since they are small related improvements, they are bundled into this PR.
Note: Since this PR depends on #1095, it was branched off from enhancement/pagination/exercise-participation. I set this as the target branch for the pull so that the diff is more useful. Once that branch is merged, the target branch can be changed to develop.
Description

Autocomplete suggestion window is now limited to a reasonable height and scrollable by itself (before it was getting very long for large suggestion sets and was increasing the height of the whole window)
The pagination option "2000 results per page" was replaced with an option "Show all results" (this can be useful if a user wants to search the whole table containing more than 2000 results with his browser or for printing the whole table)
The search by student login or name is now a little fuzzier than before (when entering an expression consisting of multiple words separated by spaces, e.g. "Max Mustermann", each of those words must be a substring of the field value as opposed to their concatenation being a substring as it was before. This is a relaxation and will for instance allow finding "Max Gregor Mustermann" when searching "Max Mustermann". A user noticed that this is a common issue since a lot of students have middle names.
The search now also supports the usage of the wildcard symbol *. Example: The user searches for "Must*mann" and  "Max Mustermann" will be found. This is done via regex. Only the symbol * is allowed though, not arbitrary regex (this would potentially disturb normal searches since the user then needs to be aware of the fact that all regex symbols need escaping).

Steps for Testing

Log in to Artemis
Navigate to Course Administration
Click on "Exercises" on a course
Click on "Participations" or "Scores" for an exercise

Screenshots

Autocomplete suggestion window height

New pagination option "Show all results"

Fuzzier student search

Allow wildcard in search

I'm resolving conflicts right now.


Can't connect to container hosted on Windows Server

Not sure if bug or question ;)
Since a recent reboot, our devops build server is no longer able to connect to container images it starts.
The container starts, and states that it is forwarding the port. But I can't connect to it, and netsh doesn't show the port as listening.
To Reproduce
Dockerfile:
# SQL Server 2019 Windows container dockerfile
## Warning: Restarting windows container causes the machine key to change and hence if you have any encryption configured then restarting SQL On Windows containers
## breaks the encryption key chain in SQL Server.

# Download the SQL Developer from the following location  https://go.microsoft.com/fwlink/?linkid=866662 and extract the .box and .exe files using the option: "Download Media"

FROM mcr.microsoft.com/windows/servercore:ltsc2022

ENV sa_password="_" \
    attach_dbs="[]" \
    ACCEPT_EULA="_" \
    sa_password_path="C:\ProgramData\Docker\secrets\sa-password" \
    install_source="http://examplesource"

SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]

# download install files
RUN invoke-webrequest -Uri $env:install_source/start.ps1 -outfile /start.ps1;  \
    invoke-webrequest -Uri $env:install_source/SQLServer2019-DEV-x64-ENU.box -outfile /SQLServer2019-DEV-x64-ENU.box; \
    invoke-webrequest -Uri $env:install_source/SQLServer2019-DEV-x64-ENU.exe -outfile /SQLServer2019-DEV-x64-ENU.exe

WORKDIR /
RUN dir
RUN Start-Process -Wait -FilePath .\SQLServer2019-DEV-x64-ENU.exe -ArgumentList /qs, /x:setup ; \
        .\setup\setup.exe /q /ACTION=Install /INSTANCENAME=MSSQLSERVER /FEATURES=SQLEngine /UPDATEENABLED=0 /SQLSVCACCOUNT='NT AUTHORITY\NETWORK SERVICE' /SQLSYSADMINACCOUNTS='BUILTIN\ADMINISTRATORS' /TCPENABLED=1 /NPENABLED=0 /IACCEPTSQLSERVERLICENSETERMS ; \
        Remove-Item -Recurse -Force SQLServer2019-DEV-x64-ENU.exe, SQLServer2019-DEV-x64-ENU.box, setup

RUN stop-service MSSQLSERVER ; \
        set-itemproperty -path 'HKLM:\software\microsoft\microsoft sql server\mssql15.MSSQLSERVER\mssqlserver\supersocketnetlib\tcp\ipall' -name tcpdynamicports -value '' ; \
        set-itemproperty -path 'HKLM:\software\microsoft\microsoft sql server\mssql15.MSSQLSERVER\mssqlserver\supersocketnetlib\tcp\ipall' -name tcpport -value 1433 ; \
        set-itemproperty -path 'HKLM:\software\microsoft\microsoft sql server\mssql15.MSSQLSERVER\mssqlserver\' -name LoginMode -value 2 ;

HEALTHCHECK CMD [ "sqlcmd", "-Q", "select 1" ]

CMD .\start -sa_password $env:sa_password -ACCEPT_EULA $env:ACCEPT_EULA -attach_dbs \"$env:attach_dbs\" -Verbose

docker-compose.yml
services:
  db:
    environment:
      SA_PASSWORD: "my-secure-password!"
      ACCEPT_EULA: "Y"
    build:
      context: .
    expose:
      - 1433
    ports:
      - 14337:1433

Expected behavior

✅ docker ps to show the container with ports <IP_ADDRESS>:14337->1433/TCP
❌ netstat -ano to show something listening on 14337
❌ Test-NetConnection -Port 14337 -ComputerName <IP_ADDRESS> to succeed

Configuration:

Edition: Windows Server 2022 (21H2 Build 20348.768)
Base Image being used: Windows Server Core
Container engine: docker
Container Engine version: Docker version 20.10.9, build 591094d

Additional context
Add any other context about the problem here.

Can you clarify what was rebooted in this scenario @altwohill ?

The host server

From: Fady Azmy @.>
Sent: Thursday, July 21, 2022 4:21:53 AM
To: microsoft/Windows-Containers @.>
Cc: Al Twohill @.>; Mention @.>
Subject: Re: [microsoft/Windows-Containers] Can't connect to container hosted on Windows Server (Issue #248)
Can you clarify what was rebooted in this scenario @altwohillhttps://github.com/altwohill ?
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/Windows-Containers/issues/248#issuecomment-1190489888, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAEZUBU23MJWORY4LEJVUSLVVARSDANCNFSM536PQSYQ.
You are receiving this because you were mentioned.Message ID: @.***>

No update to share except that we are looking into this.

We haven't been able to repro the issue; is this still happening and if so could you repro this issue with a WS2022 container? @altwohill

@altwohill we are unable to reproduce this on our side. Are you able to see if this still happens on 2022? I am going to close this for now. Please feel free to reopen this.

Closing while we wait for a reply


[WIP] ARROW-16919: DO NOT MERGE: investigate verification failure

@github-actions crossbow submit verify-rc-source-integration-linux-ubuntu-20.04-amd64

Ah…right, the verification happens inside Docker, so gotta finagle it a bit to get files outside the container. Though, the verification didn't fail in any case…

@github-actions crossbow submit verify-rc-source-integration-linux-ubuntu-20.04-amd64

@github-actions crossbow submit verify-rc-source-integration-linux-ubuntu-20.04-amd64

@github-actions crossbow submit verify-rc-source-integration-linux-ubuntu-20.04-amd64

@github-actions crossbow submit verify-rc-source-integration-linux-ubuntu-20.04-amd64

@github-actions crossbow submit verify-rc-source-integration-linux-ubuntu-20.04-amd64


Feat: support helm flag --enable-dns

resolve #788

@vincentstchu please fix DCO issue. following the link: https://github.com/helmfile/helmfile/pull/830/checks?check_run_id=13039012352


Create 2023-10-welcome-cloud-native-sustainability-week-2023.md

Add blogbost Welcome to the Cloud Native Sustainability Week 2023

LGTM! Thanks for putting in the effort in creating this blog post, @akelity 🥳


Implement Lag Features

Make use of Lag Features for extension of the training set.
Candidate columns: air_temperature, dew_temperature
Candidate windows: 6, 12, 24

Closed in b75bb29.


hyprwinwrap: Not Showing Through Transparent Window When Floating

HyperWinWrap not showing through transparent window when floating
https://github.com/hyprwm/hyprland-plugins/assets/54718375/c0f05af4-8de3-4408-a045-7eb43f1bca91

HyperWinWrap not showing through transparent window when floating
2024-07-05_21-48-58.mp4

I think that this is related to the following blur option:
ignore_opacity = true
Try disabling it and let me know if it's the same on your end.
I am well aware that the option is required, blur looks disgusting without it, just wanna see if that's the cause.

ignore_opacity = true

still the same

Ah, could be this other thing.
Are you making the terminal transparent in the terminal cfg or via hyprland window rules?
If it's the first, take a look at the issue I created recently:
#167

prob fixed

prob fixed

It isn't

prob fixed

It isn't

isn't it the same as #167?

isn't it the same as #167?

Nope, #167 refers to hyprwinwrap not being visible through apps that use native transparency.
This issue is hyprwinwrap not being visible through tiled windows.
As I said in #167, I'll make a separate bug report with some additional info soon because I am suspecting this to be a bug on hyprland side and not hyprwinwrap.


typescript: defineProps and defineEmits not co-op in type checking

Hi!
I'm using plugin v0.5.4 in Nuxt. with simple component use both defineProps and defineEmits i see type checking report error:
normal, when only use defineProps component checking ok:

when add defineEmis, all props reference in template lost:

This error only happend with type checking, runtime still work.
Thankyou!

Have you configured this? https://github.com/antfu/unplugin-vue2-script-setup#global-types

@antfu yes, this is in my tsconfig.json:
"types": [
      "@nuxt/types",
      "@types/node",
      "@nuxt/image",
      "@nuxtjs/firebase",
      "unplugin-vue2-script-setup/types",
      "unplugin-vue2-script-setup/ref-macros"
    ]

also, i found in readme we missing a thing about different between vue2's template and vue3's template type checking. i will post other issue for track better.

Fixed in @vue/composition-api 1.1.4, please update and try out


[BUG]Volumes used by MinIO workloads cannot be attached with state Degraded

Describe the bug
See the title and the reproducing steps.
To Reproduce
Steps to reproduce the behavior:

Launch a new cluster.
Deploy Longhorn v1.1.0-rc1 (or master - Dec 10, 2020). Make sure:
the Longhorn StorageClass is the default one.
the Longhorn StorageClass replica count should be greater than the Longhorn cluster worker node count.
Fetch the MinIO Chart and install it with helm

git clone https://github.com/minio/charts.git
cd ./charts/minio
helm install minio . --set persistence.size=1Gi --set resources.requests.memory=100Mi --set mode=distributed

Verify if all volumes used by MinIO can be attached with state Degraded

Expected behavior
all volumes used by MinIO can be attached with state Degraded
Log
longhorn-csi-plugin:
[longhorn-csi-plugin-qn2mv longhorn-csi-plugin] time="2020-12-10T05:23:50Z" level=info msg="ControllerServer ControllerPublishVolume req: volume_id:\"pvc-024fef2f-1f99-42e0-b89d-68fb0b3edfb5\" node_id:\"shuo-cluster-0-worker-2\" volume_capability:<mount:<fs_type:\"ext4\" > access_mode:<mode:SINGLE_NODE_WRITER > > volume_context:<key:\"fromBackup\" value:\"\" > volume_context:<key:\"numberOfReplicas\" value:\"5\" > volume_context:<key:\"staleReplicaTimeout\" value:\"2880\" > volume_context:<key:\"storage.kubernetes.io/csiProvisionerIdentity\" value:\"1607577457259-8081-driver.longhorn.io\" > "
[longhorn-csi-plugin-qn2mv longhorn-csi-plugin] time="2020-12-10T05:23:50Z" level=error msg="GRPC error: rpc error: code = Internal desc = Post \"http://longhorn-backend:9500/v1/volumes/pvc-83c016c2-f8f0-4ae0-aa20-f5f2989c2081?action=attach\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"

longhorn-manager:
[longhorn-manager-xnljz] <IP_ADDRESS> - - [10/Dec/2020:05:23:50 +0000] "GET /v1/volumes/pvc-024fef2f-1f99-42e0-b89d-68fb0b3edfb5 HTTP/1.1" 200 4949 "" "Go-http-client/1.1"
......
[longhorn-manager-xnljz] time="2020-12-10T05:23:52Z" level=error msg="There's no available disk for replica pvc-024fef2f-1f99-42e0-b89d-68fb0b3edfb5-r-d04c6efd, size<PHONE_NUMBER>"
[longhorn-manager-xnljz] time="2020-12-10T05:23:52Z" level=error msg="unable to schedule replica" controller=longhorn-volume frontend=blockdev node=shuo-cluster-0-worker-3 owner=shuo-cluster-0-worker-3 replica=pvc-024fef2f-1f99-42e0-b89d-68fb0b3edfb5-r-d04c6efd state=detached volume=pvc-024fef2f-1f99-42e0-b89d-68fb0b3edfb5
......

Notice that there is no attach request received by longhorn manager pods!
Environment:

Longhorn version: master - Dec 10, 2020
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: v1.19
Node config

OS type and version: Ubuntu 18.04
CPU per node: 2v
Memory per node: 4GB
Disk type(e.g. SSD/NVMe): 80GB
Network bandwidth and latency between the nodes: 23Gbit/s, <0.1ms

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): Digital Ocean instance

Additional context

If the volume replica count is not greater than worker node count, all volumes can be attached with state Healthy.
I cannot reproduce it with other StatefulSet YAML files. (volume replica count is greater than the worker node count)

There is tons of conflicts happens during updating volume object in the VolumeAttach call. As a result, the longhorn manager cannot respond to the CSI plugin then lead to the timeout error of calling attach:

Fail to update volume in VolumeAttach call:

[longhorn-manager-dv4dl] time="2020-12-10T12:12:31Z" level=debug msg="VolumeManager is attaching volume pvc-eef36232-f57a-4284-a8c1-7c1980a961fc: Prepare to update"
......
[longhorn-manager-dv4dl] time="2020-12-10T12:12:32Z" level=debug msg="VolumeManager is attaching volume pvc-eef36232-f57a-4284-a8c1-7c1980a961fc: Finish updating call with error: unable to attach volume pvc-eef36232-f57a-4284-a8c1-7c1980a961fc to shuo-longhorn-cluster-2-node-1: Operation cannot be fulfilled on volumes.longhorn.io \"pvc-eef36232-f57a-4284-a8c1-7c1980a961fc\": the object has been modified; please apply your changes to the latest version and try again"

Keep retrying:

[longhorn-manager-dv4dl] time="2020-12-10T12:12:32Z" level=debug msg="Encounter conflict when updating obj: unable to attach volume pvc-eef36232-f57a-4284-a8c1-7c1980a961fc to shuo-longhorn-cluster-2-node-1: Operation cannot be fulfilled on volumes.longhorn.io \"pvc-eef36232-f57a-4284-a8c1-7c1980a961fc\": the object has been modified; please apply your changes to the latest version and try again"

Timeout error in the CSI plugin:

[longhorn-csi-plugin-mlzkl longhorn-csi-plugin] time="2020-12-10T12:12:30Z" level=info msg="GRPC request: {\"node_id\":\"shuo-longhorn-cluster-2-node-1\",\"volume_capability\":{\"AccessType\":{\"Mount\":{\"fs_type\":\"ext4\"}},\"access_mode\":{\"mode\":1}},\"volume_context\":{\"fromBackup\":\"\",\"numberOfReplicas\":\"3\",\"staleReplicaTimeout\":\"2880\",\"storage.kubernetes.io/csiProvisionerIdentity\":\"1607602077348-8081-driver.longhorn.io\"},\"volume_id\":\"pvc-eef36232-f57a-4284-a8c1-7c1980a961fc\"}"
[longhorn-csi-plugin-mlzkl longhorn-csi-plugin] time="2020-12-10T12:12:30Z" level=info msg="ControllerServer ControllerPublishVolume req: volume_id:\"pvc-eef36232-f57a-4284-a8c1-7c1980a961fc\" node_id:\"shuo-longhorn-cluster-2-node-1\" volume_capability:<mount:<fs_type:\"ext4\" > access_mode:<mode:SINGLE_NODE_WRITER > > volume_context:<key:\"fromBackup\" value:\"\" > volume_context:<key:\"numberOfReplicas\" value:\"3\" > volume_context:<key:\"staleReplicaTimeout\" value:\"2880\" > volume_context:<key:\"storage.kubernetes.io/csiProvisionerIdentity\" value:\"1607602077348-8081-driver.longhorn.io\" > "
[longhorn-csi-plugin-mlzkl longhorn-csi-plugin] time="2020-12-10T12:12:30Z" level=debug msg="ControllerPublishVolume: volume pvc-eef36232-f57a-4284-a8c1-7c1980a961fc current nodeID is shuo-longhorn-cluster-2-node-1"
......
[longhorn-csi-plugin-mlzkl longhorn-csi-plugin] time="2020-12-10T12:12:40Z" level=error msg="GRPC error: rpc error: code = Internal desc = Post \"http://longhorn-backend:9500/v1/volumes/pvc-eef36232-f57a-4284-a8c1-7c1980a961fc?action=attach\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"

The next is, what causes the conflict, and why this bug happens only in MinIO

I think that the root cause was https://github.com/longhorn/longhorn-manager/pull/795
How do you think?

Test steps:
Scenarios 1:
Test the reproduce steps in the issue's description
Scenarios 2:
Deploy the following statefulset. Notice the field podManagementPolicy: "Parallel", it instructs Kubernetes to lunch all pods at the same time and make the issue more likely to happen.
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  podManagementPolicy: "Parallel"
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 10 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      restartPolicy: Always
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        livenessProbe:
          exec:
            command:
              - ls
              - /usr/share/nginx/html/lost+found
          initialDelaySeconds: 5
          periodSeconds: 5
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "longhorn"
      resources:
        requests:
          storage: 1Gi

Verify that 10 volumes are attached within 30s.
Verify that the logs of longhorn-csi-plugin doesn't contains this timeout log:
[longhorn-csi-plugin-mlzkl longhorn-csi-plugin] time="2020-12-10T12:12:40Z" level=error msg="GRPC error: rpc error: code = Internal desc = Post \"http://longhorn-backend:9500/v1/volumes/pvc-eef36232-f57a-4284-a8c1-7c1980a961fc?action=attach\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"

verified using k3os-v0.19.4-dev5 and it works as expected.
NAME                                 READY   STATUS    RESTARTS   AGE
harvester-network-controller-2zpj6   1/1     Running   0          66m
virt-operator-7b99b7bbdb-fwtxg       1/1     Running   0          66m
virt-api-59bf84667c-flw5q            1/1     Running   0          65m
virt-api-59bf84667c-2pqvv            1/1     Running   0          65m
minio-1                              1/1     Running   0          63m
minio-2                              1/1     Running   0          63m
minio-3                              1/1     Running   0          63m
minio-0                              1/1     Running   0          63m
virt-handler-z2pzr                   1/1     Running   0          64m
cdi-operator-6c7bd7b867-9b8fp        1/1     Running   0          66m
virt-controller-7bfcdc8bb9-bvfq2     1/1     Running   1          64m
virt-controller-7bfcdc8bb9-9jxnt     1/1     Running   1          64m
cdi-apiserver-5d7db448bf-zl4wr       1/1     Running   0          51m
cdi-uploadproxy-5864bf9794-k6pmn     1/1     Running   0          50m
cdi-deployment-78985784-jm5gr        1/1     Running   0          50m
harvester-86bdcf9df7-sjfnr           1/1     Running   0          2m44s
svclb-harvester-g4b7h                1/1     Running   0          2m21s

Verified according to https://github.com/longhorn/longhorn/issues/2073#issuecomment-743958672

Closing, will track integration test implementation in a separate issue  https://github.com/longhorn/longhorn/issues/2486


about retrain shufflenetv2 question

First of all, thanks for your perfect projects.
Environments
pyhton: 3.7
pytorch: 1.7+cpu
torchvison: 0.8.1+cpu
system-os: ubuntu18.04
Hyperparameters
lr: 0.001
momentum: 0.9
weights_decay: 0.0001
batch_size: 16
Question introduction
Recently, I was learning the source code your provided in torchvision about shufflenetv2.
But when I was fine-training the network(only training fc layer), I had a problem that network convergence is very slow. like this:
[epoch 0] accuracy: 0.246
[epoch 1] accuracy: 0.253
[epoch 2] accuracy: 0.28
[epoch 3] accuracy: 0.305
[epoch 4] accuracy: 0.338
[epoch 5] accuracy: 0.353

I have read this document https://pytorch.org/docs/stable/torchvision/models.html#classification
According to this document, I downloaded the weights https://download.pytorch.org/models/shufflenetv2_x1-5666bf0f80.pth, and use same preprocessing method.
    data_transform = {
        "train": transforms.Compose([transforms.RandomResizedCrop(224),
                                     transforms.RandomHorizontalFlip(),
                                     transforms.ToTensor(),
                                     transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225])]),
        "val": transforms.Compose([transforms.Resize(256),
                                   transforms.CenterCrop(224),
                                   transforms.ToTensor(),
                                   transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225])])}

But with conditions unchanged, I just replace the model with resnet34 your provided in torchvision, and I can get great results. like this:
[epoch 0] accuracy: 0.968

Strangely, When fine-training shfflenetv2 if I change the learning rate from 0.001 to 0.1, I can get the following results:
[epoch 0] accuracy: 0.85
[epoch 1] accuracy: 0.848
.....
[epoch 29] accuracy: 0.899

Does fine-training shufflenet network need such a large learning rate?
I guess the preprocessing algorithm is not like that. Because if I use the mobilenetv2 network, I can get better results under the same conditions. Could you help me find out what's wrong? Thank you very much.
Code
https://github.com/WZMIAOMIAO/deep-learning-for-image-processing/blob/master/pytorch_classification/Test7_shufflenet/train.py

Could someone answer my question?

Could someone answer my question?


perf: Use serde to aid in loading docs

This PR addresses #75 by changing how data is loaded at server start. Before, each xml file was parsed at server start into a vector of Instructions, Registers, or Directives. Now, the following takes place:

A separate binary (asm_docs_parsing) parses said xml files into vectors and then serializes them once beforehand. The serialized content is then written to a separate file
At server start, the serialized file is deserialized, and the rest of the server's operation proceeds as normal

Before marking this PR as ready, I'd like to do a thorough performance measurement, as well as to write some tests to ensure the serialized docs stay in sync with their xml counterparts.
Averaged over 10 trials each, the server now starts about 12% faster, which is an absolute win. The performance gains added here will continue to help as we add additional architectures as well.
However, some initial measurements are promising:

The x86 register set showed a 1.88x loading time improvement
The x86 instruction set showed a 1.69x loading time improvement
Raw and serialized data file sizes are all in the same ballpark, with an aggregate reduction of 736KB. See below for details:

x86 Instructions
x86_64 Instructions
z80 Instructions
x86 Registers
x86_64 Registers
z80 Registers
Gas Directives

Raw Size (bytes)
4882695
5241289
117347
55149
101735
5047
57010

Serialized Size (bytes)
4557857
4754451
177181
58589
111965
6125
57107

Change
-324838
-486838
+59834
+3440
+10230
+1078
+97

Closes #75

If you store it as a bincode, it could lead to even bigger gains.

If you store it as a bincode, it could lead to even bigger gains.

Thanks, wasn't aware of that crate!


added plot_miles function to analysis.py and multi_accuracy should wo…

…rk given any exp dir

merging this first


[v0.4] Bump both rke and dymamiclistener to their release versions

This updates both dependencies to their release tags, in prep for a webhook v0.4.10 release.

Given that we're in codefreeze can we verify again with hostbusters that the commits for rke aren't impacting webhook? The commits: https://github.com/rancher/rke/compare/v1.5.11-rc4...v1.5.11


Icons doesn't showing

Someone can help me when i put the files in the game folder and then execute the game the icons on the radar doesn't show. I tried pressing f12 key but nothing happens.

I also installed modloader but nothing changes

Are you using an ASI Loader and copying the files to the scripts folder?
I tested this mod on the original version of the game, no mobile or DE.


[BUG] Create VM Form - root disk size dialog is misleading

Describe the bug
The implementation of the root disk slider suggests that the user MUST set a root disk size. This has two problems:

This is not the case and setting a root disk size is conpletely optional and not always possible.
User will not know the original root disk size, and setting a root disk size smaller than the original disk will fail the deployment.

To Reproduce
Steps to reproduce the behavior:

Log in as: User
Go to 'Create Instance'
Select any zone
See Root disk slider

Expected behavior
A clear indication that this is optional is required.
Screenshots

Desktop (please complete the following information):

OS: [e.g. Windows, Mac, iOS, Android with device/screen details if applicable]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

With @davidjumani

listTemplates returns size check and use that to validate root disk size (must be equal to or greater than template size/physical size)
Remove slider, keep it simply a number input
Perhaps discuss and add a switch to say override root disk size and then show the label/input (i.e. don't show it by default, a toggle/switch shows the input)

With @davidjumani

reviewed on-screen with DJ - fix  LGTM


Error when building release

Hi, I think you have to remove the '"./" +' from the dist path resolve. thank you
15:46:24 PM [vite-plugin-tauri]  tauri-cli_windows.exe download Completed.
Error: Unable to find your web assets, did you forget to build your web app? Your distDir is set to ""../C:\Users\xxxx\projects\app\project\dist""
edit
well I tried removing it  and now it builds but the ui is just blank not rendering. I  am on windows 10.  I tried debug build and same thing happens and no error messages  in the ui or backend

v0.1.10 is published with the fix. Unfortunately wasn't able to test it so let me know if it works.

thx, now it builds. but it is just a white page app. this might not be a problem related to this project, so please do a test you self when you have time. I will debug it some more

Okay it turns out doing the following fixes the problem
config: {
      build: {
        distDir: "../dist",//(await resolveConfig({}, "build", "production")).build.outDir
      }
    }

so now you know as well ;) I have not found the reason for this. but you must have had a reason not to hard code the path like this right?

I am currently away for another two weeks and can't test this. I am trying to fix this on my phone on the go.
I can't hardcode ../dist because users can change that in vite.config.js.
It seems that tauri-cli doesn't handle absolute paths correctly which what (await resolveConfig({}, "build", " production")).build.outDir returns so I think it needs to be fixed upstream in tauri.
Anyways I released version v0.1.13 with the fix (hopefully).

Thanks again  :) it works now. Hope you have not stressed yourself too hard

Not at all, thanks for reporting back.


Rubocop server crashing when it attempts to restart

Expected behavior
When running a Rubocop server, I expect that it needs to occasionally restart, and does so seamlessly without crashing or needing additional inputs from me.
Actual behavior
It crashes on attempting to restart. If I kill the server, it automatically restarts on the next run, and does work until any code change. At that point, the crashes begin again. I see this behavior both on the command line, and in my IDE (Jetbrains RubyMine). Once occurring, all Rubocop commands will crash, including switches like -V and -h.
We've used Rubocop for years with this setup and haven't any issues like this. My teammates are also not seeing the issue. One potential difference is that I am on Linux and they are on MacOS, but it's unclear why that would suddenly cause a problem after almost 5 years. This feels like an issue specific to my system, but nothing seems to work.
RuboCop version incompatibility found, RuboCop server restarting...
/home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/socket_reader.rb:36:in `ensure in read!': undefined method `string' for nil:NilClass (NoMethodError)

        Cache.stderr_path.write(stderr.string)
                                      ^^^^^^^
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/socket_reader.rb:37:in `read!'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:90:in `read_socket'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:65:in `block in process_input'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/cache.rb:150:in `write_pid_file'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:64:in `process_input'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:53:in `block in detach_server'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:46:in `fork'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:46:in `detach_server'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:38:in `start'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/client_command/start.rb:42:in `block in run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/cache.rb:137:in `acquire_lock'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/client_command/start.rb:29:in `run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/cli.rb:93:in `run_command'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/cli.rb:83:in `process_arguments'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/cli.rb:49:in `run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/exe/rubocop:8:in `<top (required)>'
        from /home/mpd/.asdf/installs/ruby/3.2.2/bin/rubocop:25:in `load'
        from /home/mpd/.asdf/installs/ruby/3.2.2/bin/rubocop:25:in `<top (required)>'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli/exec.rb:58:in `load'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli/exec.rb:58:in `kernel_load'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli/exec.rb:23:in `run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli.rb:484:in `exec'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli.rb:31:in `dispatch'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli.rb:25:in `start'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/exe/bundle:48:in `block in <top (required)>'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/friendly_errors.rb:103:in `with_friendly_errors'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/exe/bundle:36:in `<top (required)>'
        from /home/mpd/git-sources/double_loop/bin/bundle:113:in `load'
        from /home/mpd/git-sources/double_loop/bin/bundle:113:in `<main>'
/home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/socket_reader.rb:27:in `read!': uninitialized constant RuboCop::Server::SocketReader::StringIO (NameError)

        stderr = StringIO.new
                 ^^^^^^^^
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:90:in `read_socket'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:65:in `block in process_input'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/cache.rb:150:in `write_pid_file'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:64:in `process_input'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:53:in `block in detach_server'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:46:in `fork'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:46:in `detach_server'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/core.rb:38:in `start'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/client_command/start.rb:42:in `block in run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/cache.rb:137:in `acquire_lock'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/client_command/start.rb:29:in `run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/cli.rb:93:in `run_command'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/cli.rb:83:in `process_arguments'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/cli.rb:49:in `run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/exe/rubocop:8:in `<top (required)>'
        from /home/mpd/.asdf/installs/ruby/3.2.2/bin/rubocop:25:in `load'
        from /home/mpd/.asdf/installs/ruby/3.2.2/bin/rubocop:25:in `<top (required)>'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli/exec.rb:58:in `load'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli/exec.rb:58:in `kernel_load'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli/exec.rb:23:in `run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli.rb:484:in `exec'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli.rb:31:in `dispatch'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli.rb:25:in `start'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/exe/bundle:48:in `block in <top (required)>'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/friendly_errors.rb:103:in `with_friendly_errors'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/exe/bundle:36:in `<top (required)>'
        from /home/mpd/git-sources/double_loop/bin/bundle:113:in `load'
        from /home/mpd/git-sources/double_loop/bin/bundle:113:in `<main>'
bundler: failed to load command: rubocop (/home/mpd/.asdf/installs/ruby/3.2.2/bin/rubocop)
/home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/client_command/exec.rb:53:in `status': RuboCop server: Could not find status file at: /home/mpd/.cache/rubocop_cache/server/home+mpd+git-sources+double_loop/status (RuntimeError)
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/lib/rubocop/server/client_command/exec.rb:27:in `run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.66.1/exe/rubocop:12:in `<top (required)>'
        from /home/mpd/.asdf/installs/ruby/3.2.2/bin/rubocop:25:in `load'
        from /home/mpd/.asdf/installs/ruby/3.2.2/bin/rubocop:25:in `<top (required)>'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli/exec.rb:58:in `load'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli/exec.rb:58:in `kernel_load'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli/exec.rb:23:in `run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli.rb:484:in `exec'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli.rb:31:in `dispatch'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/cli.rb:25:in `start'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/exe/bundle:48:in `block in <top (required)>'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/lib/bundler/friendly_errors.rb:103:in `with_friendly_errors'
        from /home/mpd/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.7/exe/bundle:36:in `<top (required)>'
        from /home/mpd/.asdf/installs/ruby/3.2.2/bin/bundle:25:in `load'
        from /home/mpd/.asdf/installs/ruby/3.2.2/bin/bundle:25:in `<main>'

Steps to reproduce the problem

Run rubocop when server is not already running. (Should start the server, and run normally)
Make any code change.
Run rubocop again. Crashes forever.

RuboCop version
1.68.0 (the trace above shows 1.66.1, but I did update everything to verify - it crashes in the exact same way)
I've also tried purging all rubocop-family gems, then bundle installing, but no. This really feels like something on my system,
but I am very confused as to what it could be. Any hints on debugging this?
The /home/mpd/.cache/rubocop_cache/server/home+mpd+git-sources+double_loop/status file mentioned is missing, but all the other files are in that directory (i.e. lock, pid, port, stderr, token, version). I don't know where the status file comes from, or why it's missing.
Include the output of rubocop -V or bundle exec rubocop -V if using Bundler.
1.66.1 (using Parser <IP_ADDRESS>, rubocop-ast 1.32.3, running on ruby 3.2.2) [x86_64-linux]
  - rubocop-factory_bot 2.25.1
  - rubocop-graphql 1.5.4
  - rubocop-i18n 1.14.6
  - rubocop-performance 1.21.1
  - rubocop-rails 2.25.1
  - rubocop-rspec 2.29.2
  - rubocop-rspec_rails 2.28.3
  - rubocop-thread_safety 0.5.1

rubocop-graphql, rubocop-performance, and rubocop-rails have all had patch updates since everything was last working for me, but I tried a full purge-and-rollback, and it still failed, indicating to me that it might be some sysconfig issue, but no idea what it could be all of a sudden.

I can't reproduce this, can you show the stacktrace from 1.68? There have been two PRs which should have prevented this error: https://github.com/rubocop/rubocop/pull/13234 and https://github.com/rubocop/rubocop/pull/13379

Ok, this time I purged, updated to 1.68, and killed the 1.66.1 server by hand. At this point, 1.68 runs and no longer crashes on code changes. I think before I had not killed the 1.66.1 server manually before trying with 1.68.
tl; dr I think this is resolved. Sorry for the falsish alarm.

Yes, at that point you can't even close it anymore with rubocop --stop-server and have to kill it manually. I'm not too deep into the server to explain why that happens but it does :shrug:. You probably bumped the psych gem to 5.2.0 which made you run into this.

Yes, at that point you can't even close it anymore with rubocop --stop-server and have to kill it manually. I'm not too deep into the server to explain why that happens but it does 🤷. You probably bumped the psych gem to 5.2.0 which made you run into this.
Ah, actually, you might have started rubocop 1.66 with the new psych version. That would do it I think.

This is exactly what bit me today, and then went in a very long series of loops trying to find this thread :) Our app uses standard so we are stuck waiting for that to update to a newer rubocop, but glad to see a fix is waiting for us eventually.


o1vm/pickles: Add the verifier

Converting into a draft as it doesn't seem to be ready.

Need some help testing this.  It compiles now, but I'm pretty sure I forgot stuff and it's not correct.

Beside changing the assert for the quotient and adding a test, LGTM

Ready for final review.

Note to future viewers of this commit: Consider my commits verified; marc rebased our changes and that's why they aren't signed anymore.

@dannywillems Let me know if you want more changes or can approve.  Should be good, pending CI now.


Claims: Fix Primary Navigation

Context

We want to ensure that the Primary Navigation is always full screen width.
When the Primary Navigation immediately follows the Phase Banner, the Phase Banner's bottom border should be hidden.

Changes proposed in this pull request

I've had to update the school scoping, as we've updated SupportUser models to no longer have the #schools association - which was admittedly wrong anyway. A support user does not belong to a school, they manage all schools.

This allows support users to view all user-facing school pages.
Uses the https://github.com/varvet/pundit gem.

Guidance to review

Link to Trello card

Things to check

[ ] If the code removes any existing feature flags, a data migration has also been added to delete the entry from the database
[ ] This code does not rely on migrations in the same Pull Request
[ ] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[ ] If this code adds a column to the DB, decide whether it needs to be in analytics yml file or analytics blocklist
[ ] API release notes have been updated if necessary
[ ] If it adds a significant user-facing change, is it documented in the CHANGELOG?
[ ] Required environment variables have been updated or added to the Azure KeyVault

Screenshots

 Fix fiddly banners

Started a PR for the ADR at https://github.com/DFE-Digital/itt-mentor-services/pull/212


[e2e]: generic schedule main multi-uses slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/10571512542
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.schedule.main.multi-uses.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.schedule.main.multi-uses.slsa3.yml
Trigger: schedule
Branch: main
Date: Tue Aug 27 04:10:16 UTC 2024

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/10590004648
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.schedule.main.multi-uses.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.schedule.main.multi-uses.slsa3.yml
Trigger: schedule
Branch: main
Date: Wed Aug 28 04:11:13 UTC 2024
Tests are passing now. Closing this issue.


parser: Issue parsing slice types in templ expressions

Hi,
First - I couldn't think of a better title for the issue since I'm not yet sure what's happening. I'm sorry about that.
The latest version (v0.2.648) of templ seems to be having issues with slice types / slices in some cases. I've tried to produce a small example of the issue:
package example

import (
	"fmt"
)

templ componentA(x func()) {
}

templ Example() {
	@componentA(func() {
		fmt.Println(make([]int))
	})

}

If this is placed in an example.templ file templ generate produces the following error:
example/example.templ source formatting error: 51:1: expected statement, found '.'

If I replace the []int type with something else that isn't a slice type (i.e., map[string]string) it works fine.
Replacing the make call with something else, like a string, works fine as well.
I've also opened a thread for this on Slack where @joerdav stated https://github.com/a-h/templ/blob/main/parser/v2/goexpression/parse_test.go#L474 as a related resource (parsing tests, which are probably missing cases related to this).
Go version: go version go1.22.1 darwin/arm64
templ version: v0.2.648

Here's another example.
This is fine:
package inventory

templ componentA(x func(y int) []string) {
}

templ componentB() {
	@componentA(func(y int) []string {
		return []string{"hi"}
	})
}

This isn't:
package inventory

templ componentA(x func(y []int) string) {
}

templ componentB() {
	@componentA(func(y []int) string {
		return "hi"
	})

}

It seems to have something to do with inputs / input types.


support crawl-delay

added support of crawl-delay
behavior :

the function delay() returns an Option
the value is the smallest crawl-delay for the current domain, or None

Solves issue #1

Thanks for the pull request! This looks useful, I don't know if it needs to be its own feature but that's alright for now.


Update Isolasi Mandiri Page “isolasi_mandiri_page”

Automatically generated by Netlify CMS

please ignore, testing Cloudinary CMS integration for #556


chore (deps): update to expo v39

This is just an initial work to successfully upgrade Polaris to use expo v39 and fix all breaking tests.
What's been done:

Multiple test were breaking because jsdom was missing the matchMedia api. Mocking the function through the jest setup file fixes the issue.

What to do:

@testing-library/react-native needs to be upgraded too (guide here) or mobile tests won't work. Doing so introduces various breaking changes (especially in the platform-utils.native.js file), so a bunch of refactoring is required.

please link this to the issue


[FEATURE] don't fail with untracked files

Is your feature request related to a problem? Please describe.
Not sure if this is a feature request or a bug, but I can't really do much with cog if there any untracked files in a repo.
❯ cog bump --auto -d
Error: Untracked files :
	new: cog.toml

nothing added to commit but untracked files present (use "git add" to track)

But that's not an oversight; I don't want to add that file ATM.
And here it fails even when I'm using the -d option.
In other repos, I may have many more untracked files for various reasons, and I don't want to hassle with adding them to .gitignore.
Describe the solution you'd like
Allow me to configure it to turn this off, or document if it already exists (I looked through the docs but didn't find anything).
Describe alternatives you've considered

Just offer a warning, but proceed.
Remove the check entirely ;-)

I don't really have a strong preference of the three solutions, though actually lean towards the first alternative (warning but not error).

Adding an this option would definitely be a great addition.
I also lean toward the first solution.

Because of it seems not possible, to bump and add untracked or changed files (e.g. files with the updated version info) to the following commit in the pre bump hooks, it is unusable for us in our build pipelines.

Hey @oknozor @mcpride @marcbull @bdarcus :)
I wrote the PR that would implement this feature, feel free to take a look and give some feedbacks ;)


Added Priority to the admissioncontrol list

In order to properly support Pod Priorities and Preemption (kubernetes 1.8 https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) we need the Priority admission controler

Already signed the CLA

Hi @zonzamas can you please add the necessary configuration in core/config/templates/cluster.yaml ?
experimental:
  admission:
    priority:
      enabled: false

I guess you mean core/controlplane/config/templates/cluster.yaml right? the other file does not exists

@zonzamas Yes, updated.

Here ... waiting for :green_apple: from travis

Codecov Report

Merging #1066 into master will increase coverage by 0.05%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1066      +/-   ##
==========================================
+ Coverage   35.13%   35.18%   +0.05%
==========================================
  Files          59       59
  Lines        3393     3396       +3
==========================================
+ Hits         1192     1195       +3
  Misses       2039     2039
  Partials      162      162

Impacted Files
Coverage Δ

core/controlplane/config/config.go
60.94% <100%> (+0.14%)
:arrow_up:

Continue to review full report at Codecov.

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

@zonzamas Hi, thanks a lot for contributing!
This looks good but just for clarification - probably you also want --feature-gates=PodPriority=true for apiservers and kubelets to actually enable the PodPriority feature?
Are you willing to address it in a future PR(s) or you just missed it in this PR?

Thank you for kube-aws. Right now I'm enabling pod priority via plugins. I did this one because it seemed like a low hanging fruit. I'm not (yet) familiar with the code base but ill see what i can do. Under which configuration section do you think it should go? Experimental?

@zonzamas Thank you for the response, and trying kube-aws 👍
Oh, you meant a kube-aws plugin?
Btw, reading some code reminded me that there is already worker.nodePools[].featureGates which can be used to add feature gate(s) to kubelet, and controller.featureGates for its controller variant! So, there seem like no need to update the code base.
However, would you mind adding some comment to admissions.priority in cluster.yaml so that you can notice users so that they will also update featureGates?

I will look into that @mumoshu

I have changed things a bit, there are a lot of required flags to enable for Pod Priority to properly work. I have used priority admission control for that... the rest using featureGates.

here are a lot of required flags to enable for Pod Priority to properly work

Yes, everyone would thank you for your efforts 👍

the rest using featureGates.

What was the intention behind that? I guess you'd wanted to enable PodPriority in a subset of many node pools so that you can gradually roll-out PodPriority enabled worker nodes, right? (But not sure if things are really designed to work like that


Updated the project to be compatible with netstandard2.0

No more blocking APIs!
More Fault-tolerant with Polly.
Added Cancellation support.
Improved HTTP client with .NET Core Http Client Pool support for performance.
Using System.Text.Json for Faster serialization.
Improved Testability.

This implementation is great for the ASP.NET Core project and perhaps it's better to create another nuget package called Kavenegar.AspNetCore. for the .NET Core console application setting up ServiceCollection and registering dependencies are cumbersome.


Publish as a package

Publish as a package which users can deploy to their site

Amazing lib guys, any chance to publish it to npm soon ?

@tlvenn we've published the first rc.0 release.
Check it out and let us know if you have any issues with it.

Awesome, thanks guys !

Thanks for the awesome work! I tried to use rc.0 in another project (graphiql-workspace), but faced some issues. It would be great if you could look at it:
https://github.com/OlegIlyenko/graphiql-workspace/issues/17#issuecomment-285722182

any progress on this?

@mydearxym Yes it's already published on NPM: https://www.npmjs.com/package/graphql-voyager
Documented here: https://github.com/APIs-guru/graphql-voyager#using-as-a-dependency
Plus you can use Express, Hapi, Koa middleware:
https://github.com/APIs-guru/graphql-voyager#using-as-a-dependency
@RomanGotsiy It probably makes sense to close this issue?

thanks @IvanGoncharov , but i can't run voyager with next.js project, maybe it's the config issue , i will check it later

@IvanGoncharov yes, closing this
@mydearxym open a separate issue for this!


build: Update Vulkan-Headers and VUL to 1.3.275

CI Vulkan-ExtensionLayer build queued with queue ID 112860.

CI Vulkan-ExtensionLayer build queued with queue ID 112868.

CI Vulkan-ExtensionLayer build # 834 running.

CI Vulkan-ExtensionLayer build # 834 passed.


Properly parse branch name from the reference without /refs prefix

Add debug
Properly parse branch name from the reference without /refs prefix
Wrap parseEnvironmentName test into it

and why is there no ref prefix?

@leonid-shevtsov this is how head_branch sent in workflow_run event. https://github.com/railsware/falcon/runs/2323097152?check_suite_focus=true


About shap-e guidance.

Hi, sorry for bothering,
but I wonder if there are some differences between the original GaussianDreamer repo and this threestudio extension?
Since I found that in the original one they used a finetuned model, here which model is used?
Thank you for that.

You can simply put the pretrained shap-e from GaussianDreamer "shapE_finetuned_with_330kdata.pth" into folder /custom/threestudio-shap-e/shap-e/cache/
It would automatically run with the same shap-e model with code below:
if os.path.exists(os.path.join(self.cfg.cache_dir, self.cfg.finetune_model_name)):
        model.load_state_dict(torch.load(os.path.join(self.cfg.cache_dir, self.cfg.finetune_model_name), map_location=device)['model_state_dict'])

@Colezwhy You can simply put the pretrained shap-e model from GaussianDreamer, "shapE_finetuned_with_330kdata.pth", into the folder /custom/threestudio-shap-e/shap-e/cache/.
And don't forget to change line 26 in /custom/threestudio-shap-e/shap_e.py from
finetune_model_name: str = "finetune_model_name.pt"

to
finetune_model_name: str = "shapE_finetuned_with_330kdata.pth"

It will automatically run with the same shap-e model using the code below:
if os.path.exists(os.path.join(self.cfg.cache_dir, self.cfg.finetune_model_name)):
        model.load_state_dict(torch.load(os.path.join(self.cfg.cache_dir, self.cfg.finetune_model_name), map_location=device)['model_state_dict'])

However, I wonder why the initialized shape looks different when running with MVDream and StableDiffusion, even though they have the same seed.
Still figuring it out.

Thank you for that. Are you using LRM initialization when using MVDream guidance? I do not think there will be anything different in the initialized shape when using different guidance.


error 'sed: 1: extra characters at the end of d command' when using -x option

I get this error when using the -x option on Mac OSX

dupe of #131

brew reinstall --HEAD z from #131 fixed it


Use flutter repo for engine golds instead of flutter-engine.

Closes https://github.com/flutter/flutter/issues/157206.
I also added a prefix that will default to engine. to avoid accidentally stomping on golden names across repos.
/cc @gaaclarke for visibility, @Piinks for visibility.
(I would love to get rid of this "engine copy" of the client as part of longer-term mono repo deduplication).

Why do we have to make this change? Isn't this going to invalidate all of our history? I don't know if there is any benefit of starting to upload our goldens to the flutter golden endpoint.

Engine golden files in flutter/flutter monorepo land will not be able to use the engine instance of Gold. Gold instances are correlated with a repo and track commits only from that repo.

This PR keeps failing in merge queue despite passing in presubmit.
Example failure, 1 of ~200:
stdout: Given image with hash 3f5895ca785071873070f39b6ee018d2 for test engine.canvas_test_toImage
Fetching most recent positive digest for trace with ID "d378d6587de23311f96d6cbdf6daa26f".
No recent positive digests for trace with ID "d378d6587de23311f96d6cbdf6daa26f". This probably means that the test was newly added.
Non-exact image comparison using algorithm "fuzzy" against most recent positive digest "".
Untriaged or negative image

The same test in the presubmit reports the same failure:
NOTE: Untriaged image detected in tryjob.
Triage should be required by the "Flutter Gold" check
stdout:
Given image with hash 43af40a9baa67b933cde8f2dac7f28ac for test engine.canvas_test_toImage
Expectation for test: 3f5895ca785071873070f39b6ee018d2 (positive)
Fetching most recent positive digest for trace with ID "3c059772c4ee1ae45c84a335b2849854".
No recent positive digests for trace with ID "3c059772c4ee1ae45c84a335b2849854". This probably means that the test was newly added.
Non-exact image comparison using algorithm "fuzzy" against most recent positive digest "".
Untriaged or negative image

... but the flutter-gold check is not reporting anything.
It's worth noting I see the "double patchset" which in the past has meant bad state has occurred somehow:

I've confirmed that in post submit this always fails (missing expectation positives), and in pre-submit it always succeeds.

In presubmit:
stdout: Given image with hash 56846d7bfde5b4cc3d9c0d7ca50a8ebd for test engine.canvas_test_blurred_rendering_with_mirror_tile_mode
Expectation for test: 22bdae3366549bc9d7944191fc03c5b1 (positive)
Expectation for test: 56846d7bfde5b4cc3d9c0d7ca50a8ebd (positive)
Test: engine.canvas_test_blurred_rendering_with_mirror_tile_mode PASS

In postsubmit:
stdout: Given image with hash 56846d7bfde5b4cc3d9c0d7ca50a8ebd for test engine.canvas_test_blurred_rendering_with_mirror_tile_mode
No recent positive digests for trace with ID "d8d7cc4f56fc43ecbefd13ce58660be9". This probably means that the test was newly added.

... same hash, but only finds a match in presubmit, not post-submit.


Feature request: Make it possible to configure default hooks

It would be useful to be able to mark some hook (such as save_form_submission_data) to be selected by default.
We have noticed that some content editors forget to select this and we only use streamforms to save the contents of the form.

I feel the best way to solve this is to support swapping the Form model for a custom one. This way, you'd be in complete control. If you know what you're doing, you can override the edit handler instance and change the base form class on the Form model. But, a swapple model would be nicer. It appears some efforts have been made to support this, but the changes are not yet respected throughout.


PrjFSKextLogDaemon: Don't log every time a dropped kext message is detected

Resolves #1326
When developers add a lot of extra logging to the kext, it can result in a lot of dropped log messages, and the daemon log logging each time this occurred.  This lead to a lot of extra log messages about messages being dropped.
To avoid generating so much logging, the behavior of the daemon has been updated:

The first time (in each 30 minute interval) that the daemon detects a missing log message it will log an error
Every 30 minutes the daemon will record the total number of missed messages in the last interval and reset the count.

TODO

[X] Manually test changes with dropped messages

Sample logging (with the daemon's logging interval shortened to 2 minutes):

@wilbaker the premises here is great.  If we dropped one message, the probably of dropping more goes up and we don't want to log a ridiculous amount of times that we dropped a message.
That said this was exposed by a developer testing by entering lots of log messages.  I think we should agree a strategy for developers to use for logging in test.  We certainly wouldn't want any of the 'test' messages the user entered coming up in telemetry either.
I know commenting out the WriteJson is one method, is there a simple env variable we can change possible?  If you aren't sure I can ask around here :-)

That said this was exposed by a developer testing by entering lots of log messages. I think we should agree a strategy for developers to use for logging in test. We certainly wouldn't want any of the 'test' messages the user entered coming up in telemetry either.
I know commenting out the WriteJson is one method, is there a simple env variable we can change possible? If you aren't sure I can ask around here :-)

@jeschu1 the logging daemon will only report errors to telemetry, and so I think the easiest option would be log test messages at the INFO or DEFAULT levels:
// Log message levels, these correspond to their os_log counterparts
enum KextLog_Level : uint32_t
{
    KEXTLOG_ERROR = 0,   // For important failures, always gets logged and causes INFO messages to be committed too.
    KEXTLOG_DEFAULT = 2, // Run-of-the-mill messages that shouldn't be too frequent as they always are logged to disk.
    KEXTLOG_INFO = 1,    // Verbose logging that might help with diagnosing problems; these don't usually get logged to disk, except when an ERROR is loggod.
};

/azp run GitHub VFSForGit Mac Functional Tests


Through the way that proto is fully error on event

@cxp-13 ➜ /workspace (main) $ substreams build
Building manifest file: /workspace/substreams.yaml
Running command in /workspace: `substreams protogen /workspace/substreams.yaml --exclude-paths sf/substreams/rpc,sf/substreams/v1,sf/substreams/sink,sf/substreams/index,sf/substreams/index/v1,instructions.proto,transactions.proto,google`...
Error: reading manifest "/workspace/substreams.yaml": unable to get package: unable to convert manifest to package: loading protobuf: error parsing proto files ["program.proto"] (import paths: ["/workspace/proto" "/workspace"]): program.proto:157:17: syntax error: unexpected '='
Error: error running protogen: error running protogen: error running `substreams protogen /workspace/substreams.yaml --exclude-paths sf/substreams/rpc,sf/substreams/v1,sf/substreams/sink,sf/substreams/index,sf/substreams/index/v1,instructions.proto,transactions.proto,google`: exit status 1
@cxp-13 ➜ /workspace (main) $ substreams build
Building manifest file: /workspace/substreams.yaml
Running command in /workspace: `substreams protogen /workspace/substreams.yaml --exclude-paths sf/substreams/rpc,sf/substreams/v1,sf/substreams/sink,sf/substreams/index,sf/substreams/index/v1,instructions.proto,transactions.proto,google`...
Error: reading manifest "/workspace/substreams.yaml": unable to get package: unable to convert manifest to package: loading protobuf: error parsing proto files ["program.proto"] (import paths: ["/workspace/proto" "/workspace"]): program.proto:159:9: symbol "substreams.v1.program.LendingAccountBorrowEvent" already defined at program.proto:20:9
Error: error running protogen: error running protogen: error running `substreams protogen /workspace/substreams.yaml --exclude-paths sf/substreams/rpc,sf/substreams/v1,sf/substreams/sink,sf/substreams/index,sf/substreams/index/v1,instructions.proto,transactions.proto,google`: exit status 1

It generate program.proto has problem, when execute substreams init and choose the sol-anchor-beta      - Given an Anchor JSON IDL, create a Substreams that decodes instructions and events Through the way that proto is fully error on event
message LendingAccountBorrowEvent {
  string trx_hash = 1;
}

generated two same message
message LendingAccountBorrowEvent {
      AccountEventHeader header = 1;
      string bank = 2;
      string mint = 3;
      uint64 amount = 4;
}

@cxp-13 ➜ /workspace (main) $ substreams build
Building manifest file: /workspace/substreams.yaml
Running command in /workspace: `substreams protogen /workspace/substreams.yaml --exclude-paths sf/substreams/rpc,sf/substreams/v1,sf/substreams/sink,sf/substreams/index,sf/substreams/index/v1,instructions.proto,transactions.proto,google`...
Error: reading manifest "/workspace/substreams.yaml": unable to get package: unable to convert manifest to package: loading protobuf: error parsing proto files ["program.proto"] (import paths: ["/workspace/proto" "/workspace"]): program.proto:157:17: syntax error: unexpected '='
Error: error running protogen: error running protogen: error running `substreams protogen /workspace/substreams.yaml --exclude-paths sf/substreams/rpc,sf/substreams/v1,sf/substreams/sink,sf/substreams/index,sf/substreams/index/v1,instructions.proto,transactions.proto,google`: exit status 1

There are even missing parts:
message LendingAccount {
       balances = 1;
}

Should be :
message LendingAccount {
     repeated Balance  balances = 1;
}

My IDL File: https://gist.github.com/cxp-13/3e5b6880cdd218d1fc4d35d8fe249641
The generated proto file: https://gist.github.com/cxp-13/7173242746d4f07ecc68ae599411f080

Seems not a graph-client issue.

Seems not a graph-client issue.

I can't find the substreams repo, so I temporarily put the issue here.

idl::idl::program::events::LendingAccountLiquidateEvent::DISCRIMINATOR => {
                                if let Ok(event) =
                                    idl::idl::program::events::LendingAccountLiquidateEvent::deserialize(
                                        &mut &slice_u8[8..],
                                    )
                                {
                                    lending_account_liquidate_event_list.push(LendingAccountLiquidateEvent {
                                        trx_hash: transaction.id(),
                                    });
                                }
                            }

In src/lib.rs, the event just used trx_hash, so I removed the other message and the building process was successful.
message LendingAccountBorrowEvent {
     AccountEventHeader header = 1;
     string bank = 2;
     string mint = 3;
     uint64 amount = 4;
}


Upload faling on windows-latest with EBUSY

I'm using this action to release binaries from a matrix CI workflow building on macOS, linux and windows. The windows job is failing with the following error:
EBUSY: resource busy or locked, lstat 'D:\pagefile.sys'

The other two are working just fine. Is action-gh-release supported on a windows build?

It looks like you are trying to include all files at the root of your file system with/*. This is likely not what you want. You could try a relative path. This should be relative to the working directory of  your checkout.

Thanks for sharing this awesome GH Action @softprops!
Oh that is definitely not what I want. The workflow is defined exactly like this:
    - name: Setup env
      run: |
        echo ::set-env name=OUTPUT_DIR::$(make show-output-dir)
    - name: Release cli
      if: startsWith(github.ref, 'refs/tags/')
      uses: softprops/action-gh-release@v1
      with:
        files: ${{ env.OUTPUT_DIR }}/*
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Where OUTPUT_DIR is the relative path of the output folder. This exact workflow works on macOS and linux. Maybe something related to the use of environment variables being broken in the Windows setup. It seems the variable was properly set:

Could it be the env is not being passed down to the action code? I'm not sure at which point the context ${{ env.OUTPUT_DIR }} is resolved.

Could it be the env is not being passed down to the action code?

That would be my theory. I don't think env gets inherited between steps by default
I'd try some experiments like setting it explicitly
Or adding a debug step in between
with:
        files: ${{ env.OUTPUT_DIR }}/*
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
       OUTPUT_DIR: ${{ env.OUTPUT_DIR }}

The docs say it should be available https://help.github.com/en/actions/reference/workflow-commands-for-github-actions#setting-an-environment-variable
Either way I'd run some experiments to see if there's a way to be more explicit and work backwards to implicit


RFC: Client request pipelining

Currently, client_write() sends the request to openraft via mpsc channel, which spools (potentially many) requests. The openraft core works on batches of requests and produces batches of responses. However, on the client_write() side, each task has to explicitly await the client_write().
To improve things, one could think about multiple solutions.
What immediately comes to mind is to use another mpsc channel, where the consumer of replies can consume them at its own pace (also pipelined). However, this would probably require major rework and I don't know whether we can integrate it with existing API. So I don't think this is the way to go.
What we already have, is a semi-abstraction of reply handling - sending the reply via oneshot channel. So my suggestion would be the following:
Instead of hard-coding a oneshot channel to send the reply back, the RaftMsg::ClientWriteRequest would require a new type ReplyConsumerType: ReplyConsumer or so on the config for tx.
The ReplyConsumer would be something like this:
trait ReplyConsumer<D, R> {
    fn from_request(request: D) -> (D, Self);
    fn request_completed(self, R);
}

so it can be built from AppData. The only additional change in openraft would be to use tx.request_completed() instead of tx.send() to send a reply to ClientWriteRequest.
The default implementation of ReplyConsumer would internally create and use oneshot channel and implement a Future (basically, wrapping the request as is done today). This would require zero change to the user code (beyond specifying the default type for ReplyConsumer).
If the user uses the default implementation for ReplyConsumerType, then client_write() would be simply enabled by where ReplyConsumerType: Future. There would be no change to the client. Of course, the user is also free to create a different implementation which implements Future, so client_write() can be used also with custom implementation.
A second, synchronous API client_write_ff() (or so, ff for fire-and-forget) would not require implementing Future, instead it would rely on the implementation of ReplyConsumer doing the "right thing" to send the reply for further pipelined processing (e.g., via posting to a user-specific mpsc channel spooling replies).
With this fairly small change, we could enable fully-pipelined processing also in the caller of client_write() w/o resorting to a workaround with task-per-request.
Thoughts?

If the user uses the default implementation for ReplyConsumerType,

I have a general understanding of your concept.
It seems that ReplyConsumer is an internal component of Openraft.
Could you explain whether and how a user can decide to utilize the default implementation of ReplyConsumerType?
Additionally, would you be able to provide the method signatures for the revised client_write() and client_write_ff() functions?

No, ReplyConsumer is a public trait, which can be implemented by the user as needed (for example, we'd push replies into reorder buffer reordering them with read-only requests on the same client connection). But, to ease the implementation, I'm suggesting to provide something like DefaultReplyConsumer which implements ReplyConsumer and Future and internally uses oneshot channel. The type config would specify which reply consumer to use.
As for the signature, it would be:
    pub async fn client_write(
        &self,
        app_data: C::D,
    ) -> Result<ClientWriteResponse<C>, RaftError<C::NodeId, ClientWriteError<C::NodeId, C::Node>>>
    where C::ReplyConsumer: Future<Output = Result<
        ClientWriteResponse<C>,
        RaftError<C::NodeId, ClientWriteError<C::NodeId, C::Node>>
    >>;

    pub fn client_write_ff(&self, app_data: C::D);

The only suboptimal thing is that you can call client_write_ff also with the default reply consumer. OTOH, it would do exactly what it says - fire and forget. The response and any potential error would be lost, so probably not a big deal.

I see that Openraft calls ReplyConsumer::request_completed() to send back the response. But why does it needs a D to create a ReplyConsumer with ReplyConsumer::from_request(D)?

From the method signature I do not see how a user get an instance of ReplyConsumer, then who will poll the Future of ReplyConsumer?

But why does it needs a D to create a ReplyConsumer with ReplyConsumer::from_request(D)?

The idea is to pass additional information "hidden" in D, which allows us to create the consumer. For example, the queue where to put the reply. Otherwise the reply consumer be stateless, which is not what we want. Alternatively, one could pass reference to SM or similar, where it could be hidden as well. But, some form of context for the reply consumer is needed.

From the method signature I do not see how a user get an instance of ReplyConsumer, then who will poll the Future of ReplyConsumer?

The user won't get the instance. The Future is polled within client_write(), same as today with oneshot::Receiver and client_write() would still return C::R. I.e., in the default case it will produce exactly the same binary code as we have today.
In the other case where the user implements ReplyConsumer, say, to post responses to a queue, the ReplyConsumer::request_completed() will be called with the response and then the user is free to do with the reply whatever he pleases (in this case, post the response to some queue, which was noted down when creating the ReplyConsumer based on the context).

Make sense.
The abstraction for queuing replies is an elegant design. 👍

@schreter
Isn't there an issue with the Future implementation for ReplyConsumer?
The instance of ReplyConsuemr will be sent to RaftCore so that RaftCore send back the reply via it.
Thus the Future should not be implemented for ReplyConsumer but instead, it should be implemented for another instance like a receiver.
The ReplyConsumer API would be like the following: from_request builds a ReplyConsumer and a receiver Future.
pub type AppDataResult<C> = Result<(LogIdOf<C>, ROf<C>), ForwardToLeader<C>>;

#[derive(Debug, Clone, thiserror::Error)]
#[error("The response consumer has been closed.")]
pub struct Closed;

pub trait ReplyConsumer<C>: OptionalSend + 'static
where C: RaftTypeConfig
{
    fn from_request(
        app_data: C::D,
    ) -> (
        C::D,
        Self,
        Option<impl Future<Output = Result<AppDataResult<C>, Closed>>>,
    )
    where Self: Sized;

    // ...
}

Make sence?

The ReplyConsumer API would be like the following: from_request builds a ReplyConsumer and a receiver Future.

You are right, we need two objects, one that we send to consume the reply (e.g., send it over oneshot channel) and one to await in/return back to the caller. That also helps with defining the "other" API:
pub trait ReplyConsumer<C>: OptionalSend + 'static
where C: RaftTypeConfig
{
    /// The type generated for the send side, which may be a `Future`.
    /// (the name is preliminary, it's suboptimal)
    type SendResult;

    fn from_request(
        app_data: C::D,
    ) -> (
        C::D,
        Self,
        Self::SendResult,
    )
    where Self: Sized;

    // ...
}

impl Raft {
    // ...

    pub async fn client_write(
        &self,
        app_data: C::D,
    ) -> Result<ClientWriteResponse<C>, RaftError<C::NodeId, ClientWriteError<C::NodeId, C::Node>>>
    where C::ReplyConsumer::SendResult: Future<Output = Result<
        ClientWriteResponse<C>,
        RaftError<C::NodeId, ClientWriteError<C::NodeId, C::Node>>
    >>;

    pub fn client_write_ff(&self, app_data: C::D) -> C::ReplyConsumer::SendResult;

    // ...
}

I.e., the client_write() version with Future result would just await the future, but even if you'd use client_write_ff() with Future-based SendResult, it would be well-formed. You could await the future yourself somewhere else (e.g., send multiple requests and then join! them and the like).
Then, client_write() would be just a thin wrapper:
    pub async fn client_write(
        &self,
        app_data: C::D,
    ) -> Result<ClientWriteResponse<C>, RaftError<C::NodeId, ClientWriteError<C::NodeId, C::Node>>>
    where C::ReplyConsumer::SendResult: Future<Output = Result<
        ClientWriteResponse<C>,
        RaftError<C::NodeId, ClientWriteError<C::NodeId, C::Node>>
    >> {
        self.client_write_ff(app_data).await
    }

Make sense