Step 5 & 6

Hi,
Excited to get your module for our family google calendar in MM. I am a super beginner and can't understand what to do in step 5 & 6.
5. Run authenticate.js:
node authenticate.js.
6. Follow the instructions and it should print your calendar. Copy the ID of the calendar you want to the config.
Could you describe this in a bit more details, where do i run this, how?
Thank you!

Hi @che575757ak,
In step 5 you have to run the script for authentication, this means you have to:

Open the Terminal. Check out this article that shows how to do that.
Navigate to the directory where you installed this module. You can check out the section titled "Changing directories in Terminal" in the linked article. Basically, you have to use the cd command to navigate to the module directory, in my case magic mirror is in the root directory, so I type cd ./magic-mirror/modules/MMM-GoogleCalendar.
Once you're in the module directory just type the command node authenticate.js.  This will run the script contained in authenticate.js.

Step 6 is just following the indications that are shown once you run the node authenticate.js command, it will basically show an URL which you have to copy and paste in your browser, it will take you to a google auth page and you just have to authenticate and authorize the module, once authenticated the page will show you a code which you  will have to copy and paste as it is back in the terminal.
Once completed, if everythings ok your calendar(s) ID and the events will print to the console. You can copy the calendar ID from the message in the console or you can also find it on your google calendar page by going to the settings). The calendarID is the value that you'll set in magic mirror's config/config.js
Hope I was able to help! Let me know if you were succesful!

Thank you so much for replying!  I will try your suggestion in the next few days and let you know how i make out.
Thanks again!

Hi Again,
I did as you kindly described and I get the following:
pi@raspberrypi:~/MagicMirror/modules/MMM-GoogleCalendar $ node authenticate.js
node:internal/modules/cjs/loader:936
throw err;
^
Error: Cannot find module '/home/pi/MagicMirror/modules/MMM-GoogleCalendar/authenticate.js'
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
at Function.Module._load (node:internal/modules/cjs/loader:778:27)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
at node:internal/main/run_main_module:17:47 {
code: 'MODULE_NOT_FOUND',
requireStack: []
}
pi@raspberrypi:~/MagicMirror/modules/MMM-GoogleCalendar $
Any idea what i am doing wrong?
Got to it sooner than expected as I was excited to get it to work!
Thanks!

Hi! according to the error the module is not found. Try and check if you're in the right directory, try using this command: ls it will list the files in the current directory, if you're in the right place you should see a file called authenticate.js, otherwise you got to navigate to the modules directory and execute node authenticate.js inside the MMM-GoogleCalendar directory

Hi,
There is a file called "authorize.js" nothing named "authenticate.js".  Shall i use "node authorize.js" or change file name to "authenticate.js" then use your command "node authenticate.js"?
Thanks!

I am facing the same issue..
pi@raspberrypi:~/MagicMirror/modules/MMM-GoogleCalendar $ ls
authorize.js  calendar.css  credentials.json  LICENSE  MMM-GoogleCalendar.js  node_helper.js  README.md
that are the files inside MMM-GoogleCalendar.
Maybe I/we made been mistakes during Authentication Setup?
Do we need to conduct every single step of the 4 described in the Prerequisites
( - Node.js & npm installed.

A Google Cloud Platform project with the API enabled. To create a project and enable an API, refer to Create a project and enable the API
Authorization credentials for a desktop application. To learn how to create credentials for a desktop application, refer to Create credentials.
A Google account with Google Calendar enabled.)?

@che575757ak yes, my mistake it should be node authorize.js not node authenticate.js, thanks for pointing that out, also thanks to @georgeismike for submitting the fix.

Hi,
Just ran the "node authorize.js" and i get the following:
pi@raspberrypi:~/MagicMirror/modules/MMM-GoogleCalendar $ node authorize.js
/home/pi/MagicMirror/modules/MMM-GoogleCalendar/authorize.js:26
const { client_secret, client_id, redirect_uris } = credentials.installed;
^
TypeError: Cannot destructure property 'client_secret' of 'credentials.installed' as it is undefined.
at authorize (/home/pi/MagicMirror/modules/MMM-GoogleCalendar/authorize.js:26:11)
at /home/pi/MagicMirror/modules/MMM-GoogleCalendar/authorize.js:16:3
at FSReqCallback.readFileAfterClose [as oncomplete] (node:internal/fs/read_file_context:68:3)
pi@raspberrypi:~/MagicMirror/modules/MMM-GoogleCalendar $
I really don't know what it means.  I have the credentials.json downloaded file plus the OAuth 2 Client enabled.
Thanks...

Hi @che575757ak,
This error is basically saying that the credentials file is not what this module is expecting, it could be one of two issues:

The calendar API is not enabled in the google cloud project, check if is enabled here.
The credentials are not for a web application. Probably the credential is set for TV application and not web application. Try creating a new credential and select web application. Redownload and execute node authorize.js again.

Let me know how it goes!

Hi,
I have enabled API and shows "enabled"
I recreated the credentials for web application and ran node authorize.js but getting same exact error as above.
Sorry but maybe I don't know enough to make this work!
Thanks!

@che575757ak wait, actually I got the type wrong...😅 sorry for the confusion! I was goign by memory 😅, the right credential type is actually TV and unlimited input. This should get the module working now : )
Also, I will be adding a troubleshooting guide with these errors and all experience gathered from this thread, so new users can have an easier time setting this up, I appreciate your feedback and updates!

@che575757ak were you able to get this working?

Hi,
This module is working great for one google account calendar.
How do I add calendar from another google account? Should I follow all the process again in that google account (like creating project in google developer console) ??
Please help, thanks in advance.

@getchethanbr this question is off topic, please open a new issue with your question

Closing this issue for now, feel free to open a new issue if you need any help


padding issue with drawing an average line

Hey All,
I know that I can use the following:
layout: {
padding: {
left: 0,
right: 30,
top: 0,
bottom: 0
}
},
to create padding from the right side, when I do that and draw an average line with annotation plugin  the average line gets also the padding. Is there a way to draw the line on 100% width of the canvas and the chart will ends 30px from the right side?

@cohenu I think this issue is already solved from version 1.0.2
See codepen: https://codepen.io/stockinail/pen/abyrGav


