Add parseJson function

Adds the parseJsonArray and parseJsonObject functions. Useful if the you have an environment variable like MYCONFIG='{"enabled":true,"features":["foo","bar"]}'. I was inspired by INTERLOCK_CONFIG in https://github.com/ehazlett/interlock
This includes the changes from #63.

I think this can actually be a single function. Closing for the moment.

Thanks!

:beers:


Compilation of etcd-aws-cfn fails

Per the documentation, I ran "go install ./..." in the project directory to install the etcd-aws-cfn tool. I got this error:
go install ./...
# github.com/crewjam/etcd-aws/aws
aws/health.go:24: cannot use cloudformation.String("1") (type *cloudformation.St
ringExpr) as type *cloudformation.IntegerExpr in field value
aws/health.go:33: cannot use cloudformation.String("60") (type *cloudformation.S
tringExpr) as type *cloudformation.IntegerExpr in field value
aws/health.go:54: cannot use cloudformation.String("1") (type *cloudformation.St
ringExpr) as type *cloudformation.IntegerExpr in field value
aws/health.go:63: cannot use cloudformation.String("300") (type *cloudformation.StringExpr) as type *cloudformation.IntegerExpr in field value

I replaced cfn.String with cfn.Integer in health.go, and compilation succeeded. I am going to test to make sure the tool works as expected, then I'll submit a pull request.

Excellent, thanks!
This is due to upstream changes in go-cloudformation which is in turn due to upstream changes AWS have made in their definition of the CFN schema, so you're on the right track.


llama: preserve field order in user-defined JSON schemas

llama: preserve field order in user-defined JSON schemas
Previously we decoded and re-encoded JSON schemas during validation,
which served no purpose since json.RawMessage already validates JSON
syntax. Worse, the re-encoding lost field ordering from the original
schema, which affects inference quality during step-by-step reasoning.
While fixing this ordering issue by using json.RawMessage directly,
testing revealed that schema_to_grammar (from llama.cpp) also fails to
preserve field order during grammar generation. This appears to be the
root cause of inference degradation.
This change prevents us from mangling the user's original schema order,
but we still need to address the ordering issue in schema_to_grammar.
That will be a separate change.
Updates #7978

@bmizerany, llama.cpp's json-schema-to-grammar already ensures that the order is being preserved by using nlohmann::ordered_json. These PRs were opened in the past and kept the original key ordering while still relying on that facility:
#7588
#6658

Skipping schema_to_grammer tests in prep for @ParthSareen's work on patching. Ready to merge.


evokeds should end with evo, not ave - for mne-python to be happy

It is the other way around :-) They should end with -ave, not -evo.


Issue with fileClass

Version: 0.3.9
Install method: Obsidian Plugins
System Info: arch x86_64
OS: Linux
Kernel Version: 5.15.0-46-generic #49~20.04.1-Ubuntu SMP

I have a fileClass called datastax-case.  This file class is working on one note but not another unless the fileClass is in frontMatter by itself.
No other fileClass seems to have this issue.
With fileClass in frontmatter populated with other metadata.

As you can see, the metadata menu icon does not appear.
However, if I place the fileClass in frontmatter by itself it works.

However, even if I  join the working fileClass with the existing  frontmatter it stops working again.

The only thing changed in the above picture was to remove the dividers and remove the existing fileClass parameter from the old frontmatter.
It just seems to be this one note.
I am also using tag based fileClass as well. But that seems to have stopped working even for other notes.
However, I do have case notes which work fine.

Here is the fileClass definition
---
mapWithTag: true
tagNames: []
---

case_id:: {"type":"Input","options":{}}
salesforce_link:: {"type":"Input","options":{}}
related_cases:: {"type":"MultiFile","options":{}}
customer:: {"type":"Select","options":{"valuesList":{},"sourceType":"ValuesListNotePath","valuesListNotePath":"Templates/Lists/DataStax Customer List Values.md","valuesFromDVQuery":""}}
product:: {"type":"Multi","options":{"valuesList":{},"sourceType":"ValuesListNotePath","valuesListNotePath":"Templates/Lists/DataStax Product List Values.md","valuesFromDVQuery":""}}
astra_clusters:: {"type":"Input","options":{}}
issue_summary:: {"type":"Input","options":{}}
issue_type:: {"type":"Multi","options":{"valuesList":{"1":"KMIP"},"sourceType":"ValuesList","valuesListNotePath":"","valuesFromDVQuery":""}}
incident:: {"type":"Boolean","options":{}}
status:: {"type":"Select","options":{"valuesList":{"1":"new","2":"investigating","3":"handoff","4":"resolved"},"sourceType":"ValuesList","valuesListNotePath":"","valuesFromDVQuery":""}}
pd_alert:: {"type":"Input","options":{}}
jira_issues:: {"type":"Input","options":{}}
case_subject:: {"type":"Input","options":{}}
product_versions:: {"type":"Multi","options":{"valuesList":{},"sourceType":"ValuesListNotePath","valuesListNotePath":"Templates/Lists/DataStax Product Version List.md","valuesFromDVQuery":""}}

Here is the case template
<%*
let title = tp.file.title
if (title.startsWith("Untitled")) {
title = await tp.system.prompt("Title");
}
await tp.file.rename(title) -%>

<% tp.file.include("[[DataStax Case Frontmatter Template]]") %>

# <% title %>

>[!INFO] Case Info
>case_id:: <% title %>
>case_subject:: <% tp.system.prompt("Case Subject") %>
>salesforce_link:: <% tp.system.prompt("Salesforce Link") %>
>related_cases::
>customer::
>product::
>product_versions::
>astra_clusters:: <% tp.system.prompt("Astra Cluster") %>
>issue_summary:: <% tp.system.prompt("Issue Summary?") %>
>issue_type::
>incident::
>pd_alert::
>jira_issues::
>status::

## Issue Synopsis

## Working Notes
<% tp.file.include("[[Datastax Case - Working Notes Template]]") %>

## Artifacts

``````col
`````col-md
flexGrow: 2.0
===
#### jira Links:

#### Slack Links:

#### Documentation:

flexGrow=3.5
===
#### file links:

#### Possibly Related Cases
```dataview
TABLE case_subject,product_versions,issue_summary,issue_type FROM #datastax-case AND !"Templates" WHERE issue_type = this.issue_type
```

## Generated Documentation

## Resolution Notes

------------------------------------------------

## Metadata fileClass
#datastax-case
```
Please let me know if you need further information.

Thank you.

Hi, I think there's a problem with your record/purpose field: it lacks an ending quote. Therefore the frontmatter is considered as invalid
Could you fix it and try again?

any chance to test this?
i can't reproduce the issue. I'll close it for now


[PLAY-770] fixed. Google fonts should be supported by the player

@shamansir please review.

@shamansir updated

great, thank you a lot!

np :)

I thought you were going to use google font loader. if you don't use it here, then why do we need to use it in the editor?

Hmm, though I haven't discussed that with @vkoresh particularly, but I'd prefer not to use GFL and stay as vanilla as possible, for the sake of the Player "package" size. Also, adding one more remote alien resource loader would require more work to integrate it with Player's own Resource Manager (even while the latter is actually cache/subscribe manager).
Yet if GFL provides truly a lot of speed over this solution, I'd load/add GPL only for projects with Google Fonts, of course.


prep.sh should be more modular

prep.sh actually can do four different things:

Download a MSFT-built SDK
Download MSFT-built previously-source-built artifacts
Additionally download portable packages and insert them into the previously-source-built archive (bootstrap scenario)
Download known prebuilts for the current release (generally previews only)

We should break these out so that the default behavior is to do all four of these things but each individual behavior can be disabled with an argument like --no-sdk or --skip-sdk, etc.

When this issue is completed, we should update the N-1 CI leg to include the --no-sdk option, as the point of that leg is to acquire its own SDK.

Fixed by https://github.com/dotnet/installer/pull/15697


Cannot compile a Scrooge Finagle service

Hello,
Since I upgraded my Scala rules (last version known to work was 21c8913a2cf35130870df9f07a781afc77f33693, from last March), I cannot compile anymore my Thrift services with Scrooge. Creating scrooge_scala_library when the IDL file contains only structs is ok, but I cannot create a library when the IDL file also contains a service.
When trying to compile the target scrooge_scala_library, I get a lot of compilation errors looking like:
error: object finagle is not a member of package com.twitter
Previously, I used to add "//3rdparty/jvm/com/twitter:finagle_thrift" to my deps to bring in the Finagle dependency, but if I do so, I now get another error:
<target //3rdparty/jvm/com/twitter:finagle_thrift> (rule 'scala_import') doesn't contain declared provider 'ThriftInfo'
I couldn't spot any documentation or tests about compiling Finagle Scrooge services, so I am a bit stuck. I can contribute tests/documentation if given a hint about how things are supposed to work. Thanks!

@pvcnt could you possibly submit a failing test?
The problem is we didn't have any tests for this and are clearly not exercising this. :(
I'm afraid the refactor of the rules may have broken thrift services.
You can try to work around with:
https://github.com/bazelbuild/rules_scala/blob/master/twitter_scrooge/twitter_scrooge.bzl#L386
scrooge_scala_import(
  name = "finagle_deps",
  scala_jars = ["//3rdparty/jvm/com/twitter:finagle_thrift"]
)

and then add that as a dep...
However, if that does not work, we may have a bigger problem. Obviously, that's a pain... what we probably need to do is improve a thrift toolchain similar to the scalac provider code so that we can configure which jars are on the classpath by default.

@johnynek Thank you for your response and suggestion.
I created a reproducibility repository here: https://github.com/pvcnt/rules_scala-issue-592 Please use bazel build thrift:service_scala_thrift to try to compile a simple Scrooge service, which fails.
I tried your suggestion, and I have another error:
ERROR: /Users/vincent/workspace/rules_scala-issue-592/thrift/BUILD:20:1: in scrooge_scala_library rule //thrift:service_scala_thrift:
Traceback (most recent call last):
	File "/Users/vincent/workspace/rules_scala-issue-592/thrift/BUILD", line 20
		scrooge_scala_library(name = 'service_scala_thrift')
	File "/private/var/tmp/_bazel_vincent/aaff53d76bc8f1f19b1b4ed957fdcd9f/external/io_bazel_rules_scala/twitter_scrooge/twitter_scrooge.bzl", line 334, in _scrooge_scala_library_impl
		struct(scala = _create_scala_struct(ctx..., ...)])
	File "/private/var/tmp/_bazel_vincent/aaff53d76bc8f1f19b1b4ed957fdcd9f/external/io_bazel_rules_scala/twitter_scrooge/twitter_scrooge.bzl", line 335, in struct
		_create_scala_struct(ctx)
	File "/private/var/tmp/_bazel_vincent/aaff53d76bc8f1f19b1b4ed957fdcd9f/external/io_bazel_rules_scala/twitter_scrooge/twitter_scrooge.bzl", line 356, in _create_scala_struct
		dep[ScroogeAspectInfo].java_info.outputs.jars
