Context aware info or help button and page on every screen

Description
There should be a button which leads to a pop-up/screen which explains the current screen.
@taleldayekh Could you please paste the screen, which you have showed us?
Acceptance criteria

There is an information icon on the top
It is an overlay for the whole screen
Per screen

One illustration
One paragraph

There is one route
It recognizes on which page it is
The text is defined in the translation file
It is individually formatted per screen
The content for all the screen defined in https://github.com/raiden-network/light-client/issues/698#issuecomment-725418451 is written and implemented

Tasks

[ ] Explain limitations to Sahsh @taleldayekh
[ ] Design @sashseurat
[ ] Illustrations
[ ] Implement

The idea is to provide the user easy access to additional information whenever she is unsure about a certain step in any of the dApp flows.
By clicking the "i" (information) symbol on a screen the user is shown an ovelay with additional information, perhaps together with an illustration. This can be used both to clearify what the user should do on a given screen but also for explaining blockchain/ethereum/dApp concepts that might be unclear for a new user.

Examples of real world implementations in other apps:

Maybe should do this instead of #1487
@sashseurat @MariaNono Do you have got ideas regarding that issue?

@christianbrb Here is where I think it makes sense to provide the users with some sort of "documentation" inside the dApp in the info overlay. Have a look and gimme your thoughts.
Select Hub

Not necessarily clear what a hub is.
Open Channel

Short description of the concept of channels.
Transfer (for mediated transfers)

Short descriptions about the PFS concept and the purpose of selecting routes (hops).
Channels

Describe that the user channels open with the currently selected token and if they cannot see a specific channel it might mean that they have the wrong token selected.
Also describe the close and settle functionality.
Transfer ETH

Short description about the main account and Raiden account ETH.
Withdraw Tokens

Describe how the user would get tokens here, i.e. by closing channel.
UDC

Move current description of the UDC to info overlay.
Backup State

Explain to user why backing up state is crucial.

@taleldayekh & @christianbrb
Here a designed draft of my suggestion for the Select a Hub screen overlay:
https://www.figma.com/proto/KVi3wU2n28KlozER6tmg4m/LC-Info-Overlays?node-id=1%3A14&viewport=-95%2C292%2C0.5&scaling=min-zoom
It will really nice if the illustration can be done by @MariaNono!
The approach is:

Giving user an overlay in the appearance of a screen, with a bit of a highlighted background to draw user's attention, and provide better contrast for easier reading of a big paragraph.

Simple text in large font for a clear and accessible explanation.

Two exit points (X + Done) for user's hightened sense of control

Placeholder for illustration depicting a hub - a node which is connected to several other nodes

Here is draft for Open Channel screen overlay (in same Figma file, under different page):
https://www.figma.com/file/KVi3wU2n28KlozER6tmg4m/LC-Info-Overlays?node-id=10%3A20

@sashseurat Very nice! @taleldayekh It is improving the dApp a lot, thanks for pushing it :)
Just a workflow and implementation proposal. Is it always the same screen and just the text and icon need to be "configured".

Just a workflow and implementation proposal. Is it always the same screen and just the text and icon need to be "configured".

Yes exactly like that :)

Hi, @sashseurat I have just finished some first sketches and discussed them with @taleldayekh
Have a look and let's discuss them soon.

Second sketch iteration!
@christianbrb , @taleldayekh , @sashseurat , I would proceed with these ideas unless you any changes to suggest.

@MariaNono Looks very nice :)
Open channel:

Please also add dots (tokens) on the left side of the channel (it is the deposit)
Just make the arrows into one direction (from left to right) as the the user can just pay somebody if the partner hasn't done a counterdeposit.

UDC Funds:
This one is really hard. It should be shown, that it is used to pay a service.
User/Wallet -> Token -> Service (RSB Provider)


Is there a way to force a state ? to manually switch to another state ?

Hi,
I use your directive as a screensaver and i would like to know if Is there a way to force a state ? to manually switch to another state ?
thanks for your work

sorry for this dumb question just found answer...
states.{STATENAME}.active = true;

Hi,
this may work in your case, but it does not trigger a real state change with updating all values and firing the callbacks. Instead, you should have two active states...
I Just pushed a litte change (f7158b0de544fd4b5b9c2e8c564103b837a3d839). There you have an activate()-Method on every state that you defined, so you can manually activate it.
Please tell me if that works for you :)

Sorry for late response ! It works well thanks a lot :)


ChartPointsScatterCrossesLayer does not allow a change of colour

I have tried to change the colour for cross point type to anything but black. It always draws crosses in black. Any idea if this is a bug.  Thanks

It should be customizable - the passed fill color is used as stroke color. See https://github.com/i-schuetz/SwiftCharts/blob/master/SwiftCharts/Layers/ChartPointsScatterLayer.swift#L227
Please ensure you are passing correctly the color.

Thanks  for your prompt feedback.
Indeed I tried just that. The itemFillColor works file for circle, square,
triangle, except for cross, where the itemFillCollor is supposed to be used
for the context strokColor, but it doesn't.  Strangely enough, I have even
hard-coded the line:
context.setStrokeColor(itemFillColor.cgColor) to context.setStrokeColor
(UIColor.red.cgColor)
and still crosses are painted black.
I guess, there is an issue here.
Regards,
Kais
On Sun, Sep 17, 2017 at 7:15 PM, Ivan Schütz<EMAIL_ADDRESS>wrote:

It should be customizable - the passed fill color is used as stroke color.
See https://github.com/i-schuetz/SwiftCharts/blob/master/
SwiftCharts/Layers/ChartPointsScatterLayer.swift#L227
Please ensure you are passing correctly the color.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/i-schuetz/SwiftCharts/issues/298#issuecomment-330100888,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAOOj98_zGX0tB3NZac8C8xOlMw2j9Nks5sjagCgaJpZM4PaAnL
.

You will have to debug this, since I don't have time (sorry). It shouldn't be difficult to figure by looking in the scatter layer. If there's a bug then a pull request is welcome.


Test fails for 'nested resolver with many nested rows'

Signed-off-by: Riccardo Fiorenza<EMAIL_ADDRESS>

