mini.map: integration highlights not working.

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md
[X] I have updated 'mini.nvim' to latest version

Module(s)
map
Description
mini.map integration highlights do not work. added lines are expected to be green in the map.

Neovim version
NVIM v0.10.0-dev-354+g24b60b0f7 (24b60b0f71e0ffbd09c827230ecb5a37e833cade)
Steps to reproduce

Use this minimal config

...

require("lazy").setup({
	{
		"catppuccin/nvim",
		name = "catppuccin",
		priority = 1000,
		opts = {
			intergration = {
				mini = true,
			},
			custom_highlights = function(colors)
				return {
					MiniMapNormal = { fg = colors.surface0 },
					MiniMapSymbolCount = { fg = colors.mauve },
					MiniMapSymbolLine = { fg = colors.surface1 },
					MiniMapSymbolView = { fg = colors.surface0 },
				}
			end,
		},
		config = function(_, opts)
			require("catppuccin").setup(opts)

			vim.cmd.colorscheme("catppuccin")
		end,
	},
	{
		"lewis6991/gitsigns.nvim",
		opts = true,
	},
	{
		"echasnovski/mini.map",
		version = false,
		dependencies = "lewis6991/gitsigns.nvim",
		lazy = false,
		keys = { ... },
		config = function()
			local map = require("mini.map")
			map.setup({
				integrations = {
					map.gen_integration.gitsigns({
						add = "GitSignsAdd",
						change = "GitSignsChange",
						delete = "GitSignsDelete",
					}),
				},
				symbols = {
					encode = map.gen_encode_symbols.block("3x2"),
				},
				window = {
					show_integration_count = true,
				},
			})
		end,
	},
}, {
	change_detection = {
		notify = false,
	},
})

Open a tracked file and modify some lines. The highlights are simply not shown. We can doubly check that the integrations do actually exist by running := MiniMap.gen_integration.gitsigns()(), and the highlights are somehow the issue.

Am i missing something?
Expected behavior
Highlights are applied to affected minimap lines.
Actual behavior
Lines remain on their default highlighting

Thanks for detailed issue!
Today I had to use Neovim nightly and just noticed this myself. Spent several hours finding the culprit which ended up being my own recklessness. Pushed the fix several minutes ago.
Could you try the latest main?


Old AWS cluster has some issues

changed to a new address of mine.

zoinks - need to resolve conflicts


record-details: previewer randomly gives error

Package version (if known): latest
Describe the bug
The record details page gives an exception with the below stacktrace

After refreshing the page it works.

It looks like that it is happening consistently only on a dev env. We have some of these errors in some prod instances, but very few.
It looks like that it is related on how the previewers are registered, but the cause has not been found. Closing the issue for the moment.


LYWSD03MMC Error: does not match regular expression

Invalid config for [sensor.mitemp_bt]: value F09D59781AFFF5BF2000839B does not match regular expression (?i)^[A-F0-9]{32}$ for dictionary value @ data['encryptors']['a4:c1:38:ce:2a:67']. Got 'F09D59781AFFF5BF2000839B'. (See /config/configuration.yaml, line 33). Please check the docs at https://github.com/custom-components/sensor.mitemp_bt
The LYWSD03MMC has with firmware 1.0.0_0109 a 24 digit token.
...
"mac" : "A4:C1:38:CE:2A:67",
"localip" : "<IP_ADDRESS>",
"show_mode" : 1,
"longitude" : "0.00000000",
"latitude" : "0.00000000",
"isOnline" : false,
"token" : "F09D59781AFFF5BF2000839B",
"bssid" : "",
"did" : "blt.4.13t75k8l4gk00",
"pid" : 6,
"model" : "miaomiaoce.sensor_ht.t2",
...

Got the exact same error. the cause is a token of 24 digits instead of 32, FW version 1.0.0_0001, model is miaomiaoce.sensor_ht.t2 (LYWSD03MMC). any solution for this? extracted using the hacked mi home version (veve).

I found now this Project : https://github.com/mKeRix/room-assistant/issues/277. It extract the Mi Token (24 char) and Bind Key (32 char). I used the Bind Key in HA and it works, insane.

You need the 32 char key. I’ve added the instructions to the faq, as given in your link. Thanks.


Fixing alignment of Input and Subscribe Button

Description:
Fixing alignment of Input and Subscribe Button.
Screenshot:

Please assign this task to me under gssoc-ext24

Please assign this issue to me .
https://github.com/maliumesh1

Hi there!
I noticed this issue is already assigned, but I had a solution ready and submitted a PR #33  Feel free to review or close it if it’s not needed.
Thanks!

Hi there!
I noticed this issue is already assigned, but I had a solution ready and submitted a PR #33  Feel free to review or close it if it’s not needed.
Thanks!

I had already submitted PR 13h ago  for review.Once its merge Project Admin will close this issue.
Also you are allowed to raised PR for assigned issues only according to guidelines pf gssoc


Method issue when includes 0-9

If a method ends in a number "doSomething2" then the AnchorTypeIDEncoding is wrong as it treats it as do_something_2 instead of the required do_something2
I only needed to generate once so I didn't really solve this correctly as it's across multiple repos
https://github.com/gagliardetto/anchor-go/pull/3

Fixed in https://github.com/gagliardetto/anchor-go/pull/5/files

Fixed by https://github.com/gagliardetto/anchor-go/pull/5


syntax: highlight function calls

First, thanks for the great plugin!
I got inspired by this issue: https://github.com/sheerun/vim-polyglot/issues/283
Changes are minimal, I also updated the doc and README
Thanks,
Antoine

@nfnty , could you please take a look at this pull request?
The changes are minimal, thanks in advance :smiley:

Thanks! I refactored it a bit to reduce complexity and to not interfere with other syntax.

@nfnty I just updated your plugin and it seems your commit is breaking the highlighting: function definition, function calls and builtin function now have the same color.
before 53ea235:

after 53ea235:

mine:

Was this intentional?
Thanks,
Antoine

Yeah, my bad. Should be fixed now.

@nfnty thanks a lot for the quick response. The builtin function highlighting is now fixed.
However, function definition class definition and function calls now all have the same color.
Would it be possible to have:

function definition and class definition with one highlighting (the same as before my PR)
function call with another highlighting

After f73fbf0ba68054b44384109c4e0fa4a51eecabbf:

Thanks,
Antoine

Yes, just change the highlight link for  pythonFunctionCall.
hi link pythonFunctionCall Identifier

Replace Identifier with whatever highlight group you want.

@nfnty got it. However, your latest commit also changes the class definition and the function definition highlight as shown on my screenshots. Is this intended?