object of type 'NoneType' has no field 'jars'
ERROR: Analysis of target '//thrift:service_scala_thrift' failed; build aborted: Analysis of target '//thrift:service_scala_thrift' failed; build aborted
INFO: Elapsed time: 0.125s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (1 packages loaded)

I am not very familiar with complex Bazel rules, but let me know if I can help otherwise (e.g., by contributing tests or documentation).

I encountered a similar exception and got around it by re-binding a group of libraries. I made a PR (which is pending) updating the README on how to do this: https://github.com/bazelbuild/rules_scala/pull/847

It's been four years, I moved on. :)

@pvcnt does that mean to date there is no way to compile bindings for service in thrift using scrooge?

I don't know tbh, I'm not anymore using those rules.


Support using the container standard output as input for the LogProxyConsumer

Enhancement Proposal
Currently, log filenames need to be specified for the LogProxyConsumer to be able to scrap them. It would be nice to support gathering the logs from the containers' standard output, which would be beneficial in several ways:

No need to manage rotation of the logs files
Reduced risk of losing entries in case a container stops between the write and the scraping of the file
Logs could be queried without the logging infrastructure without additional tooling, just by using kubectl
It's the de facto standard

This will likely be very easy for us to support once pebble lands its new log forwarding feature :)

This is exactly what the Pebble Log Forwarding feature aims to solve. Closing this in favor of https://github.com/canonical/pebble/pull/256


Can't restart connection after disconnect

Connection was stopped after internet disappeared (or any another reason). I want to restore connection by command connection.start, but get fail "Starting connection failed - invalid state". That means that connection can't started because it's current state is 'stopped', not 'initial'. (func start() in HttpConnection.swift). Also I can't get current state (if now is not in 'connected') to force stop and start connection.
I think need change logic to like:
        if changeState(from: .initial || .stopped, to: .connecting) == nil {
And would be good to make public state of connection. Thank you.

This is currently by design. Once the connection is stopped it cannot be started. Currently, you will have to create a new connection each time you want to connect to the server. Having said that, I admit that doing this and getting it right is challenging. I started thinking on making the connection re-usable/restartable but it is actually more challenging than changing the condition you pointed to.

And would be good to make public state of connection.

What are the scenarios you need it for?

@moozzyk i am implementing a chat application with your library. Beautiful job you have done i must say but the only challenge i am having is because the connection times out and i have to reopen it everytime...I just put my methods in the viewWillAppear()...but then it is bad userExperience meaning it has to reload all the messages and conversation again anytime a user leaves the messaging tab.

@blavkjay - I think you are discussing a few issues hereL

it has to reload all the messages and conversation again anytime a user leaves the messaging tab.

I have an impression that the connection is being closed because it goes out of scope and is being deinitialized. Make sure you keep a reference to your HubConnection instance for the entire time you expect the connection to the server be open. If you for instance create a HubConnection instance in a function and will not keep the reference as a class variable as soon as you leave the method the local variable will go out of scope and the connection will be closed. The same would happen if the hub connection reference is a class variable but the instance of the class that keeps a reference to the hub connection instance is deinitialized. In your case it feels that you keep the reference to the hub connection on the messaging tab and if the user is leaving the messaging tab it is being cleaned up resulting in deinitializing the hub connection instance and therefore breaking the connection to the server.

the connection times out

In general this should not happen. The underlying connection is using webSockets and the webSocket protocol by default tries to ensure that the connection stays alive. If you see frequent time outs (not really sure what it means - is this disconnects?) the problem can be on the client or on the server. I would recommend turning on logging at the debug level on the client to see what error you get.
You may also want to check if this is not the server that is terminating the connection.

@moozzyk : As you said above This is currently by design. Once the connection is stopped it cannot be started. Currently, you will have to create a new connection each time you want to connect to the server.
I am curious how to create a new connection
var hubConnection = HubConnectionBuilder(url: URL(string: "(mainWebsiteURL)/ChatHub")!)
.withLogging(minLogLevel: .debug)
.withHttpConnectionOptions() { httpConnectionOptions in
        httpConnectionOptions.headers = ["Authorization": "Bearer \(UserDefaults.standard.string(forKey: "AuthorizationToken")!)", "key" : "\(Int.random(in: 0 ..< 9999999))"]
    }
    .build()

hubConnection.start()
This is how I start again, but func connectionDidOpen(hubConnection: HubConnection) { is not getting called because of which I am facing another issue.

@apphardtask  - if this is in a function then when function completes its execution the hubConnection variable will go out of scope and the object it references will be destroyed. You need to keep the reference to the hub connection.

I believe the original question was answered. The reconnect issue is being tracked as #86 and I think it should be resolved now.

I am not too familiar with AutosoftDMS/SignalR-swift but at first glance, it is meant for the old (non-ASP.Net Core) of SignalR. This client works with the ASP.Net Core version of SignalR.
I don't believe there is any significant functionality missing in this implementation.
Please do not comment on unrelated and closed issues but open a new issue.


CTA article addition

Category

[x] Content fix
[ ] New article

What's in this Pull Request?
In response to customer escalations we are adding information about the SPE role

Closing because of version history issues and merge conflicts


Recipes for reproducing "Worst-case forget set in data-wise unlearning"

Hi @ljcc0930 @a-F1 :):)
Not really an issue with the code but an ask. I am trying to reproduce the unlearning evaluations. In appendix B1 you state:
For FT [66], RL [26], EU-k [25], CF-k [25], and SCRUB [39],
the unlearning process takes 10 epochs, during which the optimal learning rate is searched within the range of [10−4, 10−1]. It is not super clear how this should be specified in the main_evalmu.py args since the provided example is for retraining. Also, for the random sets, did you use the same learning rate?
Could you please provide "the recipes" on how to reproduce Table 3 with the current version of the code? A bash or txt file with the launching commands for different methods would be veeery helpful.
I tried with the default rate and scrub but seems that the model is diverging on the unlearning process and does not reproduce.

Thank you for your appreciation and recognition of our work. For selecting the optimal hyperparameters for different unlearning methods, we first perform a grid search on the Random Forget Set and choose the hyperparameters corresponding to the smallest averaging gap (avg.) as the optimal ones. For the same approximate unlearning method on the Worst-Case Forget Set, we use the same values.
We will update the README with commands for different methods as soon as possible. If you have any other questions, please feel free to contact us.

The issue has been closed. If you have any further questions, please feel free to contact us.


Add fine-grained cpu orchestration proposal

Ⅰ. Describe what this PR does
Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews

/lgtm
/approve


chore(sandbox): migrate to nextjs 14

Need to rebase this now that the dependency versions in trunk are pinned to exact versions.


[BUG-77]: Implementing New UI

Large Screens

Small Screens

Profile Page

The sidebar looks really good on the bigger screen!!.. Can the user hide it while they are scrolling on the small screen?

Am still experimenting with whether to leave the sidebar in view even on small screens or have it as a nav menu. Would love some input @leonamagaya @Emmanuel-Melon

Looks great! I think it should be hidden on smaller screens; @leonamagaya, right?

@Emmanuel-Melon  that's right. That way the user can I have an even better view of the content.

@Emmanuel-Melon that's right. That way the user can I have an even better view of the content.

Definitely!


util/install.sh: can't get `--version' info from python -B bin/mn

When installing mininet with the following:

Vagrantfile

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

    config.vm.box = "box-cutter/ubuntu1404-desktop"
    config.vm.provision :shell, :path => "bootstrap.sh"

end

and bootstrap.sh

#!/usr/bin/env bash
sudo apt-get update
sudo apt-get install -y git
if [ ! -d "/home/vagrant/mininet" ]; then
 sudo -u vagrant git clone git://github.com/mininet/mininet
fi
/home/vagrant/mininet/util/install.sh -a

as zipped together in the following folder:
err.zip
I keep encountering the following error:
==> default: Installing Mininet core
==> default: /home/vagrant/mininet /home/vagrant
==> default: cc -Wall -Wextra  -DVERSION=\"`PYTHONPATH=. python -B bin/mn --version`\" mnexec.c -o mnexec
==> default: PYTHONPATH=. help2man -N -n "create a Mininet network." \
==> default:    --no-discard-stderr "python -B bin/mn" -o mn.1
==> default: help2man: can't get `--version' info from python -B bin/mn
==> default: make:
==> default: *** [mn.1] Error 2
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

The problem is that version() is registered as a callback to the OptionParser, which means that when --version is passed, the version() function will be called directly, before any setup can be performed:
opts.add_option( '--version', action='callback', callback=version,
                 help='prints the version and exits' )

In mininet/log.py, the default log level is set to OUTPUT, which does not log INFO messages:
LOGLEVELDEFAULT = OUTPUT

