Support UTF-8 label matchers: Add compat package with feature flag and use in amtool

This pull request adds the adapter package that will allow users to switch between the new matchers/parse parser and the old pkg/labels parser. The new matchers/parse parser uses a fallback mechanism where if the input cannot be parsed in the new parser it then attempts to use the old parser. If an input is parsed in the old parser but not the new parser then a warning log is emitted.
To be reviewed after #3453, #3507 and #3523.

I was thinking of adding the actual feature flag in a follow up PR to keep this one small and easier to review @gotjosh.

Looks good! I have a few suggestions, let me know what you think.
No matter what I tried, I couldn't get the message about the Disabled new label matchers to show up. Can you give me an example command that would make the show up?
I tried:
./amtool --enable-feature="disable-new-label-matchers" --alertmanager.url=http://localhost:9093/ alert query

Ah I was using log.NewNopLogger()! 😄

@gotjosh I forgot to mention that #3507 must be merged before this PR, as the test I'm introducing in #3507 is supposed to fail on this branch! I will make this clear in both PRs.

Just rebased main to include #3507 and make test fails as expected 🥳 :
--- FAIL: TestQuerySilence (0.14s)
    cli_test.go:187:
        	Error Trace:	/Users/grobinson/go/src/github.com/prometheus/alertmanager/test/cli/acceptance/cli_test.go:187
        	Error:      	Not equal:
        	            	expected: []string{"alertname=\"{alertname=test3}\"", "severity=\"warn\""}
        	            	actual  : []string{"alertname=\"test3\"", "severity=\"warn\""}

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1,3 +1,3 @@
        	            	 ([]string) (len=2) {
        	            	- (string) (len=29) "alertname=\"{alertname=test3}\"",
        	            	+ (string) (len=17) "alertname=\"test3\"",
        	            	  (string) (len=15) "severity=\"warn\""
        	Test:       	TestQuerySilence
FAIL

Just rebased main to include #3507 and make test fails as expected 🥳 :
--- FAIL: TestQuerySilence (0.14s)
    cli_test.go:187:
        	Error Trace:	/Users/grobinson/go/src/github.com/prometheus/alertmanager/test/cli/acceptance/cli_test.go:187
        	Error:      	Not equal:
        	            	expected: []string{"alertname=\"{alertname=test3}\"", "severity=\"warn\""}
        	            	actual  : []string{"alertname=\"test3\"", "severity=\"warn\""}

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1,3 +1,3 @@
        	            	 ([]string) (len=2) {
        	            	- (string) (len=29) "alertname=\"{alertname=test3}\"",
        	            	+ (string) (len=17) "alertname=\"test3\"",
        	            	  (string) (len=15) "severity=\"warn\""
        	Test:       	TestQuerySilence
FAIL

I'll now work on making this test pass, which means adding a check for { and } to the relevant commands.

Examples of amtool:
Stable matchers parsing
Here we are creating two alerts, and their respective silences, in amtool using foo and alertname=bar baz using the stable matchers parsing feature flag (pkg/labels):
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" alert add foo
level=warn msg="Enabled stable matchers parsing"
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" alert query
level=warn msg="Enabled stable matchers parsing"
Alertname  Starts At                  Summary  State
foo        2023-09-21 10:05:49 +0100           active

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" alert add "alertname=bar baz"
level=warn msg="Enabled stable matchers parsing"
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" alert query
level=warn msg="Enabled stable matchers parsing"
Alertname  Starts At                  Summary  State
bar baz    2023-09-21 10:08:54 +0100           active

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" silence add foo --comment="silence alertname=foo"
level=warn msg="Enabled stable matchers parsing"
93ab0290-cd7a-44f7-8f22-6fcf1cd7c58e
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" silence query
level=warn msg="Enabled stable matchers parsing"
ID                                    Matchers         Ends At                  Created By  Comment
93ab0290-cd7a-44f7-8f22-6fcf1cd7c58e  alertname="foo"  2023-09-21 10:07:02 UTC  grobinson   silence alertname=foo

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" silence add "alertname=bar baz" -c="silence alertname=bar baz"
level=warn msg="Enabled stable matchers parsing"
58ae7810-6f5a-428d-be72-d4e3c6da5722
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" silence query
level=warn msg="Enabled stable matchers parsing"
ID                                    Matchers             Ends At                  Created By  Comment
58ae7810-6f5a-428d-be72-d4e3c6da5722  alertname="bar baz"  2023-09-21 10:10:09 UTC  grobinson   =silence alertname=bar baz

UTF-8 matchers parsing
Here we are creating the same alerts as above but this time using the UTF-8 matchers parsing feature flag. You'll notice that when we use "alertname=bar baz" the alerts and silences come out as alertname="alertname=bar baz" because of the heuristic that attempts to detect the first label as the alertname. This is different for the strict and fallback parsers which create the alert and silence as alertname="bar baz" instead of alertname="alertname=bar baz".
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" alert add foo
level=warn msg="Enabled UTF-8 matchers parsing"
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" alert query
level=warn msg="Enabled UTF-8 matchers parsing"
Alertname  Starts At                  Summary  State
foo        2023-09-21 10:11:34 +0100           active

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" alert add "alertname=bar baz"
level=warn msg="Enabled UTF-8 matchers parsing"
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" alert query
level=warn msg="Enabled UTF-8 matchers parsing"
Alertname          Starts At                  Summary  State
alertname=bar baz  2023-09-21 10:19:14 +0100           active

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" silence add foo -c="silence alertname=foo"
level=warn msg="Enabled UTF-8 matchers parsing"
7b5a593d-416c-4561-a5d7-a50ca71f0864
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" silence query
level=warn msg="Enabled UTF-8 matchers parsing"
ID                                    Matchers         Ends At                  Created By  Comment
7b5a593d-416c-4561-a5d7-a50ca71f0864  alertname="foo"  2023-09-21 10:20:33 UTC  grobinson   =silence alertname=foo

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" silence add "alertname=bar baz" -c="silence alertname=bar baz"
level=warn msg="Enabled UTF-8 matchers parsing"
534cc784-913e-4f5c-90ac-9d05bd127034
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" silence query
level=warn msg="Enabled UTF-8 matchers parsing"
ID                                    Matchers                       Ends At                  Created By  Comment
534cc784-913e-4f5c-90ac-9d05bd127034  alertname="alertname=bar baz"  2023-09-21 10:21:11 UTC  grobinson   =silence alertname=foo

Fallback
Here we are creating the same alerts as above but this time using the fallback parser (i.e. the default). The error message comes out twice because amtool parses the invalid input twice. I'm not sure if this is an issue or not.
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 alert add foo
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 alert query
Alertname  Starts At                  Summary  State
foo        2023-09-21 10:27:11 +0100           active

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 alert add "alertname=bar baz"
level=warn msg="Alertmanager is moving to a new parser for label matchers, and this input is incompatible. Alertmanager has instead parsed the input using the old matchers parser as a fallback. To make this input compatible with the new parser please make sure all regular expressions and values are double-quoted. If you are still seeing this message please open an issue." input="alertname=bar baz" err="14:17: unexpected bar: expected a comma or close brace" suggestion="alertname=\"bar baz\""
level=warn msg="Alertmanager is moving to a new parser for label matchers, and this input is incompatible. Alertmanager has instead parsed the input using the old matchers parser as a fallback. To make this input compatible with the new parser please make sure all regular expressions and values are double-quoted. If you are still seeing this message please open an issue." input="alertname=bar baz" err="14:17: unexpected bar: expected a comma or close brace" suggestion="alertname=\"bar baz\""
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 alert query
Alertname  Starts At                  Summary  State
bar baz    2023-09-21 10:27:37 +0100           active

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 silence add foo -c="silence alertname=foo"
cbe74cb0-0c57-4317-9955-a1130b45fb5b
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 silence query
ID                                    Matchers         Ends At                  Created By  Comment
cbe74cb0-0c57-4317-9955-a1130b45fb5b  alertname="foo"  2023-09-21 10:32:28 UTC  grobinson   =silence alertname=foo

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 silence add "alertname=bar baz" -c="silence alertname=bar baz"
level=warn msg="Alertmanager is moving to a new parser for label matchers, and this input is incompatible. Alertmanager has instead parsed the input using the old matchers parser as a fallback. To make this input compatible with the new parser please make sure all regular expressions and values are double-quoted. If you are still seeing this message please open an issue." input="alertname=bar baz" err="14:17: unexpected baz: expected a comma or close brace" suggestion="alertname=\"bar baz\""
level=warn msg="Alertmanager is moving to a new parser for label matchers, and this input is incompatible. Alertmanager has instead parsed the input using the old matchers parser as a fallback. To make this input compatible with the new parser please make sure all regular expressions and values are double-quoted. If you are still seeing this message please open an issue." input="alertname=bar baz" err="14:17: unexpected baz: expected a comma or close brace" suggestion="alertname=\"bar baz\""
74f79844-e087-4667-b1f0-8128df37f283
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 silence query
ID                                    Matchers             Ends At                  Created By  Comment
74f79844-e087-4667-b1f0-8128df37f283  alertname="bar baz"  2023-09-21 10:33:30 UTC  grobinson   =silence alertname=bar baz

Examples of amtool:
Stable matchers parsing
Here we are creating two alerts, and their respective silences, in amtool using foo and alertname=bar baz using the stable matchers parsing feature flag (pkg/labels):
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" alert add foo
level=warn msg="Enabled stable matchers parsing"
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" alert query
level=warn msg="Enabled stable matchers parsing"
Alertname  Starts At                  Summary  State
foo        2023-09-21 10:05:49 +0100           active

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" alert add "alertname=bar baz"
level=warn msg="Enabled stable matchers parsing"
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" alert query
level=warn msg="Enabled stable matchers parsing"
Alertname  Starts At                  Summary  State
bar baz    2023-09-21 10:08:54 +0100           active

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" silence add foo --comment="silence alertname=foo"
level=warn msg="Enabled stable matchers parsing"
93ab0290-cd7a-44f7-8f22-6fcf1cd7c58e
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" silence query
level=warn msg="Enabled stable matchers parsing"
ID                                    Matchers         Ends At                  Created By  Comment
93ab0290-cd7a-44f7-8f22-6fcf1cd7c58e  alertname="foo"  2023-09-21 10:07:02 UTC  grobinson   silence alertname=foo

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" silence add "alertname=bar baz" -c="silence alertname=bar baz"
level=warn msg="Enabled stable matchers parsing"
58ae7810-6f5a-428d-be72-d4e3c6da5722
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="stable-matchers-parsing" silence query
level=warn msg="Enabled stable matchers parsing"
ID                                    Matchers             Ends At                  Created By  Comment
58ae7810-6f5a-428d-be72-d4e3c6da5722  alertname="bar baz"  2023-09-21 10:10:09 UTC  grobinson   =silence alertname=bar baz

UTF-8 matchers parsing
Here we are creating the same alerts as above but this time using the UTF-8 matchers parsing feature flag. You'll notice that when we use "alertname=bar baz" the alerts and silences come out as alertname="alertname=bar baz" because of the heuristic that attempts to detect the first label as the alertname. This is different for the strict and fallback parsers which create the alert and silence as alertname="bar baz" instead of alertname="alertname=bar baz".
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" alert add foo
level=warn msg="Enabled UTF-8 matchers parsing"
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" alert query
level=warn msg="Enabled UTF-8 matchers parsing"
Alertname  Starts At                  Summary  State
foo        2023-09-21 10:11:34 +0100           active

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" alert add "alertname=bar baz"
level=warn msg="Enabled UTF-8 matchers parsing"
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" alert query
level=warn msg="Enabled UTF-8 matchers parsing"
Alertname          Starts At                  Summary  State
alertname=bar baz  2023-09-21 10:19:14 +0100           active

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" silence add foo -c="silence alertname=foo"
level=warn msg="Enabled UTF-8 matchers parsing"
7b5a593d-416c-4561-a5d7-a50ca71f0864
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" silence query
level=warn msg="Enabled UTF-8 matchers parsing"
ID                                    Matchers         Ends At                  Created By  Comment
7b5a593d-416c-4561-a5d7-a50ca71f0864  alertname="foo"  2023-09-21 10:20:33 UTC  grobinson   =silence alertname=foo

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" silence add "alertname=bar baz" -c="silence alertname=bar baz"
level=warn msg="Enabled UTF-8 matchers parsing"
534cc784-913e-4f5c-90ac-9d05bd127034
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 --enable-feature="utf8-matchers-parsing" silence query
level=warn msg="Enabled UTF-8 matchers parsing"
ID                                    Matchers                       Ends At                  Created By  Comment
534cc784-913e-4f5c-90ac-9d05bd127034  alertname="alertname=bar baz"  2023-09-21 10:21:11 UTC  grobinson   =silence alertname=foo

Fallback
Here we are creating the same alerts as above but this time using the fallback parser (i.e. the default). The error message comes out twice because amtool parses the invalid input twice. I'm not sure if this is an issue or not.
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 alert add foo
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 alert query
Alertname  Starts At                  Summary  State
foo        2023-09-21 10:27:11 +0100           active

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 alert add "alertname=bar baz"
level=warn msg="Alertmanager is moving to a new parser for label matchers, and this input is incompatible. Alertmanager has instead parsed the input using the old matchers parser as a fallback. To make this input compatible with the new parser please make sure all regular expressions and values are double-quoted. If you are still seeing this message please open an issue." input="alertname=bar baz" err="14:17: unexpected bar: expected a comma or close brace" suggestion="alertname=\"bar baz\""
level=warn msg="Alertmanager is moving to a new parser for label matchers, and this input is incompatible. Alertmanager has instead parsed the input using the old matchers parser as a fallback. To make this input compatible with the new parser please make sure all regular expressions and values are double-quoted. If you are still seeing this message please open an issue." input="alertname=bar baz" err="14:17: unexpected bar: expected a comma or close brace" suggestion="alertname=\"bar baz\""
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 alert query
Alertname  Starts At                  Summary  State
bar baz    2023-09-21 10:27:37 +0100           active

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 silence add foo -c="silence alertname=foo"
cbe74cb0-0c57-4317-9955-a1130b45fb5b
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 silence query
ID                                    Matchers         Ends At                  Created By  Comment
cbe74cb0-0c57-4317-9955-a1130b45fb5b  alertname="foo"  2023-09-21 10:32:28 UTC  grobinson   =silence alertname=foo

./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 silence add "alertname=bar baz" -c="silence alertname=bar baz"
level=warn msg="Alertmanager is moving to a new parser for label matchers, and this input is incompatible. Alertmanager has instead parsed the input using the old matchers parser as a fallback. To make this input compatible with the new parser please make sure all regular expressions and values are double-quoted. If you are still seeing this message please open an issue." input="alertname=bar baz" err="14:17: unexpected baz: expected a comma or close brace" suggestion="alertname=\"bar baz\""
level=warn msg="Alertmanager is moving to a new parser for label matchers, and this input is incompatible. Alertmanager has instead parsed the input using the old matchers parser as a fallback. To make this input compatible with the new parser please make sure all regular expressions and values are double-quoted. If you are still seeing this message please open an issue." input="alertname=bar baz" err="14:17: unexpected baz: expected a comma or close brace" suggestion="alertname=\"bar baz\""
74f79844-e087-4667-b1f0-8128df37f283
./amtool --alertmanager.url=http://<IP_ADDRESS>:9093 silence query
ID                                    Matchers             Ends At                  Created By  Comment
74f79844-e087-4667-b1f0-8128df37f283  alertname="bar baz"  2023-09-21 10:33:30 UTC  grobinson   =silence alertname=bar baz

I had to force push to fix the conflict in cli/utils.go.


Allow using briefs where the user is not active

We have been running out of closed briefs with responses, partly because we limit ourselves to briefs where the user is active; this restriction is not necessary however. This commit adds a method ensure_user_can_log_in that activates deactivated users, and we use this in the "log in as user with brief with brief responses" step.

:thinking:
The problem we really have here is that we're not able to do proper queries to find a usable case - we're restricted to the API. Instead of being able to ask "Give me a brief that's in state x and whose user is active" we do "Pick the first brief you find in state x and check if the user's active and oh if it isn't then - whoops - fail". We could do something a little like a proper query if we made the requests "backtrack" and try the next brief if this one's not appropriate. i.e. put it in a loop.
It would be nice if we could make the routine at least explore these avenues a bit further before it resorts to mutating the database...

@risicle I did consider creating a loop, however that would probably result in the functional test run time exploding, and not solve the issue as we have a lot of inactive users. I don't see a way around that without mutating the database.

Could it not limit itself to e.g. 5 attempts? If we really had that many inactive users, our tests would fail almost every time, because currently they give up on the first try. But they don't.

Also, I'm suggesting mutating the database as a last resort.

Could it not limit itself to e.g. 5 attempts? If we really had that many inactive users, our tests would fail almost every time, because currently they give up on the first try. But they don't.

You're right, it's not as bad as I feared

Closing in favour of #689


Dynamically load chapter data on each chapters page

Ideally we would have chapters input their own information into the database. At this point, we would use javascript to pull that data from the database and display it on the chapter page.
For example, if we have a line that would show who the current president is, it would say "President: John Doe", assuming the name of the president is John Doe, or "President: N/A" if the name of president was not yet provided by the chapter

We could probably use a Django template for this
https://www.youtube.com/watch?app=desktop&v=30Lt8qkcV4Q


Add support for I2C PCF8574

https://www.nxp.com/docs/en/data-sheet/PCF8574_PCF8574A.pdf

Luma.core v1.16.1 has support for the pcf8574.  However, you still need a display driver that supports the specific display you are attempting to use.  There is an hd44780 driver that is close to release in the luma.lcd project that does work with the luma.core.interface.serial.pcf8574 class.
Which device do you want to attach the pcf8574 to?

I don't remember but I have 2 lcd displays, LCD2004 and LCD1602, both uses the hd44780 driver.

LCD2004 and LCD1602

I also have an I2C PCF8574 and these displays available to test this.

The luma.lcd.device.hd44780 class in the current PR for luma.lcd does support the hd44780 using the luma.core.interface.serial.PCF8574 class.  So it should work for both your LCD2004 and LCD1602.  I have a 2004 display running the code as I am typing this.

I don't see the class luma.lcd.driver.hd44780, where is it?
I have tried a year ago and I have not gotten it to work for me.

It hasn't been approved yet but if you want to try it out, it is in luma.lcd branch hd44780.

In this branch: https://github.com/dhrone/luma.lcd/tree/hd44780
Any example?

Make sure you have luma.core v1.16.1 loaded.  pcf8574 is lowercase.
Example:
from luma.core.interface.serial import parallel, pcf8574
from luma.lcd.device import hd44780
interface = pcf8574(address=0x27, backlight_enabled=True)
device = hd44780(interface, width=16, height=2)
device.text = 'Hello'

You also need to make sure that you have the wiring between the pcf8574 and the hd44780 set correctly.  I just noticed that the pcf8574 class documentation markup mangled the description of how you deal with different wiring between the pcf8574 and the HD44780.  Here's a cleaner version...

   Default wiring is...
   RS - Register Select
   E - Enable
   RW - Read/Write (note: unused by this driver)
   D4-D7 - The upper data pins

   :          RS  RW   E   D4  D5  D6  D7  BACKLIGHT
   Display     4   5   6   11  12  13  14
   Backpack   P0  P1  P2   P4  P5  P6  P7         P3

   If your PCF8574 is wired up differently to this you will need to provide
   the correct values for the RS, E, COMMAND, BACKLIGHT parameters.
   RS, E and BACKLIGHT are set to the pin numbers of the backpack pins
   they are connect to from P0-P7.  COMMAND is set to 'high' if the
   Register Select (RS) pin needs to be high to inform the device that a
   command byte is being sent or 'low' if RS low is used for commands.
   PINS is a list of the pin positions that match where the devices data
   pins have been connected on the backpack (P0-P7).  For many devices this
   will be d4->P4, d5->P5, d6->P6, and d7->P7 ([4, 5, 6, 7]) which is the
   default.

   Example:
   If your data lines D4-D7 are connected to the PCF8574s pins P0-P3 with
   the RS pin connected to P4, the enable pin to P5, the backlight pin
   connected to P7, and the RS value to indicate command is low, your
   initialization would look something like...

   pcf8574(port=1, address=0x27, PINS=[0,1,2,3], RS=0x10, E=0x20,
   COMMAND='low', BACKLIGHT=0x40)

   Explanation:
   PINS are set to [0, 1, 2, 3] which assigns P0 to D4, P1 to D5, P2 to D6,
   and P3 to D7.  RS is set to 4 to associate with P4. Similarly E is set
   to 5 to associate E with P5.  BACKLIGHT set to 7 connects it to pin P7
   of the backpack.  COMMAND is set to 'low' so that RS will be set to low
   when a command is sent and high when data is sent.

Yeah! works fine, but when I run the script again receive this error:
luma/lcd/device.py:76: RuntimeWarning: This channel is already in use, continuing anyway.  Use GPIO.setwarnings(False) to disable warnings.
self._gpio.setup(self._pin, self._gpio.OUT)

That warning happens when the RPi.GPIO module is not cleaned up at the end of the program.   There was a small bug my code that allocated one of the GPIO pins even when the PCF8574 was going to be responsible for the backlight.  I believe I've eliminated it but it would be great if you could pull the latest and give it another run or three to see if the warning goes away.

Works fine! good job!!
The backlight stays on after the script ends, I need add the line: device.backlight(False) at end of script.

You need to add that but will also need to send some command or data to the display.  So..
device.backlight(False)
device.show()

The reason for this has to do with how the PCF8574 works.  Each pin from the pcf8574 is attached to the display and the driver controls the display by sending values that cause the appropriate pins to be low or high.  When you call `backlight(False)' you are changing the value for that pin that will be sent inside future bytes but not actually causing the pin to change value.  That will not happen until you send something (anything) to the display.

Yeah! works fine

What code are you using @satiromarra? I have the same i2c backpack and 16x2 display and no text is showing up.

Oh ffs, I had to add a time.sleep at the end of the program. I expected the display to retain the content that was written to it after the pyhon script exited but alas, no. Final test script:
import time

from luma.core.interface.serial import pcf8574
from luma.lcd.device import hd44780

interface = pcf8574(address=0x27, backlight_enabled=True)
device = hd44780(interface, width=16, height=2)
device.text = "Hello world"

time.sleep(20000)

Awesome!

@dhrone can you take a look at documenting the i2c backpack usage in the docs?

Which device do you want to attach the pcf8574 to?

Does this imply other displays can be connected to this "backpack"? Didn't know that.. Which ones?

@thijstriemstra I used 2 displays in the same PCF8574, 20x4 and 16x2; my i2c address is 0x3F
When the script finishes the lcd screen is empty.
I hope helped you.
the code:
#!/usr/bin/env python3

import time
import subprocess
from datetime import datetime
from luma.core.interface.serial import parallel, pcf8574
from luma.lcd.device import hd44780

interface = pcf8574(address=0x3F, backlight_enabled=True)
device = hd44780(interface, width=20, height=4)
# device = hd44780(interface, width=16, height=2)

while (True):
    CurDate = datetime.now().strftime('%m/%d/%y %H:%M:%S')

    cmd = "df -h | awk '$NF==\"/\"{printf \"Disk: %d/%d GB  %s\", $3,$2,$5}'"
    Disk = subprocess.check_output(cmd, shell=True).decode("utf-8").strip()

    cmd = "free -m | awk 'NR==2{printf \"Mem: %s/%s MB %.2f%%\", $3,$2,$3*100/$2 }'"
    MemUsage = subprocess.check_output(cmd, shell=True).decode("utf-8").strip()

    cmd = "top -bn1 | grep load | grep -v grep | sed 's/,/./g' | awk '{printf \"CPU Load: %.2f \", $(NF-2)}'"
    CPU = subprocess.check_output(cmd, shell=True).decode("utf-8").strip()

    device.text = '\n'.join([CurDate, Disk, CPU, MemUsage])
    time.sleep(1)

try:
    demo()
except KeyboardInterrupt:
    pass

device.backlight(False)
device.show()

thanks @satiromarra. You should upgrade luma.core (sudo -H pip3 install -U luma.core) and adjust this import:
from luma.core.interface.serial import parallel, pcf8574

and remove the parallel import.

luma.core updated: Successfully installed luma.core-1.16.2
I tried again and works fine (and removed parallel import).

Closing ticket since it's fixed on master, available in next release.


Cargo should NOT package everything from the crate directory

Hello,
While I was figuring out why my project will not publish on crates.io because of maximum size, I noticed cargo added everything inside the project directory. This is not such a good idea, since for example Idea IDE has some xml files inside, which I have in .gitignore but are being added to the crate. Also I figured out the reason of the maximum file size limit exceeded was I forgot to delete a test LOG file which had ~200MB and was being uploaded with the crate. This also should not happen. The file was not in .gitignore, but was not commited in git.
I think the cargo should uphold files in .gitignore and extend it by common file formats that should not be in a crate - .log, .mp4 ... But this could have some downsides.

Thanks for the report @lunemec! The nightly version of Cargo will error to publish by default if there are any untracked or dirty files in the working tree when a cargo publish is performed, and Cargo should use gitignore by default.
Perhaps you could try out nightly Cargo and see if the default ignore settings are suitable?

Also note that package.include and package.exclude are available for fine-grained configuration in Cargo itself.

Thank you for the information, I'll try the nightly version.

Awesome, it works as expected:
error: 7 dirty files found in the working directory:

.idea/encodings.xml
.idea/misc.xml
.idea/modules.xml
.idea/rust-http-logger.iml
.idea/vcs.xml
.idea/workspace.xml
js.log

Thanks!


Bug while loading t5 base model

I am trying to load t5 base model as per t5_ppo config. Strangely this error pops out. Works fine for t5-small.
	size mismatch for decoder.final_layer_norm.weight: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([768]).
	size mismatch for lm_head.weight: copying a param with shape torch.Size([32128, 512]) from checkpoint, the shape in current model is torch.Size([32128, 768]).

I got the same error, any workarounds?

RuntimeError: Error(s) in loading state_dict for T5ForConditionalGeneration:
size mismatch for shared.weight: copying a param with shape torch.Size([32100, 768]) from checkpoint, the shape in current model is torch.Size([32128, 768]).
size mismatch for encoder.embed_tokens.weight: copying a param with shape torch.Size([32100, 768]) from checkpoint, the shape in current model is torch.Size([32128, 768]).
size mismatch for decoder.embed_tokens.weight: copying a param with shape torch.Size([32100, 768]) from checkpoint, the shape in current model is torch.Size([32128, 768]).
size mismatch for lm_head.weight: copying a param with shape torch.Size([32100, 768]) from checkpoint, the shape in current model is torch.Size([32128, 768]).


fix overlap_rate data type

Description
Fixes wrong data type in text chunking processor algorithm. Currently the overlap_rate parameter for the fixed token length algorithm is wrong. It is a String when it should be a Float
https://opensearch.org/docs/latest/ingest-pipelines/processors/text-chunking/#fixed-token-length-algorithm
Issues Resolved
#7044
Checklist

[ x] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Thanks, @IanMenendez ! @gaobinlong , @heemin32 , can you please confirm the technical accuracy? Thanks.


lzw decompression

This is needed both for GIF decoding and Content-Encoding: compress.

It looks like there are enough variants of LZW that writing one implementation that can be used for compress'd data, GIFs, PDF, etc may be tricky.

Did notice you'd assigned yourself this. I worked a bit on this back when I was setting up the GIF stuff, but I don't recall what state it's in.
My plan back then was that archive/lzw would just be plain lzw but with support for either being big-endian or little-endian, and then just make sure that there is a method for the GIF-encoder/decoder to be able to handle the control commands and e.g. reset the dictionary or whatever else needs doing.

Oh, I didn't realize you already had some code written. I'll let you finish this one, and I'll do zstd in the meantime.


Fallback to Basic authentication when keycloak URL is not defined

@barreiro this is failing because of the TS linter:
src/Login.tsx
Line 7:21:   'STORE_PROFILE' is defined but never used  @typescript-eslint/no-unused-vars
Line 9:8:    'error' is defined but never used          @typescript-eslint/no-unused-vars
Line 45:35:  Forbidden non-null assertion               @typescript-eslint/no-non-null-assertion

in src/Login.tsx in horreum-web, STORE_PROFILE' and error need to be removed as imports and it is complaining about the non-null assertion in [username!] line 45


Update JAXB dependencies for JDK 11.

I'm not sure if this is something you want, but when I was playing around with your tutorial, I faced some issues with JAXB because of the way Oracle has been packaging dependencies. A quick google resolved this for me. If this is useful to you, I thought I'd share.

This project is a seed with minimal dependencies. Please add or upgrade these dependencies depending on usage.


Very slow processing of ISO 10303-2 to XML

Took nearly 1 hour to generate the XML files. Some profiling will be necessary.
The document is at:
https://github.com/metanorma/iso-10303-2/

Profiling of combined XML and ISO processing of this file:
145 mins total, 2h25

80 min was spent on Asciidoc processing, 65 min was spent on XML processing
39 min, was fetching bibliographic references. This is meant to go away with local caching, but the local caches need a lot of updating as the processing changes.

Of that, 26 min was RelatoinIso::IsoBibliography::isobib_results_filter (screen scraping), and 12 min was RelatoinIso::IsoBibliography::isobib_search_filter

38 min was spent on Asciidoc XML post processing. 37 min of that was spent on smartquotes cleanup, and almost all of that on uninterrupted_quotes_around_xml (which moves commas inside tags, to prevent bad rendering later); that was a recent addition. All the time is spent on the searching and not the manipulation: it is a complex search expression.

The main thing to do then is to change the XML Path in uninterrupted_quotes_around_xml, to make it based on Nokogiri traverse instead. (This is already done for smart quotes, and is much more efficient than text search in XPath.)
Any optimisation of Relaton is welcome.

105 mins, 1h45

80 > 36 min was spent on Asciidoc processing, 65 > 33 min was spent on XML processing
38 > 34 min was spent on Asciidoc XML post processing. 37 > 33 min is spent inside of uninterrupted_quotes_around_xml still.

So the switch to traverse was not enough.

37 mins

80 > 36 > 3 mins was spent on Asciidoc processing, 65 > 33 min was spent on XML processing

Add
Relaton::Db#fetch_async: https://github.com/relaton/relaton#fetch-document-by-references

Not yet ready:
./spec/asciidoctor/refs_spec.rb:718 # Asciidoctor::Standoc processes dated ISO reference and joint ISO/IEC references
This test retrieves:
        * [[[iso123,ISO/IEC TR 12382:1992]]] _Standard_
        * [[[iso124,ISO 124:2014]]] _Standard_
        * [[[iso125,(1)ISO/IEC TR 12382:1992]]] _Standard_
        * [[[iso126,(1)ISO 124:2014]]] _Standard_

When the VCR cache of HTTP requests is empty, the test is successful. When the VCR cache is populated (so that HTTP requests are instantaneous), I believe that the simultaneous requests for the same HTTP resource are still having race conditions: either the first pair of HTTP requests return not_found, or else all four return not_found.

./spec/asciidoctor/refs_spec.rb:718 # overrides normative status of bibliographies
This retrieves the same reference in two different reference sections:
      [bibliography,normative=false]
      == Normative References

      * [[[iso123,ISO 123]]] _Standard_

      [bibliography,normative=true]
      == Bibliography

      * [[[iso124,(1)ISO 123]]] _Standard_

The queues for both are filled, yet for some reason the second queue never gets back to the main thread as having the right number of elements.
I've left the debugging messages in there so you can see, @andrew2net

The second test is passing. But:
./spec/asciidoctor/refs_spec.rb:718 # Asciidoctor::Standoc processes dated ISO reference and joint ISO/IEC references
is still failing, intermittently. Sometimes the duplicate references are fetching correctly, sometimes they are not, and the duplicate is being treated as if it is not present online.


Switch options.query.id to options.id in link-by-id

:eyeglasses: @curioussavage

:fish:

https://github.com/reddit/snoode/commit/b2837b85e9289861c242814088fd532163364d01


Native Interactive - Clear All doesn't clear cells

Environment data

VS Code version: 1.58.0-insider
Jupyter Extension version: v2021.8.1003809038
Python Extension version: v2021.7.992362372-dev
OS (Windows | Mac | Linux distro) and version: OSX 11.4
Python and/or Anaconda version: 3.9.5
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): poetry env
Jupyter server running: Local | Remote | local

Expected behaviour
jupyter.interactive.clearAllCells deletes all cells in the current native jupyter interactive window
Actual behaviour
Nothing happens, wether run with keyboard shortcut or from command palette
Steps to reproduce:

cmd + shift + p > "clear all..."
press enter
cells not cleared

PS Native interactive looking 👌🏻👌🏻👌🏻 - excited to see how it progresses!
Logs

Output for Jupyter in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Jupyter)

XXX

Oops, that'll be because the current implementation assumes the command is being invoked with context from the interactive/toolbar menu. Should be a straightforward fix.

@joyceerhl thanks for the fix, working as expected now.
Side question... is there an explicit when-context for when the interactive window has focus similar to editorTextFocus?
jupyter.ownsSelection doesn't seem to work. Something like jupyter.interactive.hasFocus?
Is there anywhere that all the when-contexts are documented? Thanks!

I also played around with these editor contexts:
https://github.com/microsoft/vscode-jupyter/blob/d06d8d8b0c2e8d7db45fcb6dc4434cdb313e6271/src/client/datascience/constants.ts#L190
But not sure if they can be used for keyboard shortcuts... didn't seem to work anyways.

You might try notebookType == interactive?

There's no documentation for Jupyter when clauses at the moment--any Jupyter when clauses currently in use will appear in our package.json but there's no description for what they mean. It sounds like having extension-level documentation for these might be helpful to you?

@joyceerhl yes jupyter-specific documentation on the when clauses would probably help, thank you!

Validated + opened https://github.com/microsoft/vscode/issues/128166 this as you have to have selection in specific areas for it to work.


Check nodes/BMHs in IP-reuse e2e test

What steps did you take and what happened:
Currently the e2e test for IP-reuse is just checking the IPPool, not the nodes or BMHs.
What did you expect to happen:
We should extend the test to actually make sure that the IPAddresses are used, not just allocated in the IPPool. This may require a bit more changes to the tests actually, because I think we are currently only setting them in the metadata, not really using them in the networkdata.
Anything else you would like to add:
/kind feature

/triage accepted

/remove-lifecycle stale

/remove-lifecycle stale

/lifecycle frozen


cordova-firebasex-cli version plugin

Hi,
I used below plugins for ios platform. I am not getting notification for the subscribed topics,
I placed google service info.plist in root directory.
cordova-admobsdk 7.49.0 "Google Mobile Ads SDK for Cordova"
cordova-plugin-admobpro 2.49.0 "AdMob Plugin Pro"
cordova-plugin-androidx-adapter 1.1.3 "cordova-plugin-androidx-adapter"
cordova-plugin-androidx 2.0.0 "cordova-plugin-androidx"
cordova-plugin-badge 0.8.8 "Badge"
cordova-plugin-cocoapod-support 1.6.2 "Cordova CocoaPods Dependency Support"
cordova-plugin-device 2.0.3 "Device"
cordova-plugin-enable-multidex 0.2.0 "Enable Multidex"
cordova-plugin-extension 1.5.4 "Cordova Plugin Extension"
cordova-plugin-firebasex 10.0.0-cli "Google Firebase Plugin"
cordova-plugin-inappbrowser 4.1.0 "InAppBrowser"
cordova-plugin-ionic-webview 5.0.0 "cordova-plugin-ionic-webview"
cordova-plugin-market 1.2.0 "Market"
cordova-plugin-network-information 2.0.2 "Network Information"
cordova-plugin-splashscreen 6.0.0 "Splashscreen"
cordova-plugin-sqlite-2 1.0.6 "SQLitePlugin"
cordova-plugin-whitelist 1.3.4 "Whitelist"
cordova-plugin-x-socialsharing 6.0.2 "SocialSharing"
es6-promise-plugin 4.2.2 "Promise"
Notfication is not received. Is there any thing required to install? What was the mistake?

I have same problem, it works fine with v11.0.3 but not with v11.0.3-cli


Fix:s3 List Object response:delimiter

Fix:s3 List Object delimiter in response
https://github.com/localstack/localstack/issues/2859

Coverage decreased (-0.3%) to 94.142% when pulling ace221be9d590e2d8cc7e4413321077792138c03 on usmangani1:LISSUE_2859 into 0a89f9d1dfc3dacea3791533fbc27b7d08a276e9 on spulec:master.

Coverage decreased (-0.3%) to 94.142% when pulling ace221be9d590e2d8cc7e4413321077792138c03 on usmangani1:LISSUE_2859 into 0a89f9d1dfc3dacea3791533fbc27b7d08a276e9 on spulec:master.


Develop Request creation component with multiple templates

This should be heavily influenced by the outcome of:

#55
#54
#61


Implement flutter app example

Codecov Report

Merging #37 (7a06aa4) into dev (a57ddae) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               dev       #37   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           19        12    -7
  Lines          268       187   -81
=========================================
- Hits           268       187   -81

Impacted Files
Coverage Δ

...ogger/lib/src/settings/talker_logger_settings.dart

packages/talker_logger/lib/src/talker_logger.dart

...ib/src/utils/formater/colored_logger_formater.dart

...ges/talker_logger/lib/src/utils/console_utils.dart

...ker_logger/lib/src/models/log_level/log_level.dart

...logger/lib/src/models/log_details/log_details.dart

...r/lib/src/utils/filter/loglevel_logger_filter.dart

Continue to review full report at Codecov.

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


fatal error: concurrent map iteration and map write

Please use the following questions as a guideline to help me answer
your issue/question without further inquiry. Thank you.
Which version of Elastic are you using?
[ *] elastic.v7 (for Elasticsearch 7.x)
[ ] elastic.v6 (for Elasticsearch 6.x)
[ ] elastic.v5 (for Elasticsearch 5.x)
[ ] elastic.v3 (for Elasticsearch 2.x)
[ ] elastic.v2 (for Elasticsearch 1.x)
Please describe the expected behavior
goroutine 38 [running]:
31 runtime.throw(0xb9188c, 0x26)
30   /usr/local/go/src/runtime/panic.go:1116 +0x72 fp=0xc00036b868 sp=0xc00036b838 pc=0x437772
29 runtime.mapiternext(0xc0012ec4e0)
28   /usr/local/go/src/runtime/map.go:853 +0x554 fp=0xc00036b8e8 sp=0xc00036b868 pc=0x412514
27 runtime.mapiterinit(0xaaf1a0, 0xc000729b90, 0xc0012ec4e0)
26   /usr/local/go/src/runtime/map.go:843 +0x1c5 fp=0xc00036b908 sp=0xc00036b8e8 pc=0x411ec5
25 reflect.mapiterinit(0xaaf1a0, 0xc000729b90, 0x0)
24   /usr/local/go/src/runtime/map.go:1331 +0x54 fp=0xc00036b938 sp=0xc00036b908 pc=0x466a94
23 reflect.Value.MapKeys(0xaaf1a0, 0xc000e174e0, 0x95, 0x0, 0x0, 0x0)
22   /usr/local/go/src/reflect/value.go:1215 +0xc7 fp=0xc00036b9c8 sp=0xc00036b938 pc=0x4c90e7
21 encoding/json.mapEncoder.encode(0xba4270, 0xc00058a100, 0xaaf1a0, 0xc000e174e0, 0x95, 0x100)
20   /usr/local/go/src/encoding/json/encode.go:785 +0xff fp=0xc00036bb40 sp=0xc00036b9c8 pc=0x66637f
19 encoding/json.mapEncoder.encode-fm(0xc00058a100, 0xaaf1a0, 0xc000e174e0, 0x95, 0x100)
18   /usr/local/go/src/encoding/json/encode.go:777 +0x65 fp=0xc00036bb80 sp=0xc00036bb40 pc=0x6720a5
17 encoding/json.structEncoder.encode(0xc000226900, 0x3, 0x4, 0xc000294f30, 0xc00058a100, 0xaf49e0, 0xc000e174d0, 0x99, 0xaf0100)
16   /usr/local/go/src/encoding/json/encode.go:759 +0x2ab fp=0xc00036bc18 sp=0xc00036bb80 pc=0x66602b
15 encoding/json.structEncoder.encode-fm(0xc00058a100, 0xaf49e0, 0xc000e174d0, 0x99, 0xff0100)
14   /usr/local/go/src/encoding/json/encode.go:730 +0x7f fp=0xc00036bc70 sp=0xc00036bc18 pc=0x67201f
13 encoding/json.(*encodeState).reflectValue(0xc00058a100, 0xaf49e0, 0xc000e174d0, 0x99, 0xc000360100)
12   /usr/local/go/src/encoding/json/encode.go:358 +0x82 fp=0xc00036bca8 sp=0xc00036bc70 pc=0x663722
11 encoding/json.(*encodeState).marshal(0xc00058a100, 0xaf49e0, 0xc000e174d0, 0x100, 0x0, 0x0)
10   /usr/local/go/src/encoding/json/encode.go:330 +0xf4 fp=0xc00036bd08 sp=0xc00036bca8 pc=0x663314
9 encoding/json.Marshal(0xaf49e0, 0xc000e174d0, 0x30, 0xc000123500, 0x30, 0x0, 0x0)
8   /usr/local/go/src/encoding/json/encode.go:161 +0x52 fp=0xc00036bd80 sp=0xc00036bd08 pc=0x662952
7 github.com/olivere/elastic/v7.(*BulkIndexRequest).Source(0xc00007f260, 0xc00036bee0, 0x2, 0x0, 0x1, 0x1)
6   /home/xxx/golang/pkg/mod/github.com/olivere/elastic/v7@v7.0.23/bulk_index_request.go:240 +0x39a fp=0xc00036be68 sp=0xc00036bd80 pc=0x7ddd3a
5 github.com/olivere/elastic/v7.(*bulkWorker).work(0xc000296d00, 0xc34fc0, 0xc000124000)
4   /home/xxx/golang/pkg/mod/github.com/olivere/elastic/v7@v7.0.23/bulk_processor.go:484 +0x46b fp=0xc00036bfc8 sp=0xc00036be68 pc=0x7e138b
3 runtime.goexit()
2   /usr/local/go/src/runtime/asm_amd64.s:1374 +0x1 fp=0xc00036bfd0 sp=0xc00036bfc8 pc=0x46cc01
1 created by github.com/olivere/elastic/v7.(*BulkProcessor).Start
0   /home/xxx/golang/pkg/mod/github.com/olivere/elastic/v7@v7.0.23/bulk_processor.go:336 +0x1ce

It seems like the map you're passing on to the library is being modified concurrently somewhere inside your library. Make sure to pass a copy of the map, or protect the map accordingly.

I read data from channel. All code shows below:

That's the consumer side. Can you also post the code on the provider side?
You can also simplify the code to a simple for range loop, like:
for data := range esChan {
  ...
}

Make sure that your code will even run if the bulk processor yields an error when started. In the above snippet, you simply log the error, but continue anyway.
I wouldn't expect a big performance gain when a bulk processor like above.
I've posted a few recipes on working with bulk processor and (if you need more control) the Bulk API in general that you might find valuable.

the producer code:


[On page enter][Not blocking error] RangeError: A proper locale must be provided

Hello!
Describe the bug
When I enter on a page for the first time with an another locale than the default locale, I get the following error:
RangeError: A proper locale must be provided
    at new a (/home/stan/Delivery/dashboard_rtm/.next/server/chunks/526.js:1:208125)
    at m (/home/stan/Delivery/dashboard_rtm/.next/server/chunks/332.js:1:29693)
    at em (/home/stan/Delivery/dashboard_rtm/node_modules/.pnpm/next@14.1.0_@babel+core@7.23.6_@opentelemetry+api@1.7.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:131226)
    at /home/stan/Delivery/dashboard_rtm/node_modules/.pnpm/next@14.1.0_@babel+core@7.23.6_@opentelemetry+api@1.7.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:142926
    at Array.toJSON (/home/stan/Delivery/dashboard_rtm/node_modules/.pnpm/next@14.1.0_@babel+core@7.23.6_@opentelemetry+api@1.7.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:146504)
    at stringify (<anonymous>)
    at eR (/home/stan/Delivery/dashboard_rtm/node_modules/.pnpm/next@14.1.0_@babel+core@7.23.6_@opentelemetry+api@1.7.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:134889)
    at eP (/home/stan/Delivery/dashboard_rtm/node_modules/.pnpm/next@14.1.0_@babel+core@7.23.6_@opentelemetry+api@1.7.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:135332)
    at Timeout._onTimeout (/home/stan/Delivery/dashboard_rtm/node_modules/.pnpm/next@14.1.0_@babel+core@7.23.6_@opentelemetry+api@1.7.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:132112)
    at listOnTimeout (node:internal/timers:573:17)
[Error: An error occurred in the Server Components render. The specific message is omitted in production builds to avoid leaking sensitive details. A digest property is included on this error instance which may provide additional details about the nature of the error.] {
  digest: '269968065'
}
TypeError: e[o] is not a function
    at /home/stan/Delivery/dashboard_rtm/.next/server/chunks/526.js:1:213058
    at Generator.next (<anonymous>)
    at /home/stan/Delivery/dashboard_rtm/.next/server/chunks/526.js:1:210792
    at new Promise (<anonymous>)
    at d (/home/stan/Delivery/dashboard_rtm/.next/server/chunks/526.js:1:210612)
    at /home/stan/Delivery/dashboard_rtm/.next/server/chunks/526.js:1:212949
    at Module.c (/home/stan/Delivery/dashboard_rtm/.next/server/chunks/332.js:1:30162)
    at /home/stan/Delivery/dashboard_rtm/node_modules/.pnpm/next@14.1.0_@babel+core@7.23.6_@opentelemetry+api@1.7.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:225165
    at /home/stan/Delivery/dashboard_rtm/node_modules/.pnpm/next@14.1.0_@babel+core@7.23.6_@opentelemetry+api@1.7.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/server/lib/trace/tracer.js:133:36
    at NoopContextManager.with (/home/stan/Delivery/dashboard_rtm/node_modules/.pnpm/@opentelemetry+api@1.7.0/node_modules/@opentelemetry/api/build/src/context/NoopContextManager.js:25:19)

To Reproduce
Steps to reproduce the behavior:

Clone this repo https://github.com/tirraa/dashboard_rtm/
Run make install
Run make initialize-env
Run make (or make build)
Run make start
Go on the app http://localhost:3000/
Change the language to "English"
Refresh the page
The error is printed in the terminal

Expected behavior
No error should be thrown, I guess?
About (please complete the following information):

next-international version: 1.2.3
Next.js version: 14.1.0

Additional context
This error does not block the rendering of the page.
You can also use make prebuild-rtm && make dev instead of make && make start to run the app in dev mode.

Interesting, I don't know where this "A proper locale must be provided" error is coming from though 🤔

Interesting, I don't know where this "A proper locale must be provided" error is coming from though 🤔

Sorry, I've provided a rather huge project "to reproduce"... I'll try to see if I can isolate this error better in the future. Right now I'm very busy putting the finishing touches to the PoC of my "Glue" between Contentlayer and Next International. ^^"


d2l-button-icon doesn't pass the color property down to d2l-icon

In <d2l-icon> you can set color in CSS.
By analogy it seems like that should be possible in <d2l-button-icon>, but it isn't:
<d2l-icon
    icon="tier1:close-circle"
    style="color: var(--d2l-color-feedback-error)">
</d2l-icon>

<d2l-button-icon
    type="button"
    icon="tier1:close-circle"
    style="color: var(--d2l-color-feedback-error);">
</d2l-button-icon>

Result:

Interesting! So I think we were being a bit intentional about only having the icon be ferrite, since the design kind of specs it out that way. What's your use case for coloured icons?

Just glitter. I'm switching between tier1:role-switch and tier1:close-circle to cancel it:

It's easier to tell the two states apart with some color (but not required). If we don't want that because of design I'm fine with that!

Here it is with color, in case this screams "obviously wrong" :)

Yeah I'm pretty sure design intentionally wanted the grey icons to avoid having particular ones popping. There's also the accessibility angle, where enough contrast needs to exist between the icon colour and the hover background colour, which we can guarantee by controlling it.
I'd also worry that if we supported this, then suddenly colours set on parent elements would start bleeding into our icons everywhere, without us actually wanting it to happen. i.e.
<div style="color:pink">
    Pink text
    <d2l-icon></d2l-icon>
</div>

Ok, cool!
Ah that cascading thing is definitely not pretty.


How can i see classification activate maps?I can't find the file out/

Looking at the code at mnist.py
for i in range(step_start, 100000):
        print(i)
        batch_xs, batch_ys, _ = next_batch(images_train, labels_train, i, batch_size)
        sess.run(train_step, feed_dict={x: batch_xs, y_: batch_ys})
        if i % 100 == 0:
            save(sess, saver, i)
            accuracy_list = []
            j = 0
            while True:
                batch_xt, batch_yt, reset = next_batch(images_test, labels_test, j, batch_size, debug=False)
                if reset:
                    break
                accuracy_list.append(sess.run(accuracy, feed_dict={x: batch_xt, y_: batch_yt}))
                j += 1
            print('steps =', i * batch_size, 'mean accuracy =', np.mean(accuracy_list))

            inspect_class_activation_map(sess, class_activation_map, top_conv, images_test,
                                         labels_test, i, 50, x, y_, y)

the model loads at iteration 99900
the code stops right at iteration 99999
which does not enter the condition i%100==0
so there is no output or result saved at all if just running the code
just modify the i%100 to some other number or just increase the range will save the output


DependencyObject.ClearValue link not found

Title.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 8acd9840-42dc-962a-d5ac-7d4b3436206a
Version Independent ID: 2845d546-1199-a282-2823-42465317aa7f
Content: Binding Class (Microsoft.UI.Xaml.Data) - WinUI
Content Source: winui-api-build/xml/Microsoft.UI.Xaml.Data/Binding.xml
Product: reunion
Technology: winui-reference
GitHub Login: @jwmsft
Microsoft Alias: jimwalk

Thanks. Link should be fixed now.


If applicable, show the LP that created a given execution

On the Execution Details page, expose the Launch Plan which was used to create the execution.

Bug bankruptcy.

Bug bankruptcy.


@SqsListener(value = "${queue.name}") and Spring Cloud Config

Was sent here by dsyer, who think I should create an issue somewhere around here... (https://github.com/spring-cloud/spring-cloud-config/issues/157). We see loads of these fetching against the cloud config server, from the client, and it has to do with the listener set up on the SQS queue.
2016-06-17 13:34:07.055  INFO 29217 --- [nio-5000-exec-1] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: https://xxxx
2016-06-17 13:34:08.282  INFO 29217 --- [nio-5000-exec-1] c.c.c.ConfigServicePropertySourceLocator : Located environment: name=application, profiles=[main], label=master, version=4a67c66caee11fdf2e53bfa28d16eb7b1c4a622c
2016-06-17 13:34:08.521  INFO 29217 --- [nio-5000-exec-3] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: https://xxxx
2016-06-17 13:34:09.391  INFO 29217 --- [nio-5000-exec-3] c.c.c.ConfigServicePropertySourceLocator : Located environment: name=application, profiles=[main], label=master, version=4a67c66caee11fdf2e53bfa28d16eb7b1c4a622c
2016-06-17 13:34:16.525  INFO 29217 --- [nio-5000-exec-5] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: https://xxxx
2016-06-17 13:34:17.663  INFO 29217 --- [nio-5000-exec-5] c.c.c.ConfigServicePropertySourceLocator : Located environment: name=application, profiles=[main], label=master, version=4a67c66caee11fdf2e53bfa28d16eb7b1c4a622c

Haven't seen someone else reporting this before, but I might be wrong.

Hi @HagarJNode
I tried to reproduce it with the aws-refapp (https://github.com/spring-cloud-samples/aws-refapp/tree/config-server) but it didn't work. I have no log output coming from the config client. Maybe these calls are produced by some code you have in a handler method.
I'm closing this issue for now. Feel free to reopen it if you have new information about this issue.


CRITICAL - Numbering Sequence Definition for Template vs. Standard WO

Cannot find the numbering sequence for Template - SaaS shows 2 work orders of W000001 (1 for each type).  Need to close the loop on the Template sequence.

Problem was resolved via an earlier pull request.


Error in executing the deployed service.

When I ask a question like: How cold is it today?
The page in the Output section shows : Error. Not found
Here: http://natural-language-classifier-nodejs-shamitbagchi-2119.eu-gb.mybluemix.net/

did you train a classifier?

How do I need to this?

Take a look at https://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/doc/nl-classifier/get_start.shtml

So I need this package curl for this?

curl comes with your computer and allows you to do HTTP requests. You need to create a classifier with the training data that is available here and update the CLASSIFIER_ID environment variable as described in the README.md file

Ah! I didnt realize this BlueMix project was NodeJS - I thought it was a Python based NLP package ...


Add class/subclass features content

Add this missing content from WJ:MAiS 0.97

No more new features


Use BETWEEN for dates

Goals
What do you want to achieve?
I want to retrieve results between two dates
Expected Results
What did you expected to happen?
Get results between two dates
Actual Results
What did happened instead?
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Unable to parse the format string "airDateTime BETWEEN {2016-07-04 10:56:24 +0000, 2016-08-03 10:56:24 +0000}"'
Steps to Reproduce
What are steps we can follow to reproduce this issue?
        let allEpisodes = realm.objects(Episode.self)
        let today = NSDate()//.description
        let later = NSDate().dateByAddingTimeInterval(60 * 60 * 24 * 30)//.description
        let aired = allEpisodes.filter("airDateTime BETWEEN {\(today), \(later)}")

Code Sample
Provide a code sample or test case that highlights the issue.
If relevant, include your model definitions.
For larger code samples, links to external gists/repositories are preferred.
Alternatively share confidentially via mail to<EMAIL_ADDRESS>Full Xcode projects that we can compile ourselves are ideal!
Version of Realm and Tooling
In the CONTRIBUTING guidelines, you will find a script,
which will help determining these versions.
Realm version: ?
1.0.1
Xcode version: ?
7.3.1
iOS/OSX version: ?
9.3
Dependency manager + version: ?

You should use filter(predicateFormat:args:) instead of passing a simple string. Realm uses NSPredicate internally and its initializer looks at the arguments types also.
Try something like this:
let aired = allEpisodes.filter("airDateTime BETWEEN {%@, %@}", today, later)

Ok thanks for the info 👍

I have given this format ,that's not fetching the data from the database ,the date format is same as all .please give me sample code ?


Test when new dbt versions are released

Run the test suite when a new dbt release is detected. This should help us stay on top of breaking changes.
Ideally, we should be running it as early as release candidates are published so that there's enough time to respond to breaking changes and keep this updating as dbt continues to evolve.
Not sure if there are out of the box solutions but I assume I could do this with some CI tool (CircleCI / Github Actions). I think I've seen this before, but I could be wrong. Happy to hack at a solution still cause it would be pretty cool to have this nevertheless!

Looks like this might be possible with dependabot + filtering for releases rc tag https://docs.github.com/en/github/administering-a-repository/customizing-dependency-updates


NPM Start issue

Hi,
I have installed node to learn react. When I create a react app using npx create-react-app, all the files are downloaded. But when I trying running npm start, it doesn't do anything. I have tried re-installing node and vs code but nothing see,s to work.
The file I'm working on is called github-finder.
Npm version: 6.14.8, Node Version: v14.15.1
I was able to run npm scripts. I made a new directory and ran npm init. These were the contents of the package.json
{
  "name": "test",
  "version": "1.0.0",
  "description": "testing",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

The contents of the GitHub-finder directory.
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        02-12-2020     20:23                node_modules
d-----        02-12-2020     20:23                public
d-----        02-12-2020     20:23                src
-a----        26-10-1985     10:15            310 .gitignore
-a----        02-12-2020     20:23         687976 package-lock.json
-a----        02-12-2020     20:23            816 package.json
-a----        26-10-1985     10:15           3369 README.md

The contents of the public directory
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        26-10-1985     10:15           3870 favicon.ico
-a----        26-10-1985     10:15           1721 index.html
-a----        26-10-1985     10:15           5347 logo192.png
-a----        26-10-1985     10:15           9664 logo512.png
-a----        26-10-1985     10:15            492 manifest.json
-a----        26-10-1985     10:15             67 robots.txt

The contents of the src directory
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        26-10-1985     10:15            564 App.css
-a----        26-10-1985     10:15            528 App.js
-a----        26-10-1985     10:15            246 App.test.js
-a----        26-10-1985     10:15            366 index.css
-a----        26-10-1985     10:15            500 index.js
-a----        26-10-1985     10:15           2632 logo.svg
-a----        26-10-1985     10:15            362 reportWebVitals.js
-a----        26-10-1985     10:15            241 setupTests.js

The contents of package.json in Github-finder
{
  "name": "github-finder",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@testing-library/jest-dom": "^5.11.6",
    "@testing-library/react": "^11.2.2",
    "@testing-library/user-event": "^12.3.0",
    "react": "^17.0.1",
    "react-dom": "^17.0.1",
    "react-scripts": "4.0.1",
    "web-vitals": "^0.2.4"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

Tried running npm run start. Nothing changed, just moves to a new line.
I'm working on windows 10.
Any idea why this is not working?

Shows any error when you run the script ?

react-app-rewired start
Unknown script " start".


on mobile, text is very very narrow

may be a feature, not a bug, but flagging just in case.
Not a critical issue, still readable.

if we have tech time, this isn't the thing to fix. bumping back

This has grown on me over time, and I haven't heard anyone mention it. Hard to consider it an issue now...


Add who use us section.

Rendered page: https://github.com/ray-project/rayfed/pull/200

Really good for the community, thx 👍


Opening slideout scrolls page to the top

Had a strange bug where every time I opened the slideout, the page jumped to the top on mobile view. I tracked it down to the overflow-x property being set to hidden. Finally fixed it by giving html and body the display: inline-table property. Not sure if this was purely due to the floated elements I have on the page for this project or if anyone else experienced it.

Hi @aviemetI
We fixed this issue: #5
You should:

Remove width and height 100% from html.
Add overflow:hidden to .slideout-panel when the slideout is opened.


Integrate the beta clippy in CI

Reference: #855

Thanks! @mrmr1993
One question: can you go for merge or the PR needs extra approval of @mimoo?

can you go for merge

Yes, once CI has passed I'm happy to merge, unless you also wanted @mimoo to review?


Fidelity estimates exceeding 100% crash quilc

The fidelity estimates stored in Forest DB (e.g., Aspen-4's qubit 17's f1QRB at the time of this writing) can exceed 100%. This causes quilc to crash.
An easy fix for this is to clamp interpreted fidelities to +near-perfect-fidelity+. It is probably better to understand why these values appear at all before proceeding.

Note to self: I left a handful of TODOs in the diff for #380 related to this issue. Remember to clean those up once this issue is addressed.


Delete Conversation

Now comes a problem, how to delete the conversation and start a new chat?

The newest version has already added this function.


Memory class field not exposed in AgentExecutor

Hey @davidmigloz!
Started to use this (amazing) Dart package :pray:
And was wondering what's the recommended way of using the OpenAIFunctionsAgent with memory?
Should I handle the memory (e.g. ConversationBufferMemory) separately, and trigger the agent executor.run() with the list of messages from memory?
Or is there a way to init the OpenAIFunctionsAgent with a memory definition?
My current "playground" example:
import 'dart:convert';
import 'dart:io';

import 'package:langchain/langchain.dart';
import 'package:langchain_openai/langchain_openai.dart';

void main(final List<String> arguments) async {
  final chatOpenAI = ChatOpenAI(
    apiKey: {{OpenAIkey}},
    temperature: 0.0,
    maxTokens: 512,
    model: 'gpt-3.5-turbo-0613',
  );

  final tool = Tool.fromFunction(
    name: 'search',
    description: '''
    Search for...
    parameters: {
      'type': 'object',
      'properties': {
        'param1': {
          'type': 'string',
          'description': '....',
        },
        'param2': {
          'type': 'number',
          'description': '...',
        },
      },
      'required': ['param1'],
    }
    ''',
    func: (final String toolInput) async {
      final arguments = jsonDecode(toolInput);

      print('Function Call Arguments: $arguments');
      // TODO: implement search

      // Mock results
      final functionResponse = [
        'result1',
        'result2',
      ];

      return 'Suggest only one result to the user out of the following JSON list:\n$functionResponse';
    },
  );

  final agent = OpenAIFunctionsAgent.fromLLMAndTools(
    llm: chatOpenAI,
    tools: [tool],
  );
  final executor = AgentExecutor(
    agent: agent,
    tools: [tool],
  );

  final memory = ConversationBufferMemory();

  while (true) {
    // Get user input.
    stdout.write('> ');
    final query = stdin.readLineSync() ?? '';
    final userMessage = ChatMessage.human(query);

    // Add user input to memory.
    memory.chatHistory.addUserChatMessage(userMessage.content.trim());
    final messages = await memory.chatHistory.getChatMessages();

    // Chat Complete by OpenAI.
    final aiMessage = await executor.run(messages);

    // Store AI response in memory.
    memory.chatHistory.addAIChatMessage(aiMessage);

    // Output AI response.
    stdout.writeln(aiMessage);
  }
}

When handling the memory separately (as in the example above), I'm not sure how to properly store the OpenAI function-response messages (the one with the role "function" that OpenAI expects to receive as the function-call response, and should be part of the list of messages).
I mean, I would hoped to find something like:
memory.chatHistory.addFunctionChatMessage()

But couldn't find the proper way.

Hey @davidmigloz,
I see what's missing.
Will send a PR soon.

Hey @orenagiv,
Thanks for opening the issue. Indeed, the memory field was not exposed in the AgentExecutor class, which was preventing adding memory to the agent.
I've just fixed it and I'll ship a new release later today.
For your example, it will look something like this:
void main() async {
  final openaiApiKey = Platform.environment['OPENAI_API_KEY'];
  final chatOpenAI = ChatOpenAI(
    apiKey: openaiApiKey,
    temperature: 0.0,
    maxTokens: 512,
    model: 'gpt-3.5-turbo-0613',
  );

  final tool = BaseTool.fromFunction(
    name: 'search',
    description: 'Tool for searching the web',
    inputJsonSchema: const {
      'type': 'object',
      'properties': {
        'query': {
          'type': 'string',
          'description': 'The query to search for',
        },
        'n': {
          'type': 'number',
          'description': 'The number of results to return',
        },
      },
      'required': ['query'],
    },
    func: (final Map<String, dynamic> toolInput) async {
      final query = toolInput['query'];
      final n = toolInput['n'];

      print('Function Call Arguments: $query | n=$n');
      // TODO: implement search

      // Mock results
      final functionResponse = [
        'result1',
        'result2',
      ];

      return 'Results:\n$functionResponse';
    },
  );

  final agent = OpenAIFunctionsAgent.fromLLMAndTools(
    llm: chatOpenAI,
    tools: [tool],
    extraPromptMessages: [
      HumanChatMessagePromptTemplate.fromTemplate(
        'Previous conversation history:\n{history}',
      ),
    ],
  );
  final memory = ConversationBufferMemory();
  final executor = AgentExecutor(
    agent: agent,
    tools: [tool],
    memory: memory,
  );

  while (true) {
    // Get user input.
    stdout.write('> ');
    final query = stdin.readLineSync() ?? '';
    // Chat Complete by OpenAI.
    final aiMessage = await executor.run(query);
    // Output AI response.
    stdout.writeln(aiMessage);
  }
}

Note that I'm using BaseTool instead of Tool, as your tool expects two input parameters.
Then to add the history, you need to add a prompt that includes {history}, which is the input key where ConversationBufferMemory will add the history.
I've also added a test that verifies this scenario:
https://github.com/davidmigloz/langchain_dart/blob/845087fd59a0c1391ad826e06322a9e26ef0138c/packages/langchain_openai/test/agents/functions_test.dart#L34
Let me know if that covers your use case 🙂

This is awesome!
Thanks @davidmigloz 🙏
Pulled and got it to work :)
Quick question:
Aren't we're missing the "function-message"?
(by "function message" I'm referring to the response of the function-call that is passed back to the Chat Model).
I mean, when communicating with the OpenAI Function Calls - aren't we supposed to include also the "function message" as part of the list of messages that we're sending back to the OpenAI Chat Model for the next chat-completion?
I've started working on a PR with the memory updates (that you already applied :) and also with something like this:
In history.dart
/// Add a Function response message to the history.
  Future<void> addFunctionChatMessage({
    required final String name,
    required final String content,
  }) {
    return addChatMessage(
      ChatMessage.function(
        name: name,
        content: content,
      ),
    );
  }

And in chat.dart:
@override
  Future<void> saveContext({
    required final MemoryInputValues inputValues,
    required final MemoryOutputValues outputValues,
    // TODO: final MemoryFunctionValues? functionValues,
  }) async {
    // TODO: final (input, output, function) = _getInputOutputValues(inputValues, outputValues, functionValues);
    await chatHistory.addUserChatMessage(input);
    await chatHistory.addAIChatMessage(output);
    // TODO: when relevant, save the function-response message to the history:
    // await chatHistory.addFunctionChatMessage(function);
  }

I'm not yet very familiar with LangChain concepts, so maybe the way LangChain chains & tools work behind the scenes cause my suggestion above to be redundant?

Hey @davidmigloz
Submitted a PR with some related examples, and added the addFunctionChatMessage() method:
https://github.com/davidmigloz/langchain_dart/pull/83

Indeed the function message is not stored, as when you add memory to an agent executor it will only save the inputs and outputs of the agent executor (whereas the function call is an internal call of the agent). Thanks for the PR! I'll review it now.

Hey @orenagiv ,
I've just pushed some improvements in the OpenAIFunctionsAgent that allow it to have internal memory.
It now uses an LLMChain, instead of the LLM directly. So you can easily add memory to that chain.
I've updated the test to use this approach:
https://github.com/davidmigloz/langchain_dart/blob/c5b0a0a4024677be8821468ec40b43c814aee2be/packages/langchain_openai/test/agents/functions_test.dart#L66-L71
Now it stores all the messages properly, including the function message:

Let me now if that works for you and thanks again for the PR!

Thanks so much @davidmigloz !
I'm checking it now.
I noticed that the function-messages are indeed necessary to be part of the memory (that is then sent back to the Chat Model as the messages-list) because in many cases I want it to "remember" specific properties that existed in previous function-messages, so it can use them in the next tool API.
Say, what did you choose to saveContext with a HumanChatMessage with a content of FunctionChatMessage (instead of a FunctionChatMessage)?
Is it because the history is build with input and output only and you didn't want to have something like: input, function and output?

Works like a charm btw @davidmigloz  :))

Say, why did you choose to saveContext with a HumanChatMessage with a content of FunctionChatMessage (instead of a FunctionChatMessage)?

Indeed, good catch I didn't notice it.
I've just fixed it in this PR: https://github.com/davidmigloz/langchain_dart/pull/88
Now all the messages should be saved with the proper type.

Why do we need to define the "tools" in both the Agent and the Executor?

That's a good question.
The tools passed to the Agent allow it to know what actions it can take. The agent needs to know about the tools so that it can decide which one to invoke.
The tools passed to the Executor allow it to actually execute the tools when the Agent decides to invoke one. The Executor needs the actual functions representing the tools so that it can call them.
But you are right, it is kind of redundant, as the Executor can get the tools from the Agent.
I've just refactored it in this PR: https://github.com/davidmigloz/langchain_dart/pull/89
Now you just need to pass the tools to the agent.
Thanks for helping to improve the API!
Let me know if you have any other suggestions 🙂

Thanks @davidmigloz !
Great stuff :) works flawlessly.
So if I understand correctly, now at the Executor level, I don't need to define tools nor the memory.
I'm using it as follows:
final agent = OpenAIFunctionsAgent.fromLLMAndTools(
      llm: _chatOpenAI,
      tools: [...],
      memory: memory,
      systemChatMessage: SystemChatMessagePromptTemplate.fromTemplate('...'),
      extraPromptMessages: [
        const MessagesPlaceholder(variableName: BaseMemory.defaultMemoryKey),
      ],
    );

    // Init the Langchain Agent Executor
    // No need to define the tools or memory as they are already defined at the Agent level.
    _agentExecutor = AgentExecutor(
      agent: agent,
    );

Correct! now you just need to pass the agent to the AgentExecutor. You don't need the MessagesPlaceholder(variableName: BaseMemory.defaultMemoryKey) either (I'll explain why in your other issue.


Compatibility with React 0.14

React.Backbone is currently using this.getDOMNode, this is deprecated in React 0.14.
Will React.Backbone be updated to get rid of this warning?

If this is important to you I would suggest making a PR. I'm currently not using this project, but are reviewing (not sure about @clayallsopp , but it might well be that this is no issue to him at the moment either).
The code is small enough that it shouldn't be too hard to fix.

So i guess this is not really maintained anymore? Connecting a model directly to a react component is perhaps not considered very good practice anymore? Still useful in some cases though imo.

On 10 Nov 2015, at 13:19, Mark IJbema<EMAIL_ADDRESS>wrote:
If this is important to you I would suggest making a PR. I'm currently not using this project, but are reviewing (not sure about @clayallsopp , but it might well be that this is no issue to him at the moment either).
The code is small enough that it shouldn't be too hard to fix.
—
Reply to this email directly or view it on GitHub.

I don't think there's much work going into this project, but since the scope is well-defined that's not needed either imo. I think this is a good example of a project that's "done". I mean, upgrades need to be supported, but I don't think there's a need to add more functionality.
Personally, I've only used this during a transition from backbone to react, and I don't think Backbone maps cleanly to React, so imo it's not a perfect solution. Otoh, I know people who use it and are happy to keep using it.
I wouldn't say it's not maintained either, both @clayallsopp and I participate in issues and PRs, but actually fixing the code myself is no priority for me at least, more so because currently I'm not using react, so I wouldn't implement it as well as someone who does.

Originally fixed by #48, code removed in #51, so warning is gone


Add pre-commit configuration

What does this PR do?
This PR adds a pre-commit configuration, so developers may opt in to running ruff and ruff-format as a pre-commit hook.
Should reduce the need for "fix lint" commits and check_code_quality CI failures.
Sibling of https://github.com/huggingface/accelerate/pull/2451

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

I had some issues with pre-commit in the past. Some probably won't apply here (e.g. it being slow) but in the end, everyone is free to choose if they want to activate them or not, so I see no real harm (there is a small maintenance cost of keeping the config in sync).


Process Text Files in Decompiler

It turns out the game text files (TEXT/XCOMMON.TXT) are GOAL object files. They break some assumptions I made, like

They are the only v2 GOAL file, everything else is v3 or v4. The GOAL disassembler doesn't support v2 properly.
They contain GOAL strings with non-printable characters. The GOAL disassembler doesn't work on these properly.
They are located outside of a DGO file. This breaks the naming convention and object file map system.

This PR will fix these issues.
To Do before merging

[x] Support v2 in klink.cpp
[x] Confirm we can load and link text files.
[ ] Test compiling/loading/inspecting fake text data in a test
[ ] Document text stuff

Pull Request Test Coverage Report for Build 367272563

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 81.24%

Totals

Change from base Build 367153026:
0.0%

Covered Lines:
16005

Relevant Lines:
19701

💛  - Coveralls

The extracted text looks something like this:

The special characters are a mess of GOAL escape codes and non-printable characters that get turned into \c escape sequences. None of them are standard (I think Japanese is just indices into a table of selected characters) so I am just leaving it as is for now. It's not nice to look at but the game will know how to print these to the screen when needed.

We are now able to load text files!
The example works like this:

First, run the decompiler. Modify assets/game_text.txt to modify text if desired.
Run (build-data) at the compiler to build the data files
Run check.sh if you didn't modify the text to verify the text data file exactly matches the game.
Start gk, connect the listener with (lt) and run (blg) to build and load all code
Run (hack-load-text-test) to load english text.

(defun hack-load-text-test ()
  "Test to try loading game text"
  (set! *text* (the game-text-info (load "$JAK-PROJECT/out/0COMMON.TXT" *common-text-heap*)))
  )

Run (inspect *text*) or (print *text*)

gc > (inspect *text*)
[0016a084] game-text-info
	length: 617
	data[617]: @ #x16a090
	  [0] #x103 "~Y~22L<~Z~Y~27L*~Z~Y~1L>~Z~Y~23L[~Z~+26H = YES, ~Y~22L<~Z~Y~26L;~Z~Y~1L>~Z~Y~23L[~Z~+26H = NO"
	  [1] #x104 "PRESS ~Y~22L<~Z~Y~25L@~Z~Y~1L>~Z~Y~23L[~Z~+26H TO TALK."
	  [2] #x105 "PRESS ~Y~22L<~Z~Y~25L@~Z~Y~1L>~Z~Y~23L[~Z~+26H TO USE."
	  [3] #x106 "DO YOU WANT TO PLAY?"
	  [4] #x107 "DO YOU WANT TO PLAY AGAIN?"
	  [5] #x108 "QUIT"
	  [6] #x109 "PAUSE"
...

This still needs some clean up and adding tests before merging, but a huge number of things are working to make this possible!


Use correct calling convention for 32-bit VISA

Thanks for contribution!
visa-sys contains ffi bindings to visa library automaticly generated by bindgen, should they be changed to extern "system" fn too?

Oh I just found your request in visa-sys, thanks again.

No worries! Thanks for making such an awesome project. It's helped me out a lot.


doc: west: add information about private repositories

How to manage repositories that require authentication to fetch from
using west is a frequently asked question.
TL;DR on the answer is that Git already has credential storage built
in, so our expectation is that there is nothing west needs to do in
particular, as users can select whatever credential helper works for
them, or set up a custom one using something like the GIT_ASKPASS
environment variable.
That's not a very helpful expectation if people aren't aware that
credential helpers exist, though, so let's document that and provide
examples for common use cases, as well as west-specific
troubleshooting advice.

@pabigot @henrikbrixandersen I expect you may have run into this situation as end users, so I'd particularly welcome any feedback.


PostAgent propagate event?

Is it possible for a PostAgent to propagate/continue an event?
In my example I want to make a POST request, but then propagate the result JSON as a new event
Any ideas?
Cheers.

Hey @chrisrickard!
The PostAgent doesn't currently have an option to emit the results from the Post as a new Event.  Is that what you're suggesting?  If so, I think it's a good idea, and would be happy to help guide you through the process of adding it to Huginn.

Hi @cantino , correct - I think it would be handy to emit the result, so as to chain the events.
Great - I can take a look myself, but what would your general suggestions be?

Great, I think it'd be a good improvement.
One thought, though: should this just be part of the WebsiteAgent?  That Agent can already receive a url (or url_from_event) and make a request, then merge the results back into the incoming Event.  Maybe the WebsiteAgent should be able to take a method, so that it can do non-GET requests?  What do you think @dsander & @knu?
If we were to add it to the PostAgent, which is also reasonable, and possibly simpler, I think you could just use the Faraday::Response that the faraday.run_response line in post_agent.rb should return to create a new Event.

That seems like a good idea, depending on @dsander & @knu's thoughts I am happy to give that a shot

This is something needed, to use Readability API for instance.

@cantino Not sure to be honest, wouldn't the WebsiteAgent also need to accept the POST parameters in a different from then the URL string?
My first feeling is that this feature should go into the PostAgent, but if the returned data needs to be transformed in some way the WebsiteAgent already had support for XPath and JSONPath.

That's true, and I see no harm in having it in the PostAgent.  @chrisrickard, you could go ahead and try to use the Faraday::Response that the faraday.run_response line in post_agent.rb should return to create a new Event.

Another use case for this is for interacting with the Google Flights QPX API.
https://developers.google.com/qpx-express/

@chrisrickard or @Ishfal, would either of you like to make this change?

Yes, I am happy to give it a shot. Unfortunately, I don't really know Ruby, so it may take me a while to produce something meriting a commit. But, I will give it a try, and if someone else beats me to the punch then we're all that much better off.

@Ishfal I'm happy to provide feedback, code review, and to answer any questions!

Here's my first whack at it... still lots to do, but I think it's moving in the right direction. Also, apologies in advance for sloppy code, etc. -- I'm an amateur!
https://github.com/cantino/huginn/pull/997

This should be working now.


Removed CLI redesign and Location source commits from the script

Issue Number: (Link to Github Issue or Azure Dev Ops Task/Story)
Summary
One sentence summary of PR
Changes

List of comprehensive changes

Checklist

[ ] Local Tests Passing?
[ ] CICD and Pipeline Tests Passing?
[ ] Added any new Tests?
[ ] Documentation Updates Made?
[ ] Are there any API Changes? If yes, please describe below.
[ ] This is not a breaking change. If it is, please describe it below.

Are there API Changes?
If yes, what are the expected API Changes? Please link to an API-Comparison workflow with the API Diff.
Is this a breaking change?
If yes, what workflow does this break?
Anything else?
Other comments, collaborators, etc.
This PR Closes Issue #

Approving with a single non-blocking comment. It seems like there's two scripts that do the same thing? Why do we maintain two?

@gfmatthews Good question.  Because one is powershell and the other is bash and different team members need one or the other.  It is an annoying copy/paste tax that is cheaper than engineering something else given the short-term nature of this strategy.


Unable to open backpack from Inventory with keybind (open_from_inventory = true)

Mod loader
Forge
Mod version
forge-1.21.3-0.10.1-BETA
Minecraft version
1.21.3
Issue description
Unable to open backpack from inventory (with "B" keybind).
Opens If right-clicked from Toolbar (in free air, otherwise gets placed) or if held in off-hand, But will close ok with "B" keybind.
(open_from_inventory = true set in resource_backpacks.toml).
(No other keybinds conflicting with "B").
No apparent log errors.
Forge 53.0.25
If Bug

[X] I have confirmed this bug is reproducible on a minimal setup, not a modpack with many other mods.

Provide the latest.log file
N/A

Hey this is normal and intentional behavior, the Backpack only opens via KeyBind when equipped in the Chest slot. otherwise you have to hold it in your hand to open is.


[BUG?] some chains don't have a valset update yet - Insufficient Power

We still don't have a valset update on
bnb: https://bscscan.com/address/0x1876e5fA704039dfF7da0C66d516AFAcBe23c59B
matic: https://polygonscan.com/address/0x10812c485BF5cE3c5296a9f603b53344a15cC0cD
op: https://optimistic.etherscan.io/address/0x56Bff1a8D2af62584D7Ebf123452b765392e20E3
base: https://optimistic.etherscan.io/address/0x56Bff1a8D2af62584D7Ebf123452b765392e20E3
blast: https://optimistic.etherscan.io/address/0x56Bff1a8D2af62584D7Ebf123452b765392e20E3
On OP, this is blocking to instantiate the Uniswap v3 bot as SLCs require at least one valset update published on Compass.
I've observed this error on bnb, matic and op<PHONE_NUMBER>74696f6e2072657665727465643a20496e73756666696369656e7420506f776572:
execution reverted: Insufficient Power

I'm not sure if we have the same error on blast and base, since the last errors that I get are still the error fixed by pigeon v1.11.2 and I can't easily trigger new valsets and ensure that an upgraded pigeon is selected.
Where is this error coming from? Is this a bug or a feature? What is needed to get past this?

@byte-bandit @webelf101 this is blocking our next Curve TWAPs bots on Base, Matic, and BNB. We need functionality here

The error is coming from compass and basically indicates that the combined shares of all signatures on the message are not enough to reach the "power threshold", which is a constant defined as follows:
POWER_THRESHOLD: constant(uint256) = 2_863_311_530 # 2/3 of 2^32, Validator powers will be normalized to sum to 2 ^ 32 in every valset update.
I'm unsure why this constant value is being used as an absolute value to check for 2/3's majority, as obviously that depends on the total amount of shares among validators and is variable.
I do remember that Paloma also used to use this variable though, a long time ago. Tyler found and changed it. So it's possible that there's now a mismatch here, with compass checking against this constant value and Paloma using the real amount of total shares to verify that 2/3s majority is met.
I don't know the story behind this constant, I imagine it was done this way so that compass wouldn't have to be updated with the total number of shares as well? Maybe @webelf101 can share some more light on this.

Here is the commit where Tyler removed the constant used in Pigeon: https://github.com/palomachain/pigeon/commit/4e9dc09d406e6aaed05c88d666fbb4f4148bcbcb
But at that time, it already wasn't used. I have no idea if it ever was used at some point. I went back the history a little longer, but couldn't find anything. So I'm not sure this was every really done by Pigeon.
My current theory is that on messenger, the total amount of shares across validators just happened to exceed this magic number, where the number of shares on tumbler does not. Maybe we lost some validators with higher stake, or some people decided to unstake, idk.

This came from the original Gravity bridge model. However, we need a model to check if the sum of the signer's power is greater than 2 / 3 of the total sum of the validator's power. We assumed that the total sum of the validator's power is 2 ^ 32 and maybe the original code should have such value. I think you are already aware of it though. I'd like to avoid adding more data in consensus just like a total sum of power or something else. How do we calculate the powers of validators right now? @byte-bandit @taariq

This came from the original Gravity bridge model. However, we need a model to check if the sum of the signer's power is greater than 2 / 3 of the total sum of the validator's power. We assumed that the total sum of the validator's power is 2 ^ 32 and maybe the original code should have such value. I think you are already aware of it though. I'd like to avoid adding more data in consensus just like a total sum of power or something else. How do we calculate the powers of validators right now? @byte-bandit @taariq

Pigeon takes the valset with the ID that's currently on compass and just calculates the total stake of all active validators. Then it adds up the stake of everyone who signed the message, and checks if that is above the total stake of all validators. So, it seems to be dynamic, there's no normalisation happening.
This has been this way for a really long time (like more than a year at this point), and I think on the old network we just had more stake on validators, which meant the total just was above this magic number.
The way I see it, we have two ways forward:
a) add more stake to validators so the total is above that number
b) create a new version of Pigeon that performs this normalisation before sending the data
I don't believe I will have capacity to engineer, test & deploy option b. We should probably create a ticket for that regardless so we can come back to it and clean it up. But for now, increasing the stake seems to be best option to get quick results?

Thank you @byte-bandit @webelf101

Let's create the ticket for backlog to upgrade this. Good ticket for Luis to work on?
Let's increase the stake. How much is required and which validators need this stake?

I have a question. Why do we have this issue on OP only? @byte-bandit

We have it on
bnb: https://bscscan.com/address/0x1876e5fA704039dfF7da0C66d516AFAcBe23c59B
matic: https://polygonscan.com/address/0x10812c485BF5cE3c5296a9f603b53344a15cC0cD
op: https://optimistic.etherscan.io/address/0x56Bff1a8D2af62584D7Ebf123452b765392e20E3
base: https://optimistic.etherscan.io/address/0x56Bff1a8D2af62584D7Ebf123452b765392e20E3
blast: https://optimistic.etherscan.io/address/0x56Bff1a8D2af62584D7Ebf123452b765392e20E3

@byte-bandit but why don't we have it on the other 3 chains?

@byte-bandit but why don't we have it on the other 3 chains?

I don't know whether we actually have consensus on all other 3, but we do know for sure we have it on eth.
So the most obvious answer would be: timing. Valset (and therefore total shares) can change over time, which means at some point we're above the magic number, and at times with less validators in the set, we might be below. It's just an elaborate guess for now though.

@byte-bandit @webelf101 timing seems to be a factor here. I just checked all 5 chains and we have a valset on all of them now, so maybe this is no longer an issue

It's still not the intended design, as compass still doesn't actually check for true majority vote. Just that total number of shares exceed a magic number.
Let's keep this open to address at a later stage, Pigeon should normalise the numbers before sending to compass.

The valset that went through was the first valset on that chain after contract deployment and not associated with a logic call. So theoretically all valsets that were generated before would have failed. Note that arbitrum-main, eth-main, gnosis-main, did not have that issue.
The original bug report was generated when valset 125 was trying to get deployed.
Deployed valsets:
bnb-main: 127
op-main: 127
base-main: 127
blast-main: 127
matic-main: 131, note that this valset update looks different on the blockscanner than the others. Unclear if that is an explorer issue or something different in the valset update

We can close this, as Paloma actually performs the normalisation.


v1.1 backports 18-08-17

Backported PRs:
#5252
PRs that were not backported due to merge conflicts
#5243 (@tgraf) - from my initial analysis, this will require #5234 and #5115.
Signed-off by: Ian Vernon<EMAIL_ADDRESS>

This change is

#5243 (@tgraf) - from my initial analysis, this will require #5234 and #5115.

Yes, at least.


Several rules on the README are in TSLint proper already

The README seems like it could use a little bit of updating in that regard. An example is ESLint's strict is use-strict in TSLint. Glancing through the rules, there's about 6 or so of these.

Accepting PR's.


Support Kubernetes

Let's simplify the whole "data options for cluster" to just be kubernetes. If a module/option exists on both pizer & owens we'll support it in kubernetes - otherwise we won't.  I'll bring this up in our classroom meetings and we'll either support this scheme or backport the modules to owens.

I made it so the only RStudio Server versions available for kubernetes are ones where they exist for both Pitzer and Owens.  That removed a lot of code changes, especially to the form.js.

Should I go ahead and add kubernetes-test and kubernetes-dev clusters to form list? They won't show up if they aren't defined so maybe keep things simpler for people doing app testing and what not so we don't have to maintain a bunch of forks and branches and what not?

Yea that'll be fine.

Updated with commits so should still work on dev and test instances of our ondemand servers.

Testing in test , I missed a few places in Javascript to handle test/dev names.

Fix test/dev case to also work, just had to update form fields to account for the 2 non-production Kubernetes cluster names.


feat: added phone number extraction to pages.js

Here is a starting point for Issue 6.
This currently reads up to 12 characters and extracts a 10-12 digit phone number.
I would really appreciate any guidance you can offer in terms of how you may want this regex to function.
For example do you want it to ignore all non-numeric characters?
Please advise on how I can improve or customize to your goals.  Thanks

It should have:

country code (+92 / +123) or simple 0
10 Digits

should not extract

Ok thanks for the feedback. I’ll address this asap.
On Mon, Oct 30, 2023 at 7:58 AM Hammad Saaedi @.***>
wrote:

It should have:

country code (+92 / +123) or simple 0
10 Digits

[image: image]
https://user-images.githubusercontent.com/71373419/279047080-c90aee69-3ac8-45ce-89e0-4dcb4987ffd9.png
should not extract
[image: image]
https://user-images.githubusercontent.com/71373419/279047151-28b19f1c-532a-4779-be78-3d91ec34cac3.png
—
Reply to this email directly, view it on GitHub
https://github.com/hammadsaedi/regex-pro/pull/32#issuecomment-1785034054,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A6JISL572GVMKNLNT6WTSNLYB6I65AVCNFSM6AAAAAA6U7O3VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBVGAZTIMBVGQ
.
You are receiving this because you authored the thread.Message ID:
@.***>