fix: [#3756] Ensure SDK packages and their dependencies support next Node.js LTS (16.x)

Fixes # 3756
Description
This PR updates the CI checks to use Nodejs 16 and three failing tests to support the new node error messages.
Detailed Changes

Updated the following GitHub workflows to use Nodejs 16:

depcheck
lint
test-compat
test-consumer
test-repoutils

Added Nodejs 16 to the test matrix in the tests GitHub workflow.
Updated the following unit tests that were asserting an error message that changed in the new version of Node.

componentDialog.test
dialogSet.test
teamsActivityHandler.test

Testing

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage remained the same at 84.548%

Files with Coverage Reduction
New Missed Lines
%

libraries/botbuilder-lg/src/templateExtensions.ts
1
84.48%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
19667

Relevant Lines:
22035

💛  - Coveralls

The deepcheck, lint, test-compat, test-consumer and test-repoutils should also be updated by changing this line, to be -node16.x-yarn, like in tests.yaml where it uses the matrix.version

I haven't noticed that. Thanks!

Promoted to MS in PR# 4046


[enhancement]: Model Preview Image

Is there an existing issue for this?

[X] I have searched the existing issues

Contact Details
<EMAIL_ADDRESS>What should this feature add?
Feature Overview:
In the "Generation" tab of the application, it would be highly beneficial to have the ability to display reference images associated with each Model or Lora. This feature would allow users to visually identify and recall the appearance or style of different models
Motivation:
User Experience: Currently, users might struggle to remember what each Model or Lora looks like without a visual reference. This feature would simplify the process, reducing the need to manually check each model or rely on memory.
Efficiency: By having a visual cue directly within the model manager, users can make quicker and more informed decisions about which model to use.
Contributor Opportunity: As mentioned in the discord conversation, the backend already maintains and allows for editing of a preview image - This would only involve an update to the front-end component to display it.

Alternatives
No response
Additional Content
No response

Will look into this.


SSL Passthrough

Hello, it would be good to know whether Contour supports ssl passthrough and if it doesn't - whether it would be possible/reasonable to add it.
NGINX ingress controller has this  ingress.kubernetes.io/ssl-passthrough: "true" annotation, it might make sense to keep the format the same to make it easier to switch between ingresses.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: contour
    ingress.kubernetes.io/ssl-passthrough: "true"
  name: relay-ingress
  namespace: default

related to #14

@rusenask  Thanks for raising this issue. I need to ask a few clarifying questions to check I understand what a successful outcome of this issue would look like.
q. In this scenario who is doing TLS processing?  Is it Contour? Is it the service the ingress points to? Is it two or maybe all three?
q. If TLS processing is being done by the final k8s service, it feels like you'd want to configure Envoy as a TCP proxy, not a HTTPS proxy. Did I get that right?

@rothgar that issue should probably be configured through another annotation:
ingress.kubernetes.io/secure-backend: "false/true"
@davecheney

q. In this scenario who is doing TLS processing?  Is it Contour? Is it the service the ingress points to? Is it two or maybe all three?

Service that ingress points to. LB and Contour would just pass through traffic to the destination, no termination should happen.

q. If TLS processing is being done by the final k8s service, it feels like you'd want to configure Envoy as a TCP proxy, not a HTTPS proxy. Did I get that right?

Not sure about Envoy TCP proxy but what I disliked in nginx-ingress was that if you set it to TCP proxy then it can't match hostnames anymore, it's more like 8080:namespace/serviceName:port:
apiVersion: v1
kind: ConfigMap
metadata:
  name: tcp-configmap
  namespace: kube-system
data:
  8080: "default/whr:8080"

Desired behaviour in this case would be that you could still route based on hostnames to different services and ports.
I hope this makes sense.

Service that ingress points to. LB and Contour would just pass through traffic to the destination, no termination should happen.

Ingress objects are strongly coupled to HTTP. This sounds like a good use case for using a service load balancer directly. Have you tried that? What are the reasons why you decided not to use this approach?

Not sure about Envoy TCP proxy but what I disliked in nginx-ingress was that if you set it to TCP proxy then it can't match hostnames anymore, it's more like 8080:namespace/serviceName:port:

If you're in TCP mode, then i'm guessing there is no HTTP request to inspect to route the traffic. It sounds like you have to dedicate the public IP to forwarding the traffic to only one service, which is very similar to the service load balancer described above.
While I think Envoy can do this, I have some doubts about how to express this in the limitations of the Ingress object.

@rusenask ping, i'd like to keep this conversation going if you have the time.

@davecheney hey, apologies.
TLS functionality would be nice so you could mix HTTP and HTTPS (passthrough) services in one ingress.
I know that you could achieve the same thing with multiple service load balancers but having it in on ingress saves you one IP (atleast in GKE) and having external load balancers in GKE costs a bit.
At least in nginx-ingress it have this and I thought it's quite nice as you can have HTTP+HTTPS+GRPC services defined in one ingress. The only downside is that nginx keeps killing long connections. I don't need contour to provision TLS certs as I request them from my backend.

Thanks for your reply. I'll be honest, I'm not sure I understand what you're asking for, but I do understand supporting the
ingress.kubernetes.io/ssl-passthrough: "true"

annotation. So I'll work on that and we can see if there is anything left to do afterwards.

The way I think this can be accomplished is to use a tcp proxy filter on the tls listener.
There are a number of caveats with this approach:

It relies on TLS/SNI for host name routing. You can't do this on normal port 80 without binding to a new port.
Envoy must do TLS negotiation before making the backend connection. I don't know how to forward the TLS negotiation to the cluster backend, that seems to defeat the SSL spec. The backend service will have a TLS connection, but that TLS connection will be between envoy and itself, not the remote client.

If someone wants to attempt this, I'll mark it for 0.5, but I think the limitations are severe enough that you'd be better off using a service loadbalancer in TCP mode, you're not getting much value by adding Envoy into the mix.

I'm going to remove the milestone from this as i'm not sure how to implement it within the framework that the k8s Ingress document provides.

this is only supported by Haproxy with L4 TCP SNI inspection.
frontend fc_tls
  bind *:443
  mode tcp
  tcp-request inspect-delay 3s
  tcp-request content accept if { req_ssl_hello_type 1 }
  use_backend abc-tls if { req_ssl_sni -i abc.example.org }
  use_backend xyz-tls if { req_ssl_sni -i xyz.example.org }
  default_backend https-back

currently Envoy doesn't support this feature but there is an old issue still active and @PiotrSikora working on a PR..

Blocked on envoyproxy/envoy#1843

Now that envoyproxy/envoy#1843 is already addressed and released on Envoy 1.7.0, it can be done once #443 gets fixed. Before doing anything and knowing that Contour is taking the use IngressRoute CRD approach (thus not polluting standard ingress with a myriad of annotations), what about something like this?
spec:
  virtualhost:
    fqdn: "www.google.com"
    tls:
      passthrough: true

I don't know if it's even possible but appears to be easily understandable.

@davecheney, @rosskukulinski can we push this forward knowing that IngressRoute (project) is already more or less well-established?

Thanks for the ping. I recently finished the upgrade of Envoy to 1.7.0 for the 0.7 milestone so I think we have all the raw materials needed to do this.
However,
spec:
  virtualhost:
    fqdn: "www.google.com"
    tls:
      passthrough: true

This isn't the only config that would change. K8s services, what envoy calls clusters, are tired implicitly to routes in the ingressroute spec. Some thought about how to change the routes... section of the spect will probably be needed.

As it seems to be declared as out-of-scope in #787, when do you think would be the best release/time window to implement this? I'm open to collaborate on this.

I know you've been waiting a long time for this so I want to try to give you the most complete explanation of the current status.
#787 will add TCP port forwarding for TLS connections. They will be decrypted at the Envoy edge and the SNI handshake used to direct the unencrypted traffic to the target pods.
This ticket is a request to add nginx's ssl-passthrough option. Having read the docs for this feature, https://kubernetes.github.io/ingress-nginx/user-guide/tls/#ssl-passthrough, I believe that #787 will add the support to Contour to enable this.
However, envoyproxy/envoy#1843, suggests that it is possible to do the SNI handshake, but somehow forward the encrypted traffic to the backend service. From my understanding of the nginx documentation this is not now ssl-passthrough works. But for completeness the nginx docs don't specify if the traffic inside the cluster is decrypted or not.
Given the ambiguity, I forwarding encrypted traffic through Envoy, what I believe this ticket is asking for, is not in scope for Contour 0.8, but obviously doing most of this plumbing will make it possible to add it in the future.

@davecheney ssl-passthrough is implemented by peeking at the TLS ClientHello message without consuming it (i.e. without performing TLS handshake at the proxy), and simply forwarding encrypted TCP packets between TLS endpoints, in both: Envoy (using TLS Inspector) and NGINX (using ngx_stream_ssl_preread_module).
The only difference between this and #787 (assuming you're using filter chain matching in Envoy) is whether or not tls_context is included in the config.

@PiotrSikora thanks for confirming.

Cannot explain better than how @PiotrSikora did, thanks! And also for the tip that the absence of tls_context makes envoy work as ssl passthrough.

Of course Dave, will do once I empirically verify it’s something that
works. I included the patch only to show you how it’s being done.
Good night,
On Wed, 19 Dec 2018 at 22:26, Dave Cheney<EMAIL_ADDRESS>wrote:

@glerchundi https://github.com/glerchundi thank you for working on
this. I need you to not set patches but signed PRs. Sorry this is a lawyer
thing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/heptio/contour/issues/15#issuecomment-448749503, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACIPln-oCqKGjZOd2iKsAtq_3SWXux3xks5u6q8HgaJpZM4QMmnF
.


SL Review - PIA

Draft a new PIA for SL Review based on who will access and see the data collected.

end to end process map is yet to be approved and finalized. PIA work will start after.

New process map developed and shared with Hasan via MS Teams. Emma Bennett is working on the PIA and aiming for submission by Sept 23, 2022

PIA drafted and revisions submitted to Jennifer O'Neil Sept 29

With Alison for review


add 'help' and 'note' modes to diagnostic detection

rustc occasionally emits diagnostics prefixed with note: and help:. This is most prevalent with the borrow and region checkers, which will emit note diagnostics at the source of the borrow and the region that a borrow is valid, respectively.
Here's a code sample before this change:

And after:

With this change the first x is highlighted green, as rustc indicates it as immutable binding.
Region checker diagnostics tend to span the entire region whose lifetime a borrow escapes, like this:

This ends up with a swath of green highlighting. This isn't the best, I think, but other editors have this same problem (a side effect of the spans that rustc gives us). You can see also in this example a borrow checker diagnostic highlighting green the right bracket indicating the location where the borrow ends.
The borrow checker diagnostics are improved a lot by this change, since we can now mouse over the source of the borrow to get the diagnostic information:

Hi, sorry for late response.
This looks useful, thank you for your contribution!


Implement a simple compilation to X64 ELF files

A currently working compilation to ELF files (targetting the amd64 instruction set) has been implemented. The compilation only works for currently supported instructions: mov and ret.
The ELF file is not meant to be executed directly, and must be linked with various object files like ctr1.o, ctri.o, crtbegin.o, crtend.o and crtn.o. Those are needed in order to initialise the C runtime.
What has been done:

Implement a library to generate ELF files easily. This can be found here.
Implement the codegen from N* to machine code.
Run the codegen from the typed AST returned by the typechecker, and write the generated ELF file to test.o.

Has to be investigated:

I don't know if the whole compiler just takes too much RAM, or if only the ELF generation does. Some profiling needs to be done to highly reduce the memory footprint (which is at about 200 MB right now, for a program as simple as true in Bash).
There are big holes in the codegen at the moment, mostly because we only try to support a minimalistic subset of the basic instruction set.
We might want later on to be able to generate executable ELF files when a _start function is present.

#13 can now be closed at least for now.

Quick update, even though the PR has already been merged.
It seems like nsc does in fact not consume much. I was trying (using time -v) to measure the memory consumed...mostly by stack when running stack exec -- nsc .... Running .stack-work/install/.../.../bin/nsc ... yields about 9MB of RAM used, which I think is still too much for what it does, but is really far better than over 200MB of RAM.


keepalived: 2.0.20 -> 2.1.3

Semi-automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/keepalived/versions.
meta.description for keepalived is: "Routing software written in C"
meta.homepage for keepalived is: "https://keepalived.org"
meta.changelog for keepalived is: ""
Updates performed

Version update

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.1.3 with grep in /nix/store/j98ddr20dzbwwjraf116avzmbzasysjy-keepalived-2.1.3

directory tree listing: https://gist.github.com/b76bb1c2438875b05ac8f9a59cea7716

du listing: https://gist.github.com/78d6fd47cf2e2dcef37608f832ef76cb

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
keepalived

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/j98ddr20dzbwwjraf116avzmbzasysjy-keepalived-2.1.3 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A keepalived https://github.com/r-ryantm/nixpkgs/archive/9629566b93485c5bdd2a56b710429fe4fc14b5a3.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/j98ddr20dzbwwjraf116avzmbzasysjy-keepalived-2.1.3
ls -la /nix/store/j98ddr20dzbwwjraf116avzmbzasysjy-keepalived-2.1.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review 1

1 package built:
- keepalived

Maintainer pings

WFM including nixos test, non-nixos linux x86_64.


jQuery minify issue with new hugo v0.113.0+extended

This issue with the latest release.

Using Hugo (v0.113.0+extended)
jquery-3.7.0.js

{{ $scripts := slice }}
{{ range site.Params.plugins.js}}
{{ $scripts = $scripts | append (resources.Get .link) }}
{{ end }}
{{ $scripts = $scripts | append (resources.Get "js/script.js") }}
{{ $scripts = $scripts | resources.Concat "/js/script.js" | minify | fingerprint "sha512" }}

without minify its working
{{ $scripts := slice }}
{{ range site.Params.plugins.js}}
{{ $scripts = $scripts | append (resources.Get .link) }}
{{ end }}
{{ $scripts = $scripts | append (resources.Get "js/script.js") }}
{{ $scripts = $scripts | resources.Concat "/js/script.js" | fingerprint "sha512" }}

Do you any info about the last version of Hugo this was OK?

Yes, this is a bug and needs to be fixed, but I think you would get a better JS setup if you rewrote the above to use

https://gohugo.io/hugo-pipes/js/
which supports imports directly from assets (e.g. your jquery)
has an option for minification

I just quickly tested this with that jQuery version and even minified it worked OK (I just ran some basic jquery examples found onklin) ... Which I guess it means that there's a certain part of jQuery that you use that somehow gets mingled. Which means that the upstream author probably needs some more info.

I'm setting up a theme and will link the repo to this issue.

@bep https://github.com/tfsojon/jquery-hugo

Not that it makes any difference in this case (it fails also starting with the unminified jQuery source), but doing minification on already minified JS sources is not something I would recommend.

@tfsojon How do I reproduce the problem with the repo you linked to?

While reducing this to a simple example, I found that the problem is exposed when the minified resource is rendered inline (see original code).
For example, this fails:
<script>{{ $js.Content | safeJS }}</script>

This does not fail:
<script src="{{ $js.RelPermalink }}"></script>

Minimal example:
git clone --single-branch -b hugo-github-issue-11132 https://github.com/jmooring/hugo-testing hugo-github-issue-11132
cd hugo-github-issue-11132

Open the browser's console, then:
hugo server

I can confirm that was fixed with tdewolff/minify v2.12.7. Verified against @tfsojon's test repo, as well as the minimal example above. Tested with minified script inline and external.

Thank You. Issue Solved with v0.114.0

v0.114.0 was a ... workaround.


Download minio errors that should be caught and re-tried

@kyungeonchoi encountered at least 2 download errors that should have been automatically caught (see his tall for more info).

Probably fixed by #479 ?


Should be an indexerror not a valueerror

see http://chat.stackexchange.com/transcript/message/34852020#34852020 for reference
Wrong exception was being caught

I've seen ValueError types in historic error captures at this line.  It would be better to capture both types if we're going to change the capture.


HashClient._set_many() fails to report failures

Following the fix of #319 in #320, set_many() does not return a list of failed keys like it used to, when ignore_exc is True.
This was detected by the tests, but instead of fixing the code, #320 includes a change to the tests, to mark the new behavior as valid.
With the old code, when exceptions are ignored, we still get a boolean value reporting the success of each operation, and the keys to be set are properly collected into their proper lists.
For the new code, there is only one set_many() operation. I submit that the correct semantics, when ignore_exc is True and the underlying operation still raised an exception, is to still avoid raising, but return all the keys in the failed collection, not the succeeded one.

@martinnj  Thanks for the deep and enlightening analysis. This explains a lot.
I would prefer that, in cases where a whole operation on a specific client fails, all the keys for that client are marked as failed; I understand that HashClient may not be always be able to tell the difference between "whole client failed" and "specific key failed", and further, I agree that it's more sensible to fix the problem at the source than to take my original suggestion, which is at best a workaround.


Should some parts of gist be re-modularized?

Were we overzealous in de-modularizing all of gist? Perhaps there are some truly separable modules.
Caution: in many cases, modularization was not viable because, due to dependencies, one of the terms had to be in gistTop. This was true of gistNetwork and also, I believe, gistIoT. We should study the history pre-modularization to avoid recreating the same problem.

An ontology versioning ontology (Michael and Boris are working on one) is a good candidate for a separate module.

Dave is also working on a software ontology.

We should consider whether these modules should have different namespaces, so that there is real modularity rather than just the intention of modularity. One of the reasons given for using a single namespace was for refactoring - moving terms from one module to another - but I see this as just a signal that these were not truly separable modules. If something is clearly separable as a module then it should have its own namespace.

From Dave: IoT should be taken out of core.

See #66 re adding to gistIoT

Candidates:

IoT - sensor, actuator, etc. but not network because it has a more general usage)