This patch should solve this:
diff --git a/packages/sql-graphql/lib/entity-to-type.js b/packages/sql-graphql/lib/entity-to-type.js
index 8099d69..687db38 100644
--- a/packages/sql-graphql/lib/entity-to-type.js
+++ b/packages/sql-graphql/lib/entity-to-type.js
@@ -281,11 +281,14 @@ function constructGraph (app, entity, opts, ignore) {
   async function loadMany (keys, queries, ctx) {
     const fields = getFields(queries)

+    let limit = 0
+
     // TODO this is inefficient as it might load
     // more data than needed if there are more than
     // one primary key
     const where = keys.reduce((acc, pairs) => {
       pairs.reduce((acc, { key, value }) => {
+        limit++
         if (acc[key]) {
           acc[key].in.push(value)
         } else {
@@ -301,6 +304,7 @@ function constructGraph (app, entity, opts, ignore) {
     const res = await entity.find({
       where,
       fields,
+      limit,
       ctx
     })

Don't worry about the windows failure

This patch should solve this:

Thank you @mcollina, it works!


Introduce sandbox context

What type of PR is this?
/kind feature
What this PR does / why we need it:
This introduces a sandbox context which contains the static data needed to recreate the sandbox(the SandboxConfig) and the data needed to operate the sandbox, like the pod level namespaces (the SandboxState). In the future this could also be used to inject additional dependencies into the sandbox without needing to change the interface.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?
Introduce sandbox context

Codecov Report

Merging #570 (c9361b0) into master (c7b380c) will increase coverage by 0.00%.
The diff coverage is 32.22%.

@@           Coverage Diff           @@
##           master     #570   +/-   ##
=======================================
  Coverage   19.21%   19.22%
=======================================
  Files          32       32
  Lines        3685     3725   +40
  Branches     2185     2213   +28
=======================================
+ Hits          708      716    +8
- Misses       1149     1163   +14
- Partials     1828     1846   +18


Quickly launch groups of apps

Description of the new feature / enhancement
This new feature would allow:

Allow a user to start a set of applications, position them in to Fancy Zones and then save the layout referencing the apps and zones.
Allow the user to later recall the preset to reload the same applications to the same fancy zones at a later time
Allow the user to define a file to be loaded with the application as part of the preset
Edit the Preset for application layouts in fancy zones to change the application (executable file) assigned to a specific fancy zone or the file loaded
Associate a hot key with a Fancy Zone Application Layout preset

Scenario when this would be used?
This allows many use cases:

Robust business use cases leveraging fancy zones.
Robust workspace layouts that allow a user to go instantly back to their workspace rather than having to remember and re-position each application to the desired fancy zone
Use of Fancy zones in very large collaborative environments such as visualization centers, meeting auditoriums and other meeting spaces where very specific visual layouts are desired
Technical briefings of products, product information, program management tasks and VIP type business meetings where lots of data needs to be effectively arranged into different predefined screen areas

Supporting information
This feature could be similar to the behavior of tools such as the Nvidia Quadro / RTX Experience View tool or products such as Mechdyne Meeting Canvas or Vis Cube.
Window snapping in windows 11 does not in any way provide the functionality described in this idea.

Snap groups may be what you're looking for, it is built into Windows 11.
https://support.microsoft.com/en-us/windows/snap-your-windows-885a9b1e-a983-a3b1-16cd-c531795e6241#WindowsVersion=Windows_11

Windows 11 window snapping in no way provides any of the functionality that I described. The functionality is to be able to save a preset that stores application executable-to-window location and startup file as in quadro RTX desktop manager from Nvidia.  I do not believe the "developer" that responded has any clue what I am talking about. Is more description needed?

Snap groups may be what you're looking for, it is built into Windows 11.
https://support.microsoft.com/en-us/windows/snap-your-windows-885a9b1e-a983-a3b1-16cd-c531795e6241#WindowsVersion=Windows_11

Apps snapped into Fancy Zones don't currently seem to be treated as a Snap Group by the OS

@ouuens that is because the two snapping systems are not the same.

xref https://github.com/microsoft/devhome/issues/853


ASPM on PCIe supported?

Hi,
i have a ASRock N100M Mainboard and a LattePanda Mu, both with Ubuntu installed. On the LattePanda Mu i can't get ASPM for PCIe running?
sudo dmesg | grep ASPM
ASRock N100M:
[    0.020926] PCIe ASPM is forcibly enabled
[    0.282164] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
[    0.301633] pci 0000:03:00.0: ASPM: overriding L1 acceptable latency from 0x0 to 0x7
LattePanda Mu
[    0.035200] PCIe ASPM is disabled
[    0.123456] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.354135] acpi PNP0A08:00: _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]
[    0.354349] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
[    0.372246] pci 0000:04:00.0: ASPM: overriding L1 acceptable latency from 0x0 to 0x7
This is the Setting in the ASRock N100M BIOS:

Thanks.

Thank you very much for your feedback, we will pay attention to the work of energy-saving technologies, including ASPM, in the development of the next version of BIOS

Great to hear, it is really important for the PCB I am currently developing.


tonal.scaleRange behaving differently to range.scale

With latest versions from NPM:
> range = require('tonal-ranges')
> range.scale('C D E F G A B', 'C3', 'C2')
[ 'C3', 'B2', 'A2', 'G2', 'F2', 'E2', 'D2', 'C2' ]
> tonal = require('tonal']
> tonal.scaleRange('C D E F G A B', 'C3', 'C2')
[ 'C3' ]

Hi @kasbah,
Thanks for reporting this issue. Unfortunately tonal-ranges is deprecated, but it can't be unpublished due the new policy from npmjs. I'm sorry for the name pollution (I've just added a deprecated warning). The actual library is called tonal-range (in singular).
The usage is:
var range = require('tonal-range')
range.scaleRange('c d e f g a b', 'c3 c2') // => [ 'C3', 'B2', 'A2', 'G2', 'F2', 'E2', 'D2', 'C2' ]

Obviously is quite confusing, so I will try to improve the documentation (issue #13) or find a nice solution (so I'll keep this issue open)
Cheers,
Dani

Thanks @danigb, the main problem seems to be that tonal.scaleRange is giving an invalid result though?
> tonal = require('tonal']
> tonal.scaleRange('C D E F G A B', 'C3', 'C2')
[ 'C3' ]

Well, the problem in fact is with the function signature. The range must be specified as a single string, so instead of: scaleRange(..., 'C3', 'C2') you have to write scaleRange(...,'C3 C2')
This was not a right decision, so I'll improve it too.

Oh ok, it isn't it using tonal-range code itself?

Yes, tonal.scaleRange is the same function as range.scaleRange. The problem is in the documentation. I'll fix it ASAP.

Ah I see, I think it was mainly this documentation which led me astray.

Exactly. But I think the function signature is more natural as the documentation says... I think it will accept both forms: scaleRange(scale, range) and scaleRange(scale, start, end). I went with the first one for some reason I don't remember right now. I'll take a look and try to find a solution. Meanwhile you can use it as: scaleRange(scale, range)

Thanks very much! If you are going to amend it though I just thought I'd mention how I am using it. Currently I grab scales from tonal-scales and then I have to bring them into the string format as well which is a little awkward. Maybe there is a better way to do this?
const tonalScales = require('tonal-scales')
const tonalRange = require('tonal-range')

function getNotes(scale) {
    return tonalRange.range(tonalScales.scale(scale).join(' '), 0, 127)
}

I had another thought about the original bug: why not just publish tonal-ranges to be the same as tonal-range?

I think all tonal functions accepts list of notes as strings or as arrays, so you don't have to do the convertion:
var notes = tonalRange.range(tonalScales.scale(scale), 0, 127)

But again, I have a name pollution problem. The actual library is not tonal-scalesbut tonal-scale:
var scale = require('tonal-scale')
var range = require('tonal-range')
var notes = range.scaleRange(scale.get('C major'), 'c2 c4')

I now this is confusing. I'll fix that too. I'm open to suggestions.
Thanks!

I like your solution with the npmjs names problem.

Hey again, now scaleRange and other seems to have been removed from tonal-range 0.69 (even though it's still documented in the README)? I just tried to upgrade from 0.50. All the documented functions seem to be gone now.
> require('tonal-range')
{ numeric: [Function: numeric],
  chromatic: [Function: chromatic],
  fifths: [Function: fifths],
  pitchSet: [Function: pitchSet] }


Embed map in admin UI?

Investigate integration of the existing website map UI with the admin panel

#241


Use WIT cache instead of fetching same WITs many times

This cache is just a simple synchronized unexported global var.
Fixes #242

Can one of the admins verify this patch?

@aslakknutsen could you please take a look? This is almost the same PR as outdated https://github.com/almighty/almighty-core/pull/497
I just fixed all conflicts, rebased and removed a few commits which I really don't like. This is a pretty simple cache based on a global unexported map. If you think it's not worth introducing such a map then I would move #242 to backlog and take care of something more important for this sprint. We could work on some better and global cache solution later when our API (including internal) will be more stable and we will need to work on optimization.

Current coverage is 69.78% (diff: 93.33%)

Merging #591 into master will increase coverage by 0.92%

@@             master       #591   diff @@
==========================================
  Files            71         75     +4
  Lines          4046       4292   +246
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           2786       2995   +209
- Misses          987       1011    +24
- Partials        273        286    +13

Powered by Codecov. Last update 4839d29...5b6876f

[test]

@alexeykazakov When is the cache invalidated?

@kwk It's 'invalidated' on server restart, which is currently the only time we mutate(due to lack of proper immutable wits) the wits.
Even when we have DisplayName/Description, those properties belong to a WIT which is still immutable.
The original Cache PR has some numbers. But in short, when fetching the WorkItemList we can fetch up to 100 WI's in one SQL, then for each WI in the result we fetch 1 WIT via 1 SQL.
This cache removes 100 WIT Fetch SQL's per WorkItemList REST Fetch.


JWT Authentication

In the sign up route, save the user to the DB and generate a JWT token and send it to the client.
In the login route, validate the user's password against the DB, if correct generate JWT token and send it to the client.
In the client, after receiving JWT token, save it to the local storage and to the context.
Decode the token and save it to the context when the app starts up.
Add the token to every request after the client has been authenticated.
In the back-end verify the JWT token before handling requests in protected routes.

Currently we've finished the backend logic for signing up user and login them in.
We generating a JWT token for both of this endpoint.


Use of reserved keyword in function argument

This issue is about a problem in one of Phaser modules.
An attempt to minify Phaser code, using a recent uglifyjs-webpack-plugin, will fail. While investigating the issue, I found that the src/physics/matter-js/components/Friction.js module contains a function argument named static.
At first, running the dist script will complete without fail, but the Webpack plugin included in the Phaser 3 package is outdated. Prefixing the module with a "use strict"; line yields the following exception, though:
ERROR in ./physics/matter-js/components/Friction.js
Module parse failed: The keyword 'static' is reserved (5:39)
You may need an appropriate loader to handle this file type.
| var Friction = {
|
|     setFriction: function (value, air, static)
|     {
|         this.body.friction = value;
 @ ./physics/matter-js/components/index.js 8:14-35
 @ ./physics/matter-js/MatterSprite.js
 @ ./physics/matter-js/Factory.js
 @ ./physics/matter-js/Matter.js
 @ ./scene/plugins/PhysicsManager.js
 @ ./scene/local/Systems.js
 @ ./scene/local/Scene.js
 @ ./phaser.js

Recent versions of the UglifyJS plugin are more sensitive, and will fail regardless the absence of "use strict";.
This issue will likely affect users trying dev-kits containing recent releases of UglifyJS, including the Webpack plugin.

Yeah, this was fixed in #3117 and is now merged


My bower is installed. But on gulp serve I get the below issue,Error: Error: modernizr is not installed. Try running bower install.

Hello.
Is modernizr declared in your bower.json ?
If so, have you run bower install ?

yes It is and Bower installation was fine. I verified using bower list and modernizr is listed with its version.

This is fixed . My bower install installed all its components under my project but my gulp server was expecting for bower components to be under a folder named bower_components. I created a folder bower_components and moved all its components under it after which gulp serve was running fine. Thanks for the help :) Grégory Pelletey.


Add zero-shot classification demo

Source code for https://huggingface.co/spaces/Xenova/zero-shot-classification-demo

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

How can you get the model to give you the categories to begin with?

How can you get the model to give you the categories to begin with?

I'd recommend using sentence-transformers for this. There are some tutorials online (like this one), which can also be useful here.  Although, if you're interested in running with transformers.js, you should be able to reimplement some of the helper functions in JS, perhaps those needed as preprocessing or postprocessing steps on top of the model itself (which you can run with transformers.js).


database saving error

After imputing and saving data on properties, some information is lost. For instance, the field descrição, localizacao,  is not saving in the data base. It is necessary to check why it is not saving.

This is very serious, because implies database reliability

This has been fixed


set-up for 5.1.3

Steps to reproduce
I have followed the set-up file and try to add an Google Cloud Project number
But helas, it tells me I don't have sufficient rights (I need to configurate the "OAuth consent screen")
I do receive the reminder e-mail, but

no age is presented
It only gives 1 reminder (not the reminders for over 2 or 7 days)
also in the subject, it only gives that one reminder (of today)

What action or series of actions is the cause of the issue?

action 1;
action 2;
action 3;

Expected behavior
What should happen?
Current behavior
What happens instead?
Context

Version of the script: x.x.x - look for a line near the top of the code which
reads:
version: 'w.x.y-z',

Any other details which might be related to the context;

Extended description
Try to describe the problem in the most complete way. You can add images,
error messages, hypothesis and observations regarding the problem here.
Possible solution
If you think you know what causes the problem or if you know a solution for it
write it here.

Hey, thank you for filing this issue. Unfortunately, I am not certain if I understood you correctly. You said that you receive emails, which means that you have setup the script correctly.
Regarding the email notifications prior to the events, you have to set anticipateDays in the script accordingly. Did you do that?
The age calculation can be wrong if an incorrect javascript engine is set. Could you go to the script -> click the gear icon on the top left -> and ensure that the Chrome V8-Runtime is activated?

Thanks Michael,
First a small correction.
It seems the version 5.1.3 did correctly send me also the anticitaped
events (for today, and for in 2 days and in 7 days)
But it did NOT give the years
Nor (as I see now) did it give the teleplhone number (for the anticitated
events)
I did set the anticipateDays correctly on 0, 2, 7:
[image: image.png]
And the V8-runtime was already activated:
[image: image.png]
"Strange" thing is that I kept the old version (5.0.1) alive and that one
works fine (although in another gmail account I have the same problem (no
years) for this version)
version 5.0.1:
[image: image.png]
version 5.1.3:
As you can see for Marc Roels (birthday tomorrow 25/11) the e-mails addres
is there, but not his telephone number
And for non the "years" is calculated (the "91 jaar" you see is part of the
contact's name. It is his age at the moment she passed away (then 91 years,
today she would have been 98 years)
[image: image.png]
Groeten,
Jaap
Op do 24 nov. 2022 om 11:08 schreef Michael Plainer <
@.***>:

Hey, thank you for filing this issue. Unfortunately, I am not certain if I
understood you correctly. You said that you receive emails, which means
that you have setup the script correctly.
Regarding the email notifications prior to the events, you have to set
anticipateDays in the script accordingly. Did you do that?
The age calculation can be wrong if an incorrect javascript engine is set.
Could you go to the script -> click the gear icon on the top left -> and
ensure that the Chrome V8-Runtime is activated?
—
Reply to this email directly, view it on GitHub
https://github.com/GioBonvi/GoogleContactsEventsNotifier/issues/190#issuecomment-1326228787,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKBW32Z5DE2GMAJ6DDJGBFDWJ45DFANCNFSM6AAAAAASKA5PO4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Does somebody why I do get the reminder emails, but the age is missing?

I think that I was able to reproduce this issue. Will keep you posted here.
The issue seems to be https://github.com/GioBonvi/GoogleContactsEventsNotifier/blob/ff969c95c5c9039c68df9858cedee02307e7750e/code.gs#L443-L445

Could you test if the code here:
https://github.com/GioBonvi/GoogleContactsEventsNotifier/pull/191
resolves your issues?

No.
No change.
Still not a calculated age
Have I made the correct changes??

changed the version number on line 169
the lines 325 - 330 were already there
added a questionmark "?" in line 438 (or 444)

Op ma 28 nov. 2022 om 22:20 schreef Michael Plainer <
@.***>:

Could you test if the code here:
#191 https://github.com/GioBonvi/GoogleContactsEventsNotifier/pull/191
resolves your issues?
—
Reply to this email directly, view it on GitHub
https://github.com/GioBonvi/GoogleContactsEventsNotifier/issues/190#issuecomment-1329776935,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKBW324AU4NBNSO5QLAS4CLWKUO2RANCNFSM6AAAAAASKA5PO4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Lines 325-330 were deleted.
Could you share your config? (please remove your email for privacy reasons)

no, still no age calculation
How do I share my "config" ???

The settings can be found from line 12-173 of your script. With them I can see whether the same issue persists for me.
But as said above, please delete your email from the script.

var settings = {
user: {
/*
* GOOGLE EMAIL ADDRESS
*
* Replace this fake Gmail address with the Gmail (or G Suite/Google Apps) address of your
* own Google Account. This is needed to retrieve information about your contacts.
/
googleEmail<EMAIL_ADDRESS>/
* NOTIFICATION EMAIL ADDRESS
*
* Replace this fake email address with the one you want the notifications to be sent
* to. This can be the same email address as 'googleEmail' on or any other email
* address. Non-Gmail addresses are fine as well.
/
notificationEmail<EMAIL_ADDRESS>/
* EMAIL SENDER NAME
*
* This is the name you will see as the sender of the email: if you leave it blank it will
* default to your Google account name.
* Note: this may not work when notificationEmail is a Gmail address.
/
emailSenderName: '(verjaardags) kalender van xxxxxxxxxx',
/
* LANGUAGE
*
* To translate the notifications messages into your language enter the two-letter language
* code here.
* Available languages are:
*   en, cs, de, el, es, fa, fr, he, id, it, kr, lt, nl, no, nb, pl, pt, pt-BR, ru, th, tr.
* If you want to add your own language find the variable called i18n below and follow the
* instructions: it's quite simple as long as you can translate from one of the available
* languages.
/
lang: 'nl'
},
notifications: {
/
* HOUR OF THE NOTIFICATION
*
* Specify at which hour of the day would you like to receive the email notifications.
* This must be an integer between 0 and 23. This will set and automatic trigger for
* the script between e.g. 6 and 7 am.
/
hour: 0,
/
* NOTIFICATION TIMEZONE
*
* To ensure the correctness of the notifications timing please set this variable to the
* timezone you are living in.
* Accepted values:
*  GMT (e.g. 'GMT-4', 'GMT+6')
*  regional timezones (e.g. 'Europe/Berlin' - See here for a complete list: http://joda-time.sourceforge.net/timezones.html)
/
timeZone: 'Europe/Rome',
/
* HOW MANY DAYS BEFORE EVENT
*
* Here you have to decide when you want to receive the email notification.
* Insert a comma-separated list of numbers between the square brackets, where each number
* represents how many days before an event you want to be notified.
* If you want to be notified only once then enter a single number between the brackets.
*
* Examples:
*  [0] means "Notify me the day of the event";
*  [0, 7] means "Notify me the day of the event and 7 days before";
*  [0, 1, 7] means "Notify me the day of the event, the day before and 7 days before";
*
* Note: in any case you will receive one email per day: all the notifications will be grouped
* together in that email.
/
anticipateDays: [0, 1, 7],
/
* TYPE OF EVENTS
*
* This script can track any Google Contact Event: you can decide which ones by placing true
* or false next to each type in the following lines.
* By default the script only tracks birthday events.
/
eventTypes: {
BIRTHDAY: true,
ANNIVERSARY: true,
CUSTOM: true
},
/
* MAXIMUM NUMBER OF EMAIL ADDRESSES
*
* You can limit the maximum number of email addresses displayed for each contact in the notification emails
* by changing this number. If you don't want to impose any limits change it to -1, if you don't want any
* email address to be shown change it to 0.
/
maxEmailsCount: -1,
/
* MAXIMUM NUMBER OF PHONE NUMBERS
*
* You can limit the maximum number of phone numbers displayed for each contact in the notification emails
* by changing this number. If you don't want to impose any limits change it to -1, if you don't want any
* phone number to be shown change it to 0.
/
maxPhonesCount: -1,
/
* INDENT SIZE
*
* Use this variable to determine how many spaces are used for indentation.
* This is used in the plaintext part of emails only (invisible to email clients which display
* the html part by default).
/
indentSize: 4,
/
* GROUP ALL LABELS
*
* By default only the main emails and phone numbers (work, home, mobile, main) are displayed with their
* own label: all the other special and/or custom emails and phone numbers are grouped into a single
* "other" group. By setting this variable to false instead, every phone and email will be grouped
* under its own label.
/
compactGrouping: true
},
debug: {
log: {
/
* LOGGING FILTER LEVEL
*
* This settings lets you filter which type of events will get logged:
*  - 'INFO' will log all types of events event (messages, warnings and errors);
*  - 'WARNING' will log warnings and errors only (discarding messages);
*  - 'ERROR' will log errors only (discarding messages and warnings);
*  - 'FATAL_ERROR' will log fatal errors only (discarding messages, warnings and non-fatal errors);
*  - 'MAX' will effectively disable the logging (nothing will be logged);
/
filterLevel: 'INFO',
/
* Set this variable to: 'INFO', 'WARNING', 'ERROR', 'FATAL_ERROR' or 'MAX'. You will be sent an
* email containing the full execution log of the script if at least one event of priority
* equal or greater to sendTrigger has been logged. 'MAX' means that such emails will
* never be sent.
* Note: filterLevel has precedence over this setting! For example if you set filterLevel
* to 'MAX' and sendTrigger to 'WARNING' you will never receive any email as nothing will
* be logged due to the filterLevel setting.
/
sendTrigger: 'ERROR'
},
/
* TEST DATE
*
* When using the test() function this date will be used as "now". The date must be in the
* yyyy/MM/dd HH:mm:ss format.
* Choose a date you know should trigger an event notification.
/
testDate: new Date('2022/11/24 00:00:00')
},
developer: {
/ NB: Users shouldn't need to (or want to) touch these settings. They are here for the
*     convenience of developers/maintainers only.
*/
version: '5.1.4',
repoName: 'GioBonvi/GoogleContactsEventsNotifier',
gitHubBranch: 'master'
}
};

This is my execution log:
23:06:40	Mededeling	Uitvoering gestart
23:06:40	Informatie	I: test() running.
23:06:40	Informatie	I: main() running.
23:06:40	Informatie	I: validateSettings() running.
23:06:41	Informatie	I: generateEmailNotification() running.
23:06:41	Informatie	I: Date used: Fri Dec 02 2022 00:00:00 GMT+0100 (Central European Standard Time)
23:06:41	Informatie	I: Looking for contacts events on Fri Dec 02 2022 00:00:00 GMT+0100 (Central European Standard Time) (2022-12-02T00:00:00+01:00 / 2022-12-02T00:01:00+01:00)
23:06:41	Informatie	I: Found: 2
23:06:42	Informatie	I: Looking for contacts events on Sat Dec 03 2022 00:00:00 GMT+0100 (Central European Standard Time) (2022-12-03T00:00:00+01:00 / 2022-12-03T00:01:00+01:00)
23:06:43	Informatie	I: Found: 0
23:06:43	Informatie	I: Looking for contacts events on Fri Dec 09 2022 00:00:00 GMT+0100 (Central European Standard Time) (2022-12-09T00:00:00+01:00 / 2022-12-09T00:01:00+01:00)
23:06:44	Informatie	I: Found: 1
23:06:44	Informatie	I: Found 3 events.
23:06:44	Informatie	I: Extracting info from raw event object...
23:06:44	Informatie	I: Extracting info from Google Contact...
23:06:44	Informatie	I: Fetching contact info for: d6e9a160bde51a7
23:06:44	Informatie	W: People is not defined
23:06:44	Informatie	W: Invalid Google Contact ID or error retrieving data for ID: d6e9a160bde51a7
23:06:44	Informatie	I: Extracting info from raw event object...
23:06:44	Informatie	I: Extracting info from Google Contact...
23:06:44	Informatie	I: Fetching contact info for: 3419b9798eb52e2d
23:06:44	Informatie	W: People is not defined
23:06:44	Informatie	W: Invalid Google Contact ID or error retrieving data for ID: 3419b9798eb52e2d
23:06:44	Informatie	I: Extracting info from raw event object...
23:06:44	Informatie	I: Extracting info from Google Contact...
23:06:44	Informatie	I: Fetching contact info for: ebeeee78d70edc0
23:06:44	Informatie	W: People is not defined
23:06:44	Informatie	W: Invalid Google Contact ID or error retrieving data for ID: ebeeee78d70edc0
23:06:44	Informatie	I: Found 3 contacts with matching events.
23:06:44	Informatie	I: Checking birthdays on Friday 02-12-2022
23:06:44	Informatie	I: Found 1 birthdays
23:06:44	Informatie	I: Checking anniversaries on Friday 02-12-2022
23:06:44	Informatie	I: No events found on this date.
23:06:44	Informatie	I: Checking custom events on Friday 02-12-2022
23:06:44	Informatie	I: Found 1 custom events
23:06:44	Informatie	I: Checking birthdays on Saturday 03-12-2022
23:06:44	Informatie	I: No events found on this date.
23:06:44	Informatie	I: Checking anniversaries on Saturday 03-12-2022
23:06:44	Informatie	I: No events found on this date.
23:06:44	Informatie	I: Checking custom events on Saturday 03-12-2022
23:06:44	Informatie	I: No events found on this date.
23:06:44	Informatie	I: Checking birthdays on Friday 09-12-2022
23:06:44	Informatie	I: Found 1 birthdays
23:06:44	Informatie	I: Checking anniversaries on Friday 09-12-2022
23:06:44	Informatie	I: No events found on this date.
23:06:44	Informatie	I: Checking custom events on Friday 09-12-2022
23:06:44	Informatie	I: No events found on this date.
23:06:44	Informatie	I: Building the email notification.
23:06:44	Informatie	I: Sending email...
23:06:44	Informatie	I: Email sent.
23:06:44	Mededeling	Uitvoering voltooid

What I don't understand is, while I use as a  testDate: new Date('2022/11/24 00:00:00')
and anticipateDays: [0, 1, 7],
The log says: 23:06:41 Informatie I: Date used: Fri Dec 02 2022 00:00:00 GMT+0100 (Central European Standard Time)

Yes, this seems odd to me. Just to get the obvious out of the way: You saved the script, right?
Secondly,  23:06:44 Informatie W: People is not defined seems weird. Maybe there is something wrong with the people api integration.

something weird
I had a working old (5.0.1) version, with age correct calculation:

I copied (for testing purposes) the full script to a new project, changed nothing !!, added the calendar API, gave rights, and yet the age calculation is still there, but wrong:

I had to add People API to make it working, althought it is not mentioned in the Installation and setup

I actually think that does make a difference....
But it helps only partially (I get some with the calculated date, some
without and some double)
But for some odd reason I get now 1 contact with a special event (date of
death) mentioned two times:

once without the calculated years since his decease
and one with the calcutaled years

The only thing still missing (which was there in the previous versions) is
the "nickname" of the contact  added to the body
(as I have an extended family, sometimes in the "nickname" I have put
information who is who. eg. "daughter of ...". or "son of .....")
Groeten,
Jaap
Op wo 30 nov. 2022 om 16:41 schreef ekos2001 @.***>:

I had to add People API to make it working, althought it is not mentioned
in the Installation and setup
https://github.com/GioBonvi/GoogleContactsEventsNotifier/blob/master/docs/install-and-setup.md
[image: image]
https://user-images.githubusercontent.com/12628077/204842275-6cfeca27-c58c-4cca-ba07-49f488b84fec.png
—
Reply to this email directly, view it on GitHub
https://github.com/GioBonvi/GoogleContactsEventsNotifier/issues/190#issuecomment-1332364853,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKBW32ZIBGWKNHOR6YMICK3WK5YT5ANCNFSM6AAAAAASKA5PO4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Thanks @ekos2001, I have it also activated. But when I implemented the feature in #177, it seemed like we don't need to manually activate it. That might have changed, or was not working properly for new users.
@JaapAntwerp regarding this issue:

Have you included the changes from #191? Because those should also resolve the duplicate / missing code calculations.
Regarding the nick names, lets create a second issue
I will document the people api and also create a separate issue for that.

I have re-started everything, re-copied the original code, made the
changes, activated the People API  and YES, IT WORKS !!!
And I even copied it to my other gmails accounts, and (again) YES, IT WORKS
!!!!
Thanks
Groeten,
Jaap
Op wo 30 nov. 2022 om 18:18 schreef Michael Plainer <
@.***>:

Thanks @ekos2001 https://github.com/ekos2001, I have it also activated.
But when I implemented the feature in #177
https://github.com/GioBonvi/GoogleContactsEventsNotifier/pull/177, it
seemed like we don't need to manually activate it. That might have changed,
or was not working properly for new users.
@JaapAntwerp https://github.com/JaapAntwerp regarding this issue:

Have you included the changes from #191
https://github.com/GioBonvi/GoogleContactsEventsNotifier/pull/191?
Because those should also resolve the duplicate / missing code calculations.
Regarding the nick names, lets create a second issue
I will document the people api and also create a separate issue for
that.

—
Reply to this email directly, view it on GitHub
https://github.com/GioBonvi/GoogleContactsEventsNotifier/issues/190#issuecomment-1332492791,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKBW323T3AQMIBFZYSSGLDDWK6D5FANCNFSM6AAAAAASKA5PO4
.
You are receiving this because you were mentioned.Message ID:
@.***>


Switch out rails-assets with bower-rails

Can you move the rubocop changes into a separate PR (or just push to master)? It's a bit difficult to see what actually has changed.

:mushroom:
(don't forget squashing ;)


Done translating high-order components

booking the page "Higher-order components" translation

Done :)

Hi @mohshbool, please review this page. Thanks.

Done :)

Great work on your translation. I just had one comment because I think this is a big change.
I noticed that you translated 'high-order components' => 'المكونات ذات الترتيب الأعلى' but according to the glossary it should be 'مكونات من المرتبة الأعلى'.

Done :)

Great work on your translation. I just had one comment because I think this is a big change.
I noticed that you translated 'high-order components' => 'المكونات ذات الترتيب الأعلى' but according to the glossary it should be 'مكونات من المرتبة الأعلى'.

We have faced the same problem in docs/nav.yml (  me & @Fcmam5  )  .. i think المكونات ذات الترتيب الأعلى  is better ..

--> should we update the glossary in this point.

Should we stick with the glossary or with hsoub translation?

Should we stick with the glossary or with hsoub translation?

not sure but I personally went with the glossary, I actually only compared my translation with hsoub's after I was done translating, rather than basing my translation on it

Should we stick with the glossary or with hsoub translation?

I suggested that we stick to a wiki-hasoub at the beginning and when we finish everything ( first release ) we organize a good glossary and fix all small bugs.
@iRayan7  @Fcmam5  @aladin002dz  @mohshbool @maskeddeveloper

Should we stick with the glossary or with hsoub translation?

I suggested that we stick to a wiki-hasoub at the beginning and when we finish everything ( first release ) we organize a good glossary and fix all small bugs.
@iRayan7 @Fcmam5 @aladin002dz @mohshbool @maskeddeveloper

This is the approach I am supporting.

please allow me to make those little suggestions 😃
i will continue the review process another time

@mohshbool all your suggestions committed! ;)

please allow me to make those little suggestions 😃
i will continue the review process another time

@mohshbool all your suggestions committed! ;)

that's great! I have not finished reviewing, I'm sorry but I've been a bit busy, I will finish the review by midnight (utc+3) hopefully!


New package: HOFASM v0.1.0

Registering package: HOFASM
Repository: https://github.com/charlescolley/HOFASM.jl
Created by: @charlescolley
Version: v0.1.0
Commit: 5c4db3749346f20ff806a828db219f12c6606f55
Git reference: master

Upon further consideration, it may be best to cancel this pull request.


Wait until FixedUpdate can see events before dropping them

Objective
Currently, events are dropped after two frames. This cadence wasn't chosen for a specific reason, double buffering just lets events persist for at least two frames. Events only need to be dropped at a predictable point so that the event queues don't grow forever (i.e. events should never cause a memory leak).
Events (and especially input events) need to be observable by systems in FixedUpdate, but as-is events are dropped before those systems even get a chance to see them.
Solution
Instead of unconditionally dropping events in First, require FixedUpdate to first queue the buffer swap (if the TimePlugin has been installed). This way, events are only dropped after a frame that runs FixedUpdate.
Future Work
In the same way we have independent copies of Time for tracking time in Main and FixedUpdate, we will need independent copies of Input for tracking press/release status correctly in Main and FixedUpdate.
--
Every run of FixedUpdate covers a specific timespan. For example, if the fixed timestep Δt is 10ms, the first three FixedUpdate runs cover [0ms, 10ms), [10ms, 20ms), and [20ms, 30ms).
FixedUpdate can run many times in one frame. For truly framerate-independent behavior, each FixedUpdate should only see the events that occurred in its covered timespan, but what happens right now is the first step in the frame reads all pending events.
Fixing that will require timestamped events.

Doesn't this create the opposite problem where events could be missed outside of FixedUpdate if the fixed timestep is lower than delta time?

Doesn't this create the opposite problem where events could be missed outside of FixedUpdate if the fixed timestep is lower than delta time?

Hmm, yeah. I guess it really does need to be an indirect signal after all. I'll change it so that FixedUpdate queues the swap and then applies the swap at the beginning of the next frame.

Related to https://github.com/bevyengine/bevy/issues/6183.

It might be nice to document the exact behavior here, but given that this is a known-stopgap solution, I don't think it's particularly important to do so.

I think a good addition here might be to check if the time this event was last sent is really long, and in those cases emit a warning that the user may not be calling this method (for the cases where someone turned off FixedUpdate, and is rolling their own version, but didn't know that calling this was a requirement). The time-based approach would ensure that this is notified to the user at a specific interval regardless of how many events are actually sent.

(Moving to 0.12.1 so we don't forget to consider it, not because I think it should land there)

I'd like to propose a possibly controversial alternative: inputs should never be read in a fixed update system.
This is not just a way to fix this, this is a fundamental design remark: inputs are inherently tied to rendering, in the sense that they're polled in the main loop, that most inputs produce visible reactions, and that in AR/VR inputs determine the camera transform. So querying user input in fixed update I think is a design mistake.
Now, I can understand that this is not convenient, in particular when you want physics to react to user inputs. But I think this should be handled by the user on a case by case basis.
Note that Unity has exactly the same issue/limitation. This is by design. Only problem is in Unity this is poorly documented, short of a tangential note:

Note: Input flags are not reset until Update. You should make all the Input calls in the Update Loop.

Let me add a few more proofs that this is a bad idea:

as commented above the reverse problem exists
this is not an input only issue, this affects all events
we're talking about Update and FixedUpdate but the new time API allows other fixed clocks; how do we handle events for those? We don't know a priori the frequency of those updates.
since the ratio of frame to fixed frame is variable, this means the event can be:

arbitrarily delayed between its observing in Update and its observing in FixedUpdate; does it make sense to read input events from several frames ago? How will your game logic handle reading different contradicting inputs emitted on different updates but read together on fixed update?
that delay is variable frame to frame, which makes reasoning and proper handling very difficult. What if input handling is based on some state but he state changed after the update frame but before the fixed update one?

I'd like to propose a possibly controversial alternative: Inputs should never be read in a FixedUpdate system.
This is not just a way to fix this, this is a fundamental design remark: inputs are inherently tied to rendering, in the sense that they're polled in the main loop, that most inputs produce visible reactions, and that in AR/VR inputs determine the camera transform.
So querying user input in FixedUpdate I think is a design mistake.

You thought wrong. Input is not "inherently tied to rendering". It's not inherently tied to anything. We don't poll input. Input events are continuously delivered to us from the OS (through winit and gilrs) as they happen. Those events build up and we just happen to drain them into our Events resources once per frame.
If you want to mention AR/VR, AR/VR applications want async reprojection, and that requires being able to, at any arbitrary time, read newer input events that showed up in the middle of the frame. (Just so you know, we can't do this without #9122.)
Your argument really has no basis. You seem misinformed about how state changes even make their way from an input device to an application. You also don't seem to have really read the PR description or any of the existing context surrounding this issue.

Now, I can understand that this is not convenient, in particular when you want physics to react to user inputs. But I think this should be handled by the user on a case-by-case basis.

Thinking that this is a case-by-case problem shows a lack of understanding.

Note that Unity has exactly the same issue/limitation. This is by design. Only problem is in Unity this is poorly documented, short of a tangential note:

Note: Input flags are not reset until Update. You should make all the Input calls in the Update Loop.

No it isn't. Unity's legacy input module has said limitation. Their "new input system" does not (API docs here). Unity still can't do things properly in both Update and FixedUpdate at the same time (it's one or the other). That'll just be another way Bevy handles time better than Unity does. Unity developers have asked for events to be handled how I'm proposing.
In the first place, Unity isn't a particularly well-designed engine. If you want evidence from another engine, look at Godot. They have added a feature addressing this same issue.

Let me add a few more proofs that this is a bad idea: as commented above the reverse problem exists. This is not an input only issue, this affects all events.

Why do you consider this a problem? Your answer to someone wanting to read events in FixedUpdate is to just shrug. This PR is supposed to affect all events. They will all benefit from this change and from the soon-to-come timestamps.

We're talking about Update and FixedUpdate but the new time API allows other fixed clocks; how do we handle events for those? We don't know a priori the frequency of those updates.

This PR doesn't have a priori knowledge either. If users demanded more clocks, the solution would be the same—keep events alive until they're in the "past" for all clocks. But frankly, that's an unreasonable demand. The new Time API allowing other clocks to exist was just a footnote. Users don't actually need other clocks because there is no other essential cadence besides "frames" and "ticks".

Since the ratio of frame to fixed frame is variable, this means the event can be arbitrarily delayed between its observing in Update and its observing in FixedUpdate. Does it make sense to read input events from several frames ago?

It's completely sensible. Do you understand how games like Overwatch and Counter Strike 2 are able to have features like "High Precision Mouse Input" and "Sub-Tick Input"?[^1] They timestamp input events as they're received (from the OS) so that they can be seen on the correct tick (and even account for the exact moment within the tick something happened), which is exactly what I'm proposing / where I'm trying to get us. I guess those are design mistakes too.

How will your game logic handle reading different contradicting inputs emitted on different updates but read together on fixed update?

There are no "contradicting" inputs. Input events arrive continuously. Grouping them by tick is just as arbitrary as grouping them by frame. Update and FixedUpdate see the same time elapse, they just experience different spans of it at different times. Accordingly, they should observe the same events, just in different batches and at different times.

That delay is variable frame to frame, which makes reasoning and proper handling very difficult. What if input handling is based on some state but he state changed after the update frame but before the fixed update one?

This PR and what I've stated in the Future Work section is the proper handling. There is nothing users will need to reason about.
(Honestly, with the amount of effort I've invested into Bevy specifically to improve fixed timestep and input, it's really upsetting that I have to spend so much time convincing people that I know what I'm doing. Like here I am, writing the umpteenth wall of text on something I've tried to explain numerous times before. It's frustrating.)
[^1]: These are all fancy titles describing framerate-independent input handling.

@maniwani I share your frustration and perspective, but your tone is quite abrasive.

Note that Unity has exactly the same issue/limitation. This is by design

I think that we should make events work, by default, for all users, regardless of the architecture they choose. The existing design silently and sporadically fails, for all events (not just input) that are sent between the main schedule and FixedUpdate. This is not an implementation detail we should burden users with.
The tradeoffs here for fixing this bug are very mild: events persist slightly longer, which may result in a slight bounded increase in the memory their queues use. I'm not immediately clear how one might integrate this work with other types of user-defined Time, but that's largely because I have not seen anyone using them.
Timestamped input events are an important next step, but I am fully on board with @maniwani's vision of how we can solve this problem.

but your tone is quite abrasive

I apologize. I've put a ton investment in these scheduling and timing problems, and that comment seemed to have been made without similar "due diligence" (and I really did not want to see this delayed because of a misunderstanding), but I should have responded more courteously.

I'm not immediately clear how one might integrate this work with other types of user-defined Time, but that's largely because I have not seen anyone using them.

If we needed that (I really don't think we do, but just hypothetically), all we'd have to do is refine the signalling mechanism. We'll most likely need to tweak how it works to accomplish what I wrote in the Future Work section anyway.

@maniwani can you rebase this quick / merge in main to get the new CI check working?

Sorry it looks like I was a bit imprecise with some terms, which caused some confusion. But I think we have the same understanding of the ideal solution.

Input is not "inherently tied to rendering". It's not inherently tied to anything. We don't poll input. Input events are continuously delivered to us from the OS (through winit and gilrs) as they happen. Those events build up and we just happen to drain them into our Events resources once per frame.

OS may poll or receive events from hardware, and OS in turn may expose poll or event-based APIs. "Delivered" is probably a better term as you pointed. In any case, the way events are delivered to Bevy is not really important I think for this discussion. But the most common and expected way is likely for users that inputs are updated each "frame", and the frame concept is defined by the main dynamic clock. That would be different if we emitted input events multiple times per frame/tick/period though. But if we do it once periodically, then "once per frame" is probably the best model, no?

Since you mentioned AR/VR, AR/VR applications want async reprojection.

Yes, but that requires substepping/timestamping as you detailed, and is beyond the scope here, although I agree that this should be the goal. I was thinking more simply as a fallback in the meantime that rendering is ticked against the main dynamic clock, and wants the most recent inputs, so if you read inputs in a different clock (and that clock has a good chance of being at lower frequency, the most common case being physics ticking at 40/30/20 Hz), you might have 2+ frames with the same input, which will likely induce issues like motion sickness. So again I think this is an argument for inputs being ticked against the main clock. We could argue some games want to read updates in FixedUpdate only. But the main dynamic clock is probably a safer default.

Unity's legacy input module has said limitation, but their "new input system" does not (API docs here). Even then, Unity can't handle events properly in both Update and FixedUpdate at the same time (it's one or the other).

I don't think enabling "one or the other" can be considered having lifted the limitation. I think you'll agree this doesn't change anything.; you just swap the Update and FixedUpdate terms and the discussion is more or less the same. I'm glad we're aiming for something better (timestamping), but the fact Unity's new input has the same limitation as their legacy one maybe is a hint that this is on purpose rather than by mistake or lack of expertise? My take is that they don't want to add internal complexity for the sake of also adding usage complexity for users; asking for inputs from both Update and FixedUpdate only makes sense if the set of inputs you're reading in each is disjoint (e.g. read player WASD in FixedUpdate for driving physics, and read ESC key in Update to open a menu); otherwise you'll need to reconcile both reads, or you're back to losing events. And that's I think hard to explain to users. Having users handle all inputs in one or the other is safer, and as @paholg mentioned not that more difficult.

But frankly, that's an unreasonable demand. The new Time API allowing other clocks to exist was just a footnote. Users don't actually need other clocks because there is no other essential cadence besides "frames" and "ticks".

The new Time API PR introduces 3 clocks. There's also a discussion from a Bevy user immediately asking about how to use the API to create a custom clock. I wouldn't call that a footnote, nor would I assume users don't want custom clocks. I do agree this is probably not very common though. That doesn't mean we should break it; if we allow the pattern we should support it.

Does it make sense to read input events from several frames ago?

It's completely sensible. Look at Overwatch's "High Precision Mouse Input" or Counter Strike 2's "Sub-Tick Input".1 Those work by timestamping input events as they're received (from the OS) so that they can be seen on the correct tick (and even account for the exact moment within the tick something happened), which is exactly what I'm proposing / where I'm trying to get us.

I'm talking about an API returning non-timestamped events from 2+ frames ago, which will be very hard for a lot of users to interpret and process against the current game state, since they don't know when that event was first emitted (which frame), do they? I agree timestamping fixes the issue, but in the meantime without timestamps the API will be hard to use. This is what I meant by "contradicting events"; if an event says to move one way (in frame N) and another says to move the other way (in frame N+1), but you don't know which frame(s) they were emitted from because you're reading them both in a later FixedUpdate, then they may contradict each other when applied to the current game state (which is wrong; they should be applied to the state at the frame they were captured; but you can't do that without knowing the frame or timestamp). Or do we have "frame timestamp" with those events? I don't think we do.
I think I still have concerns that the current change might steer people into the wrong pattern(s) and increase the risk of footgun. Saying we fix a bug by avoiding lost events when read from FixedUpdate sounds nice, but the users should be made to understand why this "bug" exists in the first place (dynamic vs. fixed clocks). And what this change also does for me is:

Keep the bug and make it more obscure by fixing the common case (fixed clock) and leaving it broken for other cases (custom clocks).
Encourage (or at least, not prevent) users to read input events "from multiple clocks", which will have those users shoot themselves in the foot. I understand that this enables a convenient pattern where disjoint inputs are read where they're needed. But that also enables reading the same inputs twice. And to that respect, Unity's "one or the other" protects users from that footgun.
Make the internals of event management even more complex, by keeping events alive for "a dynamically changing duration based on the relative ticks of a dynamic and a fixed timestamp", which is hard to reason about to make sure the Bevy implementation is correct.

Instead, we could be educating users (via docs and/or helpers and/or API limitations) on how to best handle input events by reading and processing them all from a single system against a single clock, possibly multiple times per frame for advanced usage, and then derive from there any logic which might affect systems ticking against other clocks (like physics simulation). As @paholg confirmed, this is not very difficult to do. Or maybe we "just" need something like leafwing-input-manager, because this is really what users want (or, need), not reading raw input events at all for most user actions. The complex and precise input interactions mentioned are very specific to some genres and some particular user actions (player movement) and I think can perfectly be implemented without reading events from multiple clocks.
No need to block this PR on me. I don't think I have any consensus here. But I wanted to make sure some of those drawbacks are raised.

Or maybe we "just" need something like leafwing-input-manager, because this is really what users want (or, need), not reading raw input events at all for most user actions

Definitely agree: I'm looking to eventually upstream this. Users should very rarely be reading raw inputs themselves in real games.

But the most common and expected way is likely for users that inputs are updated each "frame", and the frame concept is defined by the main dynamic clock. That would be different if we emitted input events multiple times per frame/tick/period though. But if we do it once periodically, then "once per frame" is probably the best model, no?

I never said anything about "emitting" events more than once. A system in Update can already read events one frame late because of double buffering. There's nothing new here.

Yes, but that requires substepping/timestamping as you detailed, and is beyond the scope here, although I agree that this should be the goal.
You might have 2+ frames with the same input, which will likely induce issues like motion sickness. So again I think this is an argument for inputs being ticked against the main clock.

Like I said, XR applications want to read inputs in advance, specifically to reduce motion sickness. That's not even possible for us now, but it will be once we merge #9122.

I don't think enabling "one or the other" can be considered having lifted the limitation.

I was not praising Unity. You brought up a significant shortcoming of their legacy system. They attempted to partially address that limitation in their newer system, but still fell short.
I'm a bit baffled that you're trying to argue that Unity—with all its half-baked systems—must have had a good reason for this particular thing being half-baked as well. Am I just misunderstanding DOTS and its various shortcomings are all actually clever design points that I just don't understand yet?

I'm glad we're aiming for something better (timestamping), but the fact Unity's new input has the same limitation as their legacy one maybe is a hint that this is on purpose rather than by mistake or lack of expertise?

And maybe it was an oversight and I'm right and developing our event handling according to what I propose will be better.

Asking for inputs from both Update and FixedUpdate only makes sense if the set of inputs you're reading in each is disjoint (e.g. read player WASD in FixedUpdate for driving physics, and read ESC key in Update to open a menu).

This is always the case.

Otherwise you'll need to reconcile both reads, or you're back to losing events.

No events will be lost and there's no need to reconcile things. As I've written in the PR description, the Input resource needs the Time treatment where there's one for FixedUpdate and one for the rest of the schedule.

Or maybe we "just" need something like leafwing-input-manager, because this is really what users want (or, need), not reading raw input events at all for most user actions.

Apples-to-oranges. Input-action bindings are orthogonal to this discussion about timing.

The new Time API PR introduces 3 clocks.

I'm aware of what that PR did. I helped write it. We had 3 clocks before the PR. Time used to be a 2-in-1 and the 3rd was FixedTime.

There's also a discussion from a Bevy user immediately asking about how to use the API to create a custom clock. I wouldn't call that a footnote, nor would I assume users don't want custom clocks. I do agree this is probably not very common though.
I wouldn't call that a footnote, nor would I assume users don't want custom clocks.

Just me speaking as one of the co-authors, but "users can make their own clocks" was not a big priority. The underlying clock type exists because we wanted to minimize code duplication, and it seemed like there was no harm in making it pub. Part of me is slightly regretting that right now.
I think it's a bit odd for you to place such an emphasis on it when every other engine doesn't even let you do that. Their users are not clamoring for custom clocks. A single user inquiring is not really a hint that there are many more.

That doesn't mean we should break it; if we allow the pattern we should support it.

Actual usage patterns take priority over mostly hypothetical ones.
Events didn't work in FixedUpdate. Users can use systems in FixedUpdate and those systems can read events. That was a clearly a pattern we needed to support.
Likewise, FixedUpdate still fails to fulfill its puporse of providing framerate-independent behavior. It's event handling is still wrongly coupled to framerate. This is a clear problem that needs to be fixed, but one you do not seem to acknowledge.

I'm talking about an API returning non-timestamped events from 2+ frames ago, which will be very hard for a lot of users to interpret and process against the current game state, since they don't know when that event was first emitted (which frame), do they?
I agree timestamping fixes the issue, but in the meantime without timestamps the API will be hard to use.

Users will not need to interpret or know any of that. They can write systems that read events normally. There's nothing "hard to use" about it. I think you're extrapolating too much. There is no additional cognitive burden being placed on users.

This is what I meant by "contradicting events"; if an event says to move one way (in frame N) and another says to move the other way (in frame N+1), but you don't know which frame(s) they were emitted from because you're reading them both in a later FixedUpdate, then they may contradict each other when applied to the current game state (which is wrong; they should be applied to the state at the frame they were captured; but you can't do that without knowing the frame or timestamp).

You are talking about frames in the context of FixedUpdate, which exists to provide framerate-independent behavior, i.e. these systems explicitly do not need to care about the frame something happened.
I don't think this was a productive discussion.

If you emit events from FixedUpdate, they are going to be missed.

No, that's not correct. If you emit an event in FixedUpdate it will be queued in the front buffer. The front buffer will be swapped to the back buffer at the beginning of the next frame, so those events will be sitting pretty in that back buffer (both buffers are visible to readers) until after the next frame that runs FixedUpdate. FixedUpdate will see those events and queue another swap, and then those events will finally be dropped on the frame after.

If you disable FixedUpdate schedule, events are going to pile up infinitely.

Downside: .run_if() still misses events.

I'll give you simple and ill-advised. But it's not a solution.
I will not support that. It was like the second idea I considered and rejected a year ago. It solves nothing. Pretending the problem doesn't exist and punishing users for wanting the framerate-independence they were promised is just silly.
This is not a problem that can (or should) be fixed by redefining it.

I'm sure that was all considered before.

Yes, I did consider all of this.
Buffered events have never claimed to be reliable (and they clearly can't be without leaving room for a memory leak). This PR improves upon the status quo by making it so events are only "missed" when they're ignored by run_if.
Waiting for an event to be read by all systems with the corresponding reader will suffer from the opposite problem of one forgotten run_if causing events to never be dropped.
I'm sure it feels like such a longstanding issue shouldn't be fixable by a tiny PR like this, but this is the most concise, least "hacky" solution to this issue that I landed on after months. And the most substantial criticism thus far has been that it doesn't just work seamlessly with the brand-new thing that just came out.
When we introduce timestamps, we can make it so that only events with timestamps that are in the past from the POV of the "most behind" Time registered get dropped. (That has been my plan from the start.)
It won't harm y'all to trust the process.
(Also double buffering vs. single, ring buffer is pretty functionally equivalent. Double buffering uses more memory but it makes it cheaper to drop the events.)

If you emit events from FixedUpdate, they are going to be missed.

No, that's not correct.
This PR improved upon the status quo by making it so events are only "missed" when they're ignored by run_if.

Sorry, you're correct there. Then, this PR is actual improvement, besides the potential infinite buffering case (which we should have a warning for in the future).

tie events to schedules

Main is composed of different schedules. I don't think we can have a situation where Update can't read events emitted by systems in PreUpdate.

Read that as independent schedules. In Update and PreUpdate case, all events there can be tied to Main (as long as we can ensure that Update is only called by Main, and never by user). Aside: I'm still thinking in old paradigms when Update and PreUpdate were base system sets.
But if someone calls the same schedule from Update and FixedUpdate, that schedule would be isolated (can only read its own events, and its own events can only be read by it). If that's an issue, then this solution is not adequate.

Buffered events have never claimed to be reliable (and they clearly can't be without leaving room for a memory leak).

They can be reliable (assuming you have a certain definition of reliability):

you introduce limits (keep no more than X events AND no event can be stored for more than Y seconds).
raise a warning when those limits are reached
these limits can be flexibly defined by the user

either per event (define limits when you define event)
or per-event-reader, like struct<E: Event, L: Limits> LimitedEventReader;, with default EventReader having some sane values

Those "limits" are called QoS policies, and that's well-developed topic in enterprise systems. "No more than X events" is called Depth, "no more than Y seconds" is called Lifespan. If you are looking to pitch a startup for investors, that's a very profitable idea!
This can in theory solve all EventReader problems! In practice, users won't understand it, limits will be misconfigured, memory will be leaked, but we would blame the users. It isn't worth it just for run_if's (and custom conditional schedules), but maybe we can get some ideas there.

When we introduce timestamps, we can make it so that only events with timestamps that are in the past from the POV of the "most behind" Time registered get dropped. (That has been my plan from the start.)

Okay, sounds great.

For those that run into this, and are using Res<Input<KeyCode>> in their fixed update systems, you will still get missed inputs, the solution is to use events in fixed update as fixed in this PR, if you want to use Input<KeyCode> you can use local system param (Local<Input<KeyCode>>) and feed it events, like so:
fn handle_input(
    mut keys: Local<Input<KeyCode>>,
    mut keyboard_input_events: EventReader<KeyboardInput>,
) {
    keys.clear();
    for event in keyboard_input_events.read() {
        if let Some(key_code) = event.key_code {
            match event.state {
                ButtonState::Pressed => keys.press(key_code),
                ButtonState::Released => keys.release(key_code),
            }
        }
    }

    let up = keys.pressed(KeyCode::Up);
    let down = keys.pressed(KeyCode::Down);
    let left = keys.pressed(KeyCode::Left);
    let right = keys.pressed(KeyCode::Right);
    let respawn = keys.just_pressed(KeyCode::Return);

    // do something with inputs
}

FWIW this change def has impact on certain ways you were able to use events to move the camera for example. I just updated from 0.11 to 0.12.1 and was wondering why my camera suddenly ended up in weird positions.
Its not he prettiest code but it got stuff done:
add_systems(Update, mouse_motion.run_if(in_state(GameState::BallGame).and_then(input_pressed(MouseButton::Left))))
Inside the mouse_motion system the EventReader<MouseMotion> was read and I was quite surprised to see a whole pile of mouse movements stacked up, making the camera ending up at some weird position due to applying lots of undesired movements. I do understand the desire to persist events longer, but it is a big breaking change.

FWIW this change def has impact on certain ways you were able to use events to move the camera for example. I just updated from 0.11 to 0.12.1 and was wondering why my camera suddenly ended up in weird positions.
Its not he prettiest code but it got stuff done: add_systems(Update, mouse_motion.run_if(in_state(GameState::BallGame).and_then(input_pressed(MouseButton::Left))))
Inside the mouse_motion system the EventReader<MouseMotion> was read and I was quite surprised to see a whole pile of mouse movements stacked up, making the camera ending up at some weird position due to applying lots of undesired movements. I do understand the desire to persist events longer, but it is a big breaking change.

i have a very similar setup for mouse wheel input. i switch between scrolling and zooming with keyboard presses. every time the buttons are pressed, all the mouse wheel events are replayed and the camera ends up in wild positions.
  mouse_wheel_input
      .pipe(zoom_game)
      .run_if(zoom_key_pressed),
  mouse_wheel_input
      .pipe(scroll_game)
      .run_if(scroll_key_pressed),


Apply maven build cache extension

maven-build-cache-extension normally increases build speed about 6x faster.
It requires to upgrade the version of maven wrapper from 3.8.x to 3.9.x

This extension looks still having some problem, target directory is not generated when the project is cached, but target directory had been cleaned.


Add historical hydrate

I'm currently wanting to use this for restoring values in a document both at the latest state as well as sometimes from historical versions, using _at queries with the list of heads.
I can't see how to use autosurgeon's hydrate for this but I may be missing something. If it is missing I'd be happy to have a go at implementing it.

Ok, that sounds good. In the meantime I think I should be able to add a wrapper struct myself to use the _at calls when needed.
I think fork_at would be too expensive to be practical for this application but worth noting.


test for limits (storage size, wal size) exhaustion

Found no better place for my remarks:
Running with --client 10 passes on staging. I tried to run --no-vacuum --client 100 --skip-some-updates , got:
pgbench (14.2)
pgbench: error: connection to server at "start.stage.zenith.tech" (<IP_ADDRESS>), port 5432 failed: ERROR:  Failed to connect to the compute node: db error: FATAL: remaining connection slots are reserved for non-replication superuser connections
in compute-node logs
	2022-04-22 10:28:45
throbbing-forest-567082 FATAL  remaining connection slots are reserved for non-replication superuser connections
	2022-04-22 10:28:46

. With --client 10  it passes OK.


Mixed Module results in two help fiels

Steps to reproduce
Create a module with
@{
RootModule = "Foo.psm1"
NestedModules = "Foo.dll"
}

Each exporting cmdlets
Expected behavior
A single file in en-US\Foo.help.xml
Actual behavior
Two files:
en-US\Foo.dll-Help.xml
en-US\Foo-help.xml

Environment data

v0.9.0

When calling
Get-Help foo
only the help from Foo-help.xml is displayed. Nothing from the binary cmdlets.

@powercode thanks for reaching out and reporting this issue.
Does Get-Command discover commands in both .psm1 and .dll files?

This is by design.

This is by design.


Improve search

The issue with wildly irrelevant results ended up not being with semantic search queries, but was because the Opensearch match query does an OR on tokens by default, meaning we'd get false positives like 'military defence organisation' for 'flood defence', as both matched on 'flood'.
This PR changes all OR operators to AND, which excludes a lot of irrelevant summaries and text passages.
There's nothing to do to the search threshold as semantic search similarity doesn't currently match up to our definitions of relevant search results. This is slightly to do with passage quality, and slightly to do with the fact that we're using a general model.
Take this following set of passages and similarities to the query "energy prices", that i've put into buckets of correct and incorrect results for the search:
correct:
70.98756408691406 -- Concerning the energy sector, the Vision has as a principal objective to ensure that by 2025 both the rural and urban populations have access to reliable, clean sources of energy and at competitive prices
74.38273620605469 -- ).The world today faces two main threats related to energy – inadequate and insecure supplies at affordable prices and global warming due to over-consumption of fossil fuels.The prospects for global energy markets heighten concerns about energy security and the impact of climate change on energy-dependent small island states such as Jamaica.As stated by the IEA, “The challenge for all countries is to put in motion a transition to a more secure, lower-carbon energy system, without undermining economic and social development.
69.68185424804688 -- business operations will be exposed to risks of rising prices for water, energy, materials, and waste disposal.The private sector has an interest – and an economic opportunity – in managing the natural capital portfolio wisely, as many of the goods and services supplied by ecosystems cannot be replaced at any reasonable cost.
70.33955383300781 -- We plan to raise the efficiency of the government’s support system and make the best use of its benefits by redirecting it and targeting eligible citizens and economic sectors. For example, we understand that providing subsidies with no clear eligibility criteria is a substantial obstacle to the energy sector’s competitiveness. Free market prices shall, in the long term, stimulate productivity and competitiveness among utility companies and open the door to investment and diversification of the energy mix in the Kingdom. We will also seek to set clear subsidy criteria based on the maturity of economic sectors, their ability to compete locally and internationally and their actual need for subsidies, without endangering promising and strategic sectors.

incorrect:
75.83150482177734 -- of energy
75.09526824951172 -- energy sources
75.03023529052734 -- sustainable energy
74.73570251464844 -- energy linkages and issues
74.38256072998047 -- energy-related
74.35993957519531 -- energy and water
73.26209259033203 -- Consumers Price Index (CPI)
72.38282012939453 -- Quotable Value Quarterly House Price Index.
72.09774017333984 -- The higher subsidies for ECE are budgeted to cost $131.1 million in operating funding over the four-year forecast period. This is on top of the $105 million that we provided for the ECE
75.79498291015625 -- Energy Security
73.5206527709961 -- Fees
73.16166687011719 -- case costs

i've added minimum_should_match parameters for each match query which impose the following extra conditions:

if the search query is 2 terms or less, all terms should match
if the search query is longer than 2 terms, 66% of terms (rounded down) should match.

weirdly this didn't seem to have any impact in my tests, but leaving it in because it'll be useful if it starts working!


feat(Dialog): Add ability to set custom footer

Warnings

:warning:
There are no updates provided to CHANGELOG. Ensure there are no publicly visible changes introduced by this PR.

  Generated by :no_entry_sign: dangerJS

@kolaps33 Let's also add DialogFooter-test.ts, you can use HeaderDescription-test.ts as reference 🔨


fix(frontend): The fees needs to be computed based on the amount_burnt

Story
https://github.com/nearprotocol/nearcore/pull/2813 and https://github.com/nearprotocol/nearcore/pull/2872 introduced dynamic gas pricing and a new field amount_burnt should be used to correctly reflect the fees.
Acceptance Criteria

[ ] The transaction fee is computed as a sum of amount_burnt
[ ] Gas price should be removed from the Transaction Details page as it dynamic over time and the gas price on a single block is not representative for a transaction fee
[ ] The changes are backwards compatible, so mainnet, testnet, etc still work using the simple gas_burnt * gas_price formula
[x] Reviewed by @evgenykuzyakov

Notes
https://github.com/nearprotocol/nearcore/pull/2872 is not merged yet, so there is no field in the RPC yet. Thus, this issue is blocked at the moment.
@evgenykuzyakov Please, review the plan for the changes on Explorer, so we are on the same page here.

The transaction fee is computed as a sum of amount_burnt

Correct. Renamed the field into tokens_burnt.

Gas price should be removed from the Transaction Details page as it is not used

True.

The changes are backwards compatible, so mainnet, testnet, etc still work using the simple gas_burnt * gas_price formula

I assume this is for legacy deployed chains. Yes. The total tokens_burnt can be calculated from the sum of gas_burnt * gas_price
NOTE: We should still display total gas burnt and total prepaid gas amount as before.

@frol Do you still think we should remove "Gas Price"? Seems like this is still dynamic, correct?
See #364 for changes @ilblackdragon is suggesting to Gas Price.

Do you still think we should remove "Gas Price"? Seems like this is still dynamic, correct?

It is dynamic, but why should we remove it? I agree that we should display it better though.

[ ] The transaction fee is computed as a sum of tokens_burnt

I agree that we should display it better though.

Once we have NEAR Indexer for Explorer (/cc @khorolets) we will be able to break down the gas price to the receipts granularity and then it will make sense, but currently, displaying a single value based on the initial block is not useful anyway, and I would even say that it is misleading and thus harmful.

I see. That makes sense.

okay, I get that.


ticket updates attribute/metric additions

This PR includes the following changes:

The addition of ticket updates attributes and metrics highlighted within the Zendesk Ticket Updates Dataset documentation. Please note a high number of metrics were covered in the previous dbt_zendesk PR #12
Minor ReadMe and .yml documentation updates to reflect the appropriate model changes.
Notable change to the int_zendesk__field_pivot model with down stream effects for incorporating the user_id of the updater.

To ensure all Zendesk Ticket Updates fields are included you may reference the working Zendesk Support Metrics Google Sheet with my notes on where the fields can be found within the package if not explicitly created in this PR.
Joe's PR Overview Loom Video

QQ - how difficult would it to include the updater_name rather than updater_Id in the zendesk__ticket_field_history table? I just ran it as an example and find it pretty hard to read with all the IDs

I was able to fix the satisfaction scores good -> bad and bad -> good flag with some additional logic within the int_zendesk__ticket_historical_satisfaction model.
Additionally, I was able to leverage logic used within the dbt_jira package and create a new upstream int_zendesk__field_history_enriched model which joins the user information prior to pivoting. The field_updater_name was then easily added to the field history model for each tracked field. We can easily extrapolate this for the additional updater fields if we would like to remove the field_updater_id(s) altogether.

@fivetran-kristin I created a second Loom video going into high level some of the updates applied after your initial review. One thing I forgot to mention in the video is that all the appropriate updater fields are outlined within the ReadMe to allow users to simply copy and paste the relevant fields into their own dbt_project.yml.
Let me know if you have any questions!
Joe's 2nd PR Overview Loom Video


feat: add DE & WM categories

Bifurcation from #433
I tried to use "official" color of the logos but the darker ones were adjusted a bit. dwm uses the suckless color.
I'm not sure what causes the error in Xterm, I need to look for a patched font to test there and urxvt, Symbols only fallbacks on Alacritty.
Does this PR causes also problem?
Fix #432

I'm not sure what causes the error in Xterm, I need to look for a patched font to test there and urxvt, Symbols only fallbacks on Alacritty.
Does this PR causes also problem?

This branch is fine. It appears to be an issue with one of the additional icons not in this PR.

Returning OK:
print(require("nvim-web-devicons").get_icon("i3"))
print(require("nvim-web-devicons").get_icon("plasma"))


Run Single Model on Multiple GPUs

You might have many small GPUs, which may not load RWKV. But we can parallelize it!

Easy to use, just tell your program how many GPUs you want to use.
Compatible with CUDA_VISIBLE_DEVICES environment variable

which means you can assign any devices you desire

For single GPU instance, just set args.NUM_PARA_GPUS=1

Great work :) My idea is to keep the main ChatRWKV repository simple (easy for everyone to learn its code), while having some community forks with cutting-edge functions.
If you are interested, I can tell everyone to add new functions to your fork.

That would be great! I am also working on other features... just don't know where to contribute. It would be awesome if you could show me where and how!

Nothing offensive, but honestly I found the global variables are abused in the current code base. It may be a challenge for new comers to read and understand the work.

Nothing offensive, but honestly I found the global variables are abused in the current code base. It may be a challenge for new comers to read and understand the work.

Yeah my code is full of bad designs :) needs some refactor one day...

That's cool! I think I will close this PR now~


Config is such an overloaded word, lets replace it with something more meaningful

I came across a situation where I was passing around a Config global object in a class that used mixlib-cli and I realized I really didn't like that command line options are parsed into a config hash. I realize this makes it have a similar API to mixlib-config.
Opening this PR as a suggestion and to start a conversation. LMK what y'all think

somewhere in chef/knife i think it winds up getting refered to as config which is indeed terrible and leads to chef_config being used for the Chef::Config option.
i'm not sure that parsed_options would be much better though, and it might want to be cli_options although that makes for cli.cli_options, but that isn't how it gets invoked mostly in client/knife code.
of course it could be cli.parsed_options and the short name could be cli_parsed_options but that's getting wordier and this is a very common reference in knife.
there's also sort of the weirdness, now that i think about it, that the Chef::Config and cli options are actually merged into the config hash inside of knife.  so the config for the application are meant to come from the merged parsed config and the cli config.  maybe that is retained then and you only change this option, and the merged config is maintained as the config?  if you do that though then the scope is pretty limited, and now you're merging the config with the thing that we're not calling config any more to produce the merged config...   that's leading me towards thinking config is the right word to use here...
random first impressions off of the top of my head tho...

Not against this but there is a roughly 0% chance we could ever change this (i.e. remove the compat method) since it's baked into every knife plugin and a ton of important ones are effectively unmaintained these days :-/

I'd be a fan of cli_parsed_options, but I think we should actually decide if we care to deprecate the old term and make it something better. We should probably have that convo before doing anything here.

I understand the backwards compatibility issue. I'm still +1 on introducing a delegate so new projects I start that use mixlib-cli could stop referring to it as config

deprecating the old usage would be pretty super annoying.  if you just puts something on stderr here, its just going to generate a tirefire of bug reports and angry users in every project that uses this.  you can add a delegate but i'm fairly :-1: on deprecating it, since i think we have a hundred more important things to bug users about, and this is purely cosmetic naming for devs -- changing the name has zero added utility for users.

Updated this to remove any mention of deprecation


Allow printing out + copying of full variables in VSCode

Your proposal
Right now, it seems impossible to print out or copy a variable without the value being truncated by ellipses. I've looked around, but haven't found an option that allows this. Whether I print out the value in the debug console, or use the Variables or Watch side panel, all values keep getting truncated by ellipses.
it would be a great help! I don't know if this is something that this gem has control over, or if this is on VSCode to support.

Now you can write a text into the file like File.write('/tmp/memo', obj.inspect) (or directly to the clipboard with platform dependent way like pbcopy on macos) on debug console.
Sorry I'm not sure how to provide further way.
Please reopen if someone have good idea.


Criminal Girls: Invite Only [PCSE00516]

Game summary

Game name: Criminal Girls: Invite Only
Game serial: PCSE00516
Game version: 01.00

Vita3K summary

Version: v0.1
Build number: 1293
Commit hash: https://github.com/vita3k/vita3k/commit/164267b

Test environment summary

Tested by: IllusionMan1212
OS: Windows 10 Pro
CPU: AMD Ryzen 5 1600
GPU: NVIDIA GTX 1050Ti
RAM: 8 GB

Issues
Black screens on sceSaveDataDialogGetStatus
Screenshots
None at the moment
Log
vita3k.log

Vita3K summary

Version: v0.1
Build number: 1395
Commit hash: https://github.com/vita3k/vita3k/commit/76189aa

Issues
Goes ingame with almost everything not visible
Screenshots

Log
vita3k.log

Vita3K v0.1.5 2746-75b12013
still missing graphics during the intro
ingame no problems so far
vita3k.log

Vita3K summary

Version: v0.1.8
Build number: 3209
Commit hash: https://github.com/vita3k/vita3k/commit/22ea4f03
CPU backend: Dynarmic
GPU backend: Vulkan

App summary

App name: Criminal Girls: Invite Only
App serial: PCSE00516
App version: 1.00
Screenshots

Log
vita3k.log

Tested using lastest vulkan drivers on android 13/ using a Samsung S20+ snapdragon 865
There's minor graphical glitches but asides from that, the game seems to be working well
https://github.com/Vita3K/compatibility/assets/171383998/c4445d62-af23-4e8b-994c-4ce529f670ad


Feature/linux shortcuts

📒 Description
This PR adds the possibility to navigate all features in the application using only the keyboard
🕶 Types of changes

New feature (non-breaking change which adds functionality)

🤯 List of changes

Tabbing in the main window behaves as expected
It's possible to navigate the list of time entries with arrow keys (or by tabbing)
Ctrl + Enter opens/confirms the current view in all parts of the app
Ctrl + Delete deletes the selected time entry in all parts of the app (I thought the delete key would be more suitable for this because it is used for deleting stuff in other apps, as compared to backspace that is usually used to return somewhere)

👫 Relationships
Related to #2823 (PR) - should be merged first, it also implements some remarks by @IndrekV  in the comments
Follow up on #2262 (issue)
Closes #2151
🔎 Review hints
Check if the keyboards behave as expected everywhere

After start the console shows a lot of errors named
Unknown property margins
Unknown property margins
Unknown property margins

I agree with using the DELETE key.
Review notes.
Listing view

[x] Jumping to the list (tabbing to the list from timer)
[x] Moving UP/DOWN in list
[x] Open edit view for selected item in list
[x] Delete selected item in list
[ ] Pressing SPACE on should start the selected entry

Edit view

[ ] Trigger Done (from all fields)

When Description or Project field is focused the Ctrl+Enter still does not work. Probably has something to do with autocomplete key handling logic

[x ] Trigger delete

This branch is ready to be reviewed again.

I also added shortcut to open/close the grouped entries with keyboard. Now it's complete. Good job @MartinBriza !


multi-participant

How to make multi-participant? Is there a example of like one-on-one?

+1

+2

+1

WebRTC is initially one-to-one and 2p2 streaming solution. For multi-participant solutions check implementation of OpenTok (TokBox)


sentiment.json

Excuse me, how did you get this file sentiment.json?

Sentiment lexicon could be extracted in an unsupervised way through sentiment classification. https://github.com/jiangqn/Unsupervised-Sentiment-Lexicon-Extraction


Remove useless column from benchmark CSV output in Hydra mode

The code has no way of knowing which branch it is in at runtime anyway. The Nix code will add a column to the CSV data with the proper branch name for each benchmark.

LGTM


Executable support

@jclx Thank you for sending this PR! I have approved workflow runs on this PR so you may see the CI results.
I am reading through the PR and it generally looks okay. I need to see the difference between the behaviour that this PR is adding vs what we had earlier.
In the meantime, could you please sign the CLA so that this PR becomes eligible to be merged into the master branch?

@jclx Thank you for sending this PR! I have approved workflow runs on this PR so you may see the CI results.
I am reading through the PR and it generally looks okay. I need to see the difference between the behaviour that this PR is adding vs what we had earlier.
In the meantime, could you please sign the CLA so that this PR becomes eligible to be merged into the master branch?
@twarit-waikar - I signed it on 5/24. Clicking the link reports:
"You already signed the CLA on 2022-05-24"


Muting Channel in GoXLR does not Mute Channel in OBS

I just Tried out this plugin and it is amazing. Thank you very much. I just relized, when i Mute the Music channel on my GoXLR, the Channel isnt Muted on stream.
Is this not supported or is there somthing i have to do in order for this to work?
Thanks

No you are absolutely right. I just tested it and can reproduce the problem.
This is definitely a bug.
Could you please test what happens when you hold the mute button for a few seconds?
The GoXLR should then use the MuteToAll behavior.

I will check as soon as i can, thanks for your quick reply

I did some tests and I think I was able to fix the bug.
You can download the test build from this link. Just scroll to the bottom of the page and download the Windows/Linux-artifact.
https://github.com/parzival-space/obs-goxlr-fader-sync-plugin/actions/runs/9356581253
Please also let me know if this actually fixed your problem :)

Just tested the Test Build, it works like a charm. Thanks very much

Perfect, I will merge this into development then.
Thank you for reporting this issue.


Sensu crashes immediately if network/DNS is unavailable

In Sensu 0.26.5, if we start the client and network isn't available, the DNS lookup for RabbitMQ will fail and the client exits.
I'd like an option for the client to keep retrying DNS/connection by default or perhaps as a client configuration parameter (ex: retry_initial_connnect_dns = true).
Would prefer to not have to wrap additional daemon management tools around this (ex: runit).
"timestamp":"2017-01-18T16:17:36.146787-0700","level":"info","message":"configuring sensu spawn","settings":{"limit":12}}
/opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/eventmachine-<IP_ADDRESS>/lib/eventmachine.rb:677:in connect_server': unable to resolve server address: Success (EventMachine::ConnectionError)         from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/eventmachine-<IP_ADDRESS>/lib/eventmachine.rb:677:in bind_connect'
from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/eventmachine-<IP_ADDRESS>/lib/eventmachine.rb:653:in connect'         from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/amqp-1.6.0/lib/amqp/session.rb:457:in connect'
from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/amqp-1.6.0/lib/amqp.rb:242:in connect'         from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sensu-transport-6.0.0/lib/sensu/transport/rabbitmq.rb:188:in setup_connection'
from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sensu-transport-6.0.0/lib/sensu/transport/rabbitmq.rb:218:in connect_with_eligible_options'         from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sensu-transport-6.0.0/lib/sensu/transport/rabbitmq.rb:20:in connect'
from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sensu-transport-6.0.0/lib/sensu/transport.rb:24:in connect'         from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sensu-0.26.5/lib/sensu/daemon.rb:253:in setup_transport'
from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sensu-0.26.5/lib/sensu/client/process.rb:451:in start'         from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sensu-0.26.5/lib/sensu/client/process.rb:19:in block in run'
from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/eventmachine-<IP_ADDRESS>/lib/eventmachine.rb:194:in run_machine'         from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/eventmachine-<IP_ADDRESS>/lib/eventmachine.rb:194:in run'
from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sensu-0.26.5/lib/sensu/client/process.rb:18:in run'         from /opt/sensu/embedded/lib/ruby/gems/2.3.0/gems/sensu-0.26.5/exe/sensu-client:10:in <top (required)>'
from /opt/sensu/bin/sensu-client:22:in load'         from /opt/sensu/bin/sensu-client:22:in '

Hi @xyntrix,
We're preparing to release Sensu Core 0.27 which will include the changes in https://github.com/sensu/sensu-transport/pull/42. I believe these changes will better address the condition you're describing, putting Sensu into a retry loop on DNS lookups before attempting a connection.

The 0.27.0-1 is available in the unstable repositories :+1: https://sensuapp.org/docs/0.27/platforms