[FEATURE] requirements.txt

Nyx Text Feature Request
Description
Provide requirements.txt
Problem Statement
Easier to install, easier to pin versions if required
Proposed Solution
Provide requirements.txt
Use Cases
Installation
Implementation Ideas
See PR https://github.com/parazeeknova/nyxtext/pull/10
Alternatives Considered
[If you've considered alternative solutions to the problem, please describe them here and explain why you believe the proposed feature is the best approach.]
Additional Context
[Add any other context or information that might be relevant to this feature request.]
Your GitHub Username
[Please provide your GitHub username if you'd like to be credited for this feature request or if you'd like to be notified about updates.]
Labels
[Choose appropriate labels to categorize the feature request, such as "enhancement", "new feature", etc.]

Thanks, merged :)


SimpleListRepresentation - Rel issue

Hello everyone!
I try to implement a generic class to use the SimpleListRepresentation but I have a little issue with the Rel attribute.
My class looks like this:
public class HalRepresentationList : SimpleListRepresentation where TResource : IResource
{
public HalRepresentationList(IList tasks)
: base(tasks)
{
}
    protected override void CreateHypermedia()
    {
        this.Href = "testHref";
        this.Rel = "tasks";
        this.LinkName = "testLinkName";
    }
}

When I test its serialization, the _embedded resource does not use correctly (it does not show it) the Rel attribute like in the image below:

It should look like this:

I have to mention that this issue is on the current version on NuGet. I've got the code from github, and it shows "unknownRel-TaskHalRepresentation".
I looked in the code for this, and found out that in the _embedded resource, the Rel attribuite is taken from each resource in the list of resources as the next line speaks:
Embedded = resourceList.Count > 0 ? resourceList.ToLookup(r => r.Rel) : null;
I've changed this line with:
Embedded = resourceList.Count > 0 ? resourceList.ToLookup(r => this.Rel) : null;
and it works.
Is is correct, or I should set the Rel attribuite on each resource in the list of resources in order to get the Rel attribute of the entire list as it should be?
Thank you!
Mihai

closing stale issue


double quotes don

Describe the issue here.
Relevant URLs

Provide relevant URLs