Units and magnitudes are a good candidate for modularization, so we'll add it to that bucket.
What about IoT? This should arguably be a separate gist ontology (like accounting, HR, etc.).

DECISION: We will create a new ontology file for IoT.


Adding SONOFF matter device:MINIR4M

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


[DEMO] Categorize new thread messages on Slack support channels by Altinn team

Description
Goal:
Help reduce context switching for devs on Altinn teams by evaluating which team should respond to a support request. This same bot can also be used by first line support teams to help with triage.
Approach:
Iteratively develop a suitable zero-shot or one-shot prompt for categorizing support requests by team.
Output:
JSON document containing team name or array of team names as well as a confidence score between 1 and 10.
In scope
- [x] Include description of team responsibilities and specializations as required to give additional nuance.
- [x] Test with historical support requests in relevant Slack channels
- [ ] Support multiple team categories, with confidence score.
- [ ] For demo purposes, add to existing Studio Assistant, behind a keyword `[team]`
- [ ] Add message reaction emojis for quick feedback on quality
- [ ] Listen for replies that might contain HFRL-style feedback

Out of scope
Additional Information
No response
Analysis
Ad-hoc analysis of GPT 3.5 prompting seems to be promising.
Tests of GPT-4 do not indicate significant differences so far, but it would be useful to do a proper comparison by executing against both models and comparing results of end user testing over a period of time.

Working on integrating this demo with the [docs] agent and preparing for hosting on Azure.


Table Top Defined - Bug Fixes

Submission Checklist
Required

[X] The pull request title clearly contains the name of the sheet I am editing.
[X] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[X] The pull request makes changes to files in only one sub-folder.
[X] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

Changes / Description

Bug Fixes

Fixed dark mode Inline Rolls
Fixed skills not updating
Corrected line break in spell descriptions

Character Sheet Info Roll20 Internal Use only.


Third Contribution by SAGAR ARYA

Name: SAGAR ARYA
Research Paper:

"Compiler Optimisation using Machine Learning"
"Intrusion Detection System using Machine Learning"

@arliss-NF @SavannahSimons


[libdom] Allow Response / Request to be generics

Suggestion

🔍 Search Terms

request, response, libdom, generic, generics, type parameters
✅ Viability Checklist

My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Similar to the FormData request by @wesbos in https://github.com/microsoft/TypeScript/issues/43797, it would be great if the Request and Response globals could also accept generic type parameters.
This will become more relevant as more frameworks continue to increase their usage of these standard globals, also in Node.js.
Consider the following example of an App Route handler in Next.js (handling a POST request to an API route):
export async function POST(request: Request): Response {
  const body = await request.json();
     // ^? const body: any ❌
  return new Response(JSON.stringify({
    abc: 123, // ❌ POST function return type cannot check type of response body object
  }))
}

What would be amazing would be something similar to this:
type RequestBody = { zzz: number };
type ResponseBody = { abc: number };

export async function POST(request: Request<RequestBody>): Response<ResponseBody> {
  const body = await request.json();
     // ^? const body: { zzz: number } ✅
  return new Response(JSON.stringify({
    abc: 123, // ✅ type checked
  }))
}

📃 Motivating Example

The second example in the Suggestion section above.
💻 Use Cases

For typing the response body of API routes
Prior Art
@types/express: Request and Response types - which both accept a generic type parameter.
Workaround
Response
Wasn't able to find a nice workaround for typing the body of a Response yet.
Request
Using Type Assertion / casting via as:
type RequestBody = { zzz: string };

export async function POST(request: Request) {
  const body = await request.json() as RequestBody;

Caveats

Arguably, the Request body is unknown until runtime, so this is better handled instead with Zod or some other runtime validation. But for quick/simple projects without this validation, it's nice to be able to type the request body type.

IMO the same reason applies here: https://github.com/microsoft/TypeScript/issues/33037#issuecomment-524384825
Same thing why JSON.parse() is not generic.

JSON.parse() is only one part of the equation - the parsed request body. That is why I wrote the caveat in the issue above:

Arguably, the Request body is unknown until runtime, so this is better handled instead with Zod or some other runtime validation. But for quick/simple projects without this validation, it's nice to be able to type the request body type.

Type checking the return value of a function (the Response part of this proposal) is a statically analyzable way to enforce the response shapes of API handlers (eg. especially useful with the new Response.json() static method) and does not have anything to do with the "JSON data off the wire" mentioned in your linked comment.

@karlhorky You might like this. (I saw you on my TypedFormData package! :) I build a very small wrapper around fetch, Request and Response for this particular issues :)
Ofc it's fully compatible with regular interfaces. You can check it out here! https://github.com/k1eu/typed-request


Add support for universal link with embedded URL so that when the link is is tapped, URL is opened in dapp browser #3708

Closes #3708

@oa-s will check. But tests aren't building.

@oa-s just in case you missed this:

Also, do help create the issue for Android, assign and tag it.


simulated icub on gazebo drifts when using Gaze controller

Hi, I have a code that initialises the gaze controller on simulated icub and, on a keypress event, directs the gaze on a fixed point using lookAtMonoPixel() function.
It works as expected with icub_SIM but fails using gazebo: the head robot immediately drifts after the initialisation of gaze controller
video example
   PolyDriver m_clientGaze;
   Property option_gaze;
   option_gaze.put("device","gazecontrollerclient");
   option_gaze.put("remote","/iKinGazeCtrl");
   option_gaze.put("local","/client/gaze");

   if(!m_clientGaze.open(option_gaze))
   {
   cout<<"\n[FATAL], problems in opening gaze controller...\n\t";
   cout<<"Is iKinGazeController running?...\n\n";
       std::string exit(0);
   }

   if(m_clientGaze.isValid())
   {
   m_clientGaze.view(iGaze);
   }else
   {
   cout<<"\n[FATAL], problems in viewing gaze controller...\n";
       std::string exit(0);
   }

   iGaze->setNeckTrajTime(0.8);
   iGaze->setEyesTrajTime(0.4);

   // put the gaze in tracking mode, so that
   // when the torso moves, the gaze controller
   // will compensate for it
   iGaze->setTrackingMode(true);
   iGaze->setStabilizationMode(true);

iKinGazeCtrl is launched with parameters:
iKinGazeCtrl --robot icubSim --from configSim.ini
Gazebo is launched  with parameters:
gazebo setupV0.sdf
where setupV0.sdf is my starting configuration running  icub_with_hands and the worldInterface plugin:
<?xml version='1.0'?>
<sdf version='1.4'>
  <world name="my_world">

    <!-- Light -->
    <include>
      <uri>model://sun</uri>
    </include>

    <!-- Ground Plane -->
    <include>
      <uri>model://ground_plane</uri>
    </include>

   <!-- icub  and worldinterface plugin -->
   <model name="iCub_with_hands">
   	<include>
	    <uri>model://icub_with_hands</uri>
    	</include>
        <plugin name="world_interface" filename="libgazebo_yarp_worldinterface.so">
           <yarpConfigurationFile>model://worldInterface/conf/worldInterface.ini</yarpConfigurationFile>
        </plugin>
   </model>
</world>
</sdf>

The standard output of gazebo is the following:
output.txt
Thanks for help,
Valerio

@valeriosperati I'm afraid that what you've seen is very much related to a number of open issues on https://github.com/robotology/icub-gazebo/issues that stem from the fact that icub-gazebo still need quite a lot of tuning of the low-level PID control layer.
See for example https://github.com/robotology/icub-gazebo/issues/38
Therefore, if you don't mind, I'd rather move this issue therein.

Yea, sure!

Issue moved to robotology/icub-gazebo #61 via ZenHub