Therefore, the logger used by version() (which hasn't been properly setup) uses the default OUTPUT level, meaning that the version number (an INFO message) is not logged:
def version( *_args ):
    "Print Mininet version and exit"
    output( "%s\n" % VERSION )
    exit()

Thanks, sorry about that.
Fixed in 5470415bfcbb04b94fa17e794d121400708f7705

p.s. Haha I made the same fix - GMTA.

Hahah perfect, thanks for the fix @lantz!


[Bug] handling parenthesis in 0302 rule

What happened?
Parenthesis handling should be considered as a part of concatenated term with rule 0302
*** Test Cases ***
My Test(s) Are Nice
    Execute Command(s)

*** Keywords ***
Execute Command(s)
    No Operation
    Log  ${TEST_NAME}

The above test script should not be considered a violation with (s).
Operating System
Linux
Robocop version
1.12.0

*** Test Cases ***
My Test(s) Are Nice
    Execute Command(s)
    Test Flash(es)
    Recognize Figure(s) (Math) From Picture
    Test Sulfur (S) Concentration

Weird Test
    Test Agile Story(-ies)
    Feed Wolf(-ves)
    Life(-ves) Count Should Be

Questionable Test
    Test Time Input (s)
    Recognize Figure(s) (art) From Picture

*** Keywords ***
Execute Command(s)
    No Operation
    Log  ${TEST_NAME}

Test Agile Story(-ies)
    No Operation

Test Flash(es)
    No Operation

Feed Wolf(-ves)
    No Operation

Life(-ves) Count Should Be
    No Operation

Test Time Input (s)
    No Operation

Recognize Figure(s) (art) From Picture
    No Operation

Recognize Figure(s) (Math) From Picture
    No Operation

Thanks @rikerfi for the report and especially for the test data!
I fixed the rule with the updated regex pattern that now will catch also parenthesis and properly parse keyword/test names.

BTW It will be most likely released with Robocop version 2.1.0


Is there anyone run this successfully under macOS WeChat v3.1+ ?

I have some trouble with frida WeChat.exe under M1 with WeChat MacOS v3.1.5
I have this problem: (I have disabled the SIP and enabled the arm64e, it works with Safari without any problem):
$ frida WeChat
     ____
    / _  |   Frida 15.0.8 - A world-class dynamic instrumentation toolkit
   | (_| |
    > _  |   Commands:
   /_/ |_|       help      -> Displays the help system
   . . . .       object?   -> Display information about 'object'
   . . . .       exit/quit -> Exit
   . . . .
   . . . .   More info at https://frida.re/docs/home/
Failed to attach: process is dead

See: https://github.com/huan/sidecar/issues/1

Hi huan, I don't own an M1 Mac so I cannot help you.
Also, if you have a question about running Frida, please consider opening an issue at https://github.com/frida/frida

Hi, thanks for your quick reply!
Besides the M1 Mac, I have tried the WeChat v3.1.5 on the Intel x86 mac air, which got the same result: Failed to attach: process is dead.
What WeChat version are you using with the wechat-decipher-macos, have you tried the last version and does it works?

Hmmm, that's weird. I just tried the latest version of WeChat and the scripts work on my x86 MacBook Pro. Here is the System Version Information
Device Type: MacBookPro14,1
System Version: Version 10.14.6 (Build 18G9216)
System Language: en
WeChat Version: [2021-07-13 21:38:10] v<IP_ADDRESS> (18851) #9dfb2032a7
WeChat Language: en
Historic Version: [2021-07-06 19:06:06] v<IP_ADDRESS> (18767) #2135c6e07d
Network Status: Reachable via WiFi or Ethernet
Display: *(1440x900)/Retina

@huan
I successfully
M1 Macbook Pro
Big sur Version 11.1
WeChat Version 3.0.1

@c0618 Thank you very much for your information!
I have also succeed with Frida 15.1.11 & WeChat: Version 3.2.1 (19797) on my M1 air, it seems that the latest version of the Frida & WeChat can works together now, cheers!


Add new sql obfuscation mode normalize_only

What does this PR do?
This PR adds new SQL obfuscation mode normalize_only to support normalizing SQL without obfuscating it.
This new mode is useful for customers who want to view unobfuscated SQL statements.
By default, ObfuscationMode is still set to obfuscate_and_normalize and every SQL statement is obfuscated and normalized.

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

@ajgajg1134 we have documented the meaning of different obfuscation mode in DBM integrations, where users can set different obfuscation_mode. (the new option normalize_only will be added once the PR is merged)
For example, https://github.com/DataDog/integrations-core/blob/master/postgres/assets/configuration/spec.yaml#L730-L739

/merge


Implement TCP window scaling

Should be a matter of looking at the options and adding a few calls to functions that shift the window size back and forth.

Sure, go ahead.

This can be closed, or? :)

I think so, but since @whitequark opened it, I don't have the power to close it.


cmd/cue: have a single source of truth for cli docs

This likely means that the cli docs should be generated from the tool code.

This issue has been migrated to https://github.com/cue-lang/cue/issues/9.
For more details about CUE's migration to a new home, please see https://github.com/cue-lang/cue/issues/1078.


Can't use timestamptz

I was looking at the supported types, and I saw that timestamptz (timestamp with time zone) isn't supported. When it is stored in the DB, it has the same information as timestamp, so maybe it could be possible to decode it into the same type as timestamp (#(#(Int, Int, Int), #(Int, Int, Int))), although when encoding I think there should be an option to input a timezone (maybe a type like (#(#(Int, Int, Int), #(Int, Int, Int), Int))

Perhaps a better encoding timestampz would be based on Posix Time and the Time zone, just like the Elm time package.

This would need to be solved in pgo and then pog before Squirrel can support this.


Charsetissue

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

created by mistake instead of updating the current one.


[XamarinProfiler-MAC]: Accessibility: Keyboard: MAS2.1.1 : Snapshot popup is not accessible using Keyboard.

Prerequisites

Install Xamarin Profiler.
Launch Visual Studio.
Create a project and build the solution.
Navigate to Run Menu Tab and Invoke it. Navigate to ""Start Profiling"" option and invoke it.
This will invokes ""Xamarin Profiler"" application."

Steps to Reproduce

Follow the pre-requisites to launch the xamarin profiler application.
Select the Available instruments to "Allocations" and invoke next button. This will invokes Common options window.
Navigate to "Start Profiling" button and invoke it. This will launch Allocations profiling page.
Navigate to "Snapshot" Popup using "Snapshot" button present at top "Allocations" table using keyboard.

Expected Behavior
The user should be able to invoke the "Snapshot" popup.
Actual Behavior
User is unable to invoke the snapshot popup using keyboard.
User Impact
User who rely on keyboard will not be able to access the Snapshot popup.
Screenshots

Environment
macOS High Sierra OSX version: 10.13.4
Visual Studio for Mac Enterprise version: 7.5.2(build 40)
Xamarin Profiler version: 1.6.3-400

Log File

Please add the following tags to this bug:
A11yMAS
Accessibility
MAS2.1.1
Xamarin-Profiler-MAC
Wipro


Remote validator

Hello!
I have ASP.NET MVC 5 project. How do I create Remove Validator for example jquery validation remote?

Simplest thing to do would just be to do an ajax call to a controller action that invokes FluentValidation, and then returns the ValidationResult serialized to JSON.

Thank!

Maintenance / cleanup: Closing this as the question appears to be answered and there hasn't been any activity for a few months.


Fix exception signature

I previously extended the Etcd3Exception constructor signature such
that it was no longer possible for the derived exception types to
construct with no args.  This change aims to make that possible again, while
still allowing an Etcd3Exception to be constructed with detail text as
well as the traditional "Bad Request" message.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@483a37e). Click here to learn what that means.
The diff coverage is 100%.

@@           Coverage Diff            @@
##             master     #32   +/-   ##
========================================
  Coverage          ?   88.4%
========================================
  Files             ?       7
  Lines             ?     319
  Branches          ?      34
========================================
  Hits              ?     282
  Misses            ?      22
  Partials          ?      15

Impacted Files
Coverage Δ

etcd3gw/client.py
87.17% <100%> (ø)

etcd3gw/exceptions.py
100% <100%> (ø)

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 483a37e...4ed0ced. Read the comment docs.

@dims I believe this fixes the breakage that I accidentally introduced with #31

thanks @neiljerram


feat: add BLS12-381 public keys

Adds the two variations of BLS12-381 public keys.

Actually, if we're accepting the _ in #171 to make BLS12-381 clearer then I'd suggest the names be bls12_381-g1-pub and bls12_381-g2-pub. @vmx?

+1 have plans to use this asap :)

@rvagg are we able to merge this?

Yeah, but I don't have access to do it. Will chase someone down or get access myself to do it.

👌


⚠ Bofrost.de has degraded performance

In 88f2dcf, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1978 ms

Resolved: Bofrost.de performance has improved in f8f45a8 after 40 minutes.


Added "About Us" page landing section

Resolved: #20

@DivyanshuParwal  now it is visible

Since this one is really similar to #56 and #60, let's wait on those before proceeding

Now that we have the TopBanner component added in #56, let's use that instead of copying the code. Closing this, feel free to re-open or make a new PR (or really we should just do a single PR to finish replacing all the top sections)


Add Integration tests for the the KIP-966

https://issues.apache.org/jira/browse/KAFKA-15579

@mumrah @artemlivshits Can you help take a look?


Assorted small fixes for setup