What products and version are you using?
](https://docs.influxdata.com/influxdb/v1.8/write_protocols/line_protocol_reference/)

I try to use double quotes in select sql, the result is ok when i don't add escape,
but there is an error when I use single quotes in select sql,  after i escapes single quote, the result is ok.
is there an error in this docs?

Can you provide an example of what you are doing?

write one:
SELECT MAX("filesize") FROM "flogstat" WHERE "name"='/opt/probe/sysprobe_rh6_64_p<IP_ADDRESS>3/tm p'".log'
wrong one:
SELECT MAX("filesize") FROM "flogstat" WHERE "name"='/opt/probe/sysprobe_rh6_64_p<IP_ADDRESS>3/tm p'".log'
only one difference: backslash

soo

Can you provide an example of what you are doing? This documentation reference is for line protocol which is about formatting the data for writing into InfluxDB. But, your question(s) appear to be about querying with InfluxQL.

sorry, can you provide any url which about special characters of querying with InfluxQL, i can't find it. thank you.

Those two examples look identical to me. You start the value reference with a single quote and it ends with the next single quote. So everything after the p' should be truncated.
First off, if you really have stuffed /opt/probe/sysprobe_rh6_64_p<IP_ADDRESS>3/tm p'.log into the name field, I think you have a problem with the data ingest.   It might be worth addressing that.
But in the meantime, I think you are better off with a regex at this point.  So try, SELECT MAX("filesize") FROM "flogstat" WHERE "name"=~ /*opt/probe/sysprobe_rh6_64_p<IP_ADDRESS>3/tm*/

https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#strings

https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#strings
SELECT MAX("filesize") FROM "flogstat" WHERE "name"='/opt/probe/sysprobe_rh6_64_p<IP_ADDRESS>3/tm p\'".log'
should do it.

thank you


MEDIA_TYPE_MUSIC removed in HA Core 2025.10

I noticed the following error message in the logfiles:
"MEDIA_TYPE_MUSIC was used from hass_agent, this is a deprecated constant which will be removed in HA Core 2025.10. Use MediaType.MUSIC instead, please report it to the author of the 'hass_agent' custom integration"
I use HA 2024.11.1
This message comes up after restart HA

Same problem here ...
Any Plans to update???


cross is flickering

Because the cross is drawn in an in-memory canevas at native resolution, it gets resampled to the screen on the fly.
This sometimes causes the cross to be blurry, or even disappear!

this is very uncommon, and impossible to fix. Closing.


SEO Metadata Improvements

Fixes

Fixes #75 by @dhruvkb
Description

This PR adds per-page meta titles, descriptions, and Open Graph tags using Nuxt's built-in support. This work is not conclusive but is a good start.
Features

Single image result

Use image title, author, and license info in meta title + description
Use the actual image as the Open Graph preview images (until we do something like #32)

Search results pages

Show search query and media type (image|audio|video) in page title

Content Considerations
Here are some comparisons of various search terms related to Openverse:

free vs. cc: https://trends.google.com/trends/explore?geo=US&q=creative commons images,free photos,free images,cc photos,cc images
cc vs. creative commons: https://trends.google.com/trends/explore?geo=US&q=Creative Commons Photos,Creative Commons Images,CC Images,CC Photos,CC0 Images

Todos

[ ] Search result page descriptions "Find 1000s of openly-licensed, Creative Commons licensed {searchQuery} {media} on Openverse"
[x] Switch all meta strings to support i18n (move strings into the english translation file)
[ ] Add new default Open Graph Image (with Openverse logo, could have @panchovm design one, or do a plain black logo on white bg for now)
[ ] Titles and descriptions for all content pages (titles should match h1 tags, followed by "| Openverse" or something similar)
[ ] Testing? Anything needed here?

Technical details

Tests

Click around in the application and watch the tab title change on route changes. Also inspect the page and observe the various meta tags in the application.
Screenshots

Checklist

[x] My pull request has a descriptive title (not a vague title like Update index.md).
[x] My pull request targets the default branch of the repository (main or master).
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[x] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

Also, for the page components getting <script> blocks for the first time, I used the same component names as @obulat's PR #117 for ease of merging.

This is unfortunately so out of date that I'm going to close it—the strings here can be used as a reference in a future implementation of this functionality.

Gonna take this up and fix it for a new PR


Can't download single Imgur images, only abums?

 Error while ripping URL http://i.imgur.com/1q3DTZg.gif
java.lang.Exception: No compatible ripper found
	at com.rarchives.ripme.ripper.AbstractRipper.getRipper(AbstractRipper.java:288)
	at com.rarchives.ripme.App.rip(App.java:45)
	at com.rarchives.ripme.App.handleArguments(App.java:101)
	at com.rarchives.ripme.App.main(App.java:37)

Are non-album Imgur images really not supported?

http://www.pic4share.com/particularpic.php?id=MTIw

http://www.pic4share.com/snapmessagepic.php

I agree, this this should be looked into. Not being able to rip direct imgur link seems kind of silly.
The problem is pronounced when you have a batch of direct imgur links but would have to otherwise manually goto each link and save them

+1

Agreed, especially with the introduction of #344 being able to take a list of imgur single-image page links and rip them would be helpful.


Fix small API break in the incremental build state

https://github.com/apple/swift-driver/pull/816 moved some things around in the incremental compilation state that may be relied on by clients as public API.
This PR restores the removed API surface. Sorry I missed these during review.

@swift-ci please test

@swift-ci please test


Adding an existing tag leaves the tag_names array out of sync with the DB

Environment

Rails 5.2.2
JRuby

Steps
If you use += on tag_names to add a tag that is already in tag_names then the tag_names array is out of sync with the DB:
irb(main):018:0> model.tag_names = ["tag1", "tag2"]
=> ["tag1", "tag2"]
irb(main):019:0> model.save!
=> true
irb(main):020:0> model.tag_names += ["tag2", "tag3"]
=> ["tag1", "tag2", "tag2", "tag3"]
irb(main):021:0> model.save!
=> true
irb(main):022:0> model.tag_names
=> ["tag1", "tag2", "tag2", "tag3"]
irb(main):023:0> model.reload
irb(main):024:0> model.tag_names
=> ["tag1", "tag2", "tag3"]

Possibly as designed. I worked around it by calling reload.

Thanks for reporting this :)
I've just pushed a fix (across two commits: 3f34f097adbb3f01eaa640bcda57619cb89ce09b and 787310a4d18c01fe5005d023b0a15eb2e74a369f). I'll aim to get a new gem release out in the next week.

Thanks for the quick turnaround! There is a related behaviour when you add a tag with upper-case letters:
irb(main):002:0> e.tag_names
=> ["tag1"]
irb(main):003:0> e.tag_names += ["Upper"]
=> ["tag1", "Upper"]
irb(main):004:0> e.tag_names
=> ["tag1", "Upper"]
irb(main):005:0> e.save!
=> true
irb(main):006:0> e.tag_names
=> ["tag1", "Upper"]
irb(main):007:0> e.reload
irb(main):008:0> e.tag_names
=> ["tag1", "upper"]

It looks like any time GutenTag is doing manipulation of the tag_names array before persisting it to the DB those changes are not synced back to the array.

Thanks Anthony - I've pushed a fix for this, and published a new release - 2.5.1 - which includes all of these changes :)


Improve issue templates

Is your feature request related to a problem? Please describe.
Upgrade the way issue templates works.
This would lead to a better comfort for the users.
Describe the solution you'd like
How will this solution be done?
Refact issue templates like this: https://github.com/akinsho/bufferline.nvim/tree/main/.github/ISSUE_TEMPLATE.
Describe alternatives you've considered
None

Also add automatic labels


Settings Index

cip: 24
title: Settings Index
author: Michael Sena (@michaelsena), Paul LeCam (@PaulLeCam)
status: Draft
category: Standards
type: RFC
created: 2020-07-23
requires: Tile Doctype (CIP-8), DocId Map (CIP-10)

Simple Summary
Settings Index is a document that stores an index of global settings-related documents for a DID.
Abstract
In an identity-centric model of development, users carry their identity and resources with them across various contexts. Applications then use with these resources to provide service to the user. Portable settings allow interfaces and experiences to be contextualized and customized to the user's personal preferences, such as internationalization (commonly abbreviated as i18n) (locale, currency format), location (country of residence), accessibility (font size), appearance (dark mode), and more.
Settings Index is a document that stores an index of global settings-related documents for a DID. It does not actually store the DID's raw settings data, but rather serves as a way to route to the documents which do.
Settings Index is a subdirectory of the Identity Index (IDX) (CIP-11) and is usually linked from the Root index (CIP-12).
Motivation
The Settings Index seeks to:

Provide a single, standard interface for setting and querying categories of global settings
Provide discovery and routing to various documents that contain settings
Provide extensibility to support more categories of settings over time
Provide a reusable core component of identity that can work with any DID

Specification
The Settings Index specification consists of a doctype, schema, table, and tags.
Doctype
Settings Index uses the Tile Doctype (CIP-8).
Schema
Settings Index utilizes the DocId Map (CIP-10) schema, which simply stores a list of strings which map to Ceramic DocIds. In this case, the DocIds are pointers to various documents that store a user's settings information. A reference to this schema should be included in your Settings Index document when it is created.
Table
Settings Index Table (link when PR is submitted) contains the standard set of properties that may be contained in any given Settings Index. New properties can be added to the table by following the steps below. Additional properties not found in this table may be stored in any Settings Index, however they may be less interoperable since others may not know what they represent. Here are some common examples of properties stored in Settings Index:

i18n: a link to i18n Settings, a document which contains a DID's internationalization settings (i.e. locale, currency format)
location: a link to Location Settings, a document which contains a DID's location settings (i.e. country of residence)
accessibility: a link to Accessibility Settings, a document which contains a DID's accessibility settings (i.e. font size)
appearance: a link to Appearance Settings, a document which contains a DID's appearance settings (i.e. dark mode)

How to add a new property to the Settings Index Table

Choose a unique, descriptive property name.
Add a description for your property.
Submit a PR to the CIP repository updating the Settings Index Table (link with PR) with your property.
Mention the authors of this CIP in the comments of your PR.

Tags
When creating a Settings Index document, add the SettingsIndex tag to the document header.
Example
An example Settings Index document.
"doctype": "tile"
"schema": "<insert canonical schema for DocId Map>"
"tags": ["SettingsIndex", "DocIdMap"]
"content": {
  "i18n": "ceramic://bafyljsdf1",
  "location": "ceramic://bafysdfoijwe2",
  "accessibility": "ceramic://bafysdfoijwe3",
  "appearance": "ceramic://bafysdfoijwe4"
}

Rationale
Instead of storing all settings information in one single document, It makes more sense to create an index of settings-related documents which each store subsets of a user's settings. This design provides flexibility by allow new categories of settings to easily be added to the Settings Index without needing to revise the standard and minimizes the impact of updating individual schemas since they will not affect every other settings document. This design also improves performance by minimizing load time, since loading can be parallelized and users can only sync the needed subsets of information without always needing to load one ever-growing file.
Implementation

Settings Index Table: Find the Settings Index Table here. (Linked with PR)

DocId Map Schema: Find the DocId Map schema used by the Setting Index here. (Linked with PR)

Libraries: Not yet available.

Usage
Root Index: Since settings are only one type of resource that can be associated with a DID, it is advisable to add the Settings Index to a Root Index (CIP-12), which serves as a top-level index for a DID's resources. The recommended path from a DID to the Settings Index is: DID/Root Index/Settings Index.
Copyright
Copyright and related rights waived via CC0.

Stale, closing.


[feature request] Suricata - Add option for eve-log over syslog

Hello,
I think it's not already asked (I did not find this specific feature request).
Is it possible to add the option to send the "eve-log" format over syslog as an alternative to the default file option which is set in the configuration template?
 - eve-log:
      enabled: yes
      type: syslog #file|syslog|unix_dgram|unix_stream
      #filename: eve.json
      # the following are valid when type: syslog above
      identity: "suricata"
      facility: local5
      level: Info  ## possible levels: Emergency, Alert, Critical,
                   ## Error, Warning, Notice, Info, Debug

This will be useful in a use case where the syslog is further processed over a logstash or graylog server to produce dashboards.
Thanks,
Ruben.

It has been asked before, although I can't find the issue right away (it could also have been on the forum).
But since suricata only supports one eve.log output, it would kill the features inside OPNsense that depend on the eve.json file being there.
A lot of people use filebeat to ship these logs, maybe that's an option for your use case as well.

Hello thanks for your answer. I know about the filebeat package but for my use case I'd need to be able to do that without having to use the shell (for example to install/configure filebeat). Which features depend on the eve.json file being there?

the alert view in the interface and the et-pro telemetry package for example also assumes the log file is there.

Ok.

According to suricata's documentation one can have multiple outputs for the eve-log, https://github.com/OISF/suricata/blob/d6903e70c1b653984ca95f8808755efbc6a9ece4/doc/userguide/output/eve/eve-json-output.rst#multiple-logger-instances, it's only for the drop logs that there can only be one output, I've open a feature request on the suricata project related to that https://redmine.openinfosecfoundation.org/issues/2935.
Another problem that I see is that the remote-syslog output is truncated after 1024 characters (1 KB) and at times the full message with the eve-log json spans more than 1024 characters, can this be tweaked somewhere or it's the limit of the syslog output ?

If we can have overlapping log targets, I don't mind looking into to adding a feature.
About the syslog length, I'm afraid this is a limitation of udp syslog (https://tools.ietf.org/html/rfc3164). Newer syslog frameworks support other transports for larger messages.

For this feature to be useful, we first need to replace syslog with syslog-ng. There have been talks about it for quite some time, we might schedule this for 20.1

The syslog-ng code with tcp syslog support is available in our master branch and scheduled for release in 19.7.
For reference, IDS/IPS will gain an option called "Enable eve syslog output" :

Which can then be intercepted in the new syslog-ng target menu

Using the following settings

I tried to experiment a bit with facility / identity in the suricata.yaml as well, but for some reason these don't seem to combine very well over the different syslog sections.


qualitative color maps

hi -- thanks for this work!
i have been scratching my head a bit over how to accomplish what i want, and perhaps you know, if you've been able to make all these color maps!  In particular, i'm interested in how to make qualitative color maps -- one where colors for a particular value have a semantic meaning but don't lie on a gradient relative to their neighboring colors in the map.
I'd like to have a color map that map the classification scalar field of a las file to a particular color -- so i have integer values that lie between [0, 255] (lasfile 1.4, point format 6) and i want all the class 2 points to be brown, all class 3 to be yellow, ... etc.
this is what i've attempted so far, but when i use the following colormap in cloudcompare, all i get is a solid dark red coloring:
<?xml version="1.0" encoding="UTF-8"?>
<CloudCompare>
    <ColorScale version="1">
        <Properties>
            <name>classification-gv</name>
            <uuid>{67147e26-8743-4881-bae9-54c996012fda}</uuid>
            <absolute>1</absolute>
            <minValue>2</minValue>
            <range>155</range>
        </Properties>
        <Data>
          <!--  rgb(99,69, 44) brown -->
          <step r="99" g="69" b="44" pos="0"/> <!--2/ground-->

          <!-- rgb(249,240,107) yellow-->
          <step r="249" g="240" b="107" pos="0.00653594771242"/> <!--3/low veg-->

          <!-- rgb(38,162,105) dark green-->
          <step r="38" g="162" b="105" pos="0.0130718954248"/>   <!--4/medium veg-->

          <!--  rgb(17,247,14) light green-->
          <step r="17" g="247" b="14" pos="0.0196078431373"/>    <!--5/high veg-->

          <!--  rgb(0,0,0) black -->
          <step r="0" g="0" b="0" pos="0.0522875816993"/>        <!--10/to be deleted-->

          <!--  rgb(119,118,123) grey-->
          <step r="119" g="118" b="123" pos="0.0915032679739"/>  <!--16/manmade structure-->

          <!--  -->
          <!-- 17 / previously 3/low veg now 16/structure -->

          <!--  -->
          <!-- 18 / previously 4/medium veg now 16/structure -->

          <!-- rgb(246,245,244) cream-->
          <step r="246" g="245" b="244" pos="0.967320261438"/>   <!--150/poles-->

          <!--  rgb(26,95,180) blue-->
          <step r="26" g="95" b="180" pos="0.97385620915"/>      <!--151/primary wire-->

          <!--  rgb(255,0,0) red -->
          <step r="255" g="0" b="0" pos="0.97385620915"/>        <!--152/previously 16/structure, now wire-->

          <!--  rgb(120,18,188) purple-->
          <step r="120" g="18" b="188" pos="0.980392156863"/>    <!--153/previously 150/pole, now wire-->

          <!--  rgb(224,28,206) magenta-->
          <step r="224" g="28" b="206" pos="0.986928104575"/>    <!--154/previously 150/pole, now service trap-->

          <!--  rgb(168,139,73) olive-->
          <step r="168" g="139" b="73" pos="0.993464052288"/>    <!--155/unstrung wire-->

          <!--  rgb(229,165,10) orange -->
          <step r="229" g="165" b="10" pos="1"/>
        </Data>
    </ColorScale>
</CloudCompare>

the commented rgb(...) strings are a display convenience; my editor displays those as colorized blocks so i can look at what the colors are as i'm looking at the file itself.
Anything jump out at you as particularly off, here?   Appreciate any advice you have!

Graham,
It looks like you are on the right track, nothing fundamentally wrong with the XML side of things (Below is a discrete test I exported, 0-70 with only a few identified steps).
The only thing you could try is adding a dummy "zero" class so that your range is 0-155. The 'minValue' = 2 could be screwing up CloudCompare's color binning calculations. This way the math is a little easier for your class value position. simply, [class number]/155
<?xml version="1.0" encoding="UTF-8"?>
<CloudCompare>
    <ColorScale version="1">
        <Properties>
            <name>LAS_CLASS_TEST</name>
            <uuid>{4876bba1-36ce-4f69-bf64-3510bc801c67}</uuid>
            <absolute>1</absolute>
            <minValue>0</minValue>
            <range>70</range>
        </Properties>
        <Data>
            <step r="255" g="255" b="255" pos="0"/>
            <step r="0" g="0" b="255" pos="0.0142857142857"/>
            <step r="35" g="0" b="220" pos="0.0285714285714"/>
            <step r="207" g="0" b="48" pos="0.0428571428571"/>
            <step r="72" g="0" b="183" pos="0.0571428571429"/>
            <step r="232" g="94" b="23" pos="0.257142857143"/>
            <step r="255" g="255" b="0" pos="1"/>
            <label val="0" text="NOT CLASS"/>
            <label val="1" text="UNCLASS"/>
            <label val="2" text="GROUND"/>
            <label val="3" text="LOW VEG"/>
            <label val="4" text="HIGH VEG"/>
            <label val="18" text="HIGH NOISE"/>
            <label val="70" text="GUY WIRE"/>
        </Data>
    </ColorScale>
</CloudCompare>

For position numbers, in the I'm pretty sure they need to be decimals, I don't think CC can interpret the variable as you have them coded pos="(/ 27 27)"

whoops, that was the wrong version!

gdi-las12-test
{313333e5-e6c6-4e42-b29a-4cc19db03087}
1
0
27

:man_facepalming:   this is what happens when you think you're being clever and you aren't -- i was using an editor plugin that i thought was evaluating those expressions and replacing them with their computed value.  It wasn't, it was creating an overlay instead.
With that remedied -- success.  thank you!


Buildsystem: Use pkg-config for miniupnpc and mbedtls

Miniupnpc added pkg-config files in 2.2.3 but we require 2.2.8 https://github.com/miniupnp/miniupnp/commit/5a398006b90e35942ffd8015a9f792df9ec97fd8
MbedTLS added pkg-config files in 3.6.0 while we require 3.6.1 https://github.com/Mbed-TLS/mbedtls/blob/development/ChangeLog

Maybe we can do something like this instead to preserve support for mbedtls 2.28 LTS:
diff --git a/platform/linuxbsd/detect.py b/platform/linuxbsd/detect.py
index 2fd573da75..e8c2f88435 100644
--- a/platform/linuxbsd/detect.py
+++ b/platform/linuxbsd/detect.py
@@ -279,16 +279,18 @@ def configure(env: "SConsEnvironment"):
         env.ParseConfig("pkg-config libwebp --cflags --libs")

     if not env["builtin_mbedtls"]:
-        # mbedTLS does not provide a pkgconfig config yet. See https://github.com/ARMmbed/mbedtls/issues/228
-        env.Append(LIBS=["mbedtls", "mbedcrypto", "mbedx509"])
+        # mbedTLS only provides a pkgconfig file since 3.6.0, but we still support 2.28.x,
+        # so fallback to manually specifying LIBS if it fails.
+        try:
+            env.ParseConfig("pkg-config mbedtls mbedcrypto mbedx509 --cflags --libs")
+        except:
+            env.Append(LIBS=["mbedtls", "mbedcrypto", "mbedx509"])

     if not env["builtin_wslay"]:
         env.ParseConfig("pkg-config libwslay --cflags --libs")

     if not env["builtin_miniupnpc"]:
-        # No pkgconfig file so far, hardcode default paths.
-        env.Prepend(CPPPATH=["/usr/include/miniupnpc"])
-        env.Append(LIBS=["miniupnpc"])
+        env.ParseConfig("pkg-config miniupnpc --cflags --libs")

     # On Linux wchar_t should be 32-bits
     # 16-bit library shouldn't be required due to compiler optimizations

(Or if SCons provides a version of ParseConfig that doesn't raise an exception but just returns an error code, we could use that.)

Looks reasonable but it didn't throw any exception even on empty command :sweat_smile:
Moreover in the start of the file we check if pkg-config exist by using pkgconf_error = os.system("pkg-config --version > /dev/null") so...

And later check if lib is available with if os.system("pkg-config --exists xkbcommon") == 0:  # 0 means found

It does throw an exception for me if there's no pkg-config file for mbedtls. But indeed os.system("pkg-config --exists mbedtls") == 0 is a better option, so I suggest this diff, which works fine for me locally (uses the first branch when mbedtls-devel is installed, and the else branch otherwise).
diff --git a/platform/linuxbsd/detect.py b/platform/linuxbsd/detect.py
index 2fd573da75..c8202b147d 100644
--- a/platform/linuxbsd/detect.py
+++ b/platform/linuxbsd/detect.py
@@ -279,16 +279,18 @@ def configure(env: "SConsEnvironment"):
         env.ParseConfig("pkg-config libwebp --cflags --libs")

     if not env["builtin_mbedtls"]:
-        # mbedTLS does not provide a pkgconfig config yet. See https://github.com/ARMmbed/mbedtls/issues/228
-        env.Append(LIBS=["mbedtls", "mbedcrypto", "mbedx509"])
+        # mbedTLS only provides a pkgconfig file since 3.6.0, but we still support 2.28.x,
+        # so fallback to manually specifying LIBS if it fails.
+        if os.system("pkg-config --exists mbedtls") == 0:  # 0 means found
+            env.ParseConfig("pkg-config mbedtls mbedcrypto mbedx509 --cflags --libs")
+        else:
+            env.Append(LIBS=["mbedtls", "mbedcrypto", "mbedx509"])

     if not env["builtin_wslay"]:
         env.ParseConfig("pkg-config libwslay --cflags --libs")

     if not env["builtin_miniupnpc"]:
-        # No pkgconfig file so far, hardcode default paths.
-        env.Prepend(CPPPATH=["/usr/include/miniupnpc"])
-        env.Append(LIBS=["miniupnpc"])
+        env.ParseConfig("pkg-config miniupnpc --cflags --libs")

     # On Linux wchar_t should be 32-bits
     # 16-bit library shouldn't be required due to compiler optimizations

This PR breaks builtin_miniupnpc=yes.
See #99196

Also falling back to using builtin mbedTLS is the wrong approach.
If the user specifies to use the builtin, it should error out to point out the built in cannot be used (which can happen if the package is not installed).


Smart pagination component

Is your feature request related to a problem? Please describe.
Navigating large datasets is challenging without a pagination system. Users may experience slow loading times and difficulty accessing specific items.
Describe the solution you'd like
Implement a pagination system with:

A fixed number of items per page.
Navigation controls (Next, Previous, and page numbers).
API support for pagination parameters like page and limit.
Optimization for handling large datasets efficiently.

Describe alternatives you've considered

Infinite scrolling: Automatically load items as users scroll.
Load more button: A button to manually load more items.

Additional context

I went to work on this issue, assigned me.


Withdrawals without queues

This PR implements withdrawals without any withdrawal queue. I want to explore the space for solutions like this since in principle seems to be much simpler than the current logic so I may be missing something and I'm using this space to find out what's wrong.
This solution adds only one field last_withdrawal_validator_index to the BeaconState, that keeps track of the last validator that has performed a withdrawal. Proposers pack up to MAX_WITHDRAWALS_PER_PAYLOAD in their execution blocks starting from the next validator after last_withdrawal_validator_index.
During block processing, we simply check that the the next validators that can withdraw agree with the ones packed in the block, and that their withdrawal amount agree with the ones we expect from the state.
There is no epoch processing logic as there is no queue to include withdrawals.
This also removes unnecessary constants like MAX_WITHDRAWALS_PER_EPOCH and WITHDRAWAL_QUEUE_LIMIT
I suppose there can be a problem with validators being slashed right after doing a partial withdrawal. This can only be a bad issue for  validators that get slashed for more than MAX_EFFECTIVE_BALANCE which is very rare, another issue is that a validator may end up with a slightly bellow MAX_EFFECTIVE_BALANCE right after performing a partial withdrawal, but I don't see anything seriously wrong with this either.

This feels simpler than the queue approach, which is why I am in favor of this change. We are at such an early stage with withdrawals (at least judging from https://notes.ethereum.org/@ralexstokes/SyDqVjr4i#CL-client-implementation), that major changes like this are OK.

I actually love the simplicity of this, there is no point popping the withdrawals into state queue and then later process it at block. This will also reduce/remove pressure on epoch processing, and the lookups for finding withdrawals for a block are small  since per block limit is small (assuming high success rate of finding a valid withdrawal). The two step withdrawal isn't giving any advantage.
the full having priority over partial can still be addressed in this mode as well, but only depends on what UX we want to go for.
so  :+1:  from lodestar on this approach overall.

I'm in two minds about this approach. I really like the simplicity but I'm a bit nervous about the potential need to have to scan a lot of validators to find the required number of withdrawals given that has to happen on every block import. My concern there is two-fold:

99.9% of the time we won't be scanning far which means the potential performance issues only show up in rare situations - typically when there are already other issues going on.
The mitigation for those performance problems involves introducing and keeping in sync separate caches which significantly reduces testability and adds a lot of complexity. I was keen on not having the separate loops for full vs partial withdrawals primarily to avoid the need to introduce caches tracking the fully withdrawable validators which are unlikely to be fully exercised by spec tests. The optimisations to avoid a full scan in this case have similar testability issues.

One option to resolve this would be to simple require scanning a fixed number of validators rather than requiring a fixed number of withdrawals be included. ie block 0 includes any withdrawals available for validators 0-3, block 1 withdrawals for validators 4-8 etc. We may not use the full withdrawal capacity but given there's at least some desire to have a minimum withdrawable amount, going at a fixed rate round the validators doesn't seem like an issue.

I'm in two minds about this approach. I really like the simplicity but I'm a bit nervous about the potential need to have to scan a lot of validators to find the required number of withdrawals given that has to happen on every block import.

I thought about simply changing the for loop to have a fixed bound which we can impose right now and I wouldn't be too opposed to it. However, I find that the situation when the scan is not immediate only happens if the network has been leaking for about 5 days (and this gets longer and longer each day), and if that happens, no matter what withdrawal mechanism we have, we will be in trouble anyway and this one does not make it particularly worse since it's a scan that you can perform after block processing during the beacon's "dead time" and in parallel,  as opposed to during epoch transition. The biggest problem with adding a bound is that we do not reuse validator indices, and this means that the bound is actually less effective over time and even during happy times we will start to see decreased capacity.

However, I find that the situation when the scan is not immediate only happens if the network has been leaking for about 5 days (and this gets longer and longer each day), and if that happens, no matter what withdrawal mechanism we have, we will be in trouble anyway and this one does not make it particularly worse since it's a scan that you can perform after block processing during the beacon's "dead time" and in parallel, as opposed to during epoch transition.

Having to perform the scan separate to block transition is the complexity I'd like to avoid - and it will generally only be done for what's seen as the canonical chain so may be invalidated by a late block etc.  Having sub-optimal processing kick in when the chain hasn't been finalising for 5 days is my nightmare scenario as it increases the risk of cascading problems.  I'd actually prefer to have to scan large spans regularly rather than having it be so rare as it would then be better tested and optimised.
Also while this particular case probably isn't an issue even if we have to do a full scan, we should be really cautious about depending on caches to ensure good performance. If the cache-miss scenario is noticeably slower it can open up attack scenarios where the attacker releases a block late or something like that to deliberately trigger cache misses (and missing multiple different caches can combine in lots of complex ways to cause problems). Hence things like gas prices are always set based on worst case scenarios where caches are missed.

The biggest problem with adding a bound is that we do not reuse validator indices, and this means that the bound is actually less effective over time and even during happy times we will start to see decreased capacity.

Given the current requests are to slow down the rate of withdrawals I'm not worried about this. At some point we likely need to start reusing validator indices (or find some other way of dropping exited validators) just to bound the growth of the validator set anyway. And if we were unhappy with reduced capacity before that happened it would be easy to say we'd scan until we've either found 4 withdrawals or scanned 50 validators. I'm not against having that dual limit now if we wanted to future proof but I don't think we need it.

Having to perform the scan separate to block transition is the complexity I'd like to avoid - and it will generally only be done for what's seen as the canonical chain so may be invalidated by a late block etc. Having sub-optimal processing kick in when the chain hasn't been finalising for 5 days is my nightmare scenario as it increases the risk of cascading problems. I'd actually prefer to have to scan large spans regularly rather than having it be so rare as it would then be better tested and optimised.
Also while this particular case probably isn't an issue even if we have to do a full scan, we should be really cautious about depending on caches to ensure good performance. If the cache-miss scenario is noticeably slower it can open up attack scenarios where the attacker releases a block late or something like that to deliberately trigger cache misses (and missing multiple different caches can combine in lots of complex ways to cause problems). Hence things like gas prices are always set based on worst case scenarios where caches are missed.

FWIW, the scan is so trivial in the non-leaking case that the way we plan to implement this to simply perform it after block operations and after any change of head. No need to optimize anything. If the network hasn't been finalizing for 5 days. The penalty is a full linear scan on each block indeed, but the current system is not clear that it is better: you still rely on reorg resistant caches for the full queues, you need to be efficient in implementing the queue itself to avoid memory fragmentation or even leaking it. It is the very first time we add a queue to a consensus object. While it's true that one can envision that the nightmare scenario is bad, a general rule is that protocol complexity has many more edge and untested cases, and there's not doubt that the current specification, with a queue in the beacon state that can be very large or very small depending on the number of exiting validators, with separate logic for full withdrawals and partial withdrawals, with separate logic for epoch transition, etc. is far more complicated.

Given the current requests are to slow down the rate of withdrawals I'm not worried about this. At some point we likely need to start reusing validator indices (or find some other way of dropping exited validators) just to bound the growth of the validator set anyway. And if we were unhappy with reduced capacity before that happened it would be easy to say we'd scan until we've either found 4 withdrawals or scanned 50 validators. I'm not against having that dual limit now if we wanted to future proof but I don't think we need it.

With this I agree, we are very likely going to be needing to reuse validator indices. I'd be happy to see some expected values perhaps. If we think we will be reusing indices when we hit something like 50K exited validators, then capping the loop at 5K will keep it in the microseconds.
Notice also that all clients are already performing a full validator set scan within forkchoice on each block insertion.

limiting the loop to a tweakable constant would enforce a time restriction on how often withdrawals get processed, which would help ensure that we're not processing too fast as well, which would be positive....
I wouldn't be surprised if that number is low, like 16 ish... which would ensure we're not going through the entire validator set while we're leaking, it'd be about 3 days per full loop of 400k validators if all validators are leaking, and probably drop max_withdrawals_per_payload to something like 4 which would loop through at full inclusion in around 12 days for 400k validators... 8 would be roughly 6 days which is probably on the 'fast' side...
But doing this we're close to the '6 days for a full withdrawal is too long' discussion?

Ok I ran some benchmarks and had a poke around the caches we already have and I don't think I'm worried anymore.
I was wary because while iterating balances is cheap in Teku, iterating the actual validator list is fairly expensive because of the way we maintain the state. Any balance above 32ETH must be withdrawable and any 0 balance isn't withdrawable, so the only time we have to access the actual validator without always getting a withdrawal out of it is when the balance is less than 32ETH. Most withdrawable validators will have a balance of 0 already and can be skipped. Thus the worst case scenario would be when all the active validators have leaked to have a balance below 32ETH. The timing on this isn't too bad and we can probably just wear the cost but if needed we already have a cache of active validators since that's needed for all kinds of things and that would let us very quickly skip over the vast majority of these additional checks without any extra complexity for maintaining a new cache.
Also iterating the full validator set is faster than I remember it anyway.
So I support this proposal.

I am in support of this PR and I think it's a great iteration. Nice work @potuz :clap: Also, thanks to those who did prior iterations!
I think there are two scenarios in which to consider this PR:

During a healthy, finalizing network.
During an unhealthy, non-finalizing network.

In a healthy network, I like this PR because it adds fewer items to the state. It appears to be more "functional" and I like that for reasons that are probably subjective. There's an argument that it doesn't prioritize full withdrawals, but I don't feel strongly about that. I think prioritization can be a separate argument (i.e., this PR could also support prioritized full withdrawals in a subsequent PR).
When it comes to an unhealthy network, I think I also prefer this PR. @ajsutton has done well to highlight how this PR suffers on an unhealthy network, but I believe that the withdrawal_queue (i.e. the status quo) suffers on an unhealthy network, too.
In the "Appendix" section, I describe how the withdrawal_queue has CPU (hashing) and memory (beacon state + hashing cache) downsides when doing "skip slots" across long distances.
As an argument against this PR, it has the unfortunate downside that, in some scenarios (e.g. inactivity leak), we must suffer an iteration across the validator set for every block. The withdrawal_queue suffers for for each skipped epoch, which I expect to be less frequent. That is, I propose that a penalty for each block is worse than an equal penalty for each skipped epoch.
However, the penalties suffered are not equal. The withdrawal_queue suffers CPU and memory penalties that are (a) challenging to comprehend and (b) at times significantly worse than a validator set iteration. This PR suffers only for CPU in a tightly-bounded and easy-to comprehend way.
Another thing about this PR is that I think the "iteration every block" problem is solvable. For example, we could attach to the state a [uint64; MAX_WITHDRAWALS_PER_PAYLOAD * SLOTS_PER_EPOCH] which contains an ordered list of validator indices that are available for withdrawal. When that list is empty or the last value equals last_withdrawal_validator_index then we know there are no more withdrawals to dequeue.
So, I think this PR is certainly a step in the right direction if not a candidate for production. I'm unsure about the latter at this point :thinking:
Appendix
This appendix describes my concerns about how the withdrawal_queue behaves during skip slots. Whilst "skipping slots" (i.e., running process_slot from parent.slot to block.slot) we must maintain the withdrawals_queue and compute its hash tree root for each epoch so that we may verify the block.state_root.
The rate at which the withdrawals queue can grow is a little unclear due to "unbounded" full withdrawals, however let's assume it grows at MAX_PARTIAL_WITHDRAWALS_PER_EPOCH == 256 (for brevity, let's call this variable WITHDRAW_PER_EPOCH).
Running some benchmarks on my ~3 year old laptop (i7-10510U), I'm seeing 0.4ms to compute the hash tree root of a withdrawals_queue of length 256.
As we know, it's possible for validators to produce blocks upon the finalized checkpoint and cause all honest clients to run skip-slots from the finalized checkpoint to the wall clock slot. Since EPOCHS_PER_DAY = 225, a day of skip slots will involve at least 90ms (225 * 0.4) of hashing the withdrawal_queue. Notably, 90ms assumes perfect tree-hash caching. A cache-less implementation would end up at ~13s.
Along with this time cost, there's also a memory cost; a days worth of Withdrawal objects (44 bytes each) is 44 * EPOCHS_PER_DAY * WITHDRAW_PER_EPOCH ~= 2.5mb added to the BeaconState. Assuming we're doing current-generation tree hash caching, we're looking at a cached tree of ~3.6mb (((EPOCHS_PER_DAY * WITHDRAW_PER_EPOCH * 2) - 1) * 32).
So, if we assume that there were 450k validators viable to enter the queue before non-finality started, we'll reach a maximum withdrawal_queue size of 450k within ~7.7 days. By that time we'll have done 693ms of hashing (in the best case), added ~19mb to the BeaconState and ~33mb of tree hash cache. Without tree hash caching we're looking at 12 minutes of hashing!

I am in support of this PR expanding on others points including:

Ensures block space for withdrawals is optimally used when needed. Current dev branch will leave withdrawal spots empty unless churn limit is high enough.

However I want to point out that this approach could support an implementation where full withdrawals do not have to incur extra wait time. Snippet below is naive implementation for that goal. Splitting full and partial withdrawals in half in an arbitrary decision, but as long as churn is low and there's not a mass slashing event partial withdrawals will always dominate. Also, since the full withdrawal iteration does not have a pointer, older indexes will be prioritized always. To prevent having to loop on each block, one can keep an ordered hash set of indexes who satisfy the withdrawable_epoch condition and only evaluate those.
def get_expected_withdrawals(state: BeaconState) -> Sequence[Withdrawal]:
    epoch = get_current_epoch(state)
    withdrawal_index = state.next_withdrawal_index
    withdrawals: List[Withdrawal] = []

    # Full

    for index in range(len(state.validators)):
        balance = state.balances[index]
        validator = state.validators[index]
        if is_fully_withdrawable_validator(validator, balance, current_epoch):
            withdrawals.append(Withdrawal(
                index=WithdrawalIndex(withdrawal_index + len(withdrawals)),
                validator_index=index,
                address=ExecutionAddress(val.withdrawal_credentials[12:]),
                amount=balance,
            ))
        if len(withdrawals) == MAX_WITHDRAWALS_PER_PAYLOAD / 2:
            break

    # Partial
    index = ValidatorIndex((state.last_withdrawal_validator_index + 1) % len(state.validators))

    for probed in range(len(state.validators)):
        val = state.validators[index]
        balance = state.balances[index]
        if is_partially_withdrawable_validator(val, balance):
            withdrawals.append(Withdrawal(
                index=WithdrawalIndex(withdrawal_index + len(withdrawals)),
                validator_index=index,
                address=ExecutionAddress(val.withdrawal_credentials[12:]),
                amount=balance - MAX_EFFECTIVE_BALANCE,
            ))
        if len(withdrawals) == MAX_WITHDRAWALS_PER_PAYLOAD:
            break
        probed += 1
        index = ValidatorIndex((index + probed) % len(state.validators))
    return withdrawals

require scanning a fixed number of validators rather than requiring a fixed number of withdrawals be included

Why not both? Scan until you've found MAX_WITHDRAWALS_PER_PAYLOAD or you've hit VALIDATOR_SEEK_LIMIT, whichever comes first. This avoids the "sub-optimal processing kick in when the chain hasn't been finalising" death spiral.
Setting VALIDATOR_SEEK_LIMIT = 512 would ensure the entire validator set is processed once per day, even in the worst case scenario of no one being withdrawable, with 98% of ETH staked..

ah, can you also update fork.md with the new fields?

ah, can you also update the BeaconState in upgrade_to_capella infork.md with the new fields?

Isn't this done already?

A quick note, there were two main reasons I did the withdrawals queue initially:

To ensure that load is bound and spread across slots even in exceptional scenarios (e.g. withdrawals are initially enabled and tons of validators are withdrawable). With the combined sweep that bounds per slot, this is no longer an issue
To ensure that CL and EL can be processed in parallel. I was misguided on this item. By not having a queue, we add complexity to block building for CLs -- they must ensure that the withdrawals created at after any balance updates that happen prior to the process_withdrawals call (which can happen due to process_slots being before process_block) . BUT because withdrawals show up independently in the Execution Payload for block processing (placed there by the proposer), they can immediately be passed into EL even if validated a bit later in CL. Point being -- I was incorrect on this and it was my sticking point so this PR seems fine. Will do a deep pass on it but we can merge shortly


[ENG-2554] fix(types): Add Component Types

Adds types to React component
Adds biome for consistent formatting

Supersedes #3


Categories Limited to 5?

I have been trying to generate pie and vertical bar charts with more than 5 categories, and it's maxing out at 5 categories. It this by design?
Charts 3.6
Sketch 51.2

For Pie charts it is true, but you can generate Vertical bar chart with more than 5 categories.


is vue support?

do this  support vuejs

It has zero dependencies, so yes. Every framework.

If you mean native or component based support - no. As it is (vanillajs) you can get as much performance as possible (considering massive amount of selectables), wrapping it into a component or directives would reduce the performance drastically.


Feature Strict Mode

Added Strict Mode Feature

Are you sure it's a good idea to allow admins to toggle strict mode for users? Wouldn't it be better idea to only allow users to toggle strict mode for themselves?

Also, I think that such a drastic change in behavior should be opt-in rather than opt-out.

Are you sure it's a good idea to allow admins to toggle strict mode for users? Wouldn't it be better idea to only allow users to toggle strict mode for themselves?

nope because they will be able to trigger it whenever they want to, and they might abuse this feature.

Are you sure it's a good idea to allow admins to toggle strict mode for users? Wouldn't it be better idea to only allow users to toggle strict mode for themselves?

nope because they will be able to trigger it whenever they want to, and they might abuse this feature.

How can someone abuse it if they can only toggle it for themselves? They could just as easily not turn it on from the beginning.

Also, I think that such a drastic change in behavior should be opt-in rather than opt-out.

Well it was suggested by multiple users as they felt the bot was too strict.
So this feature will make it a bit easier and it won't kick the ones who has strict mode off.

Are you sure it's a good idea to allow admins to toggle strict mode for users? Wouldn't it be better idea to only allow users to toggle strict mode for themselves?

nope because they will be able to trigger it whenever they want to, and they might abuse this feature.

How can someone abuse it if they can only toggle it for themselves? They could just as easily not turn it on from the beginning.

yes but they might  turn it on right before getting a red card, then turning it on again. I think it's better to require the admin to know beforehand if someone needs strict mode

Also, I think that such a drastic change in behavior should be opt-in rather than opt-out.

Well it was suggested by multiple users as they felt the bot was too strict. So this feature will make it a bit easier and it won't kick the ones who has strict mode off.

Yes, I agree, but don't make it turned on by default.

Are you sure it's a good idea to allow admins to toggle strict mode for users? Wouldn't it be better idea to only allow users to toggle strict mode for themselves?

nope because they will be able to trigger it whenever they want to, and they might abuse this feature.

How can someone abuse it if they can only toggle it for themselves? They could just as easily not turn it on from the beginning.

yes but they might turn it on right before getting a red card, then turning it on again. I think it's better to require the admin to know beforehand if someone needs strict mode

Sounds good! Thanks for your time.

Also, I think that such a drastic change in behavior should be opt-in rather than opt-out.

Well it was suggested by multiple users as they felt the bot was too strict. So this feature will make it a bit easier and it won't kick the ones who has strict mode off.

Yes, I agree, but don't make it turned on by default.

The normal bot functionalities = strict mode on
the new feature is to allow someone to turn it off so they can stay in server when they get a red card.

Also, I think that such a drastic change in behavior should be opt-in rather than opt-out.

Well it was suggested by multiple users as they felt the bot was too strict. So this feature will make it a bit easier and it won't kick the ones who has strict mode off.

Yes, I agree, but don't make it turned on by default.

The normal bot functionallities = strict mode on

Are you sure it's a good idea to allow admins to toggle strict mode for users? Wouldn't it be better idea to only allow users to toggle strict mode for themselves?

nope because they will be able to trigger it whenever they want to, and they might abuse this feature.

How can someone abuse it if they can only toggle it for themselves? They could just as easily not turn it on from the beginning.

yes but they might turn it on right before getting a red card, then turning it on again. I think it's better to require the admin to know beforehand if someone needs strict mode

Sounds good! Thanks for your time.

Happy to help

Also, I think that such a drastic change in behavior should be opt-in rather than opt-out.

Well it was suggested by multiple users as they felt the bot was too strict. So this feature will make it a bit easier and it won't kick the ones who has strict mode off.

Yes, I agree, but don't make it turned on by default.

The normal bot functionalities = strict mode on the new feature is to allow someone to turn it off so they can stay in server when they get a red card.

Sounds good too! Thanks again for your time!

Also, I think that such a drastic change in behavior should be opt-in rather than opt-out.

Well it was suggested by multiple users as they felt the bot was too strict. So this feature will make it a bit easier and it won't kick the ones who has strict mode off.

Yes, I agree, but don't make it turned on by default.

The normal bot functionalities = strict mode on the new feature is to allow someone to turn it off so they can stay in server when they get a red card.

Sounds good too! Thanks again for your time!

No problem

However there are multiple conflicts due to this branch being behind with commits, especially with client.py and penalty_scheduler.py.
@SuperNova74-K


Uncatchable Google API script errors in Amplify React

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Using a custom UI with the Authenticator and only a Google Federated component (using withFederated()) will dispatch an uncatchable script error when an error occurs with the gapi instance.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than AWS Amplify.
We have a fully custom UI that is only using Google Federated users to sign into out Cognito accounts. When an error occurs within withGoogle.jsx signIn() method the gapi script throws an error.
In Chrome's console, we can see the uncaught error and read the details. But, when trying to catch the error using window.onerror this message is simply 'Script Error' and the error is removed. This sanitization is expected because the error is being dispatched by the injected script which is coming from a crossdomain (apis.google.com/).
The easiest way to trigger an error is closing the Google window pop-up when multiple Google Accounts are available. When closed before selecting an account the gapi script will throw a "popup_closed_by_user" error.
What is the expected behavior?
Ideally, our child component would be notified by the withGoogle() HoC that an error has occurred.
I have a fix to catch the error locally in a fork, by providing a second function argument to the promise. This is the recommended way to catch errors in Google's API, but I am not sure of Amplify's recommended way to pass errors up the component chain.
We can't easily rethrow the error from the promise because the scope is still bound to the script. I am looking into rebinding the error/throw and see if I can't clone/bring the Error into the component scope so that we can support Error Boundaries. But, is this the Amplify way? Is there an error state/dispatcher that is the better way? I am still learning the Amplify code base and I am not 100% sure the best approach to support your other components.
Here is the code for the catch addition in withGoogle.jsx:
signIn() {
    const ga = window.gapi.auth2.getAuthInstance();
    ga.signIn().then(
        googleUser => this.federatedSignIn(googleUser),
        error => { /* do somthing here */  }
    );
}

Which versions of Amplify, and which browser / OS are affected by this issue? Did this work in previous versions?
This is in master, from what I can tell this has always been here. I assume this is with all browsers, but I have been testing with Chrome.
You can turn on the debug mode to provide more info for us by setting window.LOG_LEVEL = 'DEBUG'; in your app.

Here is how I ended up fixing it locally and confirmed it is working on my local build and my app.
withGoogle.jsx
signIn() {
    const ga = window.gapi.auth2.getAuthInstance();
    const { onError } = this.props;
    ga.signIn().then(
        googleUser => this.federatedSignIn(googleUser),
        error => {
            if (onError) onError(error);
            else throw error;
        }
    );
}

Login.js (in my app)
<LoginButton
    federated={federated}
    onStateChange={this.handleAuthStateChange}
    onError={this.handleLoginError}
/>


[DockerInstaller@0] fails to Download 20.10.0

Required Information
Type: Bug
Enter Task Name: DockerInstaller@0
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks/DockerInstallerV0
Environment

Server - Azure Devops Server

Version: Dev17.M153.3

Agent - Private:

Windows

2.153.1

Issue Description
DockerInstaller fails to download anything newer than 17.09.0-ce.
The current Version of Docker engine is 20.10.0
The latest available Version for Docker to install with DockerInstaller is 17.09.0-ce.
Docker Team seems to moved their Downloads to another server location.

No current release at the hard-coded download folder:

Task logs
##[section]Starting: DockerInstaller
==============================================================================
Task         : Docker CLI installer
Description  : Install Docker CLI on agent machine.
Version      : 0.1.3
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/tool/docker-installer
==============================================================================
Downloading: https://download.docker.com/win/static/stable/x86_64/docker-20.10.0.zip
##[error]Error: Failed to download Docker from location https://download.docker.com/win/static/stable/x86_64/docker-20.10.0.zip. Error Error: Unexpected HTTP response: 404
##[section]Finishing: DockerInstaller

@juwens Looks like Docker has stopped supporting CLI packages for windows. So we can only support till version 17.09

@juwens Looks like Docker has stopped supporting CLI packages for windows. So we can only support till version 17.09

This is the issue that we filed on docker (https://github.com/microsoft/azure-pipelines-tasks/issues/14072)

This is the issue that we filed on docker (https://github.com/microsoft/azure-pipelines-tasks/issues/14072)

Closing it as stale issue since the author didn't get back


Groq LLM

Please add an extension to use Groq LLM
https://groq.com/
Groq has the same interface as OAI and is faster and cheaper.

Please add an extension to use Groq LLM https://groq.com/ Groq has the same interface as OAI and is faster and cheaper.

i think most of its api are openai compatible so you can really just use the openai extension, while changing the baseURL
https://console.groq.com/docs/openai

Hi, yes that is true and we can set base_url in property.json so it would be possible to make a new graph now with groq e.g. deepgram.groq.cartesia which I understand is the fastest and cheapest cascading pipline possible today.


Wish to auto open dropdown if on typing or input text focusing

Hi, thanks for making this amazing stuff. Actually i'm working on react-native-paper and i'm like using react-native-paper-autocomplete in my project.
So just wish to auto open dropdown if on typing or input text focusing as my picture below.

Thanks!

+1, this library is basically unusable (from users perspective) because it just not behave correctly.

if i click on the input i expect the list to appear
i would appreciate more flexibility in customizing behavior
list sometimes flashing over other components when opened

Agree! This is bad!
I was also thinking about opening a bottom sheet or something like that on smaller devices

But I'm a little short on time a.t.m. I'm hoping to have some time in the future to improve this.
I'm building a new app where I want to use the autocomplete on the web version so I can also look if I can improve some native stuff while I'm at it

Any news about this enhancement? Did you used it finally for the app you mentioned or did you end up using something else?
I'm considering using the component for a web/iOS app.


 This change allows the publish function to succeed even if there is nothing new to commit.

Oh yes that's great

Fixed and rebased.

@tlienart Any chance of a new release?

Yeah I guess I wanted two more things to go in it but I can release now and figure those out later


Add .clang-format file implementing our preferred style

Spinoff from https://github.com/datomusic/duo-imxrt/pull/116#discussion_r1257848027

Let's follow Google's coding conventions
Preferred style is only applied to changes (so no separate formatting commits)


Strip whitespace when looking up ManyToMany fields

This makes imports more robust when users enter whitespaces after
commas.

Sorry, I couldn't find the develop branch here https://github.com/django-import-export/django-import-export/branches/all what am I missing?

@bmihelac: Would love to know if this is something you want to merge quickly (after I address all your feedback), if not I can subclass ManyToManyWidget for my current project.

LGTM

Merged, thanks @raghavsethi for patch, @manelclos for reviewing

Uh oh!  This is causing tests to fail:  https://travis-ci.org/django-import-export/django-import-export/jobs/302923330

looking into it, thanks for noticing

Fix in d6615a716bd4cb0f8825989c2fe9add6d411b999, sorry for inconvinience

Sorry about that! Thanks for the fix!

Sorry @bmihelac I would have fixed but was looking at the Travis-CI issue instead :)

No problem @raghavsethi, I checked the code and was confident, travis would warn if anything is wrong.
@mgrdcm it is right for me to fix, since i broke it :)


Improve item list rerender

If a search is applied and only a few items are displayed, remove the filter (click "x" button in the search bar), and the app briefly freezes. This should be possible to fix with recursive rerender (one item at a time) or with better state manipulation.

Resolved in #58


Clean up '#if CORE' in Attributes.cs

Related #3565 and #4357.
Now System.Transactions is in CoreFX 2.0 but all transaction cmdlets is only in FullCLR and we haven't tests at all.

From @daxian-dbw

Let's keep the transaction related if/defs for now. More work is needed to enable transaction support.


add upgrade note for NicClusterPolicy

with 24.10.0, NicClusterPolicy is no longer deployed through helm. this means that during upgrade the existing NicClusterPolicy may be deleted from the cluster.
add upgrade note to add helm.sh/resource-policy=keep if its desired to keep the old CR.

alternative to this: is to add a pre-upgrade hook which will check if a ncp object exists and currently belongs to current helm release then add helm.sh/resource-policy=keep annotation.

alternative to this: is to add a pre-upgrade hook which will check if a ncp object exists and currently belongs to current helm release then add helm.sh/resource-policy=keep annotation.
@rollandf @e0ne @noama-nv thoughts ?
this would need to go through QA testing

I think a pre-upgrade hook will be better for user that could miss the release notes

Not needed, we added a hook to keep the NCP on upgrade:
https://github.com/Mellanox/network-operator/pull/1135


[mac] How do I fully exit an app?

In druid demo running on macOS, click exit button, the window will disappered, but the icon is still on the dock. the app cannot active again.

In macOS, by default, application does not exit after closing all windows. Application itself is responsible to detect how many window left and decide to exit or not.
Most demos of druid does not implement menus, thus you cannot exit via cmd+Q nor top-left menu, you can only exit via right-clicking app icon at the dock, or send Ctrl+C in terminal.
The example multiwin has implemented macOS's default menu, cmd+Q and application's top-left menu works. It also shows how to capture windows events like window_removed using AppDelegate, in which you can exit application by calling Application::global().quit()


Vue3 apollo quasar/feat/single repo issues tab view

This is a merge of other PR's as some contents from them were needed, so when those PR's are closed this will be less bulky


Automatically generate stubs for class-based transforms

This seems like the way to go https://mypy.readthedocs.io/en/stable/extending_mypy.html


Add images to cards

add option to attach images to responses
example:

app.intent('CardsIntent', 'Whats in shopping cart', () => {
    return {
        text: 'Your shopping cart contains Amazon Echo Device and 2 more items. To see the full list check out your Alexa app',
        card: {
            title: 'Shopping cart',
            text: 'You shopping cart contains: Amazon Echo, Amazon Tap, Echo Dot',
            image: {
                smallImage: '...',
                largeImage: '...'
            }
        }
    };
});

refer to https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/providing-home-cards-for-the-amazon-alexa-app#creating-a-home-card-to-display-text-and-an-image

fixed in 70166b1
added support for the complete card object as described in amazon docs


Add initial design.md template and Resources folder

Adds a template for creating new design documents for components. Closes #208

These templates should be placed in the blueprints folders so the devs automatically get them when generating a new component (take a look in build/blueprints/component/files/src/patternfly/*) - I wouldn't expect devs would be able to find or know to look in this folder when creating a component and we are encouraging people to use pf generate component (name).  If your goal is to use this for each component, we should move it over there once you agree on the syntax.

@stacymcauliffe Thanks for the review and comments. I've incorporated most of them. However I am closing this PR in favor of opening a new one as following discussion with @dgutride we have a better location for this.


Add new Roblox icons

Awesome extension/plugin!
I think that if you could add support for the new Roblox studio icons in VSCode, that would be really awesome. I prefer them much over the old ones.

I don't think he'll add this feature as you can do this manually.

Why not just implement them for everyone, though? I know that many people prefer it. Or at least make it a toggle for those who prefer the new icons.

I think he once said that he won't be adding that system. (Pretty sure, I was the one who requested it. I'll try and find it)

Maybe. But having the icons match the default studio ones makes more sense. I could send a pull request updating the icons if I get time.


[Bug]: HMAC timestamp is outside of the tolerance range

Please confirm that you have:

[X] Searched existing issues to see if your issue is a duplicate. (If you’ve found a duplicate issue, feel free to add additional information in a comment on it.)
[X] Reproduced the issue in the latest CLI version.

In which of these areas are you experiencing a problem?
App
Expected behavior
After successfully app installation. It display blank white screen with following message.
hmac timestamp is outside of the tolerance range

Issue
[shopify-app/ERROR] Failed to complete OAuth with error: Error: HMAC timestamp is outside of the tolerance range
Logs
[server] [shopify-api/INFO] Beginning OAuth | {shop: testhubfinal.myshopify.com, isOnline: false, callbackPath: /auth/tokens}
[server] [shopify-api/DEBUG] OAuth started, redirecting to https://testhubfinal.myshopify.com/admin/oauth/authorize?client_id=346c080303b0a7c06ae69ec4728b2784&scope=write_themes%2Cwrite_script_tags&redirect_uri=https%3A%2F%2Fc8cd-2401-4900-5978-edad-1d8a-6c16-4ab5-ee97.in.ngrok.io%2Fauth%2Ftokens&state=813507951337385&grant_options[]= | {shop: testhubfinal.myshopify.com, isOnline: false}
[server] [shopify-api/INFO] Completing OAuth | {shop: testhubfinal.myshopify.com}
[server] ---> Error at /auth/tokens InvalidHmacError: HMAC timestamp is outside of the tolerance range
[server]     at validateHmacTimestamp (E:\Shopify app\shopify-node-express-mongodb-app\node_modules@shopify\shopify-api\lib\utils\hmac-validator.js:45:15)
[server]     at E:\Shopify app\shopify-node-express-mongodb-app\node_modules@shopify\shopify-api\lib\utils\hmac-validator.js:31:9
[server]     at Generator.next ()
[server]     at E:\Shopify app\shopify-node-express-mongodb-app\node_modules\tslib\tslib.js:167:75
[server]     at new Promise ()
[server]     at Object.__awaiter (E:\Shopify app\shopify-node-express-mongodb-app\node_modules\tslib\tslib.js:163:16)
[server]     at E:\Shopify app\shopify-node-express-mongodb-app\node_modules@shopify\shopify-api\lib\utils\hmac-validator.js:27:31
[server]     at E:\Shopify app\shopify-node-express-mongodb-app\node_modules@shopify\shopify-api\lib\auth\oauth\oauth.js:124:66
[server]     at Generator.next ()
[server]     at E:\Shopify app\shopify-node-express-mongodb-app\node_modules\tslib\tslib.js:167:75
Actual behavior
It should work and install without giving any issue on windows machine.
Stack trace
No response
Reproduction steps

Operating System
Window 10
Shopify CLI version (check your project's package.json if you're not sure)
Latest
Shell
No response
Node version (run node -v if you're not sure)
18.14.1
What language and version are you using in your application?
No response

Hi, thanks for opening this, I'll tag @Shopify/client-libraries-app-templates so they can take a look at this.

Hello @alvaro-shopify,
After looking into to doc, i figured out the solution. one thing comes to mind - The HMAC validation code mentions 90 seconds as the tolerance limit, any chance your computer's local clock is off by more than 90 seconds?
All we need to do is to sync our computer clock to the latest time. Then it will start working without any issue. It's working fine from my side.
Thanks


[dev/1.30] repo: Dev v1.30.2

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/retest

pushing through to reopen branch


Can't run yum update on latest 1.22 gpu-ami

What happened:
yum update  fails with:
Error: Package tuple ('kernel-devel', 'x86_64', '0', '5.4.228', '132.418.amzn2') could not be found in packagesack

**Steps to reproduce **:
# uname -r
5.4.228-131.415.amzn2.x86_64
# yum repolist
Loaded plugins: dkms-build-requires, nvidia, priorities, update-motd, versionlock
7 packages excluded due to repository priority protections
repo id                                                                                repo name                                                                                status
amzn2-core/2/x86_64                                                                                Amazon Linux 2 core repository                                                                                29,654+196
amzn2-nvidia/2/x86_64                                                                                Amazon Linux 2 Nvidia repository                                                                                565+7
amzn2extra-docker/2/x86_64                                                                                Amazon Extras repo for docker                                                                                27+52
amzn2extra-kernel-5.4/2/x86_64                                                                                Amazon Extras repo for kernel-5.4                                                                                242+82
!neuron                                                                                Neuron YUM Repository                                                                                248+22
repolist: 30,736
# yum versionlock list
Loaded plugins: dkms-build-requires, nvidia, priorities, update-motd, versionlock
0:runc-1.1.4-1.amzn2.*
0:containerd-1.6.6-1.amzn2.0.2.*
0:docker-20.10.17-1.amzn2.0.1.*
0:kernel-headers-5.4.228-131.415.amzn2.*
0:kernel-devel-5.4.228-131.415.amzn2.*
0:nvidia-container-runtime-hook-1.4.0-1.amzn2.*
versionlock list done
# yum clean all
Loaded plugins: dkms-build-requires, nvidia, priorities, update-motd, versionlock
Cleaning repos: amzn2-core amzn2-nvidia amzn2extra-docker amzn2extra-kernel-5.4 neuron
Cleaning up everything
Maybe you want: rm -rf /var/cache/yum, to also free up space taken by orphaned data from disabled or removed repos
# rm -rf /var/cache/yum
# yum update
Loaded plugins: dkms-build-requires, nvidia, priorities, update-motd, versionlock
amzn2-core                                                                                | 3.7 kB  00:00:00
amzn2-nvidia                                                                                | 2.5 kB  00:00:00
amzn2extra-docker                                                                                | 3.0 kB  00:00:00
amzn2extra-kernel-5.4                                                                                | 3.0 kB  00:00:00
neuron                                                                                | 2.9 kB  00:00:00
(1/9): amzn2-core/2/x86_64/updateinfo                                                                                | 554 kB  00:00:00
(2/9): amzn2-core/2/x86_64/group_gz                                                                                | 2.5 kB  00:00:00
(3/9): amzn2extra-kernel-5.4/2/x86_64/updateinfo                                                                                |  31 kB  00:00:00
(4/9): amzn2extra-docker/2/x86_64/updateinfo                                                                                | 8.0 kB  00:00:00
(5/9): amzn2-nvidia/2/x86_64/primary_db                                                                                | 335 kB  00:00:00
(6/9): amzn2extra-docker/2/x86_64/primary_db                                                                                | 101 kB  00:00:00
(7/9): amzn2extra-kernel-5.4/2/x86_64/primary_db                                                                                |  21 MB  00:00:00
(8/9): neuron/primary_db                                                                                | 108 kB  00:00:00
(9/9): amzn2-core/2/x86_64/primary_db                                                                                |  69 MB  00:00:00
7 packages excluded due to repository priority protections
Resolving Dependencies
Error: Package tuple ('kernel-devel', 'x86_64', '0', '5.4.228', '132.418.amzn2') could not be found in packagesack
#

What you expected to happen:
Any  packages with updates besides those versionlocked to be installed
Anything else we need to know?:
Trying to build a new AMI for 1.22 based on amazon-eks-gpu-node-1.22-v20230203
Environment:

AWS Region: us-east-1
Instance Type(s):
EKS Platform version (use aws eks describe-cluster --name <name> --query cluster.platformVersion):
Kubernetes version (use aws eks describe-cluster --name <name> --query cluster.version):
AMI Version:  ami-079363bca92a41c98 - amazon-eks-gpu-node-1.22-v20230203
Kernel (e.g. uname -a): Linux ip-10-130-72-1.hbk.com 5.4.228-131.415.amzn2.x86_64 #1 SMP Tue Dec 20 12:51:02 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Release information (run cat /etc/eks/release on a node):

BASE_AMI_ID="ami-04e0068781ee1fe9e"
BUILD_TIME="Fri Feb  3 16:47:43 UTC 2023"
BUILD_KERNEL="5.4.228-131.415.amzn2.x86_64"
ARCH="x86_64"

This issue is caused because this AMI release has a lock on kernel-devel and kernel-headers, but not the kernel. That will be fixed in the next AMI release. We've added locking on kernel packages to prevent unintentional updates that could introduce instability; and because updating the kernel on a running node requires a reboot, which should generally only be done within a managed upgrade process that will avoid disruption to your workloads.
You can always get around the version locks by disregarding the plugin:
yum update --noplugins

But be aware that the kernel, containerd, nvidia-driver-latest-dkms, etc. that is installed may introduce instability and version skew across your nodes.


update traceloop for issue 63

Pick the last version of traceloop. This patch makes more clear which version of traceloop is picked up. It avoids the ":latest" anti-pattern.
Fixes https://github.com/kinvolk/inspektor-gadget/issues/63

In the longer run it would be better to use the same tags on docker images as the traceloop releases. And maybe release traceloop more often if we need it.

So far we haven't done any traceloop release. Meanwhile could we merge this PR, and add an issue to make releases of traceloop?

Sure.


Bench HPy

The full benchmark can be run with hpy git revision 7c832a2f (vendored in PyPy after https://foss.heptapod.net/pypy/pypy/-/merge_requests/778).
With gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, I get a "maybe-uninitialized" warning so I had to comment the flag -Werror.

The CI on Travis (testing only CPython) is green https://travis-ci.org/github/paugier/piconumpy/builds/748513697

Nice, this proves the benchmarks are viable. There is not much value to measuring benchmarks on a CI virtual machine, but this validates the approach.
You can get pypy to run on travis, you will have to download nightly builds of py3.7 to do it. You may find github actions slightly easier since soon the uses: actions/setup-python@v2 will support pypy nightlies.

@paugier Should we close this PR in favour of the new benchmark PR you are working on?


Implement the TODOs in the Harvard Architecture PR

In the Harvard Architecture PR we left a few TODOs.  Here we make good on them.
Alas, unlike @icemelon's hopes the change is slightly more involved.
There's a few things happening in this PR:

We remove the fake instruction EANY.  EANY was only ever an artifact of Risc0's incredible 'interesting' approach to decoding.  We use the real instructions ECALL and EBREAK instead.

Remove AUIPC and LUI.  Both of them are now implemented as pseudo-instructions, that translate to ADDI during decoding.

Use the same library as SP1 for RiscV decoding, instead of copy-and-pasting-and-editing Risc0's 'interesting' decoder.  That simplifies our code, and comes with a lot more tests than we ever had.  Both because of explicit tests in the library, and because of the usage in SP1 and other projects. This gets rid of much error prone bit manipulating code.

Use struct Instruction throughout the code when handling and testing instructions, instead of u32.  That makes specifying tests a lot simpler and more readable.  No more 0b_000000001010_00000_000_00001_0010011, // addi x1, x0, 10 in the code.

Remove the notion of executable vs non-executable ROM.  This is only necessary for a von-Neumann architecture: everything that's in our instruction-cache is meant to be executable already.  (We can re-implement this restriction later by controlling what is allowed to make it into the instruction cache when we eg decode the ELF.  But it's unnecessary: we already honour the executable flag for memory sections in the ELF.)

Please review with whitespace changes hidden for an easier reading experience.

Remove AUIPC and LUI.

The LUI circuit is more efficient than ADDI. No register read, fewer range checks, no addition... I recommend putting it back.
You can implement AUIPC with the LUI circuit though (absolute addressing).

If you think it's worth the hassle, we can restore the LUI circuit and also compile ADDI with rs1=0 to LUI.

Indeed.


Refactor

1.	Refactoring name: Extract method.
Location: shiro\web\src\test\java\org\apache\shiro\web\servlet\SimpleCookieTest.java\Line no. 169
Explanation: The method was extracted to make the code easy to understand and the method indicates its purpose clearly.
2.	Refactoring name: Rename method.
Location: shiro\web\src\test\java\org\apache\shiro\web\filter\mgt\SimpleNamedFilterListTest.java\Line no. 52
Explanation: The original method name was not descriptive enough and did not follow the standard naming convention for test methods. The new name clearly indicates what the test is checking for.
Location: shiro\web\src\test\java\org\apache\shiro\web\RestoreSystemProperties.java\Line no. 48
Explanation: The new method name is more descriptive and follows the standard naming convention for method names.
3.	Refactoring name: Decompose conditional.
Location: shiro\samples\spring-hibernate\src\main\java\org\apache\shiro\samples\sprhib\web\SignupValidator.java\Line no. 45
Explanation: To decompose the complicated parts of the conditional into separate methods, I have create two methods:

isEmailInvalid() - This method will take in the email address as a parameter and return a boolean value indicating whether the email is invalid or not based on the provided regular expression.
hasInvalidEmail() - This method will take in the command object as a parameter and call the getEmail() method to retrieve the email address. It will then use the isEmailInvalid() method to check if the email is invalid or not and return a boolean value accordingly.

4.	Refactoring name: Extract Class
Location: shiro\web\src\main\java\org\apache\shiro\web\filter\authc\HttpMethodsExtractor.java and shiro\web\src\main\java\org\apache\shiro\web\filter\authc\HttpAuthenticationFilter.java\Line no. 205
Explanation: I have extracted the functionality for extracting HTTP methods from options into a new class called HttpMethodsExtractor. This class has a single public method extractHttpMethodsFromOptions that takes an array of options and returns a set of HTTP methods. The private method isHttpMethod is used internally by the extractHttpMethodsFromOptions method to check if an option is a valid HTTP method. In the HttpAuthenticationFilter class, I have created an instance of the HttpMethodsExtractor class and used it to extract HTTP methods from options in the
httpMethodsFromOptions method. This makes the code more modular and easier to maintain, as the functionality for extracting HTTP methods is now encapsulated in a separate class.
5.	Refactoring name: Move method.
Location: web\src\main\java\org\apache\shiro\web\filter\authc\FormAuthenticationFilter.java\Line no. 52 and 184
Explanation: By moving the isLoginSubmission method to a separate class, we have made the code more modular and improved the cohesion of the classes. Additionally, any other classes that need to check if a request is a login submission can now use the LoginUtils class, rather than duplicating the logic in their own code.
6.	Refactoring name: Replace Conditional with Polymorphism
Location: src/main/java/org/apache/shiro/crypto/support/hashes/argon2/Argon2Hash.java/Line no. 212
Explanation: The original code has a switch statement that checks the value of a string parameter and sets the type variable to a constant based on that value. Then, it creates an instance of Argon2Parameters using the value of type and executes the generateBytes method of Argon2BytesGenerator to generate a hash. Finally, it returns a new Argon2Hash object containing the hash and other parameters.
By replacing the switch statement with polymorphism, a common interface can be defined for all possible implementations of the generateHash method, which is responsible for generating the hash. Each subclass of Argon2Algorithm can implement the generateHash method according to the corresponding value of the string parameter, thus encapsulating the algorithm-specific logic in a single class. This way, new algorithms can be easily added by adding new subclasses without modifying the existing code.

Please review the changes I have made as per your request and I have also signed CLA as per your request.

Why did you reformat all the comments? Please undo that one and squash the commits.
Coding style is for 130-character columns, not 80
Thank you!

Changed all the comments from 80-character columns to 130-character columns.
Thank you!

Changed all the comments and code indentation from 80-character columns to 130-character columns.
Thank you!

Got your CLA confirmation. Thank you

Can you help me why the build failed on Mac os version?

Can you help me why the license check is failing in the third pipeline?

can you tell me why the license check is failing in the third pipeline? please help me, I will revert back the changes that you want.


Support transpiling annotated classes into both, Scala.js and native JS classes

Currently a class annotated with @Component, @NgModule, etc., will be translated into a normal Scala class. We should allow the developer to decide wether an annotated class is translated into a Scala class or a native JS class (i.e. a @ScalaJSDefinedclass).
See also #38

If a class with classModeJS extends a non-JS parent Foo, try to replace this parent type with FooJS.
Example:
trait Foo {
  def bar = "bar"
}

trait FooJS extends js.Object {
  def bar = "bar"
}

@Injectable
@classModeJS
class Bar extends Foo

will translate to:
class Bar extends FooJS


seeking help on running stable cascade in stable diffusion automatic 1111

Hi, I installed stable cascade but i am getting following two errors:

stable cascade tab is not visible on the UI, but it appears after disabling all other extension

i am getting this error: "module diffusers has no attribute StableCascadeUNet."

please help me to solve this error

who cant make it work here 1 click installer with amazing optimizations : https://github.com/Stability-AI/StableCascade/issues/125


Upgrade Lodash dependencies to latest

To fix high severity security issue in lodash.merge.
More info: https://snyk.io/blog/snyk-research-team-discovers-severe-prototype-pollution-security-vulnerabilities-affecting-all-versions-of-lodash/
Wasn't able to run the tests or the build locally (gave me errors), so maybe I can get some guidance whether this will break anything...

My fix in https://github.com/karlhorky/mailgun-js-suppression-notifications-poc/commit/bd6c9c2913b5add1d255cb0ab4ec4a66ca87a524 with Yarn resolutions seems to not cause problems. But I'm not using much of the mailgun.js API either...

cc @jessespears @jmontemayor @srph

The tests appear to be broken for all PRs, with peer dependency errors:
npm ERR! Linux 4.15.0-1028-gcp
npm ERR! argv "/home/travis/.nvm/versions/node/v4.1.2/bin/node" "/home/travis/.nvm/versions/node/v4.1.2/bin/npm" "install"
npm ERR! node v4.1.2
npm ERR! npm  v2.14.4
npm ERR! code EPEERINVALID
npm ERR! peerinvalid The package<EMAIL_ADDRESS>does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer<EMAIL_ADDRESS>wants<EMAIL_ADDRESS>|| ^3.0.0 || ^4.0.0
npm ERR! peerinvalid Peer<EMAIL_ADDRESS>wants<EMAIL_ADDRESS><3
npm ERR! peerinvalid Peer<EMAIL_ADDRESS>wants webpack@1 || 2 || ^2.1.0-beta

Also broken on my PR #47, which is a simple edit to the readme.

Dependbot flagging this since introducing Mailgun to my project recently.
That this is still an issue a year after this ticket was opened is kinda making me question my choice to go with Mailgun TBH.

It seems we don't use lodash anymore but anyway thank you for your PR.


failure in TestTransfer

See https://circleci.com/gh/weaveworks/weave/5402
--- FAIL: TestTransfer (0.06s)
	Error Trace:	allocator_test.go:361
	Error:		Not equal: 0x20 (expected)
			        != 0x40 (actual)

With
diff --git a/ipam/allocator_test.go b/ipam/allocator_test.go
index 5df6060..287e4eb 100644
--- a/ipam/allocator_test.go
+++ b/ipam/allocator_test.go
@@ -369,6 +369,12 @@ func TestTransfer(t *testing.T) {
        alloc1.Stop()
 }

+func TestTransfer1000(t *testing.T) {
+       for i := 0; i < 1000; i++ {
+               TestTransfer(t)
+       }
+}
+
 func TestFakeRouterSimple(t *testing.T) {
        const (
                cidr = "<IP_ADDRESS>/22"

and running
GO15VENDOREXPERIMENT=1 go test -v -run TestTransfer1000 ./ipam

I have managed to get
--- FAIL: TestTransfer1000 (0.27s)
	Error Trace:	allocator_test.go:361
	Error:		Not equal: 0x80 (expected)
			        != 0x100 (actual)

on my desktop.

I cannot reproduce this on 1.4; the test has changed a fair bit on master. However, the underlying cause is in fact present in 1.4, and the fix is easy, so we might as well put it there.

better fix in d3635eed77c


Level layout

Hey Jenni, Level-Layout is finished.

Closing so Level1 can be deleted since it is causing issues.


Landuse styling not working properly on islets for browser zoom >=15

Bug description
What is happening?
areas tagged as place=islet are dropping their landuse=* tagging and thus are rendering as plain earth, instead of whatever they're covered with.
see: islet tagged as landuse=wetland on the testbed:
https://www.openhistoricalmap.org/#map=16/70.0014/-42.2715&layers=O&date=1923-01-01&daterange=1923-01-01,2023-12-31

see: islet tagged as landuse=forest in Richmond, VA
https://www.openhistoricalmap.org/relation/2744271#map=20/37.54259/-77.47363&layers=O&date=2023-12-30&daterange=1700-01-01,2023-12-31

This info does seem to be coming across in the vtiles:
https://vtiles.openhistoricalmap.org/#15.51/37.537394/-77.473061

So... maybe (maybe?) it's a stylesheet thing?
What should be happening?
areas marked with place=islet should be getting rendered properly with landuse when they have a landuse=* tag

I just noticed that this works properly at browser zoom=14:

and stops working at browser zoom=15:

This is a ultimately a vector tiles issue that cannot be solved with styling alone. This issue is related to our old coastlines and water layering issues. Notably, issue #91
The basic layering in Maputnik, where we're trying to best figure out a solution given our current vector tiles, looks like this:
Background: water blue
Land
Land Use
Water polygons
Islets
Water lines
Mapbox cuts holes in all water which fully solves this problem. In this image below, you'll see an example of recursive lakes and islands in Canada where all the water has donut holes cut out of it to show bare land and land cover, etc.

That's good feedback & that is the classic example, but it doesn't explain why the styling works at some zooms and not others as shown above! Agreed that this is a conundrum.

It doesn't work at any zoom level. It appears to work at z14 because islets (and all other_areas) only show from z15 and greater. If that needs to change, then that is a vector tiles issue as well.


Text in generated PDF is not selectable

I can't select text in generated PDF. Is this deliberately, or I'm doing something wrong?

This is due to the used program with which you open a PDF. The atom pdf-package does not permit it, but if you eg. with Adobe Acrobat Reader, your text is selectable. :)

Actually, it is not. Opening in Adobe Acrobat Reader is one of the first things that I've tried. In addition, file is 14 megs in size, which is way to much. It looks like it is one big picture, not text.
Didn't mentioned previously, I'm using Atom on OSX.

Sorry, but I'm not using OSX and can not test that. Did you accidentally exported as graphics instead of PDF? ^^ The Export definitely works with selectable text.

Adobe Acrobat Reader DC 2015 Version | Version 2015.009.20077

I've just used the command from right-click menu on markdown file.
Hmm, will try on windows and will report back.

Yes, it works on Windows. Main difference between generated PDFs is that one from Windows does have embedded fonts, while one from OSX does not.
I can't debug this further, since I don't know how. If some kind of logging can be turned on, maybe that can be helpful. Again, I don't know how.

I would be interested if a PDF that you have created under Windows, behaves well in OSX.
Unfortunately, I can not alter the fact anyway. :/ The Issue would have to go to phantom.js.
https://github.com/ariya/phantomjs


Add Diol to Awesomedotnet

Is your feature request related to a problem? Please describe.
To make the extension more popular we can add the link to awesome dotnet repo.
Describe the solution you'd like
Describe alternatives you've considered
Additional context

The pr was created:
https://github.com/quozd/awesome-dotnet/pull/1175
Close the ticket when the pr will be merged


Nearly $400/month or $20/day to run this minimal test - which isn't obvious

gcloud container clusters create space-agon --cluster-version=1.12
--tags=game-server
--scopes=gke-default
--num-nodes=4
--no-enable-autoupgrade
--machine-type=n1-standard-4

The cost of one n1-normal-4 machine is nearly $100/month (with discounts), and even though it's more likely to be run briefly for a test, if you forgot to shut it down for one day that would still cost around $20 for one day (no discount). Someone not very familiar yet with the costs involved might not think twice about this.
I was recently surprised after following some of the examples for Agones/Open Match that it cost me around $40 just because I left some things running over night. I've only recently started using google cloud platform (have used EC2 more beforehand) and just assumed the demos/examples would be done on cheap configurations.
I think it could be worth warning about the cost and/or perhaps recommending a smaller, lower-end cluster for testing (--num-nodes=1 and --machine-type=n1-standard-1/2 is probably enough)

Hey, I haven't yet spent the effort on finding the right size for this project.  For now I've added a warning.
Thanks for your feedback.

Yeah, np. I just tried dropping it down to n1-normal-n2 num-nodes=1 but for reference that wasn't enough since it refused to schedule the 'dedicated' servers. Even if I droped the requested cpu resources to 100m instead of 500m that didn't seem to work either. Was just going to try n1-normal-n1 and num-nodes=3 for now.
Thanks


tsc sometimes doesn't respect "include" in tsconfig.json

TypeScript Version:  2.6.1, 2.7.0-dev.201xxxxx
Code
Unfortunately, this error disappears when I try to construct a simple self-contained test-case (most TypeScript errors I encounter work like this, which makes debugging them really weird).
But you can reproduce this with:
git clone https://github.com/Zarel/Pokemon-Showdown
cd Pokemon-Showdown
git checkout 28cb849
npm i
tsc

Expected behavior:
No errors
Actual behavior:
punishments.js(1135,10): error TS1005: '{' expected.

This is unexpected because punishments.js is explicitly not one of the files included in "include" in tsconfig.json. Even explicitly adding "exclude": ["punishments.js"] doesn't make the error disappear.
I thought maybe I was using the wrong syntax? But when I copied the tsconfig.json to a new project, suddenly the "include" setting was being respected again (this is what I mean by "this error disappears when I try to construct a simple self-contained test-case").

...never mind, I figured it out.

(On third thought, commenting out the relevant line of dev-tools/globals.ts doesn't make the error disappear, either; I'm confused again.)

The compiler picks up imports from your files, not just include/exclude, see https://github.com/Microsoft/TypeScript/wiki/FAQ#why-is-a-file-in-the-exclude-list-still-picked-up-by-the-compiler

Yes, but if I remove the import, it's still giving the same error message.

...okay, it's working now. There was a stray input elsewhere.

...I'm still unclear on what's making the error message appear. It would probably be useful to be able to ask TypeScript what file is importing the file.
I was able to discover that chat-commands is importing punishments (and removing that import suppresses that error), but not what's importing chat-commands

...I'm still unclear on what's making the error message appear. It would probably be useful to be able to ask TypeScript what file is importing the file.

use tsc --listFiles to know what files are included in your compilation, and tsc --traceResolution to know why they were included.

Thanks!