chore: disable eval protection

Changes

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1437  👈 (View in Graphite)
#1426 : 1 other dependent PR (#1436 )
#1432
#1430
#1429
#1427
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


HPrevInfos for all user and team chains on the client

add an hprev_info node to the inner section of new team chain links that get sent to the server en route to other members. this uses the hprev values that https://github.com/keybase/client/pull/13387 set on the TeamSigchainState
also hoist those two values up into the outer section of those team chain links
add some test assertions that, after posting team chain links to the server, those chain links have the expected hprev seqnos

I believe the most unexpected thing about this work is the triple-case scenario in which the hprev details might be empty:

a root node of a brand new team after this has been fully deployed
a non-root node of a pre-existing team for which the local client does not yet have hprev details set on the TeamSigChainState
a user sigchain link, since those are intentionally excluded.

WIP
todo:

more tests
many clarifications

I like the idea where clients can do whatever until a certain day when we say they must send hprev_info. Otherwise, if a user upgrades only on one device and posts an hprevinfo sig they'll be forced to upgrade their other devices too.
Sequence might be

Run backfills for teams and users
Merge in checking (optional) hprev infos on kbweb
3.1. Enable hprev support on go client
3.2. Enable hprev support on webclient
(in the future) Enforce new sigs must be >2.3 on server

I wrote client/go/tools/sigchain to help benchmark sigchain loading.  It might be helpful to use it for this work.  It has support for memory and cpu profiling.