If you've manually changed the highlight group of pythonFunction before, then it's a side effect of changing the name into `pythonFunctionContained'. You just have to replace it in your config.

Nvm, I changed the naming back to what it was before for backward compatibility. Just update to the latest commit and you'll be good to go.

@nfnty , it's working like a charm now :smiley:
Sorry about all the back and forth and, again, thank you so much for the prompt response and for this great plugin.
Cheers,
Antoine


Link device instance to unique_identifier instead of port

Don't link the device instance to the port name, but to the unique_identifier.
This prevents that the batteries change sometimes device instance and MQTT battery ID causing missing history in the VRM portal and unfunctioning nodes in Node-RED. The root cause is that sometimes on reboot or unplug/plug of the USB to serial adapter the ttyUSB* number changes.

[ ] It has to be verified that the unique_identifier is not already used (some BMS does not have one, then it's concatenated from hardware version and battery capacity:
https://github.com/Louisvdw/dbus-serialbattery/blob/4af10dd9d323ee9e88c82d8cec3b69a9d04fddfe/etc/dbus-serialbattery/battery.py#L138-L151

[ ] If the unique_identifier exists, prevent the driver from starting and mention in the logfile that the capacity of multiple connected batteries has do differ.

Anything else?

@ogurevich maybe you have time to look into this?

I'll try to understand that tomorrow and have a couple of thoughts
Do all BMS have a serialNumber ?

The value serial is fed by the code linked above, so yes all BMS display a serial, which is in the most cases not the real serial but a concatenated value that tries to be unique.

I'm still thinking about what can be a reasonable solution here.
At the moment three tasks can be solved, that I believe the desired behavior can be realized. We can consider together how this can be implemented. We need at least:

a function that saves the last seen (used) batteries and the corresponding assigned IDs somewhere in VRM.
a function that builds the UniqueID for recognized devices when the driver is started and tries to find it by comparing stored information, then we also have the ID, which can then be assigned again.
the third function would be responsible for notifying the user in case of a conflict. Writing to the log as already suggested in the topic and perhaps also as an info alarm. In this way, the user is informed in any case.

Would an SQLite database, for example, be conceivable for this purpose?

The data is already stored in the dbus under com.victronenergy.settings
There is already a function for the unique identifier, but not for the rest

yes, thank you, i see. There are: Enabled, Name (unique Name), Service
The idea is what if we could store a little more information about a battery, no matter where, also the info: "last seen" and "last seen SOC", so we can match the battery to the name when the driver starts make smarter. We can compare different factors and thus assign the right battery. In case the formed UniqueName result in the same values. This is still a rough idea, it should mature.

ok, I entered the value: PrivDatagur01 in the User Private Data field. This is how the values in the screenshots result

Yes, thats correct. Since on serial connection I found no way to read the serial number.

any updates on this? would love to have a fix for this. very hard to read bms data with changing vrm ids

It‘s a work in progress since it takes a lot of time. You a very welcome to open a PR for this.

something like this:

import hashlib

def generate_limited_hash(input_data, min_value, max_value):
    sha256_hash = hashlib.sha256()

    # Convert the input to bytes
    input_bytes = str(input_data).encode('utf-8')

    # Update the hash
    sha256_hash.update(input_bytes)

    # Get the resulting hash value as a hexadecimal string
    hash_result = sha256_hash.hexdigest()

    # Convert the hexadecimal hash to a decimal number
    decimal_hash = int(hash_result, 16)

    # Limit the hash to the specified range
    limited_hash = min_value + (decimal_hash % (max_value - min_value + 1))

    return limited_hash

input_data = "a combination of the unique i3dent4ifier and some other fields"

min_value = 10
max_value = 50

hash_value = generate_limited_hash(input_data, min_value, max_value)
print(f"Input: {input_data}, Limited Hash: {hash_value}")

I see no difference in this. Since you cannot save the hash to the BMS it makes no sense for me. You have to recalculate the hash based on the unique data we try to generate.

ok, so the problem is there is no unique data? what about the first post, a combination of hardware id and capacity

Yes the problem is, that some BMS do not have unique data. This is already solved since a few months:
https://github.com/Louisvdw/dbus-serialbattery/blob/9b476a25b7f711d059299d0d4694b3a2e815e042/etc/dbus-serialbattery/battery.py#L144-L157

i am a bit confused now; so we already have a unique identifier method that is able to unique identify a BMS. that is good, what are we missing then ?
could this strategy work?

generate a unique identifier for each bms using the already implemented method above unique_identifier()
translate the return value of this method to a unique and fixed VRM ID using the hash method above.
set hash as VRM ID, this way we dont have to store the VRM ID as it can just be generated everytime the drivers boots up

a function that builds the UniqueID for recognized devices when the driver is started and tries to find it by comparing stored information, then we also have the ID, which can then be assigned again.

the third function would be responsible for notifying the user in case of a conflict. Writing to the log as already suggested in the topic and perhaps also as an info alarm. In this way, the user is informed in any case.

This is missing.

When a BMS is attached the driver has to check, if the BMS has already assigned a VRM ID, if not then it has to assign the next free VRM ID and store this connection somewhere with an expiration date.
If the BMS is not connected for x days, then the BMS with the VRM ID should be removed from the list.
If a BMS with the same ID is already connected the driver has to throw an error.

yea but that is my whole point. if we calculate the vrm id we dont have to store anything.

The VRM ID has to be a value between 1 and 255.

i can write a simulation. can you give me some possible values for the field 'hardware version' ? i only have one type of BMS

You have to check some issues here on GitHub and the logs.

I can give you some from my 4 Heltec BMSes

In case there is a hash-generated instance number which is already used, we could still fall back to
a) increasing numbers
b) using the USB port device name
c) integrating the capacity

We want to to this to prevent using the USB port device name

I can give you some from my 4 Heltec BMSes ![Screenshot_20231124-161107](https://private-user-

thnx!

We want to to this to prevent using the USB port device name

Clearly, but my impression is, that it will work for most systems perfectly with the hasing and only where this clashes we'd need a backup.

looked into it a bit more.
one more question @mr-manuel; the method you mentioned in the first post "unique_identifier()" doesnt seem to be used anywhere in code, is that right?
instead every specific BMS class inherits from the battery class and has its own implementation in which the unique_identifier property/variable is set. however not every BMS class seems to implement this fully (only 4 classes are setting the property for now). #link
so whats missing here is that in the base class (battery) the unique_identifier property should be set to a default value with the unique_identifier method, which can then be overwritten later on by a specific BMS class if implemented.
so this line: link
should change to:
self.unique_identifier = unique_identifier()
so at least all BMS classes have some form of a unique_identifier set. and in the case that a serial number or a custom field can actually be read from the BMS the default value can be overwritten with a more accurate value from the bms itself.
at the end; the unique_identifier property is written to the dbus path /serial.
so now we have a baseline for which i can build a simulation. if i'm still correct so far, so please confirm :)

@arrow1800 can you join our Discord server?

@arrow1800 can you join our Discord server?

accepted

This was solved and will be merged with the dev branch in the next days.


pull in generic method tests

From @jmesserly on April 29, 2016 17:20
from @vsmenon:

Also (not this CL) might be good to pull in erik's new generic method lang tests
(https://github.com/dart-lang/sdk/commit/4dd22a87bb43f2ef2d0ce755d6528cc6a7afc0a0).

Copied from original issue: dart-lang/dev_compiler#535

oh, we can't do that until we want to support the syntax. It's more of a parsing test.

I think this has been fixed! everyone's using the generic method tests now


NRGKick: Laden starten nicht mehr bei PV-Überschuss

Describe the bug
Seit einiger Zeit verhält sich evcc nicht mehr so zuverlässig wie in der Vergangenheit. Ich habe eine Zoe (für evcc keine Möglichkeit SOC abzufragen) mit einem NRGKick+NRGKick-Connect (NRGKick weiß nicht, ob Auto angeschlossen ist oder nicht!).
Sobald ich den Ladestecker anstecke, fängt das Auto erstmal mit Laden an. evcc hat dann immer erkannt, wenn kein Überschuss da war und das Laden abgebrochen. Vor ein paar Wochen hat das dann nicht mehr zuverlässig funktioniert, scheint nun aber wieder zu gehen (Nightly / https://github.com/evcc-io/evcc/commit/d7ca1fc3). Dafür hat evcc heute morgen nicht angefangen das Auto zu laden als genug Überschuss da war.
Das Auto wurde gestern Abend angeschlossen, hat kurz geladen und evcc hat den Ladevorgang gestoppt. Mitternächlich wird evcc gestoppt. Heute morgen dann wie gesagt der Fehler. Nachdem ich manuell die LadeSteuerung auf "Aus" und dann wieder auf "PV" geschalten habe, ist der Ladevorgang dann gestartet.
Logs:
Auto gestern Abend angesteckt:
[lp-1  ] DEBUG 2023/09/07 20:53:39 charge power: 0W
[lp-1  ] DEBUG 2023/09/07 20:53:40 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/07 20:53:40 charge total import: 3240.310kWh
[lp-1  ] DEBUG 2023/09/07 20:53:40 charger status: B
[lp-1  ] DEBUG 2023/09/07 20:53:40 pv charge current: 0A = 0A + -1.58A (363W @ 1p)
[lp-1  ] DEBUG 2023/09/07 20:54:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/07 20:54:10 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/07 20:54:10 charge total import: 3240.310kWh
[lp-1  ] DEBUG 2023/09/07 20:54:10 charger status: B
[lp-1  ] DEBUG 2023/09/07 20:54:10 pv charge current: 0A = 0A + -1.79A (411W @ 1p)
[lp-1  ] DEBUG 2023/09/07 20:54:39 charge power: 1760W
[lp-1  ] DEBUG 2023/09/07 20:55:00 charge currents: [9.41 0 0]A
[lp-1  ] DEBUG 2023/09/07 20:55:00 charge total import: 3240.327kWh
[lp-1  ] DEBUG 2023/09/07 20:55:00 charger status: C
[lp-1  ] DEBUG 2023/09/07 20:55:00 charge start energy: 3.24e+03kWh
[lp-1  ] INFO 2023/09/07 20:55:00 start charging ->
[lp-1  ] DEBUG 2023/09/07 20:55:00 wake-up timer: stop
[lp-1  ] WARN 2023/09/07 20:55:01 charger logic error: disabled but charging
[lp-1  ] DEBUG 2023/09/07 20:55:01 charger: guard elapse
[lp-1  ] DEBUG 2023/09/07 20:55:01 guard timer inactive
[lp-1  ] DEBUG 2023/09/07 20:55:01 pv timer elapse
[lp-1  ] DEBUG 2023/09/07 20:55:01 pv timer inactive
[lp-1  ] DEBUG 2023/09/07 20:55:01 pv charge current: 0.239A = 10A + -9.76A (2245W @ 1p)
[lp-1  ] DEBUG 2023/09/07 20:55:01 site power 2245W >= 1W disable threshold
[lp-1  ] DEBUG 2023/09/07 20:55:01 pv disable in 0s
[lp-1  ] DEBUG 2023/09/07 20:55:01 pv disable timer elapsed
[lp-1  ] DEBUG 2023/09/07 20:55:01 charger disable
[lp-1  ] DEBUG 2023/09/07 20:55:01 wake-up timer: stop
[lp-1  ] DEBUG 2023/09/07 20:55:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/07 20:55:10 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/07 20:55:10 charge total import: 3240.328kWh
[lp-1  ] DEBUG 2023/09/07 20:55:10 charger status: B
[lp-1  ] DEBUG 2023/09/07 20:55:10 final charge energy: 0.003kWh
[lp-1  ] INFO 2023/09/07 20:55:10 stop charging <-
[lp-1  ] DEBUG 2023/09/07 20:55:10 charge total import: 3240.328kWh
[lp-1  ] DEBUG 2023/09/07 20:55:10 pv charge current: 0A = 0A + -1.83A (422W @ 1p)
[lp-1  ] DEBUG 2023/09/07 20:55:10 pv enable timer reset
[lp-1  ] DEBUG 2023/09/07 20:55:10 pv timer inactive
[lp-1  ] DEBUG 2023/09/07 20:55:39 charge power: 0W
[lp-1  ] DEBUG 2023/09/07 20:55:40 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/07 20:55:40 charge total import: 3240.328kWh
[lp-1  ] DEBUG 2023/09/07 20:55:40 charger status: B
[lp-1  ] DEBUG 2023/09/07 20:55:40 pv charge current: 0A = 0A + -2.01A (463W @ 1p)

Mitternachts-Restart:
[lp-1  ] DEBUG 2023/09/07 23:59:39 charge power: 0W
[lp-1  ] DEBUG 2023/09/07 23:59:40 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/07 23:59:40 charge total import: 3240.328kWh
[lp-1  ] DEBUG 2023/09/07 23:59:40 charger status: B
[lp-1  ] DEBUG 2023/09/07 23:59:40 pv charge current: 0A = 0A + -0.943A (217W @ 1p)
[lp-1  ] DEBUG 2023/09/08 00:00:03 charge total import: 3240.328kWh
[main  ] INFO 2023/09/08 00:00:08 evcc 0.119.4 (d7ca1fc3)
[main  ] INFO 2023/09/08 00:00:08 using config file: /etc/evcc.yaml
[main  ] INFO 2023/09/08 00:00:08 starting ui and api at :7070
[lp-1  ] WARN 2023/09/08 00:00:08 poll mode '{always 1m0s}' may deplete your battery or lead to API misuse. USE AT YOUR OWN RISK.
[site  ] INFO 2023/09/08 00:00:08 site config:
[site  ] INFO 2023/09/08 00:00:08   meters:      grid ✓ pv ✓ battery ✗
[site  ] INFO 2023/09/08 00:00:08     grid:      power ✓ energy ✓ currents ✗
[site  ] INFO 2023/09/08 00:00:08     pv 1:      power ✓ energy ✓ currents ✗
[site  ] INFO 2023/09/08 00:00:08   vehicles:
[site  ] INFO 2023/09/08 00:00:08     vehicle 1: range ✗ finish ✗ status ✗ climate ✗ wakeup ✗
[lp-1  ] INFO 2023/09/08 00:00:08 loadpoint 1:
[lp-1  ] INFO 2023/09/08 00:00:08   mode:        pv
[lp-1  ] INFO 2023/09/08 00:00:08   charger:     power ✓ energy ✓ currents ✓ phases ✗ wakeup ✗
[lp-1  ] INFO 2023/09/08 00:00:08   meters:      charge ✓
[lp-1  ] INFO 2023/09/08 00:00:08     charge:    power ✓ energy ✓ currents ✓
[lp-1  ] DEBUG 2023/09/08 00:00:08 phase timer inactive
[lp-1  ] DEBUG 2023/09/08 00:00:08 pv timer inactive
[lp-1  ] DEBUG 2023/09/08 00:00:08 guard timer inactive
[lp-1  ] INFO 2023/09/08 00:00:08 vehicle updated: unknown -> Zoe
[lp-1  ] DEBUG 2023/09/08 00:00:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 00:00:09 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 00:00:09 charge total import: 3240.328kWh
[lp-1  ] DEBUG 2023/09/08 00:00:09 charger status: B
[lp-1  ] DEBUG 2023/09/08 00:00:09 charge start energy: 3.24e+03kWh
[lp-1  ] INFO 2023/09/08 00:00:09 car connected
[lp-1  ] DEBUG 2023/09/08 00:00:09 pv timer elapse
[lp-1  ] DEBUG 2023/09/08 00:00:09 pv timer inactive
[lp-1  ] DEBUG 2023/09/08 00:00:09 charger: guard elapse
[lp-1  ] DEBUG 2023/09/08 00:00:09 guard timer inactive
[lp-1  ] DEBUG 2023/09/08 00:00:09 charge total import: 3240.328kWh
[lp-1  ] DEBUG 2023/09/08 00:00:09 pv charge current: 0A = 0A + -0.926A (213W @ 1p)
[lp-1  ] DEBUG 2023/09/08 00:00:09 pv enable timer reset
[lp-1  ] DEBUG 2023/09/08 00:00:09 pv timer inactive
[lp-1  ] DEBUG 2023/09/08 00:00:39 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 00:00:39 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 00:00:39 charge total import: 3240.328kWh
[lp-1  ] DEBUG 2023/09/08 00:00:39 charger status: B
[lp-1  ] DEBUG 2023/09/08 00:00:39 pv charge current: 0A = 0A + -0.913A (210W @ 1p)

Heute morgen wurde das Auto kurz benutzt und dann wieder angesteckt bevor PV-Leistung da war:
[lp-1  ] DEBUG 2023/09/08 07:53:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 07:53:09 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 07:53:09 charge total import: 3240.328kWh
[lp-1  ] DEBUG 2023/09/08 07:53:09 charger status: B
[lp-1  ] DEBUG 2023/09/08 07:53:09 pv charge current: 0.491A = 0A + 0.491A (-113W @ 1p)
[lp-1  ] DEBUG 2023/09/08 07:53:39 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 07:53:49 charge currents: [9.54 0 0]A
[lp-1  ] DEBUG 2023/09/08 07:53:49 charge total import: 3240.329kWh
[lp-1  ] DEBUG 2023/09/08 07:53:49 charger status: C
[lp-1  ] DEBUG 2023/09/08 07:53:49 charge start energy: 3.24e+03kWh
[lp-1  ] INFO 2023/09/08 07:53:49 start charging ->
[lp-1  ] DEBUG 2023/09/08 07:53:49 wake-up timer: stop
[lp-1  ] WARN 2023/09/08 07:53:50 charger logic error: disabled but charging
[lp-1  ] DEBUG 2023/09/08 07:53:50 pv timer elapse
[lp-1  ] DEBUG 2023/09/08 07:53:50 pv timer inactive
[lp-1  ] DEBUG 2023/09/08 07:53:50 pv charge current: 0A = 0A + -7.89A (1815W @ 1p)
[lp-1  ] DEBUG 2023/09/08 07:53:50 site power 1815W >= 1W disable threshold
[lp-1  ] DEBUG 2023/09/08 07:53:50 pv disable in 0s
[lp-1  ] DEBUG 2023/09/08 07:53:50 pv disable timer elapsed
[lp-1  ] DEBUG 2023/09/08 07:53:50 charger disable
[lp-1  ] DEBUG 2023/09/08 07:53:50 wake-up timer: stop
[lp-1  ] DEBUG 2023/09/08 07:54:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 07:54:09 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 07:54:09 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 07:54:09 charger status: B
[lp-1  ] DEBUG 2023/09/08 07:54:09 final charge energy: 0.002kWh
[lp-1  ] INFO 2023/09/08 07:54:09 stop charging <-
[lp-1  ] DEBUG 2023/09/08 07:54:09 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 07:54:09 pv charge current: 0.257A = 0A + 0.257A (-59W @ 1p)
[lp-1  ] DEBUG 2023/09/08 07:54:09 pv enable timer reset
[lp-1  ] DEBUG 2023/09/08 07:54:09 pv timer inactive
[lp-1  ] DEBUG 2023/09/08 07:54:37 set target energy: 14
[lp-1  ] DEBUG 2023/09/08 07:54:37 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 07:54:37 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 07:54:37 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 07:54:37 charger status: B
[lp-1  ] DEBUG 2023/09/08 07:54:37 pv charge current: 0.535A = 0A + 0.535A (-123W @ 1p)
[lp-1  ] DEBUG 2023/09/08 07:54:39 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 07:54:49 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 07:54:49 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 07:54:49 charger status: B
[lp-1  ] DEBUG 2023/09/08 07:54:49 pv charge current: 0.27A = 0A + 0.27A (-62W @ 1p)

Hier erkennt evcc dass es Laden könnte, es wird aber nicht richtig gestartet.
[lp-1  ] DEBUG 2023/09/08 08:39:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:39:09 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:39:09 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:39:09 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:39:09 pv charge current: 0.913A = 0A + 0.913A (-210W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:39:39 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:39:39 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:39:39 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:39:39 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:39:39 pv charge current: 1.5A = 0A + 1.5A (-346W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:40:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:40:19 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:40:19 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:40:19 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:40:19 pv charge current: 5.41A = 0A + 5.41A (-1244W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:40:19 site power -1244W <= -1200W enable threshold
[lp-1  ] DEBUG 2023/09/08 08:40:19 pv enable timer start: 1m0s
[lp-1  ] DEBUG 2023/09/08 08:40:19 pv enable in 1m0s
[lp-1  ] DEBUG 2023/09/08 08:40:39 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:40:49 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:40:49 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:40:49 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:40:49 pv charge current: 6.91A = 0A + 6.91A (-1590W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:40:49 site power -1590W <= -1200W enable threshold
[lp-1  ] DEBUG 2023/09/08 08:40:49 pv enable in 30s
[lp-1  ] DEBUG 2023/09/08 08:40:49 pv enable timer remaining: 30s
[lp-1  ] DEBUG 2023/09/08 08:41:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:41:09 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:41:09 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:41:09 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:41:09 pv charge current: 6.95A = 0A + 6.95A (-1599W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:41:09 site power -1599W <= -1200W enable threshold
[lp-1  ] DEBUG 2023/09/08 08:41:09 pv enable in 10s
[lp-1  ] DEBUG 2023/09/08 08:41:09 pv enable timer remaining: 10s
[lp-1  ] DEBUG 2023/09/08 08:41:39 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:41:49 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:41:49 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:41:49 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:41:49 pv charge current: 6.77A = 0A + 6.77A (-1556W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:41:49 site power -1556W <= -1200W enable threshold
[lp-1  ] DEBUG 2023/09/08 08:41:49 pv enable in 0s
[lp-1  ] DEBUG 2023/09/08 08:41:49 pv enable timer elapsed
[lp-1  ] DEBUG 2023/09/08 08:41:49 max charge current: 10A
[lp-1  ] DEBUG 2023/09/08 08:41:49 charger: guard elapse
[lp-1  ] DEBUG 2023/09/08 08:41:49 guard timer inactive
[lp-1  ] DEBUG 2023/09/08 08:41:50 charger enable
[lp-1  ] DEBUG 2023/09/08 08:41:50 wake-up timer: start
[lp-1  ] DEBUG 2023/09/08 08:42:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:42:09 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:42:09 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:42:09 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:42:09 pv charge current: 7A = 0A + 7A (-1609W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:42:09 pv disable timer reset
[lp-1  ] DEBUG 2023/09/08 08:42:09 pv timer inactive
[lp-1  ] DEBUG 2023/09/08 08:42:39 charge power: 0W
[site  ] ERROR 2023/09/08 08:42:49 pv 1 energy: read failed: read tcp <IP_ADDRESS>:60804-><IP_ADDRESS>:502: i/o timeout
[lp-1  ] DEBUG 2023/09/08 08:42:59 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:42:59 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:42:59 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:42:59 pv charge current: 7.15A = 0A + 7.15A (-1644W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:43:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:43:09 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:43:09 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:43:09 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:43:09 pv charge current: 7.28A = 0A + 7.28A (-1674W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:43:39 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:43:39 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:43:39 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:43:39 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:43:39 pv charge current: 7.44A = 0A + 7.44A (-1712W @ 1p)

Manueller Stop/Start:
[lp-1  ] DEBUG 2023/09/08 08:49:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:49:09 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:49:09 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:49:09 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:49:09 pv charge current: 7.63A = 0A + 7.63A (-1754W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:49:13 set charge mode: off
[lp-1  ] DEBUG 2023/09/08 08:49:13 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:49:13 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:49:13 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:49:13 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:49:13 charger: guard elapse
[lp-1  ] DEBUG 2023/09/08 08:49:13 guard timer inactive
[lp-1  ] DEBUG 2023/09/08 08:49:13 charger disable
[lp-1  ] DEBUG 2023/09/08 08:49:13 wake-up timer: stop
[lp-1  ] DEBUG 2023/09/08 08:49:14 set charge mode: pv
[lp-1  ] DEBUG 2023/09/08 08:49:14 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:49:15 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:49:15 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:49:15 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:49:15 pv charge current: 7.72A = 0A + 7.72A (-1776W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:49:15 site power -1776W <= -1200W enable threshold
[lp-1  ] DEBUG 2023/09/08 08:49:15 pv enable timer start: 1m0s
[lp-1  ] DEBUG 2023/09/08 08:49:15 pv enable in 1m0s
[lp-1  ] DEBUG 2023/09/08 08:49:39 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:49:49 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:49:49 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:49:49 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:49:49 pv charge current: 7.66A = 0A + 7.66A (-1761W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:49:49 site power -1761W <= -1200W enable threshold
[lp-1  ] DEBUG 2023/09/08 08:49:49 pv enable in 26s
[lp-1  ] DEBUG 2023/09/08 08:49:49 pv enable timer remaining: 26s
[lp-1  ] DEBUG 2023/09/08 08:50:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:50:09 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:50:09 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:50:09 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:50:09 pv charge current: 7.96A = 0A + 7.96A (-1831W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:50:09 site power -1831W <= -1200W enable threshold
[lp-1  ] DEBUG 2023/09/08 08:50:09 pv enable in 6s
[lp-1  ] DEBUG 2023/09/08 08:50:09 pv enable timer remaining: 6s
[lp-1  ] DEBUG 2023/09/08 08:50:39 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:50:39 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:50:39 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:50:39 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:50:39 pv charge current: 7.75A = 0A + 7.75A (-1783W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:50:39 site power -1783W <= -1200W enable threshold
[lp-1  ] DEBUG 2023/09/08 08:50:39 pv enable in 0s
[lp-1  ] DEBUG 2023/09/08 08:50:39 pv enable timer elapsed
[lp-1  ] DEBUG 2023/09/08 08:50:39 guard enable in 34s
[lp-1  ] DEBUG 2023/09/08 08:51:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:51:09 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:51:09 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:51:09 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:51:09 pv charge current: 7.57A = 0A + 7.57A (-1741W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:51:09 site power -1741W <= -1200W enable threshold
[lp-1  ] DEBUG 2023/09/08 08:51:09 pv enable in 0s
[lp-1  ] DEBUG 2023/09/08 08:51:09 pv enable timer elapsed
[lp-1  ] DEBUG 2023/09/08 08:51:09 guard enable in 4s
[lp-1  ] DEBUG 2023/09/08 08:51:39 charge power: 0W
[site  ] ERROR 2023/09/08 08:51:49 grid energy: read failed: read tcp <IP_ADDRESS>:33362-><IP_ADDRESS>:502: i/o timeout
[site  ] ERROR 2023/09/08 08:51:49 read failed: read tcp <IP_ADDRESS>:33362-><IP_ADDRESS>:502: i/o timeout
[lp-1  ] DEBUG 2023/09/08 08:52:09 charge power: 0W
[lp-1  ] DEBUG 2023/09/08 08:52:09 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:52:09 charge total import: 3240.331kWh
[lp-1  ] DEBUG 2023/09/08 08:52:09 charger status: B
[lp-1  ] DEBUG 2023/09/08 08:52:09 pv charge current: 7.96A = 0A + 7.96A (-1831W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:52:09 site power -1831W <= -1200W enable threshold
[lp-1  ] DEBUG 2023/09/08 08:52:09 pv enable in 0s
[lp-1  ] DEBUG 2023/09/08 08:52:09 pv enable timer elapsed
[lp-1  ] DEBUG 2023/09/08 08:52:09 charger: guard elapse
[lp-1  ] DEBUG 2023/09/08 08:52:09 guard timer inactive
[lp-1  ] DEBUG 2023/09/08 08:52:09 charger enable
[lp-1  ] DEBUG 2023/09/08 08:52:09 wake-up timer: start
[lp-1  ] DEBUG 2023/09/08 08:52:39 charge power: 1690W
[lp-1  ] DEBUG 2023/09/08 08:52:39 charge currents: [9.21 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:52:39 charge total import: 3240.335kWh
[lp-1  ] DEBUG 2023/09/08 08:52:39 charger status: C
[lp-1  ] DEBUG 2023/09/08 08:52:39 charge start energy: 3.24e+03kWh
[lp-1  ] INFO 2023/09/08 08:52:39 start charging ->
[lp-1  ] DEBUG 2023/09/08 08:52:39 wake-up timer: stop
[lp-1  ] DEBUG 2023/09/08 08:52:39 pv charge current: 9.79A = 10A + -0.213A (49W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:52:39 site power 49W >= 1W disable threshold
[lp-1  ] DEBUG 2023/09/08 08:52:39 pv disable in 0s
[lp-1  ] DEBUG 2023/09/08 08:52:39 pv disable timer elapsed
[lp-1  ] DEBUG 2023/09/08 08:52:39 guard enable in 1m30s
[lp-1  ] DEBUG 2023/09/08 08:53:09 charge power: 1670W
[lp-1  ] DEBUG 2023/09/08 08:53:19 charge currents: [9.2 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:53:19 detected active phases: 1p
[lp-1  ] DEBUG 2023/09/08 08:53:19 charge total import: 3240.354kWh
[lp-1  ] DEBUG 2023/09/08 08:53:19 charger status: C
[lp-1  ] DEBUG 2023/09/08 08:53:19 pv charge current: 10.1A = 10A + 0.113A (-26W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:53:19 pv timer reset
[lp-1  ] DEBUG 2023/09/08 08:53:19 pv timer inactive
[lp-1  ] DEBUG 2023/09/08 08:53:39 charge power: 1670W
[lp-1  ] DEBUG 2023/09/08 08:53:49 charge currents: [9.18 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:53:49 detected active phases: 1p
[lp-1  ] DEBUG 2023/09/08 08:53:49 charge total import: 3240.368kWh
[lp-1  ] DEBUG 2023/09/08 08:53:49 charger status: C
[lp-1  ] DEBUG 2023/09/08 08:53:49 pv charge current: 10.1A = 10A + 0.143A (-33W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:54:09 charge power: 1670W
[lp-1  ] DEBUG 2023/09/08 08:54:09 charge currents: [9.15 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:54:09 detected active phases: 1p
[lp-1  ] DEBUG 2023/09/08 08:54:09 charge total import: 3240.377kWh
[lp-1  ] DEBUG 2023/09/08 08:54:09 charger status: C
[lp-1  ] DEBUG 2023/09/08 08:54:09 pv charge current: 10.2A = 10A + 0.165A (-38W @ 1p)
[lp-1  ] DEBUG 2023/09/08 08:54:39 charge power: 1670W
[lp-1  ] DEBUG 2023/09/08 08:54:39 charge currents: [9.14 0 0]A
[lp-1  ] DEBUG 2023/09/08 08:54:39 detected active phases: 1p
[lp-1  ] DEBUG 2023/09/08 08:54:39 charge total import: 3240.391kWh
[lp-1  ] DEBUG 2023/09/08 08:54:39 charger status: C
[lp-1  ] DEBUG 2023/09/08 08:54:39 pv charge current: 10.6A = 10A + 0.639A (-147W @ 1p)

Woran kann das liegen?
Gruß,
Martin
Steps to reproduce
siehe oben
Configuration details
siehe oben

Log details
siehe oben

What type of operating system are you running?
Docker container
Version
No response

Hier erkennt evcc dass es Laden könnte, es wird aber nicht richtig gestartet.

Es wird gestartet, aber nichts passiert:
[lp-1  ] DEBUG 2023/09/08 08:41:50 charger enable
[lp-1  ] DEBUG 2023/09/08 08:42:09 charge currents: [0 0 0]A

Warum lässt sich nicht sagen. Evcc scheint das Richtige zu tun. Probier mal bitte den Charger auf trace zu setzen damit wir mehr sehen.

Kann ich den loglevel im laufenden Betrieb ändern? Oder stoppen, config ändern, starten?

Keine neuen Erkenntnisse.

Hi,
sorry - bisher konnte ich das noch nicht wieder reproduzieren, da das Auto nicht geladen wurde bzw. nicht immer angesteckt war.
Heute Vormittag hat das Auto erst geladen. Dann wurde um ca. 10:14 das Laden aufgrund von zu wenig Überschuss gestoppt.
Gegen 10:45 hätte es wieder gestartet werden müssen.

So wie ich das sehe schreiben wir fleissig Ladefreigabe und Strom, es passiert aber nichts:
{"Values":{"ChargingStatus":{"Charging":true},"ChargingCurrent":{"Value":7},"DeviceMetadata":{"Password":"****"}}}

Da bliebe eigentlich nur mal den Support zu fragen, warum das nicht verarbeitet wird. Vielleicht ließe sich auch irgendwie rausfinden, ob die Freigabe im Charger erfolgreich verarbeitet wurde?

@andig : Ich finde gar kein PUT Request um das Laden zu stoppen?

Für mich sieht es so aus, als würde das Laden über GET gestoppt und über PUT gestartet. Ist das korrekt?
Wäre es möglich für den NRGKick das Laden zu stoppen/starten indem nur der Charging-Status geändert wird? Ohne gleichzeitige Angabe des Charging-Currents-Parameters?

Dein Punkt war doch:

Laden starten nicht mehr bei PV-Überschuss

Im Log (bzw. im Screenshot- deshalb kann ich auch nichts raus kopieren) sehe ich "disable in 1min". Vmtl. war dein Auto vorher schon voll- jedenfalls fehlt der Teil vom Log wo abgeschaltet worden wäre...

Der Teil vom Screenshot steht auch oben genauso im vorherigen Post. Das Auto war zu dem Zeitpunk nicht voll.

Es ändert doch nichts. Im Logfile siehst Du, dass evcc kein Ladeende sendet. Dennoch stoppt das Auto anscheinend. Warum  kann ich Dir nicht sagen. Außerdem gibts doch hier um den Ladestart???

Kannst du das bitte als „code“ formatieren?

Habs geändert.

Im Log fehlt site daher ist der Kontext unklar.


Update Documentation Images to Latest Interface and Formats

Updated all images to the latest Mattermost interface within the source/images directory. This update includes replacing outdated screenshots and, where necessary, changing image formats from PNG to GIF to enhance clarity and understanding in the documentation.

Summary

This pull request comprehensively updates the documentation images to reflect the latest Mattermost interface. The updates ensure that all screenshots are current and align with standard expectations. Additionally, some images were converted from PNG to GIF to provide better visual guidance where animations or multi-step processes were illustrated.
Ticket Link

Ticket Link
Milestone 02, 03, 04: #6658

Hello @yesbhautik,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

@yesbhautik - This is an outstanding docs PR with high impact! Thank you so much.
How easy would it be for you to do the following without a lot of rework?

remove the hand pointers from the screenshots
remove the red outlines from the screenshots

If it's easy, could you make these changes to all impacted screenshots, please? If it means entirely re-capturing the images, let's not introduce more work than you've already done.
Also, please ensure all mobile screenshots are scaled down to 30%. They're currently quite large on a given docs page.

I added hand pointers while taking screenshots because I thought they would provide better clarification for users. Regarding the red outlines, I only included them where they were previously present in the documentation.
As per your request, I can address the issue of hand pointers and remove them from the screenshots. However, in the case of red outlines, most of the screenshots where these outlines are present are outside the Mattermost platform, such as in Azure portal, Windows, and other external interfaces. Removing the red outlines from these could be quite challenging and may introduce errors or inconsistencies.
To effectively remove the red outlines, I can utilize premium software and AI tools to streamline the process. Please provide further confirmation so I can proceed with these adjustments.

How easy would it be for you to do the following without a lot of rework?

remove the hand pointers from the screenshots
remove the red outlines from the screenshots

If it's easy, could you make these changes to all impacted screenshots, please? If it means entirely re-capturing the images, let's not introduce more work than you've already done.

I added hand pointers while taking screenshots because I thought they would provide better clarification for users. Regarding the red outlines, I only included them where they were previously present in the documentation.
As per your request, I can address the issue of hand pointers and remove them from the screenshots. However, in the case of red outlines, most of the screenshots where these outlines are present are outside the Mattermost platform, such as in Azure portal, Windows, and other external interfaces. Removing the red outlines from these could be quite challenging and may introduce errors or inconsistencies.
To effectively remove the red outlines, I can utilize premium software and AI tools to streamline the process. Please provide further confirmation so I can proceed with these adjustments.

Also, please ensure all mobile screenshots are scaled down to 30%. They're currently quite large on a given docs page.

The mobile screenshots appear quite large because we used the original, high-resolution images. Scaling them down in the future could complicate updates. We have two possible solutions to address this:

Apply CSS to set a universal size for mobile screenshots across the documentation. This approach ensures consistency and can be easily adjusted in the future. However, implementing this may require opening another issue in the repository to handle the CSS changes.
Manually edit each screenshot to scale them down to 30%. This would involve altering the images directly, which could be more time-consuming and less flexible for future updates.

Please confirm which option you prefer to proceed with. If opting for the CSS solution, we can initiate a new issue to track and implement the changes.

@yesbhautik - Given the effort it will take to remove elements from the new product screenshots (advanced tooling and AI), I would prefer not to ask you to complete that extra work, given how much you've already contributed in this docs PR.
I do want to provide context as to why I explored the effort to remove the elements:

You're right that there are existing screenshots that include red outlines, and this convention is typically used for external tools beyond Mattermost. The red outline is a convention we definitely want to avoid in the product docs, going forward with Mattermost-based screen captures, because it's not inclusive from an accessibility perspective. Those with colour-based vision challenges see the red outline very differently, and those differences simply introduce noise to the image, not clarity.

The pointer icon is more of a branding consistency issue. We haven't included pointers in screenshots across the docs site, and if we decided to introduce such a convention, we'd want the pointer icons to be aligned with the Mattermost corporate brand.

Again, given the effort needed to remove these elements, I am open to accepting this PR as-is. However, note that there are merge conflicts that need to be resolved first. Any merge conflicts you're seeing are because another contributor is currently creating brand new mobile-specific screenshots as part of another docs campaign. Please review all current and previous merge conflicts (please go back and review merge conflict changes you applied previously) to ensure you're not overwriting the other contributor's contributions, please.

Given the effort it will take to remove elements from the new product screenshots (advanced tooling and AI), I would prefer not to ask you to complete that extra work, given how much you've already contributed in this docs PR.
I do want to provide context as to why I explored the effort to remove the elements:

You're right that there are existing screenshots that include red outlines, and this convention is typically used for external tools beyond Mattermost. The red outline is a convention we definitely want to avoid in the product docs, going forward with Mattermost-based screen captures, because it's not inclusive from an accessibility perspective. Those with colour-based vision challenges see the red outline very differently, and those differences simply introduce noise to the image, not clarity.
The pointer icon is more of a branding consistency issue. We haven't included pointers in screenshots across the docs site, and if we decided to introduce such a convention, we'd want the pointer icons to be aligned with the Mattermost corporate brand.

Again, given the effort needed to remove these elements, I am open to accepting this PR as-is.

Alright, no worries. Marge this PR after clearance if conflicts & image reducing the mobile screenshot scale. Just create new issue for removing RED OUTLINES & HAND ICONS over the all images, I will move forward into when I get free. Currently, I started working on #3872.

Hello, @cwarnermm. The issue with the mobile screenshot size scaling has been resolved.
Regarding the conflicts, I am getting some error in Web editor. Please find the attached screenshot. Could you resolve this minor conflict issue?

@yesbhautik - I may be mis-remembering that there were additional merge conflict resolutions that need to be revisited on this PR. If this is the first time you're encountering merge conflicts, then I can confirm that I'm mixing up this PR with others :)

If this is the first time you're encountering merge conflicts

Come on, I have worked with merge conflicts, but I am getting confused here. Also, I was unable to find conflicts details & reason.
No worries. Still tired.

@yesbhautik - Please revert/remove the following image updates from this PR:

source/images/mobile-bookmark-add-choice.png
source/images/mobile-bookmark-add-details.png
source/images/mobile-bookmark-add.png

And any other image update you've made whose filename starts with mobile- as they directly conflict with another contributor's updates.
Also - I didn't intend to suggest that you weren't familiar with merge conflict workflows. I was intending to say that if you and I haven't talked about merge conflicts until now in the context of this PR, that's entirely a mistake I've made by mixing up this PR with another PR.

@cwarnermm I have replaced my images with old images as it was.


How do I integrate your editor into my web application?

Is your feature request related to a problem? Please describe.
I'd like to use your marcdown-editor in one of my projects, but I have no idea how it is supposed to be used inside other projects.
Describe the solution you'd like
A documentation explaining how to use your editor inside other projects would help a lot.
Some kind of installation-manual would be nice.
Furthermore a short description on how to modify the code would be nice as well.
Describe alternatives you've considered
There is no alternative to a documentation ;)
Having some kind of build or deploy directory containing ready-to-use files that just needs to be included in the main HTML file will also work as long as the project is as small as this project is.
Additional context
I was just looking at the code to figure out if simple copy&paste would be enough to use your editor. Obviously it is not, because index.css defindes properties of body and other basic HTML elements. So using this file directly would break the whole application :)

How do I integrate your editor into my web application?

You'll have to wait couple of days until I release Marcdown Library ✨

Regarding documentation:

Marcdown is built with primarily two libraries:

MarkedJS - For markdown parser
highlightjs - For code highlighting
along with some help of HTML, CSS and JavaScript.

Regarding Marcdown Library (WIP) 🚀

Currently Marcdown is a standalone progressive web application to create, edit, view and save Markdown files. To use this in your own web application you can either build a similar application using MarkedJS and highlightjs or wait for Markdown library release. Library will be a single JavaScript file which you can import on any web application to make similar editor and preview screen 🎉👌

Introducing Marcdown Library (alpha) ⚗
Refer here for installation: https://github.com/liyasthomas/marcdown#installing
Refer here for sample file: https://github.com/liyasthomas/marcdown#example-html-file
More updates coming soon ✨


Release 10.4.0

Add lowContrast to DataRowItem

@merchako I am reluctant to use disabled as that has other implications than color, which we don't address here. I also don't feel the need to add other emphasis colors at the moment. What I do wonder is should we change the color variable here to match the disabled color and if you have an idea how to use the primary text color with 38% opacity.

I am going to stick with what we have and we can change if needed in the future.

:tada: This PR is included in version 10.4.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Rest-Auth registration not working with custom_signup with allauth

Hey guys,
I'm using rest-auth for my project and it's not working with the custom_signup that allauth has.
I'm setting ACCOUNT_SIGNUP_FORM_CLASS to a custom signup form, and I stuck a breakpoint in custom_signup from allauth and it never fires. I haven't looked into your guys' code yet but it doesn't seem to be calling the custom_signup function in accounts/forms.py in allauth.

use REST_AUTH_REGISTER_SERIALIZERS when using django rest auth....don't use the form....
http://django-rest-auth.readthedocs.io/en/latest/configuration.html

This isn't completely related to the issue, but does anyone know if I have to copy the source code RegisterSerializer functions, such as validate_email and validate_password, if I simply want to update the Registration fields? Is there a way to simply inherit django-rest-auth's RegisterSerializer, and update the required fields?
It seems redundant to copy the exact same code if I am simply wanting to update the fields. I want to add first_name, last_name and remove password2, but from my research it looks like I have to rewrite a custom RegisterSerializer that uses almost the exact same functions as the original serializer.


DI for RP Filters is a little confusing

In the opening section, this topic states that RP filters:

Have access to the following services:

IConfiguration
IHostEnvironment
IWebHostEnvironment

Can not access services other than the preceding by Dependency Injection (DI). The TypeFilterAttribute and ServiceFilterAttribute can access the services registered in the DI container. For more information, see ServiceFilterAttribute and TypeFilterAttribute.

These services aren't provided to the filter via DI. They're just passed in to the filter's constructor when added in Startup. The only DI here is into the Startup constructor, but that's not related to RP filters and how DI works for those. I don't think there's anything wrong with passing e.g. IConfiguration this way, but it's not DI and RP filters don't have special access to these. I think this makes the explanation a bit confusing.
I think I'd remove the first bullet and update the second to just indicate that DI can be used and link as it already does.
At a higher level, I'd like to see this page merged into the existing filters page. I realise that might not be practical, but it's just a thought given how closely related the two topics are.

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

ID: f0646a3d-a5d1-d4b0-5494-fe38219d16c9
Version Independent ID: 8b659e63-93b8-a496-bc9b-dce0d9fa8f3c
Content: Filter methods for Razor Pages in ASP.NET Core
Content Source: aspnetcore/razor-pages/filter.md
Product: aspnet-core
Technology: aspnetcore-razorpages
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

@Rick-Anderson I've edited in the content (I guess you don't get notifications for that).

Good idea. Can you PR this?

Can you PR this?

The DI changes or a merger?

DI changes.
Maybe we can patch the merger with cross linking for now.


SCRD-4770 Unhide server groups and nic mappings buttons when edit server in day2 UI

This commit includes:

Unhide buttons related to server groups and nic mappings in
edit server details in day2 UI.
In day2 UI:
The server groups used in deployed servers can not be deleted.
The existing networks and child server groups members in the
server group used by deployed servers can not be deleted.
User can add networks or child server groups in the server group
used by deployed servers.
User can not edit the server group name if the server group used
by deployed servers.
The nic mappings used by deployed servers can not be deleted.
The existing logical names and ports in the nic mapping used by
deployed servers can not edited or deleted.
The nic mapping name can not be edited if it is used by deployed
servers.
User can add new logical name + ports for a nic mapping used by
deployed servers..
User can still can add new server group or nic mapping
User can still edit or delete server group or nic mapping that is
not used by deployed servers.

In day0 UI:
User should be able add/delete/edit server group and nic mappings.
Note: the UI goes with change in https://gerrit.suse.provo.cloud/#/c/5356/

Thanks for the fix. Looks much better. Note: did not test this.


Add roberta pooling layer to the trainable arguments

Roberta randomly initialises the top pooling layer when loaded from transformers. Ideally, this layer should be trained in full, and not just with LoRa, to avoid random noise.

Let me, in that case, not merge this PR and we can add this if we actually decide to use the pooler. To avoid clutter in the code.


Not possible to navigate to a particular authentication once the auth fields are populated

Entered request url, user/pwd in basic auth. Cannot go back to 'Basic'. If Digest is selected, basic as well as digest are shown to be selected.

Proposed solution: Similar to checkboxes against tags in request builder section, there should be radioboxes against authentication types. When one type is selected, automatically other types are deselected even if fields are populated.

New design made. To be reviewed before implementing, @ranjan-rk


nixos/nix-daemon: Add enable option

Motivation for this change
Don't worry, it's is true by default. But I think this is important to
have because NixOS indeed shouldn't need Nix at run time when the
installation is not being modified, and now we can verify that.
NixOS images that cannot "self-modify" are a legitamate
use-case that this supports more minimally. One should be able to e.g. do a
sshfs mount and use nixos-install to modify them remotely, or just
discard them and build fresh ones if they are run VMs or something.
The next step would be to make generations optional, allowing just
baking /etc and friends rather than using activation scripts. But
that's more involved so I'm leaving it out.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

I love the concept of this - I've been toying with this idea myself as well. Being able to build a NixOS image using Nix but without Nix in the runtime closure is a super interesting idea.

Ugh, i forgot about nixosTests. The layering violation leaves me deeply unsettled.

Is the pkgsFun portion needed to completely remove nix from the closure?

@tomberek Not sure, maybe I'll save that for later.


Support filters on the image

From @talapadi on July 24, 2018 14:49
Filters such as black and white, noise etc
Copied from original issue: chimple/maui#631

Done and tested


Update Select component to follow conventions

update name to Select and references to it in sass, etc
replace "options" array name with "items"
replace inputName parameter with name
replace labelText and labelClasses with a label object that takes the
same parameters as the label component
add functionality to specify "selected" property in an item
update template to to reflect changes above
update example in select.njk file
update table of arguments to reflect changes
add functionality to specify html attributes that get appended to
the element
update YAML file to reflect new parameters

Trello ticket: https://trello.com/c/Hx0HRqIz/257-update-selectbox-component-api-and-name

You've committed all the changed READMEs as well – intentional?

oh no, reverting...

updated, with single argument option for label text and error message removed


042 master hangs up after a couple of seconds

just programmed https://github.com/mck1117/wideband/commit/f784d5d5b91b0d4528596ff69e7f543b37e84ff9 artifact into hardware which is known to run https://github.com/mck1117/wideband/releases/tag/first-release
I see a second of green and blue LED blinking and then both lights go off. Also no data on the CANbus

it's overflowing RAM and for some reason the linker isn't catching it


After add plugins my project can not be opened by ue4

I did Binary installation on Windows .affter create Plugins directory in myproject root directory and unzip the plugin into it and end with /Plugins/UnrealEnginePython.
Then i use ue4 to open my project , it said Missing Modules and rebuild them , but always error with "your project could not be compiled . try rebuilding from source manually."
How can i fix it?
thanks

Python 3.6.8
UnrealEngine 4.22.3
in windows 10 64bit


JerseySupport error response masking hard coded

Environment Details

Helidon Version: 2.2.1-SNAPSHOT
Helidon SE or Helidon MP
JDK version: N/A
OS: N/A
Docker version (if applicable):

Problem Description
Hiding/masking of error responses is hard coded in JerseySupport.java#119. With applications that already sanitise the error responses there is often a desire to be able to consume the payload.
This has two problems:

Moving away from default behaviour of Jersey Client which will cause confusion,
Not possible to disable.

IMO this is opt-in behaviour and should be neither the default or hard-coded.
Steps to reproduce
N/A

@dansiviter We absolutely need to change the default as this behavior presents a security risk. The app can override this by re-setting the property, but I agree this can be tricky as it depends on the loading of JerseySupport. One possible minor improvement would be for the code to make sure the property is unset (null) before setting it. The way an app could override this externally. Would that help in your case?
Application developers can also define their own exception mappers.

Depends on your interpretation of a security risk. I expect if I use Jersey, ReSTEasy URLConnection or any other client library that I would be able to read the payload without configuration regardless of status code. That in itself is not a risk. The risk comes when the downstream system bleeds information when a error occurs. Therefore, I understand why there is an option to opt-in to hiding the payload, but it shouldn't be the default and it must be configurable.
It also concerns me that the only way to supply this is via system properties. It should come from the normal configuration mechanism so the value can be set globally in application.yaml or equivalent.

Thinking about it, if we can just have this come from the normal configuration mechanism this would suffice. Happy for it to default to true if we can globally set this (not via System properties).

PR #2737


MM-18818: Don't display default Support Email

Summary
Support gets emails from users that should be going to the users own support. Currently if the Support Email is empty, we don't display it. This PR expands that to if the Support Email is the default (feedback@mattermost.com), it won't display it.
Ticket Link
https://mattermost.atlassian.net/browse/MM-18818
Related Pull Requests
Screenshots

/update-branch

@sbishel can you please fix the failing unit tests.

/update-branch

/update-branch

Closed. After further review, this fix is not correct. This will remove the help email from community. Need a different fix.

/update-branch


Hi

What article on docs.github.com is affected?

What part(s) of the article would you like to see updated?

Additional information

What article on docs.github.com is affected?

What part(s) of the article would you like to see updated?

Additional information


Panic or crash when creating a timer with MHz frequencies

First of all, I would just like to add that I'm not very experienced with embedded rust, and I might just be missing something trivial. However, I have looked through all the examples in this repo, and read the relevant pages in the crate documentation, but I'm none the wiser.
I'm trying to create a timer for use with the ws2812-timer-delay crate, which requires a timer running at 3MHz. When I try to implement this timer, the board doesn't do anything, and I've narrowed the problem down to the second line in this snippet.
let mut led_timer = Timer::new(c.device.TIM1, clocks, &mut rcc.apb2);
led_timer.start::<Nanoseconds>(3.MHz().to_duration().unwrap());

If I comment it out, the code works, but if I include it, the board just "freezes" which I'm assuming means it has panicked or crashed.
If I change it to Microseconds and 3.kHz(), the board works, but I can't use a clock of 3kHz.
In case it is relevant, the board in question is an STM32F303CB (On an OLKB planck rev6 board)
Is this behavior expected, and in that case why? Otherwise, am I doing something wrong, and how would I go about making a 3MHz timer?

Okay, so this is definitely a bug. I've found out the cause. Thanks for the reports.
The panic is caused by a division of 0, which was caused by an unsigned integer overflow  ... :(
I've come up with a fix, will open an MR soon (I hope)
But in addition to the bug, I advise you to increase the Bus Clock speed of which the timer is connected to (PCLK2 in this case AFAIK), so that the resolution of the timer frequency is high enough. E.g 3.MHz with a rcc.cfgr.pclk2(8.MHz()) might result into 4 MHz.
Sadly, even with my fix, setting the resolution like this is not very precise. Especially for frequencies close to the peripheral clock.
Maybe I should expose API to set the psc and the arr values directly.

I've also found another bug in the timer implementation. When the timer was awaited once (timer.wait()) the Update event was never cleared, so the next (timer.wait()) call would return immediately, independent of the timer frequency :(

I've released version v0.9.2, which includes the fixes. Can you report, if this fixes your problem?
https://crates.io/crates/stm32f3xx-hal/0.9.2

Seems to work now! Thanks a lot for the quick response and fix! :D

For the record, I used rcc.cfgr.pclk2(24.MHz()), and it seems to work well enough to control the ws2812 leds

Thanks! :) You were lucky, that I was already working on this project that day, which I've neglected because of lack of time the last months :see_no_evil: :grinning:


get_client_config does not fetch from default file location.

In get_client_config, the documentation states:
"""
In Linux clients, the omnisci client configuration is read from:
    :code:`$HOME/.config/omnisci/client.conf