if the discovery address is no 'istio-pilot.domain' - get the SAN from env or default. Bug #7010
for testing allow overriding the pilot address with annotation (so we can test without changing the entire mesh). This may also help users use a 'canary' pilot for testing.
for load testing and to allow some larger jobs - allow annotation for cpu/mem of sidecar
improve consistency between remote and main templates (setting the common cpu to sidecar doesn't make sense, it is the common setting for pilot/mixer/etc - so should be much larger than what we allocate for each sidecar)
add more info to debug which gateway rejects configs (with multiple gateways it's tricky)
avoid pilot crash if cluster name are not in expected format
remove unused zipkin option

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: costinm
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS [costinm]
pilot/OWNERS [costinm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Also - add 1.0 to the actual mixer setup job, not only the deployment.

@costinm: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
be6f92dd25e54a163480cd98f2be8b8f1d9cbfb9
link
/test istio-unit-tests

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


Feat: new schedule creation popup (refs: #55)

Please check if the PR fulfills these requirements

[x] It's submitted to right branch according to our branching model
[x] It's right issue type on title
[x] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[x] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
[ ] It does not introduce a breaking change or has description for the breaking change

Description

Demo: http://<IP_ADDRESS>:8080/examples/example01-basic.copy.html

Thank you for your contribution to TOAST UI product. 🎉 😘 ✨

misalignment.

Check white bottom margin.

Remove a hover style after click lock button.

Add JSDOC {Calendar} properties at calendar.js like Schedule.


Bootstrap's JavaScript methods not working

A bootstrap modal can be triggered via a data attribute or via JavaScript.
This works:
    <button type="button" class="btn btn-primary" data-toggle="modal" data-target="#exampleModal">
      Launch via data attribute
    </button>

            <...>

This doesn't:
this.$refs.bsModal.modal('toggle')
It causes: "this.$refs.bsModal.modal is not a function"
I see that the bootstrap jQuery plugin is imported in plugins\index.js but is there anything else to do in order to enable those methods?

You have to wrap it with jQuery
$(this.$refs.bsModal).modal('toggle')

I tried that as well and the result is: Uncaught ReferenceError: $ is not defined

You have to import jQuery
import $ from jquery`

Perfect, that's it! Thanks!!


Specify Client Versions on Engine API

By analyzing the structure of beacon blocks on the network, we are able to obtain fairly accurate data on consensus layer client diversity. Unfortunately, do to the fact that the overwhelming majority of validators use mev-boost, their execution clients do not leave any fingerprint behind in block proposals. Thus we are forced to rely on limited self-reporting data from staking pools. Many pools do not participate, and we often have outdated statistics for the pools that do. Worse yet, we have no data on client diversity for home stakers.
This PR can change that. There are two competing proposals:

simply reuse the existing web3_clientVersion by exposing it on the engine_api
adopt the more comprehensive engine_clientVersionV1 method

By adopting one of these, we can allow the consensus clients to learn which execution client they are connected with. They can then embed this in their graffiti field by default when the user doesn't bother to set it. A quick survey of recent proposal graffiti reveals that:

lighthouse
teku
nimbus
lodestar

Already embed their client and version by default. It would be great to add the execution client to this. Perhaps prysm could be convinced to join as well.
An analysis of ~2000 recent blocks indicated that nearly half of all validators don't bother to change their graffiti from the default so the potential to gather data here is huge.
In my testing, I already found that nethermind enables web3_clientVersion on the authenticated connection.

Adding this to the engine api is definitely an improvement.  In order to fit within the graffiti, we should specify a field size limit or a strategy to encode the version info.

I'm personally more in favor of standardizing web3_clientVersion, because it already exists in clients.

In light of comments received so far I've pushed an alternative specification called engine_clientIdentificationV1 which is more comprehensive. There are a couple things to be decided:

Do we reuse web3_clientVersion or choose the more comprehensive engine_clientIdentificationV1?
Should we require this method be supported instead of recommending its support? (SHOULD vs MUST)
Do we agree on the abbreviations for the ClientCode?
Do we accept using the first 4 bytes of the commit hash as a short-hand for version?

Personally I lean towards taking engine_clientIdentificationV1 and making it mandatory if there aren't objections. If we're not going to take the easy route and just reuse web3_clientVersion then we might as well make a method that accomplishes what we're really trying to do here (get better measurements of EL client diversity). To that end, we require a standardized shorthand for specifying both clients in the limited space of block graffiti (32 bytes).
The definitions of ClientCode specified here allow us to encode both execution and consensus client versions inside the block graffiti within just 20 bytes. For example:
LH1be52536BU0f91a674

If desired, the space could be further reduced so that the bytes of the commit hash are embedded directly into the graffiti bytes (allowing the full consensus and execution client versions to be specified in 12 bytes).
Standardizing the version specifications this way makes graffiti analysis easy regardless of what client pairs are used.

Very supportive of this change. Agree with previous comments around naming. Unsure if we should introduce versioning for identification. we already have unversioned engine_exchangeCapabilities, might as well drop v1 and simply have engine_clientVersion

Unsure if we should introduce versioning for identification. we already have unversioned engine_exchangeCapabilities, might as well drop v1 and simply have engine_clientVersion

I believe engine_exchangeCapabilities is the only unversioned method because we won't allow it to ever change. If engines began supporting a new version then clients would have to do trial and error to determine which version to call, which defeats the purpose of having a "what methods do you support" method.

Supportive of this change. Maybe the method could be renamed to engine_exchangeClientVersion similar to engine_exchangeCapabilities since we are essentially exchanging the versions.

Is there an advantage of being prescriptive about the format the client returns it's version in? I was imagining something much closer to web3_clientVersion where any value would be accepted by CL and incorporated into the graffiti.
I guess there isn't much downside as it is mainly just upfront cost of spec'ing things out.

Is there an advantage of being prescriptive about the format the client returns it's version in? I was imagining something much closer to web3_clientVersion where any value would be accepted by CL and incorporated into the graffiti.

Having a conformed format will only help in identification, and in 'economy of graffiti'.  Ensuring there is a predictable portion of graffiti consumed by client identification makes it more palatable IMO.  The primary downside is just the gatekeeping required to maintain the list.
I like the human readable and more verbose bits, but I think that might only be useful in CL logs, since it is behind JWT secured endpoint.

It seems like the other missing part that would be nice in graffiti would be the builder and version if used (mostly used, but not always)
The encoding makes sense to fit inside graffiti bytes. not sure what % of blocks use default graffiti and whether this will be useful ultimately...

@rolfyone We already have data on the builders because they fill the execution payload's extraData field. E.g. this block has rsync-builder.xyz in the extra data: https://beaconcha.in/slot/8312808. The relays also provide data APIs that let us map blocks & builders to relays. Often there are multiple relays that will produce/publish each builder payload. Some of these affinities are displayed on sites like https://mevboost.pics/.
The only thing the local BN could read would be a list of relays from mev-boost or its own config. This would be 1) too long to include in graffiti and 2) redundant, given the above.

Okay I just want to take the temperature of the room. Please react to this to vote:
:heart: - vote for reusing web3_clientVersion
:tada: - vote for engine_clientVersionV1
:+1: - vote for adopting engine_clientVersionV1 but renaming to engine_exchangeClientVersionV1

Prysm supports this proposal.
I filed this issue to start recording our user-agent info in graffiti by default: https://github.com/prysmaticlabs/prysm/issues/13558

Thus far all votes are for adopting the new method so I've removed references to reusing web3_clientVersion

LOOOL! Exchange is when semantically the same entity is sent in both directions.

I am sorry to be late to this discussion, looks like @lightclient’s meme forced me to become a part of it.
If we’re deciding about a client version as a part of Engine API spec then it should be engine_getClientVersion. If we want web3_clientVersion to be exposed on the Engine API endpoint it is also fine and we can do it by simply adding this method to the list of those that are exposed (we have it in the Engine API spec too), then no need to spec out this method as a part of Engine API.

Is there an advantage of being prescriptive about the format the client returns it's version in? I was imagining something much closer to web3_clientVersion where any value would be accepted by CL and incorporated into the graffiti.

I'm weakly in favour of this way rather than have the graffiti require an extra step to convert a code.
However, if the code is decided upon, then can it be standardized? Seems a bit random at the moment, e.g.
Besu = BU
Teku = TK
Grandine = GR

I'm weakly in favour of this way rather than have the graffiti require an extra step to convert a code.

There is no conversion of a code - the code itself will be embedded in the graffiti. That's the whole point of the code (specifying a client in limited space). The point of the code is to ensure that lighthouse,teku,prysm,nimbus, lodestar or any other consensus client will all indicate a connection with a teku client by specifying TK in their graffiti. If we don't standardize the format for how the clients are embedded in the graffiti, then every client combination will be different, making analysis much more difficult.

Also, would rather not have an enum to maintain as clients come and go.

I get what you're saying.. but we need to standardize how clients will be indicated in graffiti somehow. This system is low maintenance, only requiring adding a new entry when a new client team arrives, and accommodating any two-letter code even before it is reserved.

However, if the code is decided upon, then can it be standardized? Seems a bit random at the moment

I left it to the client teams to choose their own code. I know besu's is different than teku's but I thought besu wouldn't like the code BS lol. But again, that's up to besu. If people want to standardize some method of picking out letters that's fine but I wouldn't want to hold up this PR hashing out such things.

NEW POLL 😄
In case this wasn't already clear, this PR also proposes a loose standard for specifying the client versions in graffiti. I had this in mind:
CL_codeCL_commitEL_codeEL_commit

for example:
LH1be52536BU0f91a674

This leaves 11 characters that users can specify if they wish (I've already received a request for that feature from a user that wanted to customize their graffiti without excluding their node from diversity analysis).
Please react with:
👍 - agree with this standard
👎 - would like a different standard (please comment)

This format captures the majority of the graffiti space. Instead, using only 2 bytes per commit and raw encode leaves 24 characters back to the user. Such a tinny thing is an easier sell to a wider range of stakers.
Only 2 bytes?
Users don't usually build client binaries of random commits of the codebase, instead, there are only a few commits associated with the official releases teams do. Any commit for a release of the prior hard forks is non-viable. So a very prolific team that ships monthly and a year hard-fork schedule that leaves us with 12 possible commits in a 16-bit space. In the unlikely case of collision, we can probably figure out the version from the commit of the other client.
Raw encode
Taking the example above, let's encode the commit as

hex: LHa674BU1be5
raw: LH¦tBUå

None is particularly human-friendly, which is not the point of the tag. A developer can quickly map the raw to hex; client diversity crawlers don't care. The chance of the entire tag having invisible ASCII characters is 0.3% low enough IMO.

What about 1 byte client identifiers (we have 26 letters 👀) and 2-bytes of ASCII commit hash? e.g.
L045bB0f54
Length is 10 bytes leaving 22 for the user, and it's human readable + won't destroy renderers/terminals where it is displayed.
Rocket Pool already uses single character identifiers namespaced by consensus and execution (e.g. N is Nimbus and Nethermind). We could use the same, or use unique letters which allows for future clients that are not strictly consensus or execution (or both)

Length is 10 bytes leaving 22 for the user, and it's human readable + won't destroy renderers/terminals where it is displayed.

I'm happy either way, the first client identifier could just be any character, but I agree sticking to the first letter gives 52 for CL and 52 for EL, and could expand to use the whole 96 printables not just the letters if we had to... or just having a new field in a hard fork one day...
I'm generally in favour of human readable just for simplicity, it'd be nice to standardise on position in graffiti, so if a user does use some of the graffiti space we know where their bits are consistently.... So if i have a 12 character string for my custom graffiti, does the client embed before that or after... I don't mind start or end, as long as we don't have some going to start and some going to end.. This would allow visualisers to just trim that data if its present easily.
Given the 32 bytes is fixed, could potentially stick it in the last 10 bytes if available, but I'm not strongly opinionated whether it should be start or end.

I do think this is a very needed change. Additionally, The nethermind research team has been awarded a grant by the ESP program to study the collection of client diversity data. the following is a link to our preliminary ideas
https://ethresear.ch/t/allowing-validators-to-provide-client-information-privately-a-project-by-nethermind-research-and-nethermind-core/18527
With the above in mind, i think we should consider an approach where this APi takes the usage of multiplexers like https://github.com/TennisBowling/executionbackup into consideration.
Maybe this method should return a list of (client, version, and commit) instead of just a single one

If we were going to do 1-byte identifiers then I might propose the client codes be:
Execution:

B: besu
J: ethereumJS
E: erigon
G: go-ethereum
N: nethermind
R: reth

Consensus:

G: grandine
L: lighthouse
S: lodestar
N: nimbus
T: teku
P: prysm

I suppose we could do this, but it already gets messy with several clients sharing the same first letter (especially lighthouse and lodestar both being consensus clients). The end result isn't much better (only saving 2 characters). I also find 2 characters to be more readable. Additionally, the two byte identifiers allow us to adopt a flexible standard where the amount of space for the version bytes could be adjusted depending on what the user chose as their graffiti. For example:
user graffiti takes up 0 characters:
LH1be52536BU0f91a674
user graffiti takes up 20 characters:
LH1be5BU0f91
user graffiti takes up 24 characters:
LH1bBU0f
user graffiti takes up 28 characters:
LHBU
I think this standard achieves all 3 goals (human readable, max space for the user, collision resistance). But anyone else is welcome to weigh in.

I'm happy with 2 byte client IDs, and think the advantage of choosing something outweighs the delay from bikeshedding. I've switched my vote to option 5 but will also accept any of the options with rough consensus. Let's get this done.

I'm happy with 2 byte client IDs, and think the advantage of choosing something outweighs the delay from bikeshedding. I've switched my vote to option 5 but will also accept any of the options with rough consensus. Let's get this done.

💯 agree with this. Option 5:
LH1be5BU0f91

is a great balance of the various concerns and if we find that users want more characters, we can adopt the flexible standard which is compatible with option 5.

This PR specifies the exchange of information about cl and el client on engine API, i think it's best we dont mix this with how to represent this data in the graffiti field. That can go into consensus spec, maybe?
I dont think a returned list is added complexity. It is just forward-looking. Regardless of how the multiplexers are implemented( you check the linked implementation), it is still important to represent them

i think it's best we dont mix this with how to represent this data in the graffiti field. That can go into consensus spec, maybe?

This PR does not enshrine a standard for representing data in graffiti. But we are having a discussion on the standard here because it informs how we design this API (the client codes for example)

I dont think a returned list is added complexity. It is just forward-looking. Regardless of how the multiplexers are implemented( you check the linked implementation), it is still important to represent them

None of the other engine-api methods are designed to accommodate multiplexers. Instead, we place the responsibility for handling multiple messages onto the multiplexer itself so that it appears as a single client to the consensus layer. I don't understand why this method alone must be designed to accommodate this when we don't have a reason for the consensus layer to gather such information. What is the CL supposed to do with multiple client codes or multiple commit prefixes when the purpose of these fields is to encode such data in graffiti? In the absence of such a purpose, I'm in favor of applying this principle but I'm open to taking a vote.

What is the CL supposed to do with multiple client codes or multiple commit prefixes when the purpose of these fields is to encode such data in graffiti? In the absence of such a purpose, I'm in favor of applying this principle but I'm open to taking a vote.

Given the research i linked as well, posting such data in the graffiti field could not be the final approach CLs will have to adopt. Such information will be relevant then. Im down to be convinced otherwise as well.
But, in the case that this lands how it is, there is a high probability we will have to have V2 of the same method with reporting multiple ELs depending on the research findings.

I'm happy with 2 byte client IDs, and think the advantage of choosing something outweighs the delay from bikeshedding. I've switched my vote to option 5 but will also accept any of the options with rough consensus. Let's get this done.

This is very similar to how Rocketpool identifies their client combinations using their Smart Node software and has worked well to help identify their client combos for troubleshooting/incentives/etc.

I'm happy with 2 byte client IDs, and think the advantage of choosing something outweighs the delay from bikeshedding. I've switched my vote to option 5 but will also accept any of the options with rough consensus. Let's get this done.

💯 agree with this. Option 5:
LH1be5BU0f91

is a great balance of the various concerns and if we find that users want more characters, we can adopt the flexible standard which is compatible with option 5.

How much do we want to enforce this?
If user specifies a graffiti taking all 32 bytes, client shouldn't start anymore?
Should we give an opt-out option to regain full 32 bytes?
I have mixed feelings...

How much do we want to enforce this?

If user specifies a graffiti taking all 32 bytes, client shouldn't start anymore?
Should we give an opt-out option to regain full 32 bytes?

This is absolutely not enforced. Most of the data will come from people who don't bother to set their graffiti. Users will always have the ability to choose whatever they want for their graffiti or to not provide this data at all. But some will want to set custom graffiti while also providing data for client diversity. For those users, we want to give them more bytes so they are more likely to participate.

How much do we want to enforce this?

If user specifies a graffiti taking all 32 bytes, client shouldn't start anymore?
Should we give an opt-out option to regain full 32 bytes?

This is absolutely not enforced. Most of the data will come from people who don't bother to set their graffiti. Users will always have the ability to choose whatever they want for their graffiti or to not provide this data at all. But some will want to set custom graffiti while also providing data for client diversity. For those users, we want to give them more bytes so they are more likely to participate.

Ok that's good.
If we sacrifice human readibility we could have the first byte representing clients (4bit cl,  4bit el)

If we sacrifice human readibility we could have the first byte representing clients (4bit cl, 4bit el) + 4bytes (2 cl, 2 el) for commits, so we end up with 5 versioning + 27 user msg

That's a nice option if we want to always provide versioning while taking up minimal space. But it does limit us to only 16 execution / consensus clients ever, and based on my conversations a lot of people seem to prefer readability.
In practice, the versioning information is really just nice to have for some debugging cases. But it is not strictly necessary. It is much less important than knowing the implementation itself for the purposes of measuring EL client diversity. That's why I like the flexible standard because it allows users 28 characters if they really want it, while preserving readability, without limiting EL/CL client implementations, and it preserves the version information for debugging in the vast majority of cases.

I've renamed the method to getClientVersionV1 in accordance with @mkalinin's suggestion. I've also decided to accommodate multiplexers by returning an array of ClientVersionV1 objects for two reasons:

We require some way to indicate to the consensus client that a multiplexer is being used so that the data can be excluded from graffiti. So we may as well indicate this by receiving more than one ClientVersionV1 object
Knowing each client version in a multiplexer scenario may be useful in the future for other methods of measuring client diversity which do not use graffiti.

LAST CALL FOR CONCERNS
I believe we've addressed all concerns that have been raised at this point. The core idea of this PR has widespread support and most disagreement is minor & related to small implementation details. There's no reason to spend weeks bikeshedding about this optional feature.
CURRENT PLAN

wait a few more days for small fixes
merge if there are no major objections
see if issues arise during implementation and make changes as needed
after widespread implementation, consider making this method mandatory

If you agree with this plan, please give a :+1:, otherwise comment your objection

Please add spell check errors to wordlist.txt.

How much do we want to enforce this?

If user specifies a graffiti taking all 32 bytes, client shouldn't start anymore?
Should we give an opt-out option to regain full 32 bytes?

This is absolutely not enforced. Most of the data will come from people who don't bother to set their graffiti. Users will always have the ability to choose whatever they want for their graffiti or to not provide this data at all. But some will want to set custom graffiti while also providing data for client diversity. For those users, we want to give them more bytes so they are more likely to participate.

How does everyone plan to represent this in flags? Are we going to artificially limit the size of user-specified graffiti flags? Otherwise, what would users expect the behavior to be if they specify 20-32 bytes of graffiti"? For instance do we truncate the version string from right to left? Doing that would assume precedence in importance of the information: CL impl > CL git hash > EL impl > EL git hash. It would also be hard for software parsing this field to differentiate user-specified graffiti that flows into this section and looks like an ident/hash from the real thing.
If this is required then IMO we should limit the size of user-provided graffiti to 20 bytes and be very explicit about the fact that 1) this will be a breaking config change for users and 2) there is no opting out by "overriding" the default with a flag.

One thing you could do is continue dropping client version data up until you can no longer store the EL+CL code combo. I think version / commit is nice to have but as critical.

One thing you could do is continue dropping client version data up until you can no longer store the EL+CL code combo. I think version / commit is nice to have but as critical.

Yeah the EL is most important (hardest to determine through other means), then CL, then versions. So if the plan is to truncate, I think we should just order it that way: (EL|CL|el-hash|cl-hash). You could get fancy and interleave the EL/CL hash bytes one-by-one but maybe that's overkill :)

One thing you could do is continue dropping client version data up until you can no longer store the EL+CL code combo. I think version / commit is nice to have but as critical.

Exactly. This is what I've been referring to as a flexible standard. The version information is nice to have but not critical.

I'm not sure I'd interleave, but shortening does make sense. If the version of a client is present, it being in the same logical chunk will be easier to search for. eg. searching for LH1b from the example below..

user graffiti takes up 0 characters: LH1be52536BU0f91a674 user graffiti takes up 20 characters: LH1be5BU0f91 user graffiti takes up 24 characters: LH1bBU0f user graffiti takes up 28 characters: LHBU
I think this flexible standard achieves all 3 goals (human readable, max space for the user, collision resistance). But anyone else is welcome to weigh in.

I think this is a sensible approach, and if the user graffiti is beyond 28 characters just not having the data...
Do we know what percentage of blocks have more than 28 bytes of graffiti? seems like we could get a fairly good estimation of how useful this would be...

I've compiled the discussion around choosing a graffiti standard into a single document:
https://hackmd.io/@wmoBhF17RAOH2NZ5bNXJVg/BJX2c9gja
I welcome any comments. Also, there haven't been any requests for changes in days. Seems like we can merge this?

@lightclient it's been about a week since people agreed we should merge this and there haven't been any objections. Is that enough time to merge?


Add missing words

I added 8 words that were missing for me.
[1] skilful skillful
skilfully skillfully
[2] wilful willful
wilfully willfully
[1] https://dictionary.cambridge.org/dictionary/english/skilful
[2] https://dictionary.cambridge.org/dictionary/english/wilful

Thank you :)


[Question] Robotframework Grammar

Hello team,
I'm thinking about writing a treesitter grammar for the robotframework syntax and was wondering if there is a grammar or spec defined for it somewhere? Something similar to what Go or Python provides for example.
This would be helpful in creating the parser as opposed to trying to come up with it yourself from the User Guide.
Would be great if anyone could help me out if something like this exists.
Keep up the great work with the framework :)

First of all, a tree-sitter based parser for Robot Framework would be awesome! Unfortunately there's no official grammar spec for Robot and due to the nature of our grammar creating one would be somewhat complicated. One big problem is that we support both space and pipe separated data, but the latter is so little used that you can probably ignore it. We should actually consider deprecating and removing it altogether.
There was a similar question about the grammar, for the exact same purpose, on Twitter some time ago. If I got it right, the person asking it was @Hubro here on GitHub and he seems to have done at least something in his tree-sitter-robot repository. Perhaps it would be possible to collaborate? There could also be others in our community interested on this.
One person I suspect is interested on this is @Snooz82 who was recently talking about updating our Pygments lexer. That's something we definitely need to do, but a tree-sitter parser would allow syntax highlighting etc. also outside Python world.

A formal grammar for Robot would be useful in general even if it wouldn't be able to cover all special cases we have. If that's needed for a tree-sitter, I'd be happy to help creating one.

Thank you very much for your help.
I don't think it currently would be worth your time to create a formal spec/grammar for it just for this single case of me trying to create a TS grammar for it. Although I think a grammar/spec is always a nice thing to have to so that one has defined what is allowed and what is not.
I've had a look in @Hubro's repo and forked it and have began expanding it & fixing issues. Work on it may be a bit slow since I have a day job to attend to and since it's my first time writing any kind of grammar. The generous syntax for robot files is not helping either, but I'll see what I can do and try to support the most common features.
On another note, when exploring the syntax I created the following file:
*** Test Cases ***
Test
    # None of these work
    hi a
    \ hi a
     hi a

*** Keywords ***
 ${arg} a
    Log To Console  Called with ${arg}

But I can't seem to be able to ever call this keyword. Just thought it was an interesting find, or maybe missing something.

I worked on the tree-sitter parser for a couple of weekends for the purpose of improving syntax highlighting of Robot files in my editor. I got it to a point where syntax highlighting worked pretty much perfectly in the repositories I work in, so the incentive to keep working on it disappeared :smile:
One thing in particular I never added support for is conditional (IF/ELSE) blocks, but we don't have any instances of those at my job so it hasn't bothered me.
If you're interested in the syntax highlighting, these are the queries I'm using:
(comment) @comment
(ellipses) @punctuation.delimiter

(section_header) @keyword
(extra_text) @comment

(setting_statement) @keyword

(variable_definition (variable_name) @variable)

(keyword_definition (name) @function)
(keyword_definition (body (keyword_setting) @keyword))

(test_case_definition (name) @property)

(keyword_invocation (keyword) @function)

(argument (text_chunk) @string)
(argument (scalar_variable) @string.special)
(argument (list_variable) @string.special)
(argument (dictionary_variable) @string.special)

This is a great example of scratching your own itch! 😃
For the wider audience, it would be great if the results were made more publicly available and so that others in the community could contribute as well. One possible step to that direction would be moving the repo to MarketSquare. If you are interested on that, @emanlove ought to be able to help if needed.

@ALX99, is there a space before the ${arg} a keyword definition? Need to investigate this.

Semi-related: To support CodeMirror 6 in jupyterlab_robotmode we'll eventually need one that worked with lezer... though perhaps it may be possible to map treesitter to lezer.
Either way: having a repo of grammars that can be pitted against each other, and the source of truth in this repo, would be a possible direction, which specific editor implementations could reuse.

@ALX99 @pekkaklarck
Quick update in case you're interested. Over the last month I finished my tree-sitter parser for Robot: https://github.com/Hubro/tree-sitter-robot
It's now included in Neovim and Helix by default and it has queries for syntax highlighting, indentation and folding.

Awesome work @Hubro!


NH-72863 cluster version fix

fixed by creating sw.k8s.cluster.version on k8s.cluster.version metric only

Don't forget to mention this in the changelog.


Nginx migration

To get python 3.9, I upgraded the server to Debian 11. Sadly, the apache configuration broke down with a very weird infinite loop appearing when importing scipy under wsgi module in apache. After couple days of no progress at all, I decided to try an alternative.
As a result, we're running on Nginx and all seem to be working fine. I've decided it's a good opportunity to document this. Hence the Nginx and some Apache configuration tweaks.

I don't care about quality of this that much. What's the chance anyone would set up a server instance of this?

I'm not an Nginx/apache expert, but it looks fine for me.
I think that is a big chance that we will use this configuration. ;)

I think that is a big chance that we will use this configuration. ;)

We already do. The reason I did this is I couldn't make it work on Python 3.9 on Debian 11 with Apache. The scipy import kept getting stuck in infinite loop with some futex. This didn't happen when I was importing into python interpreter or when running Flask from command line.
Thanks for the review!


Website

Added Dropdowns in the navigation bar
Description
Dropdowns added based upon data provided in wireframes here
Fixes # (issue)
Type of change
.

✅New feature (non-breaking change which adds functionality)

Checklist:

✅My contribution follows the style guidelines of this project
✅I have performed a self-review of my own contribution
✅I have made corresponding changes to the documentation
✅ My changes generate no new warnings
✅I have checked my code and corrected any misspellings

hi, can you push this pr to the website branch on this repo? @prishison

@prishison I can see that only one file called "Header.js" has been modified but the page has a list and a footer too. Didn't you implement those things?

@umang-sinha it is already present


Clean up and Complete Input/Output ports of CVE2

Marking this as complete.  The outstanding work related to this task is captured in #207 and #211.


Implementation Support Options? (Question)

Are there dedicated Microsoft Microsoft Healthcare Team support pathways for assistance with FHIR Open Source project implementations?  If so, can you define how those resources are accessed/procured?

the best approach is to reach out to your Cloud Solution Architect


Top level async

I realize this is a controversial one.
But if you require TL async you can't use this plugin at all, because top level sync is baked in transform.js.
Any chance of optionalizing async here?

Hey folks (this is a canned reply, but we mean it!). Thanks to everyone who participated in this issue. We're getting ready to move this plugin to a new home at https://github.com/rollup/plugins, and we have to do some spring cleaning of the issues to make that happen. We're going to close this one, but it doesn't mean that it's not still valid. We've got some time yet before the move while we resolve pending Pull Requests, so if this issue is still relevant, please @ me and I'll make sure it gets transferred to the new repo. :beer:


Process stuck at 100% usage of one CPU core, h2 receiving GoAway frames

Context
Version
hyper: 0.14.24
h2: 0.3.15
Note: in the debugging notes below, different versions may show. But these are the latest versions with which I've reproduced the problem.
Platform
Linux feanor 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux

Description
In my app I do pretty vanilla usage of https://github.com/Byron/google-apis-rs. In my program, I make a request every 10 seconds. It works just fine for about 15-20 minutes, but then the process gets stuck at 100% usage of one CPU core, and a response never comes.
block_on(
    self.hub
        .events()
        .list("primary")
        .add_scope(Scope::EventReadonly)
        .doit(), // here!
)
.map(|(response, events)| {
    // this scope is never reached
})
.map_err(|_| EventsProviderError {})

The expected behavior would be that this fails at some point if the response doesn't return, but it never fails (well, I've left it running for up to 40 minutes, multiple times).
Under the hood, google-calendar-3 uses hyper:
let mut req_result = {
    let client = &self.hub.client;
    dlg.pre_request();
    let mut req_builder = hyper::Request::builder().method(hyper::Method::GET).uri(url.clone().into_string())
            .header(USER_AGENT, self.hub._user_agent.clone())                            .header(AUTHORIZATION, format!("Bearer {}", token.as_str()));

            let request = req_builder
            .body(hyper::body::Body::empty());

    client.request(request.unwrap()).await
};

Interesting debug logs are these GoAway frames and session_timed_out debug data, which happen (reproducibly) 4 minutes after the process gets stuck:
2023-02-03T23:35:09.720770Z DEBUG Connection{peer=Client}: h2::codec::framed_read: received frame=GoAway { error_code: NO_ERROR, last_stream_id: StreamId(2147483647), debug_data: b"session_timed_out" }
2023-02-03T23:35:09.720832Z DEBUG Connection{peer=Client}: h2::codec::framed_read: received frame=Ping { ack: false, payload: [0, 0, 0, 0, 0, 0, 0, 220] }
2023-02-03T23:35:09.720853Z DEBUG Connection{peer=Client}: h2::codec::framed_write: send frame=Ping { ack: true, payload: [0, 0, 0, 0, 0, 0, 0, 220] }
2023-02-03T23:35:09.720941Z DEBUG Connection{peer=Client}: h2::codec::framed_write: send frame=GoAway { error_code: NO_ERROR, last_stream_id: StreamId(0) }
2023-02-03T23:35:09.720962Z DEBUG Connection{peer=Client}: h2::proto::connection: Connection::poll; connection error error=GoAway(b"", NO_ERROR, Library)

My suspicion is that hyper is receiving an response it's not handling. I don't have a mechanism to add a timeout that works, so my program is in an irrecoverable state.
Debugging notes
Sorry if this is too much for an issue. I've been trying my best to figure out what's going on.
Basic print debugging
I vendored google-calendar-3 and added some basic print debugging. Looks like the response just never comes back and the program doesn't go further than the await here:

I tried adding a timeout around this and it never times out (same behavior):
timeout(Duration::from_secs(10), client.request(request.unwrap())).await.unwrap()

Process status when the hang happens
When this happens, the process goes from interruptible sleep to running (Sl+ to Rl+):
fausto    408829  0.5  0.1<PHONE_NUMBER>8 pts/2    Sl+  23:49   0:01 ./target/debug/joinable
 ~/Development/joinable => ps aux | grep 408829 | grep -v grep
fausto    408829  0.5  0.1<PHONE_NUMBER>8 pts/2    Sl+  23:49   0:01 ./target/debug/joinable
 ~/Development/joinable => ps aux | grep 408829 | grep -v grep
fausto    408829  4.1  0.1<PHONE_NUMBER>8 pts/2    Rl+  23:49   0:15 ./target/debug/joinable

So maybe it's not waiting for IO anymore.
GDB backtrace
Got a backtrace from gdb. Looks like the process is stuck between these two and goes into an infinite loop there:
futures-executor-0.3.25/src/local_pool.rs:95
std/src/thread/local.rs:446

Note: I got this backtrace by attaching to the running process. I'm not completely sure whether I got the right frames, but this seemed like the most promising output to me.

Full backtrace (expand)

(gdb) backtrace
#0 futures_executor::local_pool::run_executor::{closure#0}<core::result::Result<(http::response::Responsehyper::body::body::Body,
google_calendar3::api::Events), google_calendar3::client::Error>,
futures_executor::local_pool::block_on::{closure_env#0}<core::future::from_generator::GenFuture<google_calendar3::api::{impl#133}::doit::{async_fn_env#0}<hyper_rustls::connector::HttpsConnector<hyper::client::connect::http::HttpConnectorhyper::client::connect::dns::GaiResolver>>>>>
(thread_notify=0x7f1e0b9afc30) at
/home/fausto/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.25/src/local_pool.rs:95
#1  0x000055b4bc25bbb1 in
std::thread::local::LocalKey<alloc::sync::Arc<futures_executor::local_pool::ThreadNotify>>::try_with<alloc::sync::Arc<futures_executor::local_pool::ThreadNotify>,
futures_executor::local_pool::run_executor::{closure_env#0}<core::result::Result<(http::response::Responsehyper::body::body::Body,
google_calendar3::api::Events), google_calendar3::client::Error>,
futures_executor::local_pool::block_on::{closure_env#0}<core::future::from_generator::GenFuture<google_calendar3::api::{impl#133}::doit::{async_fn_env#0}<hyper_rustls::connector::HttpsConnector<hyper::client::connect::http::HttpConnectorhyper::client::connect::dns::GaiResolver>>>>>,
core::result::Result<(http::response::Responsehyper::body::body::Body,
google_calendar3::api::Events), google_calendar3::client::Error>>
(self=0x55b4bcf505a8, f=...) at
/rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/thread/local.rs:446
#2  0x000055b4bc25b3aa in
std::thread::local::LocalKey<alloc::sync::Arc<futures_executor::local_pool::ThreadNotify>>::with<alloc::sync::Arc<futures_executor::local_pool::ThreadNotify>,
futures_executor::local_pool::run_executor::{closure_env#0}<core::result::Result<(http::response::Responsehyper::body::body::Body,
google_calendar3::api::Events), google_calendar3::client::Error>,
futures_executor::local_pool::block_on::{closure_env#0}<core::future::from_generator::GenFuture<google_calendar3::api::{impl#133}::doit::{async_fn_env#0}<hyper_rustls::connector::HttpsConnector<hyper::client::connect::http::HttpConnectorhyper::client::connect::dns::GaiResolver>>>>>,
core::result::Result<(http::response::Responsehyper::body::body::Body,
google_calendar3::api::Events), google_calendar3::client::Error>>
(self=0x55b4bcf505a8, f=...) thread/local.rs:422
#3  0x000055b4bc126bbf in
futures_executor::local_pool::run_executor<core::result::Result<(http::response::Responsehyper::body::body::Body,
google_calendar3::api::Events), google_calendar3::client::Error>,
futures_executor::local_pool::block_on::{closure_env#0}<core::future::from_generator::GenFuture<google_calendar3::api::{impl#133}::doit::{async_fn_env#0}<hyper_rustls::connector::HttpsConnector<hyper::client::connect::http::HttpConnectorhyper::client::connect::dns::GaiResolver>>>>>
(f=...) at
/home/fausto/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.25/src/local_pool.rs:86
#4  0x000055b4bc1270ce in
futures_executor::local_pool::block_on<core::future::from_generator::GenFuture<google_calendar3::api::{impl#133}::doit::{async_fn_env#0}<hyper_rustls::connector::HttpsConnector<hyper::client::connect::http::HttpConnectorhyper::client::connect::dns::GaiResolver>>>>
(f=...) at
/home/fausto/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.25/src/local_pool.rs:317
#5  0x000055b4bc091ccf in
joinable::events::providers::google_calendar::{impl#2}::fetch_events
(self=0x7f1df8001478) at src/events/providers/google_calendar.rs:87

Wireshark and tokio-console
I tried to take a further look at what packets are being passed around:

My program was polling every 10 seconds for testing, so (1) and (2) show successful requests and all their packets (the box after 2 is also a successful request).
Section (3) shows the closing of the TCP connection when I realized the program got stuck and no further packets were received (I hit Ctrl+C).
So the finding is: the Rust program is stuck before the response packets arrive.
tokio-console output looks like this:

This is the last resource that pops up and never stops being used:
│   110 n/a     Sync   198.8622s tokio::sync::oneshot         Sender|Receiver ✅   <cargo>/hyper-0.14.23/src/client/dispatch.rs:125:24      rx_dropped=false tx_dropped=false value_received=false value_sent=true              │

Note: I don't understand the output of tokio-console completely, as I'm not super experienced with async Rust).
The resource is this one-shot channel here:
https://github.com/hyperium/hyper/blob/0.14.x/src/client/dispatch.rs#L124-L130
The number of polls in the tasks view of tokio-console is no longer increasing (although that could be because the program is stuck, and is no longer emitting traces).
New debug logs after I added tokio-console
Looks like enabling the tracing feature of Tokio made my logs show some more stuff...
This is a healthy fetch:
2023-02-03T23:30:59.593351Z DEBUG hyper::client::pool: reuse idle connection for ("https", www.googleapis.com)
2023-02-03T23:30:59.594418Z DEBUG Connection{peer=Client}: h2::codec::framed_write: send frame=Headers { stream_id: StreamId(217), flags: (0x5: END_HEADERS | END_STREAM) }
2023-02-03T23:30:59.726889Z DEBUG Connection{peer=Client}: h2::codec::framed_read: received frame=Headers { stream_id: StreamId(217), flags: (0x4: END_HEADERS) }
2023-02-03T23:30:59.727045Z DEBUG Connection{peer=Client}: h2::codec::framed_read: received frame=Data { stream_id: StreamId(217) }
2023-02-03T23:30:59.727125Z DEBUG Connection{peer=Client}: h2::codec::framed_read: received frame=Data { stream_id: StreamId(217), flags: (0x1: END_STREAM) }
2023-02-03T23:30:59.727204Z DEBUG Connection{peer=Client}: h2::codec::framed_read: received frame=Ping { ack: false, payload: [0, 0, 0, 0, 0, 0, 0, 216] }
2023-02-03T23:30:59.727249Z DEBUG Connection{peer=Client}: h2::codec::framed_write: send frame=Ping { ack: true, payload: [0, 0, 0, 0, 0, 0, 0, 216] }

This is the fetch where the process gets stuck:
2023-02-03T23:31:09.591212Z DEBUG hyper::client::pool: reuse idle connection for ("https", www.googleapis.com)
2023-02-03T23:31:09.592015Z DEBUG Connection{peer=Client}: h2::codec::framed_write: send frame=Headers { stream_id: StreamId(219), flags: (0x5: END_HEADERS | END_STREAM) }
2023-02-03T23:31:09.718778Z DEBUG Connection{peer=Client}: h2::codec::framed_read: received frame=Headers { stream_id: StreamId(219), flags: (0x4: END_HEADERS) }
2023-02-03T23:31:09.718854Z DEBUG Connection{peer=Client}: h2::codec::framed_read: received frame=Data { stream_id: StreamId(219) }
2023-02-03T23:31:09.719094Z DEBUG Connection{peer=Client}: h2::codec::framed_read: received frame=Data { stream_id: StreamId(219), flags: (0x1: END_STREAM) }
2023-02-03T23:31:09.719142Z DEBUG Connection{peer=Client}: h2::codec::framed_read: received frame=Ping { ack: false, payload: [0, 0, 0, 0, 0, 0, 0, 218] }
2023-02-03T23:31:09.719163Z DEBUG Connection{peer=Client}: h2::codec::framed_write: send frame=Ping { ack: true, payload: [0, 0, 0, 0, 0, 0, 0, 218] }
2023-02-03T23:35:09.720770Z DEBUG Connection{peer=Client}: h2::codec::framed_read: received frame=GoAway { error_code: NO_ERROR, last_stream_id: StreamId(2147483647), debug_data: b"session_timed_out" }
2023-02-03T23:35:09.720832Z DEBUG Connection{peer=Client}: h2::codec::framed_read: received frame=Ping { ack: false, payload: [0, 0, 0, 0, 0, 0, 0, 220] }
2023-02-03T23:35:09.720853Z DEBUG Connection{peer=Client}: h2::codec::framed_write: send frame=Ping { ack: true, payload: [0, 0, 0, 0, 0, 0, 0, 220] }
2023-02-03T23:35:09.720941Z DEBUG Connection{peer=Client}: h2::codec::framed_write: send frame=GoAway { error_code: NO_ERROR, last_stream_id: StreamId(0) }
2023-02-03T23:35:09.720962Z DEBUG Connection{peer=Client}: h2::proto::connection: Connection::poll; connection error error=GoAway(b"", NO_ERROR, Library)
[2023-02-03T23:35:09Z DEBUG rustls::conn] Sending warning alert CloseNotify

Particularly this:

Note that that first frame with session_timed_out debug data happens exactly 4 minutes after the process becomes stuck.

Note that these notes are all upstreamed from https://github.com/Byron/google-apis-rs/issues/402

This looks related: https://stackoverflow.com/questions/55087292/how-to-handle-http-2-goaway-with-httpclient
So probably my connection has exhausted a server-side per-connection limit and is being closed by the server. Maybe hyper is not handling that?

Looks like golang/net retries when it gets GoAway:
https://github.com/golang/net/commit/8dab9293431a241c65a8e8d46bbaa0492ec94849

Trying (but failing) to reproduce this here: https://github.com/fnune/hyper-goaway-repro
I get an expected/welcome immediate failure:
 ~/Development/hyper-goaway-repro [101] => cargo run --bin client                                      14:09:47
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/client`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: hyper::Error(Io, Kind(BrokenPipe))', src/client/bin/main.rs:18:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

What I'm looking for is to emulate the process hanging problem...

That's disappointing, ChatGPT...

Recorded the GoAway frames with Wireshark:

(1) The server sends [FIN, ACK]
(2) The client ignores the packet and sends [RST]
Once more:

They happen ~18-20 minutes after the connection begins.

futures-executor-0.3.25/src/local_pool.rs:95

This is a red flag to me. I would check where you are calling the local pool, (is that block_on you mention at the top it?), and rip them out. They don't work well with Tokio's reactor. Replace them with either a tokio runtime block_on call, or better, make the function async itself, and just use #[tokio::main].
The reason they conflict: Tokio's reactor uses epoll_wait when it needs to wait on IO. When epoll returns, Tokio's reactor processes all events it noticed. By using futures-executor, it's block_on does something a little different. When the future is not ready, it will park the thread (std::thread::park()) until the future wakes up. The problem is that the reactor is on that same thread, and since it parked, it will stall there, and never reach the epoll_wait. Using futures-executor is a very common cause for deadlocks.

Oh no! That makes sense...
I suppose the unexpected communication at the TCP level I'm seeing was a red herring, then, and the client isn't responding correctly to the [FIN, ACK] simply because my thread is parked?

It's hard for me to say exactly. The TCP stuff happens inside the kernel, and isn't necessarily blocked by the user-space thread parking. But it won't ever wake up that thread.
I mean it could be something else, but that is the most common culprit if futures-executor is involved.

I'm trying to fit the 100% core usage within the framework of your (eye-opening) explanation, but I can't figure it out. I suppose while the thread is parked something is polling to see if it needs to be waken up?
(I'll be on my computer trying out your suggested patch in some minutes)
Thank you so much for your time and help already!

Okay, I turned the whole code path async to be able to make better use of Tokio like you suggested. I'm no longer using block_on (from any source) and things are working perfectly!
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_write] send frame=GoAway { error_code: NO_ERROR, last_stream_id: StreamId(0) }
[2023-02-06T19:35:34Z DEBUG h2::proto::connection] Connection::poll; connection error error=GoAway(b"", NO_ERROR, Library)
[2023-02-06T19:35:34Z DEBUG rustls::conn] Sending warning alert CloseNotify
[2023-02-06T19:35:34Z DEBUG hyper::client::connect::dns] resolving host="www.googleapis.com"
[2023-02-06T19:35:34Z DEBUG hyper::client::connect::http] connecting to <IP_ADDRESS>:443
[2023-02-06T19:35:34Z DEBUG hyper::client::connect::http] connected to <IP_ADDRESS>:443
[2023-02-06T19:35:34Z DEBUG rustls::client::hs] No cached session for DnsName(DnsName(DnsName("www.googleapis.com")))
[2023-02-06T19:35:34Z DEBUG rustls::client::hs] Not resuming any session
[2023-02-06T19:35:34Z DEBUG rustls::client::hs] Using ciphersuite TLS13_AES_256_GCM_SHA384
[2023-02-06T19:35:34Z DEBUG rustls::client::tls13] Not resuming
[2023-02-06T19:35:34Z DEBUG rustls::client::tls13] TLS1.3 encrypted extensions: [Protocols([6832])]
[2023-02-06T19:35:34Z DEBUG rustls::client::hs] ALPN protocol is Some(b"h2")
[2023-02-06T19:35:34Z DEBUG h2::client] binding client connection
[2023-02-06T19:35:34Z DEBUG h2::client] client connection bound
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_write] send frame=Settings { flags: (0x0), enable_push: 0, initial_window_size: 2097152, max_frame_size: 16384 }
[2023-02-06T19:35:34Z DEBUG h2::proto::connection] Connection; peer=Client
[2023-02-06T19:35:34Z DEBUG hyper::client::pool] pooling idle connection for ("https", www.googleapis.com)
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_write] send frame=WindowUpdate { stream_id: StreamId(0), size_increment: 5177345 }
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_write] send frame=Headers { stream_id: StreamId(1), flags: (0x5: END_HEADERS | END_STREAM) }
[2023-02-06T19:35:34Z DEBUG rustls::client::tls13] Ticket saved
[2023-02-06T19:35:34Z DEBUG rustls::client::tls13] Ticket saved
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_read] received frame=Settings { flags: (0x0), max_concurrent_streams: 100, initial_window_size: 1048576, max_header_list_size: 65536 }
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_write] send frame=Settings { flags: (0x1: ACK) }
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_read] received frame=WindowUpdate { stream_id: StreamId(0), size_increment: 983041 }
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_read] received frame=Settings { flags: (0x1: ACK) }
[2023-02-06T19:35:34Z DEBUG h2::proto::settings] received settings ACK; applying Settings { flags: (0x0), enable_push: 0, initial_window_size: 2097152, max_frame_size: 16384 }
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_read] received frame=Headers { stream_id: StreamId(1), flags: (0x4: END_HEADERS) }
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_read] received frame=Data { stream_id: StreamId(1) }
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_read] received frame=Data { stream_id: StreamId(1), flags: (0x1: END_STREAM) }
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_read] received frame=Ping { ack: false, payload: [0, 0, 0, 0, 0, 0, 0, 0] }
[2023-02-06T19:35:34Z DEBUG h2::codec::framed_write] send frame=Ping { ack: true, payload: [0, 0, 0, 0, 0, 0, 0, 0] }