Note: I ended up going with the "forward loop after verify". If we change that logic it should be in another PR I think.
Here are some basic benchmarks with patrick's tool. I use Chris' sigchain up to link 1181--I was having difficulty inserting hPrevInfos into Sigchain v2 links and generating the sig properly.
Here's what's weird: My code runs faster than master (I've rebased) for even a sigchain without any hPrevInfos. I think this is probably due to a bug and I'm currently trying to find out why.
New code, chain without any hPrevInfos
sig chain load time: 220.659368ms
sig chain load time: 215.105665ms
sig chain load time: 185.585235ms
sig chain load time: 185.113498ms
sig chain load time: 181.354496ms
sig chain load time: 182.001488ms
New code, chain specifies hPrevInfos at every link
sig chain load time: 209.048189ms
sig chain load time: 187.376278ms
sig chain load time: 180.46583ms
sig chain load time: 183.717237ms
sig chain load time: 180.633384ms
sig chain load time: 180.596296ms
Master, chain specifies hPrevInfos but is not parsed
sig chain load time: 220.743641ms
sig chain load time: 199.590767ms
sig chain load time: 194.840192ms
sig chain load time: 200.595857ms
sig chain load time: 198.960194ms
sig chain load time: 196.902234ms

I suggested over KB messenger that @heronhaye take a count of thenumber of link unpacks, to make sure they haven't changed.

talking with @heronhaye, here's what's outstanding...
on this PR

stop actually sending high_skips to the server. we can do this with the new feature flag implementation or by wrapping it in if false to stop adding complexity to an already very large piece of work, and then replace it with a feature flag in a fast-follow.
start tracking high links on the team_sigchain_state as they come in. this was removed from an earlier commit and just needs to get put back.
get the server PR https://github.com/keybase/keybase/pull/2806 merged and deployed.
manual testing against pre-existing and new user/team chains on our deployed server code (with the feature flag off and on).

on the server PR (https://github.com/keybase/keybase/pull/2806) which validates any high_skips that are on links...

maybe a little more manual testing on user sigchains, but otherwise it's ready for more eyes. kthx!

otherwise

finish backfill - might be worth discussing if it makes sense to go 100% of the way if we only need one pre-high_skip-high-link per sigchain. already brought this up with @mlsteele.
set up feature flag on the server. off for everyone.
investigate how to build a reader/loader for teams that respects skips. we've been talking about what this will need to look like. what will have to be added to the server, how to fallback to the normal sigchain, etc. we'll make a design doc soon, but it likely won't be trivial.
same for users. teams first because we think that will maybe be easier. i wouldn't be surprised if we change our minds an even number of times.

think through roll out

are we going to get a new link type where an admin can sign for all the high links? @heronhaye mentioned it, but i was unfamiliar. maybe we can assume this will be there when we're building the reader so we can (1) take full advantage of it, and (2) reduce the scope of cases the reader will need to be able to handle.
other rollout concerns like verifying that the clients and the server 100% agree on which are high links, do we want different feature flags for user chains and team chains, etc. all things we'll dig into. :)

There's still some more work to do before merging with making sure the upgrade process is smooth. I can change the variable name but I don't understand the issue--is it wrong or just confusing?

Teams part looks good!

@heronhaye what do we want to verify before merging this? let's block off some time and push it over the finish line.

Miles' PR has a good list
modern resets

revocations

web_service_binding that are eldest (danl 7)

web_service_binding that are eldest on non-current subchains that are missing from the db

for convenience, here is that commit: https://github.com/keybase/client/commit/d75f95b9918a726698ea86877f86f2230b5fb8ac


Added Mvc localization package to MVC

cc @DamianEdwards, @Eilon, @rynowak

:watch:

The changes from my earlier comments look good. Added a few more comments, plus awaiting to see updates based on Doug's comments. :hourglass_flowing_sand:

@dougbu, @Eilon Updated code.

@dougbu Updated

The code looks :shipit: to me after a few small comments.
BTW the AppVeyor build is failing due to some doc errors or something:
[00:07:14] warn
[00:07:14] : Invalid documentation syntax in src\Microsoft.AspNet.Mvc.Localization\bin\Debug\dnx451\Microsoft.AspNet.Mvc.Localization.xml:
[00:07:14] warn
[00:07:14] :   91: This is an <see cref="T:Microsoft.AspNet.Mvc.Localization.IHtmlLocalizer"/> that provides strings for <see cref="!:TResource"/>.
[00:07:14] warn
[00:07:14] :   95: <!-- Badly formed XML comment ignored for member "M:Microsoft.AspNet.Mvc.Localization.HtmlLocalizer`1.#ctor(Microsoft.Framework.Localization.IStringLocalizerFactory,Microsoft.Framework.WebEncoders.IHtmlEncoder)" -->
[00:07:14] warn
[00:07:14] :   125: An <see cref="T:Microsoft.AspNet.Mvc.Localization.IHtmlLocalizer"/> that provides strings for <see cref="!:TResource"/>.

Also, there's this warning in the build:
[00:07:14] C:\projects\mvc\samples\MvcSample.Web\project.json(14,46): warning: Dependency specified was Microsoft.AspNet.Mvc.Localization >= 1.0.0-* but ended up with Microsoft.AspNet.Mvc.Localization 6.0.0-t150624003425.

So should fix that as well.

:watch:

@dougbu updated

cc @Eilon, @dougbu

With the exception of the special case where format substring matches "{[0-9]+}", probably can't special case HtmlString format arguments at all. That may be fine since the current API is just C#.
We need to think more about these scenarios if / when we support localization tag helpers that accept arguments. My suggestion is to use an IDictionary<string, string> property to bind all arguments and ensure none are passed as HtmlStrings.
For now, suggest Debug.Assert()ing that no argument is an HtmlString.

:watch:

Updated PR. cc @Eilon

:shipit:

:watch:

@dougbu updated code

Unfortunate the https://github.com/aspnet/Mvc/pull/2701#discussion_r34604265 discussion is hidden by default. Use $(".discussion-item-toggle-closed").click() in F12 console to expose that.

:watch:

Travis build failing due to HtmlLocalizer_HtmlWithArguments_ReturnsLocalizedHtml(format: "{0:'{{characters that should be escaped}}b'###'b'}", ...) test failure on Mono. Don't execute that case on that platform.

:watch:

I am going to disable this test and a file a bug for this case since it does not work on Mono and encoding is not happening correctly anyways.

cc @dougbu

:watch:

cc dougbu

:shipit: with Mono fix, after squashing and moving to the release branch.

Thanks @dougbu  for the review. Merged d8a523a07f76f722b00a2a95f74668b9fc93e6a4


Why don't you make a language pack

Why not do a language pack, I think language pack can translation is not much.

I pushed a branch "feature/language-pack"
In this branch has the languages (https://github.com/renatomarinho/laravel-gitscrum/tree/feature/language-pack/resources/lang)
Example is : https://github.com/renatomarinho/laravel-gitscrum/blob/feature/language-pack/resources/lang/en/gitscrum.php

First version to EN language pack : https://github.com/renatomarinho/laravel-gitscrum/commit/d1985ec55cf68839a3932f87eee463a6d0bebc6b

Thanks, I'd like to convert the language pack to translate into Chinese

@DukeAnn thanks so much!


Implements to 4/19

Memo - Methods
Scheduler
EventLoop
NewThread
VirtualTimeScheduler
HistoricalScheduler
Disposable
RefCountDisposable
ScheduledDisposable
Subject
BehaviorSubject
ReplaySubject
LINQ-Generation
Empty
Never
If
Generate
FromAsync
FromAsyncPattern
FromEvent
FromEventPattern
For
Case
Interval
Range
Repeat
Return
Start
Throw
Timer
Using
While
LINQ
Aggregate
All
Amb
And/Then/When
Any
AsObservable
Average
Buffer
Cast
Catch
Chunkify
Collect
CombineLatest
Concat
Contains
Count
Create
DefaultIfEmpty
Defer
Delay
DelaySubscription
Dematerialize
Distinct
DistinctUntilChanged
Do
DoWhile
ElementAt
ElementAtOrDefault
First
FirstOrDefault
ForEach
GroupBy
GetEnumerator
GroupByUntil
GroupJoin
IgnoreElements
IsEmpty
Join
Last
LastOrDefault
Latest
LongCount
Materialize
Max
MaxBy
Merge
Min
MinBy
MostRecent
Multicast
Next
ObserveOn
OfType
OnErrorResumeNext
Publish
PublishLast
RefCount
Replay
Retry
Sample
Scan
Select
SelectMany
SequenceEqual
Single
SingleOrDefault
Skip
SkipLast
SkipUntil
SkipWhile
StartWith
Subscribe
SubscribeOn
Sum
Switch
Synchronize
Take
TakeLast
TakeLastBuffer
TakeUntil
TakeWhile
Throttle
TimeInterval
Timeout
Timestamp
ToArray
ToAsync
ToDictionary
ToEvent
ToEventPattern
ToList
ToLookup
ToObservable
Wait
Where
Window
Zip
LINQ.ErrorHandling
Finally

I find that IObservable.GetEnumerator is not supported.

FromAsync does not seem to be supported either

Is Unirx support ElementAt and Count in the future?


Instructions pointing to non-existing version v9.0.0

The recently updated combine instructions recommend v9.0.0 which does not seem to exist yet:
https://github.com/cms-analysis/HiggsAnalysis-CombinedLimit/tags
The 'git checkout v9.0.0' command also naturally fails.
In addition, the default lxplus compiler is not the standard architecture for 11_3_4, so would be good to update the instructions on that part as well.
[juska@lxplus792 combine]$ cmsrel CMSSW_11_3_4
WARNING: Release CMSSW_11_3_4 is not available for architecture slc7_amd64_gcc10.
Developer's area is created for available architecture slc7_amd64_gcc900.

Hi Juska, the new release is nearly ready, but indeed the instructions were updated slightly prematurely. We've removed the parts pointing to v9.0.0 for now.


[Project Moon TRPG] New features update

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

New Sheet Details

The name of this game is: <   >  (i.e. Dungeons & Dragons 5th Edition, The Dresden Files RPG)

The publisher of this game is: <   > (i.e. Wizards of the Coast, Evil Hat)

The name of this game system/family is: <   > (i.e. Dungeons & Dragons, FATE)

[ ] I have followed the Character Sheets Standards when building this sheet.

[ ] This sheet has been made on behalf of, or by, the game's publisher.
[ ] This game is not a traditionally published game, but a copy of the game rules can be purchased/downloaded/found at: <   >
[ ] This sheet is for an unofficial fan game, modification to an existing game, or a homebrew system.

Changes / Description
New update:
-Default Sheet Settings related support (Edit Mode)
-Customizable game settings/calculations
-Custom Ailments feature
-Tool selection bar, tool and weapon uses in rolls
-General UI adjustments and fixes

Character Sheet Info Roll20 Internal Use only.


fix(modal): slot alignment

Describe pull-request
Slot name convention
Solving issue
Fixes: DTS-1954
How to test

Go to the preview link or branch out
Check if the names of the props are header, body, actions
Check if the props are working
Check if the header prop and/or slot are working
Check if "X" icons stays in place if no header text is provided

Suggested test steps

[ ] Browser testing (Chrome, Safari, Firefox)
[ ] Keyboard operability
[ ] Interactive elements have labels.
[ ] Storybook controls
[ ] Design/controls/props is aligned with other components
[ ] Dark/light mode and variants
[ ] Input fields – values should be displayed properly
[ ] Events

Shorter CSS classes updated
Docs updated


Add helper function to get header fields

Changes
Add helper function to get header fields. Used during Python SDK generation
Tests

[X] make test passing
[X] make fmt applied
N/A relevant integration tests applied

Codecov Report
Attention: 15 lines in your changes are missing coverage. Please review.

Comparison is base (99aeb90) 18.69% compared to head (10685be) 18.67%.

Files
Patch %
Lines

openapi/code/method.go
0.00%
9 Missing :warning:

httpclient/response.go
0.00%
6 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #822      +/-   ##
==========================================
- Coverage   18.69%   18.67%   -0.02%
==========================================
  Files         117      117
  Lines       21653    21668      +15
==========================================
  Hits         4047     4047
- Misses      17355    17370      +15
  Partials      251      251

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


Client: Create NavigationContext

This feature will enable one to setup even complex navigation within application - for example everlasting back buttons!

Done in quite different way.


Update PHPUnit Version Reqs, Links to Forums, other info

Some data on the website, in the README, and on the Wiki is outdated. Update it to latest correct information.

I've made sure all information in the 1.6.0 release branch and develop branch are accurate. If you find any incorrect links or references, let me know.


Cancel Ensemble

Additional: Sends notification to those registered

"Promote" isCompleted to an Enum:

Not complete
Completed
Canceled

? Rescheduled? Is this a state of an Ensemble?

Note that these are STORED states of an Ensemble, vs. states that depend on "what date/time is it now?" (the latter effect PAST, FUTURE, IN PROGRESS, etc.).

Done. See #61 for the deletion of the Zoom meeting.


debug: lshw: Fix lshw patches and std::length error

This PR improves and fixes some issues with lshw patches:

Remove file names hard coded in Dockerfile
Fix patch<PHONE_NUMBER>9455527de9ce7cbb9530e2b31d043b.patch that was not
being applied successfully
Rename patches to put them in order to be applied
Add a patch to fix std::length_error that was notice on ARM platforms.
When calling lshw the following error is happening:

    ~# lshw
    terminate called after throwing an instance of 'std::length_error'
      what():  basic_string::_M_create
    Aborted

Changes were tested successfully both on ARM64 and x86_64 platforms.
Signed-off-by: Renê de Souza Pinto<EMAIL_ADDRESS>

Updates in this PR: address review comments.

Updates in this PR:

Remove former 5th patch (to fix std::lenght error) and provide a proper fix for this issue
Add more patches from Debian sid that:

Fix spelling errors
Fix Makefile variable for cross-compilation (it's gonna be needed if/when we enable cross-compilation for debug package)
Disable fetching newer lshw versions from web (for privacy and it's not useful to us)


Revert/7.2 get service cors [S3C-1009]

Depends on https://github.com/scality/Arsenal/pull/384

@ironman-machine
SCALITY_ARSENAL_BRANCH=revert/7.2-getService-cors
try

Hello @electrachong
"SCALITY_ARSENAL_BRANCH=revert/7.2-getService-cors": Success
"try": Success: Try build successfully launched on 'http://ci.ironmann.io/gh/scality/Integration/17572' with the following env. args:
{
    "SCALITY_INTEGRATION_BRANCH": "ultron/rel/7.2",
    "SCALITY_ARSENAL_BRANCH": "revert/7.2-getService-cors",
    "DEFAULT_BRANCH": "rel/7.2",
    "REPO_NAME": "S3",
    "SCALITY_S3_BRANCH": "revert/7.2-getService-cors"
}

:sunny: :+1: circleCI test succeeded!

PR has been updated. Reviewers, please be cautious.

CONFLICT (add/add): Merge conflict in tests/unit/api/serviceGet.js
CONFLICT (add/add): Merge conflict in tests/functional/aws-node-sdk/test/object/corsPreflight.js
CONFLICT (add/add): Merge conflict in tests/functional/aws-node-sdk/test/object/corsHeaders.js
CONFLICT (add/add): Merge conflict in lib/api/serviceGet.js
CONFLICT (add/add): Merge conflict in lib/api/corsPreflight.js

@ironman-machine
after=https://github.com/scality/Arsenal/pull/384
r=3e1b5ca87d37eb15f55ecc4b8eaf867dcc887f4c

There is already a pending pull request on the same branch

Hello @rahulreddy
"after=https://github.com/scality/Arsenal/pull/384": Success
"r=3e1b5ca87d37eb15f55ecc4b8eaf867dcc887f4c": Success

@ironman-machine r-

Hello @rahulreddy
"r-": Success

@ironman-machine
clean
after=scality/Arsenal#384
r=3e1b5ca87d37eb15f55ecc4b8eaf867dcc887f4c

Hello @rahulreddy
"clean": Success
"after=scality/Arsenal#384": Success
"r=3e1b5ca87d37eb15f55ecc4b8eaf867dcc887f4c": Success

There is already a pending pull request on the same branch

One dependency hasn't been merged yet

rebased; end to end running here: http://ci.ironmann.io/gh/scality/Integration/17726

This pull request isn't mergeable.

@ironman-machine
clean
after=scality/Arsenal#384
r=fe365da09fb45280755b796b5f611da1bc1b3721

Hello @electrachong
"clean": Success
"after=scality/Arsenal#384": Success
"r=fe365da09fb45280755b796b5f611da1bc1b3721": Success

One dependency hasn't been merged yet

@ironman-machine
clean
after=scality/Arsenal#384
r=fe365da09fb45280755b796b5f611da1bc1b3721

:hourglass: PR is now pending. CI build url: http://ci.ironmann.io/gh/scality/Integration/17740

Hello @electrachong
"clean": Failure: PR is already approved. If you really want to run clean, use r- before doing so. :dizzy:
"after=scality/Arsenal#384": Success
"r=fe365da09fb45280755b796b5f611da1bc1b3721": Failure: The PR is already approved with this SHA.

@ironman-machine
r-
clean
after=scality/Arsenal#384
r=fe365da09fb45280755b796b5f611da1bc1b3721

Hello @electrachong
"r-": Success
"clean": Success
"after=scality/Arsenal#384": Success
"r=fe365da09fb45280755b796b5f611da1bc1b3721": Success

:hourglass: PR is now pending. CI build url: http://ci.ironmann.io/gh/scality/Integration/17741

:broken_heart: :umbrella: circleCI test failed.

http://ci.ironmann.io/gh/scality/Integration/17740 and http://ci.ironmann.io/gh/scality/Integration/17726 passed; merging manually

@ironman-machine
r-
clean
after=scality/Arsenal#384

Hello @electrachong
"r-": Success
"clean": Success
"after=scality/Arsenal#384": Success

@ironman-machine r+

:hourglass: PR is now pending. CI build url: http://ci.ironmann.io/gh/scality/Integration/17752

Hello @electrachong
"r+": Success

:sunny: :+1: circleCI test succeeded!


add vivo in adopter list

Vivo uses the JuiceFS in AI and other workloads for storage, management intensive data. Add vivo in the adopter list.

Codecov Report

Merging #1873 (a742367) into main (85af540) will increase coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1873      +/-   ##
==========================================
+ Coverage   61.28%   61.38%   +0.09%
==========================================
  Files         135      135
  Lines       23410    23410
==========================================
+ Hits        14347    14370      +23
+ Misses       7389     7371      -18
+ Partials     1674     1669       -5

Impacted Files
Coverage Δ

pkg/chunk/cached_store.go
76.05% <0.00%> (-0.19%)
:arrow_down:

pkg/vfs/writer.go
79.66% <0.00%> (+1.01%)
:arrow_up:

pkg/meta/sql_lock.go
75.00% <0.00%> (+2.56%)
:arrow_up:

pkg/vfs/reader.go
80.29% <0.00%> (+3.10%)
:arrow_up:

Continue to review full report at Codecov.

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


a problem @at-root

there has a problem with precss,when i use '@at-root' like you has said it doesn't work
this is the postcss file:
.test{
  color:red;
  @at-root{
    .test2{
      color:blue;
    }
  }
}

and then the output file:
.test{
  color:red;
  @at-root{
    .test2{
      color:blue;
    }
  }
}

i tried  to ask the author of '@at-root' and he said that this is wrong in precss and it run normal in postcss

+1
What progress has the task?

i‘m sorry to say that it no reply at all and finally i change it to sass

@jonathantneal Any updates?


LIP: 0 - SafeSnap

Somebody made the first proposal to enable SafeSnap feature by Gnosis, which makes sure that snapshot votes have technical force on what the multisig can do. I fully support it and voted YES. LINK HERE TO VOTE

Voted in. Close?

Somebody needs to implement it now?

I've create the proposal, and if there's not better candidate can implement it as well. but I need to coordinate it with someone from admins. Will ping admins


Reuse same widget causes child form field to be overwritten

Is there an existing issue for this?

[X] I have searched the existing issues

Package/Plugin version
9.1.1
Platforms

[X] Android
[X] iOS
[ ] Linux
[X] MacOS
[ ] Web
[ ] Windows

Flutter doctor

Flutter doctor

Minimal code example

Code sample (pseudocode)

class ChildWidget
{
   ChildWidget(this.name)

   build() => FormBuilderDropdown(name: '${this.name}_dropdown');
}

class MainWidget
{
  build() => FormBuilder(child: Column(children: [ChildWidget(name: "a"), ChildWidget(name: "b")]));
}

Current Behavior
When the FormBuilder.onChanged fires, the FormBuilderState.fields collection contains ONLY the field "b_dropdown" (the last childwidget to build).
A runtime warning is output "flutter: Warning! Replacing duplicate Field for a_dropdown -- this is OK to ignore as long as the field was intentionally replaced"
Expected Behavior
When the FormBuilder.onChanged fires, the FormBuilderState.fields collection should contain BOTH the fields "a_dropdown" and "b_dropdown".
Steps To Reproduce
On any environment, create a widget tree where a child widget (in my example I've called the class ChildWidget) is used multiple times in the same form.
The child widget should contain a FormBuilder form field, but it uses some unique name (i.e passed by argument) to name the field.
It appears that the FormBuilder subsystem is perhaps using the widget tree to identify form fields, because the last ChildWidget to render will have its formfields added to the FormBuilder.fields collection, overwriting the previous ones.
Aditional information
No response

Hi @Adam-Langley
Maybe this https://github.com/flutter-form-builder-ecosystem/flutter_form_builder/pull/1451 had something related with this?
Can test with main branch


FY2019Q4 Quarterly refresh

validated tutorial steps (made lots of changes)
updated tutorial file names to be ordered
updated tutorial steps to match same bullet-list format as other training modules
updated screenshots
updated code downloads
fixed / updated code issues in tutorial

I haven't looked at the code stuff yet, but in the Markdown I've got some big objections to the changes :).

Renaming the files breaks our docs publication, requiring me to go do some manual updates. Can we not do that?
Converting the topics to numbered lists is not consistent with how we publish stuff on Docs. The Docs folks actually tell us explicitly NOT to do that. We need to revert that change.

On the code front I'm guessing the changes are massive because of recreating the project with latest Android Studio?

@jasonjoh said:

On the code front I'm guessing the changes are massive because of recreating the project with latest Android Studio?

There were a lot of code changes as the tutorial as is didn't work for me. I don't think there was much different with the Andriod Studio update, rather the majority of the changes were just differences in copy/paste.
@jasonjoh said:

Renaming the files breaks our docs publication, requiring me to go do some manual updates. Can we not do that?

OK... I'll undo that and put it the way it was
@jasonjoh said:

Converting the topics to numbered lists is not consistent with how we publish stuff on Docs. The Docs folks actually tell us explicitly NOT to do that. We need to revert that change.

I'll need to check on this as this doesn't match the way the other modules work that are done for OfficeDev. The format they were in is generally considered non-condusive to learning (prose-style steps rather than real steps). I'll follow up...

@jasonjoh Apparently the default .gitingore in the root of the repo is incorrect in that it included MORE files that were necessary for an Andriod Studio project... basically everything in .gradle & .idea. It assumed they'd be in the root... but they aren't in a content repo like this. I'm not sure when that changed but it hadn't done that in previous quarterly refreshes.
I'll submit a commit that cleans that up and removes a lot of files...

@jasonjoh the number of files changed appears to be the effect of the refresh using the latest version of Android Studio. Appears the .gitignore files are different than what was put there originally. Suspect some hand-edits were done to the project files when this module was ported over from its previous configuration. The other stuff appears to be whitespace changes... again... I don't do any config changes to Andriod Studio, just take the default setup.

Per our email discussion I'm going to merge this into a testing branch for now so we can evaluate the formatting changes and see if we want to adopt them across all of our tutorials.


Feature request - Multiple monitor support.

Hey there! I currently own 3x24 inch monitors at 1920x1080 resolution and I would like to know if theres any way to get it to support a triple monitor setup or higher count multi monitor setup.
I have made this work by using the surround feature in the NVIDIA Control Panel, it basically takes 3x 1920x1080 Monitors and makes it look like its a single big 5760x1080 monitor and then Adrilight shows it as a single monitor and all program features work fine, the thing is the Surround mode sucks at everything except gaming so if i wanted to watch movies and stuff i would have a lot of funky problems.
I saw someone make this work whit two monitors and two arduinos, heres the link https://www.youtube.com/watch?v=EQBOjNDq3S8 .
I took a look at the code, i'm quite new at programming and have very limited knowledge in C#, i'm gonna try doing some work and see if i can get results about this but for those whit more experience my suggestion is made :D .
Heres how the adrilight preview looks like in the 5760x1080 resolution.

i think it is absolutely possible to introduce multimonitor support in adrilight, but i also think it is way to much work. think about all the ways the monitors could be setup, all the ways you could put leds around them and all the testing needed. I also cared about smooth migrations for all users.
you are asking for a feature which could easily need 100+ hours of solid work. not gonna happen, sorry. 😒


Bug: getting 500 from calling /api/auth/setup

Prerequisites

[X] I have searched the repository’s issues and Kinde community to ensure my issue isn’t a duplicate
[X] I have checked the latest version of the library to replicate my issue
[X] I have read the contributing guidelines
[X] I agree to the terms within the code of conduct

Describe the issue
I'm using Nextjs v14.2.11. When I haven't logged in, I get this error every time from methods called in getKindeServerSession, like getUser, isAuthenticated. What's worse, the error seems to make the web page break down on the mobile(iPhone13pro).
from the server side:

from the client side:

on mobile:

Library URL
https://github.com/kinde-oss/kinde-auth-nextjs
Library version
2.3.8
Operating system(s)
macOS
Operating system version(s)
ventura 13.6.9
Further environment details
No response
Reproducible test case URL
No response
Additional information
No response

Hi @QingjiaTsang,
Thank you for raising, is this reproducible on our starter kit?

Hi @QingjiaTsang,
Thank you for raising, is this reproducible on our starter kit?

I'm using the following starter kit with kinde v2.3.8 and update the nextjs version to 14.2.11. It won't cause any error though.
https://github.com/kinde-starter-kits/kinde-nextjs-app-router-starter-kit
but for now I don't know why it's throwing the error in my project

@DanielRivers
I can share the codebase to you and please check it out.
https://github.com/QingjiaTsang/real-estate-app-nextjs14

It turns out to be the nextjs error causing the browser to break on IOS.  see https://stackoverflow.com/questions/78981693/newly-created-next-js-app-giving-error-url-canparse-is-not-a-function
The setup api error still remains, but it won't affect pretty much, so I close the issue.


Error triggered on amplify push/pull after deleting then adding new fields to a custom Graphql type

How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
v20
Amplify CLI Version
12.10.1
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No
Describe the bug
I ran a successful amplify push request for our graphql API. In this request, the only thing we changed was removing two String array fields from a custom type and adding some new fields to the same custom type. This type is not a model - it's being referenced in a model. After the successful push, whenever we try to perform another push command we get the following error:
PushResourcesFault: Cannot read properties of undefined (reading 'map')
at AmplifyToolkit.pushResources (/snapshot/amplify-cli/build/node_modules/@aws-amplify/cli-internal/lib/extensions/amplify-helpers/push-resources.js:116:23)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Object.executeAmplifyCommand (/snapshot/amplify-cli/build/node_modules/@aws-amplify/amplify-category-function/lib/index.js:277:5)
at async executePluginModuleCommand (/snapshot/amplify-cli/build/node_modules/@aws-amplify/cli-internal/lib/execution-manager.js:139:5)
at async executeCommand (/snapshot/amplify-cli/build/node_modules/@aws-amplify/cli-internal/lib/execution-manager.js:37:9)
at async Object.run (/snapshot/amplify-cli/build/node_modules/@aws-amplify/cli-internal/lib/index.js:121:5)
I'm assuming that the system still thinks the original two string array fields still exist but it can't find them so it throws this map error. I've tried running an amplify pull but I get a very similar error. So, at this point I'm stuck and can't update or pull my API at all.
Expected behavior
Amplify push command should run successfully without the aforementioned error.
Reproduction steps

Create a model and a custom type. Reference the custom type in your model.
Make sure the custom type has a string array field then push your changes
After pushing your changes, remove the string array field from your custom type and add some other fields
Push your changes again
Afterwards, future push attempts will fail due to the bug I mentioned above.

Project Identifier
No response
Log output

# Put your logs below this line

Additional information
No response
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

Apparently I was missing:
"providers": [
"awscloudformation"
],
in my project-config.json file. I've never had this in there before (this is an old project) so I'm not sure why it triggered the error now.


Infinite Scrolling

Wow, this is great! I was curious if you were going to be implementing infinite scrolling? Where if you reach either the left or right side, you will then be taken back to the other.  Great job!

@croossin Thanks a lot for comment. Actually i've implemented this control to be a replica of the same gesture/UX in Paper Facebook app and i'm not sure about the user experience of infinite scrolling. I think this is a good idea may be i can add an option for infinite scrolling besides the normal scrolling. Let me think about it more.


Syncing modules with mainstream ps2sdk

Pull Request checklist
Note: these are not necessarily requirements

[x] I reformatted the code with clang-format
[x] I checked to make sure my submission worked
[x] I am the author of submission or have permission from the original author.

Pull Request description

In fact I created this commits not only for syncing but because im trying to port open-ps2-loader into newest ps2toolchain and this steps also can improve mainstream builds.

You tested and compiled OPL after this changes?
After this commits is needed update the ps2toolchain or the ps2sdk for compile the OPL?
Best regards.

@doctorxyz all the new changes made from @AKuHAK work good.
You may need to update PS2SDK and PS2TOOLCHAIN if you haven't done so in the past couple of days. :)

Oops!  Spoke to soon.  Seems something got broken with SMB.  When launching a game, I got a black screen.  I've been playing this game for ages, never had an issue until today. :(
Will reboot to see if I can spot the error??

@AKuHAK I was able to conduct a few more tests for you.
I wanted to find out if the new PS2SDK changes are causing this issue or just your file changes in your pull request.
So, if I compile the ps2homebrew repo version found here: https://github.com/ps2homebrew/Open-PS2-Loader/commits/master -- with the new changes of PS2SDK -- it will give me the error I reported above.
Plus according to a few testers at: http://www.ps2-home.com/forum/viewtopic.php?f=13&t=2265 -- this seems to be affecting only SMB and HDD users.  USB users are not having this issue.
If I compile the ifcaro repo with the new PS2SDK changes (without the file changes in your pull request), there is no issue.
So we can now narrow it down that the files changes made in this pull request is affecting both SMB and HDD users.
I hope this helps.

I will make more tests before pushing commit.


Search package from 3rd package manager, e.g. vcpkg, conan ...

related issue https://github.com/xmake-io/xrepo/issues/9

vcpkg
$ xrepo search vcpkg::pcre
The package names:
    vcpkg::pcre:
      -> vcpkg::pcre-8.44#8: Perl Compatible Regular Expressions
      -> vcpkg::pcre2-10.35#2: PCRE2 is a re-working of the original Perl Compatible Regular Expressions library


Flickr images do not show in Full screen mode

Steps to Reproduce:

Contribute a Flickr image
Select Full screen from the Resource Summary page

Expected result:
The image should show
Actual result:
Empty full screen mode

From the javascript console:Refused to display 'https://www.flickr.com/photos/58130019@N08/15131237412' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
Sounds like flickr stuff doesn't like allow being displayed in an iframe anymore


Why panic instead of returning error?

I see that there are a LOT of panics in this crate. Why is it so designed? Why not just return some InvalidData std::io::Error or crate defined error?

Okay I see that only incorrect API usage can cause panic.

JsonReader and JsonWriter API (and their implementation) is pretty flexible, at the cost of incorrect usage not being detectable at compile time. Therefore, if they are used incorrectly they panic at runtime. But as you mention, a panic can only happen due to incorrect usage. For correct usage this cannot happen regardless of what JSON data you process (if a panic does happen, I would consider that bug).
There is also the Simple API which implicitly enforces correct usage, and except for a few explicitly documented cases does not panic. However, its API is less flexible.


[redis_proxy] Add support for SELECT and KEYS

This RP mainly improves the compatibility of redis proxy, improvement as follows:

Add support for the select command, referring to the implementation of Apache KVRocks and Microsoft Garnet, simply returns OK.
Add keys command support, send keys commands to each shard on the backend, and then merge the results.
For unsupport commands, the return value is the same as Redis, because some clients judge this return value, for example, Java lettuce client

I rebased the last commit, mainly to solve the compatibility issues of the Java client.
https://github.com/envoyproxy/envoy/pull/37706/commits/234aa2390af88e8684956229d285c8f415e93269#diff-c0fa1fc35dc58d68142878191b27317c2de9789d87c14034fdb7ecfa7136226b

There is still one that hasn't turned green, I will add some test cases later.

Okay, all the checks have been passed.
@mattklein123


Implement a leveling feature

Is your feature request related to a problem? Please describe.
All economy bots have their own leveling system. Hence this bot needs one of it's own. The leveling system is needed because it's another feature that adds to the sense of purpose in player's participation. There are currently no ideal ways of scraping this data from elsewhere, so this needs to be done on our own, built in to the bot itself. This is important, and it does not necessarily require much time to make.
Describe the solution you'd like
Removal of the Tatsu API from integrating with the bot. I touched on this here: https://github.com/SGA-A/c2c/pull/41. The reason being is that it is completely redundant to the bot economy. It is simply there to track your Tatsu attributes, and nothing more. Sadly, their API is also very lacklustered and does not dispatch events like if a user has ranked up within the server which would be of use in this case.
Here are some things we have planned for this leveling system:

Add rewards associated with leveling up.
Create a leaderboard filter to sort users based on their level.
Set the limit of the level to 100,000

Levels should also reset when a user decides to prestige.

Be able to contribute to your overall personal multiplier.

This list is not exhaustive, more ideas will be added with time.
Describe alternatives you've considered
I have found that some people, especially on PyPI, offer libraries for leveling systems and cards for users to view their experience, levels and profile picture neatly sorted into a single card image. I am in the process of considering this, but again it seems more intuitive to make it on our own since there is more 'control' of what we'd like to take place.
Additional context
Leveling is a concept where you can execute commands within the bot and earn a random amount of experience for each app command completion. This can also be based on how many messages you send in any given mutual guild the user is in with the bot. This can be used to create incentives for messaging or even to promote usage of the bot.

Just wanted to add that there will no longer be a maximum level the player can reach.
The level could theoratically be able to reach infinity, but still we do not feel there is a need to set a limit.
The changes have been reflected in this commit: https://github.com/SGA-A/c2c/commit/8675194fdee669a18ddbde28d1e35bd76320e3c5.


PyTorch distributor

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1378  👈
#1305
#1304
#1280
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @dongreenberg and the rest of your teammates on  Graphite

Merge activity

Nov 12, 11:52 PM EST: A user started a stack merge that includes this pull request via Graphite.


The deposit ID#0 is due but the progress bar is still moving forward.

At the same time, deposit ID#0 is due but the UI shows "Withdraw earlier", need to check and change it to "Withdraw". @isunaslabs

Seen. Please give me the account address that you've used to generate this bug

0xAe0222eA1c24c3579b4CC751a2BE757aBeDFD78E


Update React-UI and Icons

Our icons are way out of date. This appears to be part of the React-UI package which is also way out of date.
Update to the latest versions of each.

This is going to require an update from MUI 4 to MUI 5


epub 'display format' problems

The 'two-page' display format for an ebook doesn't work after choosing the corresponding icon in Settings. Instead, Readium continues to display single-page format.
Also, the Page Width feature doesn't seem to be working. The display is stuck on full width.
I use:

Readium Chrome extension on WIN 7

latest official version available from the Chrome Web Store

what EPUB are you having this problem with?
reflow or fixed layout?

@danielweck can you close this due to inactivity? Would be good to get some control of the issue queue in this library. I don't mind helping to moderate.


warning and hello

Hi dude, hope you don't mind my humble changes...

I was thinking on adding a div with a small animation, w d y think? Maybe you expect smth different...


Ext traits should not be used in where bounds

The codebase has various where clauses like the following:
https://github.com/denoland/fastwebsockets/blob/5402e4eacdaebd82856e4721151e522bff00e04f/src/fragment.rs#L102-L105
It is recommended that you instead use S: AsyncRead + AsyncWrite + Unpin. Functionally they are equivalent, but avoiding the Ext traits makes more sense semantically and produces better error messages for users of your library.

Thanks. Fixed in https://github.com/denoland/fastwebsockets/commit/d2e383348121f98533397c1a096a388f56613e39


feat: spawn new thread for each add_transaction request

This change is

Codecov Report
Attention: Patch coverage is 54.54545% with 5 lines in your changes are missing coverage. Please review.

Project coverage is 61.79%. Comparing base (1d45e65) to head (ef93f8b).
Report is 1 commits behind head on main.

Files
Patch %
Lines

crates/gateway/src/errors.rs
0.00%
4 Missing :warning:

crates/gateway/src/gateway.rs
85.71%
0 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #62      +/-   ##
==========================================
- Coverage   62.32%   61.79%   -0.54%
==========================================
  Files          11       11
  Lines         292      301       +9
  Branches      292      301       +9
==========================================
+ Hits          182      186       +4
- Misses        105      109       +4
- Partials        5        6       +1

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


Fixes #527 history button not working

Description
This PR fixes the history button that gets shown when viewing a historical version of a model so that it correctly links back to the history listing for that object.
Related Issue
#527
Motivation and Context
Fixes a broken link that users expect to work.
How Has This Been Tested?
I tested this by installing it as a development dependency in our django project. I also ran make tests however only the sqlite versions worked since I haven't setup postgres/msql locally.
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have run the pre-commit run command to format and lint.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] I have added my name and/or github handle to AUTHORS.rst
[x] I have added my change to CHANGES.rst
[x] All new and existing tests passed.

I found another way to do this.
We could define a template at templates/admin/change_form_object_tools.html and if the simple_history app is installed before the admin, it allows us to override the template without having to override that block.
However, I think the additional installation requirements are a bit too burdensome.


Is there a "Circuit Breaker" for Spring Boot Kafka client?

In case that Kafka server is (temporarily) down, my Spring Boot application ReactiveKafkaConsumerTemplate keeps trying to connect unsuccessfully, thus causing unnecessary traffic and messing the log files:
2021-11-10 14:45:30.265  WARN 24984 --- [onsumer-group-1] org.apache.kafka.clients.NetworkClient   : [Consumer clientId=consumer-group-1, groupId=consumer-group] Connection to node -1 (localhost/<IP_ADDRESS>:29092) could not be established. Broker may not be available.
2021-11-10 14:45:32.792  WARN 24984 --- [onsumer-group-1] org.apache.kafka.clients.NetworkClient   : [Consumer clientId=consumer-group-1, groupId=consumer-group] Bootstrap broker localhost:29092 (id: -1 rack: null) disconnected
2021-11-10 14:45:34.845  WARN 24984 --- [onsumer-group-1] org.apache.kafka.clients.NetworkClient   : [Consumer clientId=consumer-group-1, groupId=consumer-group] Connection to node -1 (localhost/<IP_ADDRESS>:29092) could not be established. Broker may not be available.
2021-11-10 14:45:34.845  WARN 24984 --- [onsumer-group-1] org.apache.kafka.clients.NetworkClient   : [Consumer clientId=consumer-group-1, groupId=consumer-group] Bootstrap broker localhost:29092 (id: -1 rack: null) disconnected

Is it possible to use something like a circuit breaker (an inspiration here or here), so the Spring Boot Kafka client in case of a failure (or even better a few consecutive failures) slows down the pace of its connection attempts, and returns to the normal pace only after the server is up again?
Is there already a ready-made config parameter, or any other solution?
See also https://stackoverflow.com/q/69914621/2886891

Please don't use GitHub issues to ask questions; use the discussions tab (or Stack Overflow).
Never ask the same question in multiple places; it wastes your time and ours.

Thanks @garyrussell. However I am aware of  the parameter reconnect.backoff.ms, this is how I create the ReactiveKafkaConsumerTemplate bean:
@Bean
public ReactiveKafkaConsumerTemplate<String, MyEvent> kafkaConsumer(KafkaProperties properties) {
    final Map<String, Object> map = new HashMap<>(properties.buildConsumerProperties());
    map.put(ConsumerConfig.GROUP_ID_CONFIG, "MyGroup");
    map.put(ConsumerConfig.RECONNECT_BACKOFF_MS_CONFIG, 10_000L);
    final JsonDeserializer<DisplayCurrencyEvent> jsonDeserializer = new JsonDeserializer<>();
    jsonDeserializer.addTrustedPackages("com.example.myapplication");

    return new ReactiveKafkaConsumerTemplate<>(
            ReceiverOptions
                    .<String, MyEvent>create(map)
                    .withKeyDeserializer(new ErrorHandlingDeserializer<>(new StringDeserializer()))
                    .withValueDeserializer(new ErrorHandlingDeserializer<>(jsonDeserializer))
                    .subscription(List.of("MyTopic")));
}

And still the consumer is trying to connect every 3 seconds.
So I think it is rather a bug or a change request, unless I am doing something wrong.

Please stop the discussion here - as I said; questions are for Stack Overflow - it is not even this project; it's reactor-kafka.
In any case; these properties are in the kafka-clients and have nothing to do with Spring.


Social Network/Reddit/Reddit Investigator. Error 404

http://www.redditinvestigator.com/

Removed, thank you.


Update composer.json

Expand support for monolog and yaml dependencies.
Fix outdated setup php to new<EMAIL_ADDRESS>

Try to re-run CI / build, but it will work (I updated php-action version after I did initial PR).


Fedora uses a new name for wireless lan interfaces. Added a new condi…

…tion to find these interfaces too.

thx @rimolive
going accept PR

Many thanks for the patch!


Refactor playground

Overview
As more features are added I think a vanilla.js-based implementation would become more cumbersome and difficult to maintain. So we plan to refactor the playground based on Vue framework
Tasks

[ ] Refactor playground based on Vue framework
[ ] Replace the current CodeMirror editor with Monaco.
[ ] Support for transformer configuration editing. Learn more #2709

Possible Tasks

Linter rules configuration
..

Playground Design
Since we don't have a designer, we can't design a nice playground, but instead, maybe we can use shadcn-vue and utility-first CSS framework for UnoCSS or TailwindCSS to help us build it quickly. Or ask AI at https://www.vue0.dev/
Expected Outcome
By the end of this refactor, the OXC Playground should be more user-friendly and maintainable. The switch to Vue and Monaco should provide a better development experience.
Reference

https://github.com/sxzz/ast-explorer AST Explorer, Use Vue and Monaco
https://play.swc.rs/ SWC Playground
https://biomejs.dev/playground/ Biome Playground

I've been spending a lot of time writing language services for Monaco for custom DSLs my company uses, I could help integrate an Oxc language service into Monaco

Oh nice! I plan to create a new repo for the playground, stay tuned.


Fix warning maybe-uninitialized in install-dependencies

Description
Recent versions of gcc (11.x) changed some rule about uninitialized variables, causing a warning which is for some reason considered as an error when I try to run bootstrap.sh. See https://github.com/google/googletest/issues/3219 and https://github.com/google/googletest/pull/3024
This fixes it by applying a patch  which is already in the master branch of googletest, but not in the release version used by the script.
Testing instructions
On Ubuntu 21.10, follow the build instructions, then try to run bootstrap.sh.
Without the patch, it causes the following error:
$ ./bootstrap.sh
#### Initializing... ####
PREFIX: /home/pierre/dev/wallet-core/build/local
patching cmake minimum version
patching file CMakeLists.txt
patching file googletest/CMakeLists.txt
patching file googlemock/CMakeLists.txt
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonInterp: /usr/bin/python (found version "3.9.7")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pierre/dev/wallet-core/build/local/src/gtest/googletest-release-1.10.0
Scanning dependencies of target gtest
[ 12%] Building CXX object googletest/CMakeFiles/gtest.dir/src/gtest-all.cc.o
In file included from /home/pierre/dev/wallet-core/build/local/src/gtest/googletest-release-1.10.0/googletest/src/gtest-all.cc:42:
/home/pierre/dev/wallet-core/build/local/src/gtest/googletest-release-1.10.0/googletest/src/gtest-death-test.cc: In function ‘bool testing::internal::StackGrowsDown()’:
/home/pierre/dev/wallet-core/build/local/src/gtest/googletest-release-1.10.0/googletest/src/gtest-death-test.cc:1301:24: error: ‘dummy’ may be used uninitialized [-Werror=maybe-uninitialized]
 1301 |   StackLowerThanAddress(&dummy, &result);
      |   ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
/home/pierre/dev/wallet-core/build/local/src/gtest/googletest-release-1.10.0/googletest/src/gtest-death-test.cc:1290:13: note: by argument 1 of type ‘const void*’ to ‘void testing::internal::StackLowerThanAddress(const void*, bool*)’ declared here
 1290 | static void StackLowerThanAddress(const void* ptr, bool* result) {
      |             ^~~~~~~~~~~~~~~~~~~~~
/home/pierre/dev/wallet-core/build/local/src/gtest/googletest-release-1.10.0/googletest/src/gtest-death-test.cc:1299:7: note: ‘dummy’ declared here
 1299 |   int dummy;
      |       ^~~~~
cc1plus: all warnings being treated as errors
make[2]: *** [googletest/CMakeFiles/gtest.dir/build.make:82: googletest/CMakeFiles/gtest.dir/src/gtest-all.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:219: googletest/CMakeFiles/gtest.dir/all] Error 2
make: *** [Makefile:160: all] Error 2

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist
None of the checklist items are applicable.

@PiRK could you please check if gtest 1.11.0 has fixed this or not? also sed on macOS by default is bsd version, that's why iOS CI failed

@PiRK could you please check if gtest 1.11.0 has fixed this or not? also sed on macOS by default is bsd version, that's why iOS CI failed

I believe gtest 1.11 has fixed this. I can compile it without an error. I initially assumed that it wasn't fixed in 1.11 because when I searched for the error message I saw reports of the same error happening with that version, but those users must have been mistaken, or maybe they were building the master branch.
I will update the PR to simply use 1.11 instead of 1.10, rather than patching an old version, if that is OK with you.

Yes, let's try 1.11.0

Note that I removed the patches becauses all the relevant cmake_minimum_required versions have been updated to 2.8.12:
https://github.com/google/googletest/blob/release-1.11.0/CMakeLists.txt#L4
https://github.com/google/googletest/blob/release-1.11.0/googlemock/CMakeLists.txt#L45
https://github.com/google/googletest/blob/release-1.11.0/googletest/CMakeLists.txt#L56


New design for System Message

📒 Description
It's time to revamp the layout of System Message, by use what's done in New Login and Sign-up design PR #2774
💻 Environment
Platform: macOS
💯 Acceptance Criteria

Re-use the Alert Banner, which is done in #2774
Extend new feature for System Message
Implement new "Error sync" icon in Entry Cell

Sub-tasks:

[ ] Support sync triangles button at bottom of TimeEntryCell
[ ] Implement loader when syncing


docs: improve readme

Description
Add badges and sections summarizing the contributing guidelines, code of conduct, and license to the project's README.
Type of change

[x] This change requires a documentation update.

Checklist

[x] My code follows the style guidelines of this project.
[x] I have made corresponding changes to the documentation.

Screenshots

Notes to reviewers
Happy Hacktoberfest!

This is great! Thanks @paulaxisabel


Guide Rewrite

This is a rewrite of the guide with many changes. In addition to content changes, structural changes were made to the guide as a potential template for future guide updates to follow.
Addresses issues #33, #32, #31, #29, #28.
Several changes were made to promote correctness, make for a better user experience, and allow the option to dual publish to Spring Academy in the future.

The README.adoc has no text content, but instead links to 3 separate files. This allows spring.io/guides to publish the guide with the full context, including Spring Initializr, while allowing Spring Academy to only be concerned with the guide specific content, located in content.adoc. There should be no change for how users view the guide on spring.io.
The README.adoc added an additional conditional section that can be set if rendering for Spring Academy to exclude certain sections.
The initial and complete folders were removed in favor of keeping only the solution in the root project directory. This should simplify the user experience by providing fewer places to look for code and create an easier experience when importing the project to an IDE. The user can still follow along with a blank project by starting with Spring Initializr. This format of keeping the code in the root directory makes it possible to easily load the project to Spring Academy as well.
A single build tool is used. For this guide, Gradle is used because it is the preferred build tool of the project driving the functionality of the guide, Spring Framework. Having a single build tool should simplify the user experience when importing the project to a local IDE. This ease of import is also important for the user experience when loading into Spring Academy.
A lot of references to the common macros project were removed. This was done to prioritize correctness and user experience over ease of guide creation. A few problems exist when trying to use a common template. First, the wording may be slightly off, as demonstrated by issue #33. The 'web' text in the line This web application is 100% pure Java... comes from a common file. Second, some teachings were incorrect. For example, in the popular rest-service guide, we advise the user that @ComponentScan will check the com/example package, but that information is not correct. It will in fact check the com/example/restservice package in this particular guide. Third, the commands to package the application as a jar file were not correct. The problem is persistent to all guides as described here.
References to dated technologies, i.e. web.xml and WAR files, were also removed. This was done when removing links to the common GitHub macro repository in favor of static text.
The Build an executable JAR section was renamed to Building the Application and text was added for using Cloud Native Buildpacks and Native Image compilation.

I think that instead of 3 separate files, using ifndef from AsciiDoc Conditionals would be a better approach.
If we choose to publish this guide to Spring Academy, we could set the variable env-exclude-spring-initializr to exclude certain sections. This can easily be achieved using a downdoc command:
npx downdoc -a env-exclude-spring-initializr README.adoc

@Buzzardo what do you think about this use of a conditional?
@joemoore do you think an approach could work for Spring Academy?

Converted to draft until I come up with a better solution to importing some common components from the getting started macros GitHub repository. Thanks for the feedback @mbhave!

I added a new file to the getting-started-macros repository that is intended to be a common section at the end of every guide.

The 3 files in this PR can be checked into the common macro project at a later date.

guide_intro.adoc
spring_academy_intro.adoc
spring_academy_see_also.adoc

Before those files are checked into the macro project and used as a template for all guides to follow, I'd like to verify that the process to convert content to Spring Academy (reducer, downdoc) is successful. This requires a GitHub action to execute, which should be performed on a non-forked repo.