"""

However, creating such file in the default location (/home/<user>/.config/omnisci/client.conf) still has no effect. Only after exporting the file location to OMNISCI_CLIENT_CONF is it actually parsed/processed.

I just tested and it seems to be working fine.
diff --git a/rbc/omniscidb.py b/rbc/omniscidb.py
index 56f8001..6facd3a 100644
--- a/rbc/omniscidb.py
+++ b/rbc/omniscidb.py
@@ -187,6 +187,7 @@ def get_client_config(**config):
         return config

     conf = configparser.ConfigParser()
+    print(f'reading conf file from: {conf_file}')
     conf.read(conf_file)

     if 'user' in conf:

Leads to:
$ pytest -rs -sv --disable-warnings --tb=line rbc/tests/test_omnisci_array_methods.py -k sum_initial
============================================================================================== test session starts ==============================================================================================
platform linux -- Python 3.9.7, pytest-6.2.5, py-1.11.0, pluggy-1.0.0 -- /home/guilhermeleobas/miniconda3/envs/rbc/bin/python
cachedir: .pytest_cache
rootdir: /home/guilhermeleobas/git/rbc, configfile: setup.cfg
collecting ... reading conf file from: /home/guilhermeleobas/.config/omnisci/client.conf
 OmnisciDB version (6, 0, 0, 'dev-20211207-0b597423f8')
collected 14 items / 13 deselected / 1 selected

rbc/tests/test_omnisci_array_methods.py::test_ndarray_methods[sum_initial] reading conf file from: /home/guilhermeleobas/.config/omnisci/client.conf
PASSED


Support different CSV dialects

Provide an API for users to specify the dialect a given CSV file is using.

See discussion here: https://github.com/openspending/openspending/issues/859

@akariv what do you mean the dialect a given CSV file?

@akariv I was part of it)
I don't see what datapackage-py needs else from tabulator API (more than implemented now):
table = topen('path.csv',
        parser_options={'delimiter': ';', 'any_other_csv_params': ..., dialect: SniffingDialect()},
        parser_class=parsers.CSV,  # by default for this file type but it will be right to set it explicitly while passing options
)

CLOSED
@akariv
@vitorbaptista
Please re-open if current API is not enough.


Unable to persist session using blazor wasm

I have been looking through and I can't seem to find any information, I followed the blazor example, and keep getting errors when trying to retrieve the session, I also don't see at any point when the load session code is run, you have RetrieveSessionAsync, however this doesn't from what I can see, this doesn't call the session handler, if the user logs in then it seems to work, however if they close the browser this does not work, and I have debugged the code and at no point does the SessionHandler.LoadSession() get run.

Can you take a look here and see if it answers?
https://github.com/acupofjose/supasharp-todo/blob/master/SupasharpTodo.Shared/Providers/SupabaseAuthenticationStateProvider.cs

Not sure about Blazor, but in the Unity template the session is loaded once as part of the client initialization, and then the persistence session handler is called later to save it. Idea being that the session is loaded once off disk when the app launches but otherwise the client is running and the session is in memory, persisted on occasion depending on events.
https://github.com/wiverson/supabase-unity-template/blob/0894da86cbcb73fe7c7f0dd6e7a1793fa26f98cb/Assets/App/com/example/SupabaseManager.cs#L27

That looks to be working thank you for your help and quick reply


gnomeExtensions.tophat reports GTop not found on nixos-unstable channel

Describe the bug
When I trying to use this extension on nixos-unstable channel, it reports:
Requiring GTop, version none: Typelib file for namespace 'GTop' (any version) not found

Already tried workaround: https://github.com/fflewddur/tophat/issues/106#issuecomment-1848319826, but it still cause same error.
Steps To Reproduce
Steps to reproduce the behavior:

Install gnomeExtensions.tophat
Logout and login to gnome-shell
tophat will not working and report error

Expected behavior
gnomeExtensions.tophat should not report any error and display correct status on topbar
Screenshots

Additional context
There is indeed a related patch for this extension: https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4cdcdd85627df25aec55/pkgs/desktops/gnome/extensions/extensionOverrides.nix#L122C1-L129C6, but for some reason it is not working on unstable channel. Not sure for the cause.
Notify maintainers
@jtojnar

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.6, NixOS, 24.05 (Uakari), 24.05.20231211.a9bf124`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(root): `"nixos"`
 - nixpkgs: `/nix/store/4fgs7yzsy2dqnjw8j42qlp9i1vgarzy0-source`

Add a :+1: reaction to issues you find important.

There is a PR to fix it properly but it will require rebase onto GNOMR 45: https://github.com/NixOS/nixpkgs/pull/267160


Set up README doc

Also add keywords to the package.json when you add the README
keywords:

knob
dial
ui
component
components
javascript
js
html
css
sass
scss

Resolved by commit: https://github.com/jhnsnc/knob-input/commit/6b61574f0a72c9331369b78661658a8b3ace9349


instagram signup is buggy

at least two problems:

indieauth fails for @zegnat because he uses his own auth endpoint, https://vanderven.se/martijn/auth/ , which we somewhat handle ok, but its verification response doesn't return me, which we don't handle ok. IRC discussions, snarfed/oauth-dropins@d65d415d32b5c5920ec5daeb778ee58b301d3ecc, snarfed/oauth-dropins@f8ff52eb4b02952e8dfeaea62442c400d330547d.
when i try to log in, indieauth works ok, but then the IG profile page fetch gets rate limited, which breaks badly with an IG-rendered error page 😂 😭.

apologies @zegnat, but i may deprioritize 1 until if/when you actually use bridgy. 😆 2, though, i should look at.
cc @aaronpk

I am curious about tracking down that IndieAuth error though. I'm not sure why the verification response didn't return me, since that's how IndieAuth works. Could be an error on Zegnat's endpoint with something. Maybe the right answer is to better surface or log the error responses during that part of the flow so this is easier to troubleshoot. Now that Wordpress is about to get its own built-in IndieAuth endpoint, people using Bridgy will be getting this IndieAuth response from a lot more different sites than just indieauth.com soon.

we debugged more and determined that i'm not sending an Accept header or otherwise doing conneg in the code verification request, but i'm expecting a form-encoded response, and @zegnat's endpoint is returning JSON: {"me":"https:\/\/vanderven.se\/martijn\/"}. the spec also says the response is JSON.
@zegnat says his endpoint should default to form-encoded though, not JSON: https://gist.github.com/Zegnat/4ad87603bcabbf8e095363df99845e50 . the plot thickens.

@zegnat added logging and reported that i'm sending Accept */* (maybe added by app engine urlfetch), which triggers him to return json. got it. thanks for the sleuthing @zegnat!

i updated the signup profile fetch to ignore rate limiting.

@zegnat i think this is fixed, so your auth endpoint should work now. feel free to try!

I also have issues authenticating with my site. The error message I see after the redirect is:

HTTP Error 400: 400 Bad Request The server could not comply with the request since it is either malformed or otherwise incorrect. IndieAuth verification failed: error=Invalid+auth+code

The URL looks fine to me (includes code=123abc, and the state param is being accepted.

looking at the log from one of your indieauth callback requests:
GET /instagram/callback?code=CODE&state=%257B%2522endpoint%2522%253A%2522https%253A%252F%252Fupdates.kip.pe%252Findieauth%252Fauth%2522%252C%2522me%2522%253A%2522https%253A%252F%252Fupdates.kip.pe%2522%257D&me=https%3A%2F%2Fupdates.kip.pe%2Fprofile%2Fbasti

decoding state "%7B%22endpoint%22%3A%22https%3A%2F%2Fupdates.kip.pe%2Findieauth%2Fauth%22%2C%22me%22%3A%22https%3A%2F%2Fupdates.kip.pe%22%7D"
requests.post https://updates.kip.pe/indieauth/auth {'data': {'me': u'https://updates.kip.pe', 'state': '', 'code': u'CODE, 'client_id': 'https://brid.gy/', 'redirect_uri': 'https://brid.gy/instagram/callback'}}
Error 400, response body: u'400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n IndieAuth verification failed: error=Invalid+auth+code '

...auth code and me do indeed look fine.

@skddc here's the auth code verification request bridgy makes, as a curl command:
$ curl -v -d 'me=https%3A%2F%2Fupdates.kip.pe&state=&code=CODE&client_id=https%3A%2F%2Fbrid.gy%2F&redirect_uri=https%3A%2F%2Fbrid.gy%2Finstagram%2Fcallback' https://updates.kip.pe/indieauth/auth
...
< HTTP/1.1 400 Bad Request
...
error=Invalid+auth+code

here's a simplified, more readable version, without the non-standard me and state parameters. same result:
curl -v -d 'code=CODE&client_id=https://brid.gy/&redirect_uri=https://brid.gy/instagram/callback' https://updates.kip.pe/indieauth/auth

i'm replacing CODE with an auth code bridgy got from the callback above from your auth endpoint, 2018-06-27 16:53:32 UTC. this failure may be because the code expired, though, so maybe i can catch you in person to debug together.

looks like this may be a bug in known, or at least a bad interaction between it and bridgy. @rikmendes had the same problem with https://rmendes.net/ , also on known.
hey @mapkyca, any tips on how we could debug this? known users are having trouble logging into bridgy (instagram) with their sites' indieauth. details above.

Hmm... do we have a record of what's sent to known / getting from known? (I've not got a public instagram, so not tried to replicate)

I could retry it and tell you the exact time and URL of the request if that helps.

@mapkyca thanks for looking! you don't actually need an instagram account to repro on https://brid.gy/ , just click the instagram button and then try to log in with indieauth.
the initial redirect from bridgy to known looks like this:
https://updates.kip.pe/indieauth/auth?me=https%3A%2F%2Fupdates.kip.pe&state=%257B%2522endpoint%2522%253A%2522https%253A%252F%252Fupdates.kip.pe%252Findieauth%252Fauth%2522%252C%2522me%2522%253A%2522https%253A%252F%252Fupdates.kip.pe%2522%257D&redirect_uri=https%3A%2F%2Fbrid.gy%2Finstagram%2Fcallback&client_id=https%3A%2F%2Fbrid.gy%2F

known then redirects back to bridgy with an auth code:
https://brid.gy/instagram/callback?code=CODE&state=%257B%2522endpoint%2522%253A%2522https%253A%252F%252Fupdates.kip.pe%252Findieauth%252Fauth%2522%252C%2522me%2522%253A%2522https%253A%252F%252Fupdates.kip.pe%2522%257D&me=https%3A%2F%2Fupdates.kip.pe%2Fprofile%2Fbasti

bridgy then tries to verify the auth code - details above in https://github.com/snarfed/bridgy/issues/809#issuecomment-401585415 - which known 400s.

Hmm... bridgy seems to not like private accounts. I'll see if I can create a new instagram and try again...

@mapkyca true, but this bug happens during indieauth, before bridgy looks at your Instagram account at all. if you were able to indieauth with known successfully, then you didn't reproduce the bug. maybe you're on a newer known version that fixed it?

I'm on ec0752d (June 18), if that helps.

Oh, that actually works. So maybe that's how I did it back when setting it up the first time. Thanks!
Would be nice if people with single-user instances could just use their domain name, of course. My profile does appear on the frontpage, too.

If you have a single user install you can use the domain, but you have to explicitly set "single user" mode. This is because that mode puts the user header on the top of the front page, which has all the rel=me links that IndieAuth uses...

That's what I haven, and yet it doesn't work.

Interesting... so you're saying that https://yoursite.com/profile/skddc works but https://yoursite.com doesn't?

Yes, see my original comment: https://github.com/snarfed/bridgy/issues/809#issuecomment-400754726

I found out what broke it. See my last comment in the linked Known issue.

glad you figured it out!


When the business has a hot spot, the latency of apply log is too high

Bug Report
What version of TiKV are you using?

TiKV
Release Version: 5.2.0
Edition: Community
Git Commit Hash: d1967b8
Git Commit Branch: heads/refs/tags/v5.2.0
UTC Build Time: 2021-08-14 02:02:01
Rust Version: rustc 1.56.0-nightly (2faabf579 2021-07-27)
Enable Features: jemalloc mem-profiling portable sse protobuf-codec test-engines-rocksdb cloud-aws cloud-gcp
Profile: dist_release
What operating system and CPU are you using?
tiup ：
1PD
1TiDB
3TiKV
all node：500G NVME、4 cores、8G mem
Steps to reproduce
1、run sysbench prepare
threads=128
tableNum = 512
tableSize =<PHONE_NUMBER>0
sysbench --config-file=/root/config oltp_point_select --tables=512 --table-size=10000000000 --auto_inc=true prepare
2、A few minutes later，one node is mistakenly detected as a slow node
What did you expect?
the latency of apply log can not be high，such as seconds
What did happened?
the latency of apply log is few seconds

/type bug

/severity major

/assign BusyJay

This is working as expected. I think it's an improvement.


Fixed version without corrupted colors.js version released

The underlying lib qrcode has a dependency of the lib colors.js which was corrupted on purpose by its author [1]. Read the article Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps by BleepingComputer.
As the author of the original qrcode dependency currently has no time to release a fixed version, I forked [2] the qrcode lib and bumped the dependency to a fixed version [3].

[x] angularx-qrcode 13.0.3 was released today with a fork of the lib, which makes no use of the affected colors.js versions.
[x] The dependency will be switched back the moment there is a fix released.

[1] colors.js
https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/
[2] The used fork is located here:
https://github.com/Cordobo/node-qrcode
[3] Commit changes
https://github.com/Cordobo/node-qrcode/commit/e09bcd350aa664d4ddc3699617607197d6368a32

This fix was reverted in angularx-qrcode 15.


Add an option to clear recorded sounds upon capture initiation

When the user clicks 'Capture' while there are still unadded captured files selected, a dialog prompt should be shown, asking whether the list should be cleared or new files should be appended to the existing ones.

Tested:

a dialog prompt is shown when there are already unuploaded captured filed (at least one)
a dialog prom is not displayed if captured audio is already uploaded
a dialog prom is not displayed if audio was selected from the phone


Clarify the ErrorCollector API regarding errKey

This is a followup to this discussion.
In this PR I've made some changes to the ErrorCollector interface, in order to clarify how errKey is expected to be used.
Before this change, one would be able to pass in more than a single errKey value, while in fact only the first value in the slice would ever be used in order to determine the aggregation key. With this change, it is clear that errKey is a single value.
While working on this, I had to make some changes to some function signatures. I did my best to preserve what I could, but this is certainly a breaking change for those who are already passing in errKey through any of the Report*() functions, and for those who use Report(err) and relying on the default SeverityError.
The new interface of ErrorCollector after this change is:

Before
After

Report(err error)
Report(report ErrorReport)

ReportError(err error)

ReportWithSeverity(err error, severity Severity, errKey ...string)
ReportWithSeverity(err error, severity Severity)

ReportWithHTTPContext(err error, httpCtx *HTTPContext, errKey ...string)
ReportWithHTTPContext(err error, httpCtx *HTTPContext)

ReportWithHTTPContextAndSeverity(err error, severity Severity, httpCtx *HTTPContext, errKey ...string)
ReportWithHTTPContextAndSeverity(err error, severity Severity, httpCtx *HTTPContext)

ReportWithHTTPRequest(err error, r *http.Request, errKey ...string)
ReportWithHTTPRequest(err error, r *http.Request)

ReportWithHTTPRequestAndSeverity(err error, severity Severity, r *http.Request, errKey ...string)
ReportWithHTTPRequestAndSeverity(err error, severity Severity, r *http.Request)

ReportErrorWithContext(errWithContext ErrorWithContext, severity Severity, errKey ...string)
ReportErrorWithContext(errWithContext ErrorWithContext, severity Severity, errKey string)

FYI @marctc


Provide standardized interface for calling reference interpreter

Request description
Today, it isn't practical to call the StableHLO reference interpreter. Invoking the interpreter requires going through the MLIR translate infrastructure (i.e. via interpretRegistration in StablehloTranslateMain.cpp), and does not currently support specifying user inputs into a model or doing any meaningful post processing on the model outputs short of printing them to screen. This makes it difficult to run StableHLO MLIR models.
It would be great to provide a standardized API to call into the StableHLO reference interpreter, in which clients could specify the following:

The StableHLO MLIR (or ModuleOp) to be executed
The model inputs, as InterpreterValue instances
An optional interpretation fallback callback (which defaults to the existing interpreterFallback in StablehloTranslateMain.cpp)

Akin to eval, the interface could return a SmallVector<InterpreterValue> of result tensors. While I think the eval method might be able to be repurposed for this feature, I think lower level abstractions (such as Regions, Scopes and Processes should not be something which are required & exposed to downstream users).

This has been completed in https://github.com/openxla/stablehlo/pull/1784 and a few followup PRs


[Feature] 🌈 Make In English Please

Describe the problem related to the feature request
[Feature] 🌈 Make In English Please
Describe the solution you'd like
[Feature] 🌈 Make In English Please
Describe alternatives you've considered
[Feature] 🌈 Make In English Please
Additional context
[Feature] 🌈 Make In English Please

要改config.js吧

There is no plan to make this project in English.
Just because it would spend experience maintaining i18n.
You can use Translate Plugin to instead of offical i18n

please

make antoher repo https://github.com/Harry-zklcdc/go-proxy-bingai-en


feat: add cli test mode

CLI supports building in test mode to enable mocking the profile
See README for details.

I reviewed changes in 941143e13b16fbfb1b7567b08223f31e07b4d847, caa96df37932e67bc47a111a3ec50b1e7ae415ab, and 8c939a99b7002a9a31257a640580deb1a752b43c


Math formula position are detected wrongly

Description
In my PDF I have some math formula. I encounter no problem when reading the file with pdfminer, but the position of the math is wrong.
Because of this, pdfminer can't group text into meaningful paragraph.
Files
p1.pdf
Code
from pdfminer.high_level import extract_pages

for page in extract_pages('p1.pdf'):
    for elem in page:
        print(elem)

Result

[...]
<LTTextBoxHorizontal(6) 89.997,606.158,241.137,618.158 'Methods of Calculation\n'>
<LTTextBoxHorizontal(7) 89.997,574.914,221.639,599.143 'The nominal total shear stress \nflow \n'>
<LTTextBoxHorizontal(8) 119.551,574.914,288.717,585.414 ' at that point, by the following equation:\n'>
<LTTextBoxHorizontal(9) 231.790,588.643,541.299,599.143 ' in the side shell or longitudinal bulkhead plating is related to the shear\n'>
<LTTextBoxHorizontal(10) 222.627,565.050,231.783,576.984 'fs\n'>
<LTTextBoxHorizontal(11) 138.131,550.102,239.360,560.750 'N/t, kN/cm2 (tf/cm2, Ltf/in2)\n'>
<LTTextBoxHorizontal(12) 138.125,530.049,261.020,539.049 'shear flow,  kN/cm (tf/cm, Ltf/in.)\n'>
<LTTextBoxHorizontal(13) 138.125,512.049,254.864,521.049 'thickness of the plating, cm (in.)\n'>
[...]

Problem
As we can see on this screen shot :

I am supposed to find a single line containing :

The nominal total shear stress fs in the side shell or longitudinal bulkhead plating is related to the shear
flow N at that point, by the following equation:

But instead, I have :

The nominal total shear stress \nflow \n located at y=574 (Nothing wrong)
fs\n located at y=565 (Wrong position ! Should be on the same line as previous)
[...]

Because the math is located at the wrong position by pdfminer, paragraph can't be gather to meaningful sentences

Is there anyway to fix this problem ?

I agree there is an issue here... the bounding box for the fs is way too low, and this is causing the rest of the text to be interpreted wrong.

I'm afraid I am not very familiar with the part of the code than handles this, and don't have much time at the moment, so am not sure what a fix might be at this stage.

Hey thanks for the fast answer !
Quick question, how did you display the boxes in blue like this ? In my browser, the bounding boxes are fine.
Is it a debug tool specific to pdfminer ?

Hey! It's actually using a tool I built on top of pdfminer.six (py-pdf-parser), so no it's not a debug tool specific to pdfminer, but for me it allows me to check these things quite quickly. I have seen other people posting similar screenshots, so I think it may be possible some other way too.
I notice that when I highlight the text in my PDF viewer, certain lines appear way bigger than they should, so it could actually be some problem with the PDF.
In the following screenshot, I am highlighting "shear flow" and it works correctly:

However, in this one I am highlighting "The nominal total shear", and it's too big (probably down to where that wrong character box is showing):

This does lead me to think that perhaps it's some way that the PDF is generated... however we may somehow be able to fix this I don't know.

Thanks for your answer !
There must be a way, because my browser is fine :

I will search more...

I wonder if this is the same problem as  #618, with the "descent variable " somehow getting the wrong value...


Update For XiangweiTest.md

:warning: Validation status: warnings

File
Status
Preview URL
Details

Docs/Test04/For XiangweiTest.md
:warning:Warning

Details

Docs/Test04/For XiangweiTest.md

Line 35: [Warning] Invalid file link:(~/active-directory-get-started-premium.md).

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:warning: Validation status: warnings

File
Status
Preview URL
Details

Docs/Test04/For XiangweiTest.md
:warning:Warning

Details

Docs/Test04/For XiangweiTest.md

Line 35: [Warning] Invalid file link:(~/active-directory-get-started-premium.md).

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


View conversion to SwiftUI

Downloads view has been converted and it seems to work pretty well.

Onboarding: Low-stakes. Done
Preferences: I have this working in a Playground, but to get the proper Settings view toolbar with a TabView involves conversion to the SwiftUI lifecycle instead of the AppKit one, or manually frobbing NSToolbar (gross).
Tracklist: Good low-risk opportunity to use tables bound to an array. Will probably involve a refactor of SBPlayer in Swift to expose the tracklist as an @ObservableObject?
Library views (Music, ServerLibrary, etc.): Would involve a lot of @FetchRequest...
Database: Would be a good way to clean up the awful mess there. Wiring up sheets, subviews, and selectors sounds nightmarish though.

Concerns would be:

We have extensive NSTableView customization and common patterns, how hard would these be with SwiftUI Table?

I have a prototype of Database in a SwiftUI test project with:

view switching in sidebar
enumerates playlists in servers

But:

toolbar, right sidebar, and actions not implemented yet

SwiftUI has a very annoying issue for the tracklist (and probably playlist) case, where you can't really have multiple of the same tracks in whatever collection the Table/List represents, because the selection is based by a Set<SBTrack>, not by an index. It'd need a data model change, or regress to the pre-index change. Might have to play with .enumerated() sometime...

Another issue is that Table requires macOS 12. We still support 11, but I don't know if it'd be worth dropping it. App Store users look to be mostly on 12 or 13.


added lib/pq to the vendor dir and renamed the go-sqlmock to its version

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-traffic_ops-test-PR/22/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/61/


python312Packages.ruff: 0.7.2 -> 0.7.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.ruff is: Extremely fast Python linter
meta.homepage for python312Packages.ruff is: https://github.com/astral-sh/ruff
meta.changelog for python312Packages.ruff is: https://github.com/astral-sh/ruff/releases/tag/0.7.3
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.7.3 with grep in /nix/store/1pa5w5r1yyfavjywvlqx9vqdwdknj9hf-python3.12-ruff-0.7.3-bin
found 0.7.3 in filename of file in /nix/store/1pa5w5r1yyfavjywvlqx9vqdwdknj9hf-python3.12-ruff-0.7.3-bin

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

40 total rebuild path(s)

40 package rebuild(s)

First fifty rebuilds by attrpath

dmarc-metrics-exporter
marimo
nbqa
nixpkgs-openjdk-updater
open-webui
openapi-python-client
python311Packages.explorerscript
python311Packages.ifcopenshell
python311Packages.marimo
python311Packages.pyhanko
python311Packages.pytest-examples
python311Packages.pytest-ruff
python311Packages.python-lsp-ruff
python311Packages.ruff
python311Packages.skytemple-dtef
python311Packages.skytemple-files
python311Packages.skytemple-ssb-debugger
python311Packages.xhtml2pdf
python311Packages.xsdata
python312Packages.explorerscript
python312Packages.ifcopenshell
python312Packages.marimo
python312Packages.pytest-examples
python312Packages.pytest-ruff
python312Packages.python-lsp-ruff
python312Packages.ruff
python312Packages.skytemple-dtef
python312Packages.skytemple-files
python312Packages.skytemple-ssb-debugger
python312Packages.xsdata
ruff
ruff-lsp
skytemple
tests.devShellTools.nixos
tests.testers.lycheeLinkCheck.network
tests.testers.nixosTest-example
tests.testers.runNixOSTest-example
tests.trivial-builders.references
vunnel

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/1pa5w5r1yyfavjywvlqx9vqdwdknj9hf-python3.12-ruff-0.7.3-bin \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

Or:
nix build github:r-ryantm/nixpkgs/4a1393afe0f1e6e2a013e4e7ceba8cdeea0a3db3#python312Packages.ruff

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/1pa5w5r1yyfavjywvlqx9vqdwdknj9hf-python3.12-ruff-0.7.3-bin
ls -la /nix/store/1pa5w5r1yyfavjywvlqx9vqdwdknj9hf-python3.12-ruff-0.7.3-bin/bin

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

x86_64-linux

:white_check_mark: 64 packages built:

dmarc-metrics-exporter
dmarc-metrics-exporter.dist
marimo (python312Packages.marimo)
marimo.dist (python312Packages.marimo.dist)
nbqa
nbqa.dist
nixpkgs-openjdk-updater
nixpkgs-openjdk-updater.dist
open-webui
open-webui.dist
openapi-python-client
openapi-python-client.dist
python311Packages.explorerscript
python311Packages.explorerscript.dist
python311Packages.ifcopenshell
python311Packages.marimo
python311Packages.marimo.dist
python311Packages.pyhanko
python311Packages.pyhanko.dist
python311Packages.pytest-examples
python311Packages.pytest-examples.dist
python311Packages.pytest-ruff
python311Packages.pytest-ruff.dist
python311Packages.python-lsp-ruff
python311Packages.python-lsp-ruff.dist
python311Packages.ruff
python311Packages.ruff.bin
python311Packages.ruff.dist
python311Packages.skytemple-dtef
python311Packages.skytemple-dtef.dist
python311Packages.skytemple-files
python311Packages.skytemple-files.dist
python311Packages.skytemple-ssb-debugger
python311Packages.skytemple-ssb-debugger.dist
python311Packages.xhtml2pdf
python311Packages.xhtml2pdf.dist
python311Packages.xsdata
python311Packages.xsdata.dist
python312Packages.explorerscript
python312Packages.explorerscript.dist
python312Packages.ifcopenshell
python312Packages.pytest-examples
python312Packages.pytest-examples.dist
python312Packages.pytest-ruff
python312Packages.pytest-ruff.dist
python312Packages.python-lsp-ruff
python312Packages.python-lsp-ruff.dist
ruff (python312Packages.ruff)
ruff.bin (python312Packages.ruff.bin)
ruff.dist (python312Packages.ruff.dist)
python312Packages.skytemple-dtef
python312Packages.skytemple-dtef.dist
python312Packages.skytemple-files
python312Packages.skytemple-files.dist
python312Packages.skytemple-ssb-debugger
python312Packages.skytemple-ssb-debugger.dist
python312Packages.xsdata
python312Packages.xsdata.dist
ruff-lsp
ruff-lsp.dist
skytemple
skytemple.dist
vunnel
vunnel.dist

Maintainer pings
cc @figsoda @GaetanLepage for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.


Psych-DS and JSON-LD/Schema.org validation should be separate

TL;DR
We propose to create separate, self-contained functions for validation psych-DS vs JSON-LD/Schema.org criteria.
Detailed View
In order to ensure that our system is sufficiently modular and extensible, we propose that psych-DS and JSON-LD/Schema.org criteria should be validated by separate, self contained components. Part of the reasoning for this is that we predict that changes could arise in either set of criteria at any point, and that these changes will arise independently, since the two standards are managed by different organizations, and so it would make sense to separate the structures in which those criteria are stored/referenced by the app. Naturally, our goal will be to integrate the modules to the maximum extent possible, sharing as much schema-agnostic functionality and architecture as possible.

Another point: the rules that Psych-DS metadata enforces over & above schema.org metadata can be thought of as the "base extension" for Psych-DS - if communities build on top of Psych-DS in the future, they would be adding additional extensions in a similar way - e.g. by adding rules such as "variableMeasured must include age" or "countryOfOrigin must be present and must be a 3-letter ISO country code"


Visual Studio Community 2019 no longer available.

All Visual Studio Community downloads point to the 2022 version, which is not supported by ROS yet.
I have just setup a new PC and can't build anything.
File "c:\opt\ros\foxy\x64\lib\site-packages\colcon_cmake\task\cmake\build.py", line 162, in _reconfigure
raise RuntimeError(
RuntimeError: Unknown / unsupported VS version '17.0'

Partial answer:
If CMake is updated to the latest version, then newly created packages can be built as they default to VS 2022 and the latest CMake version supports this.
However old packages still can't be rebuilt.

Visual Studio 2019 is available in the older downloads section - https://visualstudio.microsoft.com/vs/older-downloads/. I'll update the docs.

The default toolchains are the important part.

I updated ros.org for ROS1 and fixed out ROS2 docs - https://github.com/ms-iot/ROSOnWindows/pull/357.

Thankyou, I did look but obviously not hard enough.

Per @ooeygui comments above


Add support for Azure

Do you have plans to support reading from Azure blob storage as an external location?

Hello,
we have no current plans to integreade with Azure blob storage. The current best approach is probably to export the files form there as parquet and ingest those.