For some reason I no longer get the GoAway frames after 20 minutes. In the instance above I got them just after first running the program. Makes me wonder at what point the thread got parked. I may continue investigating with a breakpoint on std::thread::park I guess.
Thank you so much for your help! You not only fixed my program but also helped me realize that I need to learn more about reactors and async Rust in general.

Nice! I'm glad it was that simple.
(It would be nice if Tokio could somehow detect this, but most obvious ways have other downfalls. :()


Dropdown - emit msg on event

Description
This PR adds a new option to the ui-dropdown node to select when an output message should be triggered:

As explained in the info panel:

This msgTrigger property can also be dynamically set.  The default value is "onChange" like in the previous versions, to avoid breaking changes.
The following example flow demonstrates the default "onChange" value, which is then dynamically overwritten by a "onClose" value:

Related Issue(s)
Closes 1457
Checklist

[X] I have read the contribution guidelines
[ ] Suitable unit/system level tests have been added and they pass
[X] Documentation has been updated

[ ] Upgrade instructions
[ ] Configuration details
[ ] Concepts

[ ] Changes flowforge.yml?

[ ] Issue/PR raised on FlowFuse/helm to update ConfigMap Template
[ ] Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production

Labels

[ ] Includes a DB migration? -> add the area:migration label

P.S. I used the @blur event, because @close was never triggered.  See this discussion.

Thanks @bartbutenaers - great stuff.
Apart from a shift of where the form-row is in the config, and the labels used, this is good to go as far as I'm concerned. I'll be merging once the tests give me the green light.


Document the new and/or edge cases

We changed two edge cases in https://github.com/rethinkdb/rethinkdb/issues/4132 and https://github.com/rethinkdb/rethinkdb/issues/4696 .  r.and() and r.or() (with 0 arguments) are now legal and defined to be true and false respectively.  We also now define r(false).or(nil) to be nil.

This is partially addressed by https://github.com/rethinkdb/docs/pull/934 (though I just noticed that the signature still needs updating).

#934 actually only updates the indexes, and I don't think we need to mention this in the index file because it is an edge case -- I want to mention it as a separate note in the main files for and and or. (Although an update to the signature will go in the index files too.)


[5.4] Move "tap" method to BuildsQueries trait.

Method tap was moved from Illuminate\Database\Query\Builder to Illuminate\Database\Concerns\BuildsQueries trait.
Eloquent builder when and tap methods passes different builder instances to the callback.
when passes current eloquent builder to the callback, but tap method uses Illuminate\Database\Query\Builder as callback argument.
For example:

>>> (new User)->newQuery()->tap(function($builder) { dd(get_class($builder)); });
"Illuminate\Database\Query\Builder"

>>> (new User)->newQuery()->when(true, function($builder) { dd(get_class($builder)); });
"Illuminate\Database\Eloquent\Builder"

So, we can't use one type hint callback for when/tap methods, like (class callback case will illustrate this better):
class SomeBuilderCallback
{
   public function __invoke(Illuminate\Database\Eloquent\Builder $builder)
   {
       // do stuff
   }
}

// In one part of application
User::when($condition, new SomeBuilderCallback);

// In other part
User::tap(new SomeBuilderCallback); // will fail

I don't understand what bug this is fixing.

In addition, with tap method i can't use eloquent builder features, like
Model::tap(function($builder) {
   $builer->with('relation');
});


Update Footer

Hey @Sujal-2820 ,
I would like to remove the empty space under the footer and update the footer and elements in it. I will make it look good like footer in every other modern website.
Could you please assign this to me and label it as "Hacktoberfest-accepted"

What is this PR about ?
This PR updates the footer and fixes the issues, And adds new elements.
This PR removes the empty space under the footer and make it good like every other modern website
Here is the updated link : https://sai-kumar0.github.io/Hacktoberfest-Web/


Can't confront found bounties from the scanner(TA)

Apparently there is a bug in Tracker's Alliance quest (via Creations) that once you scanned an NPC and found bounties on them, you cannot confront/talk/interact with them.

Game Version
<IP_ADDRESS>
Language
English (EN)
New Game
No
Reproduction Steps
While taking the first Tracker's Alliance mission there is a quest where you will need to scan for NPCs in Akila to see if they have bounties on their head. You can encounter more than one random NPCs in Akila that have bounties, most of the NPCs cant be interacted or talked to hence the bug.

I have also experienced this later in the game. When you find a random bounty in towns and click the target in the scanner, a "Bounty Hunting" mission is started. When you exit the scanner and attempt to talk to the NPC, they are unresponsive. However, when I checked using 'getstage' the stage was 9999, so not properly started. I completed it using the console and the next one I found functioned as it should.

Same issue here. "Confront" an Ecliptic mercenary. There is a "Talk" option but it does nothing. I got diplomacy to get him to stop attacking and the talk option still does nothing. Stunning and loot/transfer all his items doesn't complete the mission. Eventually he wakes up and is just aggro again.

How did you fix it with console commands?

Same issue. Is it bugged like this for everyone? Hopefully it will be fixed soon, or a workaround found.

Also bugged for me, if anyone has any work around that would be appreciated. Noticed that when running SQO on the quest (id: FD00004A) returns value 100 Confront <Alias=PrimaryRef> DORMANT. Returned reference value for SQT does not match the NPC's purported value.

+1
Just want to add that I'm having the same bug on console. I also tried opening on the PC via cloud, and the bug is still there.
Hopefully there's a fix on the way.


SAK-48373 - Roster: use a css class that actually exists

(For the 2nd time since the original merge got undone by someone else's subsequent commit)
This is the same as #11492, but it got undone by #11530

@maurercw Sorry about that :)

No worries!


Promote password import in autofill menu

Task/Issue URL: https://app.asana.com/0/72649045549333/1207617229892922/f
BSK PR: https://github.com/duckduckgo/BrowserServicesKit/pull/976
Description:
When adopting a new browser after a long time using something else, you expect your browser to have all your data. If you skipped import during onboarding you will find out about the missing data at the time when you're trying to use the password. This creates huge friction right in the middle of a task. See Comment by Peter Dolanjski on Password and autofill issues.
Reminding users of the option to import right when that friction happens could be a way to quickly give recourse and solve the problem for all subsequent browsing needs.
This feature promotes the import in autofill scenarios when the user has few or no passwords saved.
Steps to test this PR:
https://app.asana.com/0/72649045549333/1208245520043990/f
Definition of Done:

[ ] Does this PR satisfy our Definition of Done?

Internal references:
Pull Request Review Checklist
Software Engineering Expectations
Technical Design Template
Pull Request Documentation

@amddg44 Just for posterity the bug you mentioned was already fixed in autofill.js and is in the 13.1.0 version (Release Candidate)
https://github.com/duckduckgo/duckduckgo-autofill/pull/649


Interior floor

Tasks

[x] caulk the seams
[x] lay plastic covers
[x] double layer of foam panels
[x] lay horizontal 2x4 , 4 pieces
[x] lay vertical 2x4, probably 9 pieces

Separated from #11 as this can't really be worked on until the walls are insulated.
The plan is to have 2 layers of 50mm insulation, followed by 2 layers of 2x4 framing. The top layer will be a single 12mm sheet of plywood. Finally for the finish, we will use simple tiled carpets.
This is a blocker for the final door insulation, let's do this ASAP.

Structure.

tile carpet
12mm ply
2x4
2x4
foam
foam
plastic cover
24mm base
frame

Next actions

[ ] trim first of row of 2x4s by 5mm
[ ] measure and cut second row of 2x4s
[ ] check for level with door trim
[ ] lay and trim ply wood

Progress

laid the first row of 2x4s and half of the second row
tested laying the panel on top and it sagged in the middle
realised there needs to be support in between the rows too, am using off cuts for those
I'm now out of fresh 2x4s
there's the material left over from the scaffolding but a lot of them have mold

Could I do the door frame using off cuts of hivest wood and my floor panels?
10mm + 10mm + 12mm = 32mm. The gap is 33mm.

Done.