Authentication is unnecessarily difficult

Currently, the only way to sign in seems to be to type in your email address, to wait up to 5+ minutes in the worst case (worst  that I’ve experienced so far, that is) to receive an email with a link, and to click on that link. This is highly inefficient, making it unnecessarily difficult to sign in. It’ll be especially problematic when in-person attendance is taken because it will slow down the attendance process, reducing the amount of time that people have to work on their projects. This new RCOS website should at the very least not be a regression from Telescope, which means that it should support authentication with Rensselaer CAS/Shibboleth, Discord, or a password.

Unfortunately, it seems that emails sent to RPI addresses take much longer to arrive than other email providers. Using Gmail, I receive the emails after a few seconds.
A magic link was used as it was quick to implement and worked for all types of users: students, alum, faculty, and external guests.
We can definitely implement more sign-in options, including signing in with Discord/GitHub. Given that the emails take a while to arrive for students, I'll pursue these options. CAS/Shibboleth I'd like to avoid because I don't want the login to depend on an RPI system they can turn off at a whim. It's also a hassle to implement and provides nothing more than the magic link does (email verification). Unless it provides more value than email verification, I think it should be avoided. Let me know if you feel strongly about this though.

Also note that once logged-in, your session remains for a while and you won't have to log in again. The Mentors had to log in again today as I changed the session store from database to a cache so all existing sessions were invalidated.

Unfortunately, it seems that emails sent to RPI addresses take much longer to arrive than other email providers. Using Gmail, I receive the emails after a few seconds.
Well, due to #30, the vast majority of users can’t take advantage of that.

A magic link was used as it was quick to implement and worked for all types of users: students, alum, faculty, and external guests.
We can definitely implement more sign-in options, including signing in with Discord/GitHub. Given that the emails take a while to arrive for students, I'll pursue these options. CAS/Shibboleth I'd like to avoid because I don't want the login to depend on an RPI system they can turn off at a whim. It's also a hassle to implement and provides nothing more than the magic link does (email verification). Unless it provides more value than email verification, I think it should be avoided. Let me know if you feel strongly about this though.
Email verification is a bad solution on its own because it creates significantly more friction, even when emails arrive instantaneously, because you have to context-switch to a different app or website. Discord and GitHub authentication shouldn’t be too difficult to implement since, well, the functionality already exists; it’s just not enabled for initial sign-in. Additionally, adding support for WebAuthn would be a significant improvement. It dramatically improves security and ease-of-use, especially when there’s an option to disable other forms of authentication (since the overall security is only as good as the weakest link).

Added GitHub and Discord login. WebAuthn would be interesting to pursue, let me know if you're interested in contributing in that area potentially! I haven't worked with it before but am open to checking it out too.


React cool with Material UI Next

Hello :)
I'm new to react, and looking forward to implement something with this very cool starter!
But reached to the problem, that I can't use Material UI next, due to it's usage of newer js syntax.
On yarn start:production I get:
/Users/university/Documents/react-cool-starter-master/node_modules/material-ui/es/Card/CardActions.js:5
import React from 'react';
^^^^^^
SyntaxError: Unexpected token import
How could I change build process that this node_module would be babel'ified to work?
Thanks!

That's objecting to es6 module import! Have you built?? (yarn build)

@gediminastub Did you use the latest commit?

Sorry, the problem was that I installed Next version which wasn't es6. Thank You again for all! :)

I'm having same issue with Material UI next. When I try to run production build and start, I get same:
import React from 'react';
^^^^^^
Also tried bable preset: node 6 to compile it to right ES version (put .babelrc in project and allowed babel to use it). However, then I get that <Html is unexpected token.
Thank You for Your time in advance :)

@akimirka Try to set up the babel config from here

Close due to inactive.


Bug: Specific UNICODE string error?

Describe the bug
When I try to enter a specific unicode string into surrealDB using the python client, I get a parse error.
import asyncio
from surrealdb import Surreal

async def test():
    """Example of how to use the SurrealDB client."""
    async with Surreal("ws://localhost:8000/rpc") as db:
        await db.signin({"user": "root", "pass": "root"})
        await db.use("test", "test")
        await db.create(
            "person",
            {
                "user": "제10",
            },
        )

if __name__ == "__main__":
    import asyncio

    asyncio.run(test())

Result:
  File "......database/test.py", line 9, in test
    await db.create(
  File "....../lib/python3.9/site-packages/surrealdb/ws.py", line 482, in create
    success: ResponseSuccess = _validate_response(
  File "....../lib/python3.9/site-packages/surrealdb/ws.py", line 161, in _validate_response
    raise exception(response.message)
surrealdb.ws.SurrealPermissionException: Parse error

Errors occur on strings like "제10", "가1234"
Steps to reproduce
[[package]]
name = "surrealdb"
version = "0.3.0"
Expected behaviour
Expecting a normal DB INSERT
SurrealDB version
1.0.0-beta.9+20230402.5eafebd for macos on aarch64
surrealdb.py version
0.3.0
Contact Details
No response
Is there an existing issue for this?

[X] I have searched the existing issues

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Thanks for letting us know about this bug, it has been fixed now, and a new release 0.3.1 is out on PyPi


Trev8939/hotspots

Another one ready for you, if you have the scope for a review @doneill.
Thanks!

Thanks @doneill. I've added a FAB to allow re-analysis. This was the only calendar type icon I could find.

@TADraeseke Nice work, good to merge.


Add 'golang' to go get URL of Setup instructions

This fixes the URL of the go get command in the Setup section of the documentation.
Without this, it of course shows an error.
fatal: could not read Username for 'https://github.com': terminal prompts disabled
package github.com/dep/cmd/dep: exit status 128

I signed it!

ack, ty!


feat(context-menu): returns context menu dismiss result

Adding context menu dismiss result, so we would know the menu is dismissed because the user selected an item or canceled it.
In this PR, it is only implemented on Mac and Windows.

Can't we implement the same on Linux using the signals emitted on menus? see https://docs.gtk.org/gtk3/signal.MenuShell.selection-done.html and https://docs.gtk.org/gtk3/signal.MenuShell.cancel.html

Hmm, I'm expecting that the result could return synchronously when it is dismissed. Signals seem unable to do it synchronously.
If we need to support Linux, maybe it should emit a dismiss MenuEvent on all platforms?

we can probably use a channel to synchronously wait for a result, no?

we can probably use a channel to synchronously wait for a result, no?

Cool, I'll try it later

thanks, you may also need to do something like this https://github.com/tauri-apps/wry/blob/1d63fa325327a02a0a8be9ee50ce1eb7a0e8e04f/src/webkitgtk/mod.rs#L874-L880 in case it is dead-locking

Can't we implement the same on Linux using the signals emitted on menus? see https://docs.gtk.org/gtk3/signal.MenuShell.selection-done.html and https://docs.gtk.org/gtk3/signal.MenuShell.cancel.html

Just added these two signals.
But the events are slightly not as expected that when I mouse click on an empty space. On macOS and Windows, they will see this behavior as canceled, but on Linux (at least on Wayland), it sees it as select-done


bug: to_data_frame index is truncated to integer rather than being float

When I try to convert it to data frame with the as_data_frame I get a warning that it is going to be deprecated but when I use to_data_frame I still get wrong time index.
I would expect here to have a time index with multiplies of 1/256.0 (sampling duration) as I have an rawArray with sampling rate 256.0 (Hz)
Example:
rec.data.as_data_frame().head(10).index
Int64Index([0, 3, 7, 11, 15, 19, 23, 27, 31, 35], dtype='int64')
rec.data.to_data_frame().head(10).index
Converting time column to int64...
Int64Index([0, 0, 0, 0, 0, 0, 0, 0, 0, 0], dtype='int64')
rec.data.info['sfreq']
256.0
Confirmed by Chris Holdgraf: "Hey Hanan - you're right, the index is converted to an integer. I'll take a look at this today to see what may be going on. Would you mind opening an issue on github so we can track progress on this?"

@chanansh can you see if this is fixed in master now? @choldgraf implemented a fix a couple of hours ago.

Any luck @chanansh?

sorry didn't have time to check yet.
HS
On Mon, Apr 20, 2015 at 8:23 PM, Eric Larson<EMAIL_ADDRESS>wrote:

Any luck @chanansh https://github.com/chanansh?
—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/issues/1949#issuecomment-94515047
.

I'm going to go ahead and close this -- feel free to ping us if it turns out to still be incorrect


how to restrcit the number of item to be exported during JIRA export

for example there are 40000 work items so i want to export first 1000 and then next 1000 and so on.. how we can achieve that

@ankusinha23 We have no plans to support pagniation, but you can achieve something similar by limiting export to batches of issues through the query property of your config.json file. Simply enter a JQL query that filters issues on the ìd property, for example:
project = "PROJECTKEY" AND id >= 10000 AND id < 11000
project = "PROJECTKEY" AND id >= 11000 AND id < 12000
project = "PROJECTKEY" AND id >= 12000 AND id < 13000

And so on.
You can always use the issues view in your Jira project to experiment with different JQL queries.


JEI compatibility

The + symbol doesn't appear when using the wireless crafting terminal to craft items from JEI. It works fine without this mod.

which minecraft version, and which modloader?

Minecraft 1.18.2, Forge 40.1.84


Export IWeakReferenceSource

https://learn.microsoft.com/en-us/windows/win32/api/weakreference/nn-weakreference-iweakreferencesource

Implemented as of https://github.com/tristanlabelle/swift-winrt/commit/b3e78f20b8439d2e83013e20976ce5eb25337328


Add onAfterSubmit or resetAfterSubmit prop?

I've been noticing a lot of questions in the remix Discord about how to do things after the form has been submitted (mostly how to reset the form). I feel like some of the solutions that get thrown around don't cover 100% of cases (what happens if the form errors, what if there are multiple forms on the page, etc).
I wonder if this is something that would make sense to add to this library?

I think I'm going to go with a resetAfterSubmit prop for now. The only use-case I can think for this feature is resetting the form. Anything else I can think of has a better, remix-ier solution and I don't want to lead anyone astray. Example: I could imagine someone using onAfterSubmit for toasts, but I think session.flash would be a better fit for toasts.
It's also uncertain what an onAfterSubmit prop would do if the action redirects instead of returning data.
If anyone stumbles on this and you really, really need something to happen after submit other than resetting the form and session.flash doesn't do what you need, you could realistically tie into the onReset prop of the form. Since we're resetting the form after submit, the onReset callback will be fired.


model.fit fails when using generator of keras sequence

Please make sure that this is a bug. As per our
GitHub Policy,
we only address code/doc bugs, performance issues, feature requests and
build/installation issues on GitHub. tag:bug_template
System information

Have I written custom code (as opposed to using a stock
example script provided in TensorFlow):
OS Platform and Distribution: Linux Ubuntu 19
TensorFlow installed from "pip3 install tensorflow" (2.1.0)
Python version: 3.7.5
CUDA/cuDNN version: - GTX 980 || CUDA 10.1 || cuDNN: 7.65

Describe the current behavior
When using a sequence generator on model.fit I get this error on every epoch:
Error occurred when finalizing GeneratorDataset iterator: Cancelled: Operation was cancelled
Standalone code to reproduce the issue
I created a customer generator from the keras sequence class like so (taken from https://blog.ml6.eu/training-and-serving-ml-models-with-tf-keras-3d29b41e066c):
`
import ast
import numpy as np
import math
import os
import random

import pandas as pd
from tensorflow.keras.preprocessing.image import img_to_array as img_to_array
from tensorflow.keras.preprocessing.image import load_img as load_img
import tensorflow as tf

def load_image(image_path, size):
    # data augmentation logic such as random rotations can be added here
    return img_to_array(load_img(image_path, target_size=size)) / 255.

class KagglePlanetSequence(tf.keras.utils.Sequence):

def __init__(self, df_path, data_path, im_width, im_height, batch_size, mode='train'):

    self.df = pd.read_csv(df_path)
    self.im_size = (im_width, im_height)
    self.batch_size = batch_size
    self.mode = mode

    # Take labels and a list of image locations in memory
    self.labels = self.df['LABELS'].apply(lambda x: ast.literal_eval(x)).tolist()
    self.image_list = self.df['IMAGE_ID'].apply(lambda x: os.path.join(data_path, x + '.jpg')).tolist()

def __len__(self):
    return int(np.floor(len(self.df) / self.batch_size))

def on_epoch_end(self):
    # Shuffles indexes after each epoch
    self.indexes = range(len(self.image_list))
    if self.mode == 'train':
        self.indexes = random.sample(self.indexes, k=len(self.indexes))

def get_batch_labels(self, idx):
    # Fetch a batch of labels
    return np.asarray(self.labels[idx * self.batch_size: (idx + 1) * self.batch_size], dtype=np.float32)

def get_batch_features(self, idx):
    # Fetch a batch of images
    batch_images = self.image_list[idx * self.batch_size: (1 + idx) * self.batch_size]
    return np.asarray([load_image(im, self.im_size) for im in batch_images], dtype=np.float32)

def __getitem__(self, idx):
    batch_x = self.get_batch_features(idx)
    batch_y = self.get_batch_labels(idx)
    return batch_x, batch_y

`
The csv file I load is with a column for the image_ids and one column for the labels in the format: "[0, 0, 0, 1]"
I initialize the generator
BATCH_SIZE = 32
IMG_WIDTH = 320
IMG_HEIGHT = 180

seq = KagglePlanetSequence(CSV_PATH,
                           IMAGES_PATH,
                           im_width=IMG_WIDTH,
                           im_height=IMG_HEIGHT,
                           batch_size=32)

I build my model:

model = models.Sequential()
model.add(Conv2D(4, (3, 3), activation='relu', input_shape=(IMG_HEIGHT, IMG_WIDTH, 3)))
model.add(MaxPooling2D((2, 2)))
model.add(Conv2D(8, (3, 3), activation='relu'))
model.add(MaxPooling2D((2, 2)))

model.add(Flatten())
model.add(Dense(3, activation='sigmoid'))

model.summary()

model.compile(optimizer='adam', loss=losses.categorical_crossentropy, metrics=['accuracy'])

I call mode.fit
model.fit(seq,
          verbose=1,
          epochs=1,
          workers=4)

Train for 5 steps
2020-02-26 18:47:43.446662: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libcublas.so.10
2020-02-26 18:47:43.693552: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libcudnn.so.7
5/5 [==============================] - 2s 323ms/step - loss: 1.2517 - accuracy: 0.4250
**2020-02-26 18:47:44.917946: W tensorflow/core/kernels/data/generator_dataset_op.cc:103] Error occurred when finalizing GeneratorDataset iterator: Cancelled: Operation was cancelled**

And I get this error:
Error occurred when finalizing GeneratorDataset iterator: Cancelled: Operation was cancelled

@HadiSDev
please share the csv file and all dependencies for us to replicate your issue in our local.

Sorry zip file is quite big, but here you go:
http://www.mediafire.com/file/yp6exg4auwjbywu/drive-download-20200229T130542Z-001.zip/file
csv file is in the actions directory and images in the images directory

@HadiSDev
I ran the code shared by you and face this error, please share all dependencies and indented code for us to replicate and help you resolve the issue.


[ENH] rename_columns function mapper enhancements

PR Description
Please describe the changes proposed in the pull request:

Adds the function argument which takes a Callable which does dynamic replacement of column names

**This PR resolves #785 **

PR Checklist

Please ensure that you have done the following:

[x] PR in from a fork off your branch. Do not PR from <your_username>:dev, but rather from <your_username>:<feature-branch_name>.

[x] If you're not on the contributors list, add yourself to AUTHORS.rst.

[x] Add a line to CHANGELOG.md under the latest version header (i.e. the one that is "on deck") describing the contribution.

Do use some discretion here; if there are multiple PRs that are related, keep them in a single line.

Automatic checks
There will be automatic checks run on the PR. These include:

Building a preview of the docs on Netlify
Automatically linting the code
Making sure the code is documented
Making sure that all tests are passed
Making sure that code coverage doesn't go down.

Relevant Reviewers

Please tag maintainers to review.

@samukweku
@ericmjl

@samukweku could you do the honors please? :smile:


Double and Float values should be rounded

A double value should not have more than 2 decimal places. If there are more than 2 decimal places, the value should be rounded, not cut off.

See https://github.com/guh/guh-webinterface/pull/91


RPM repo unavailable to clone or browse

Hello!
We operate on a secure network and packages are made available to our systems via a package mirror server. I'm trying to clone the repo with Foreman; it's reporting repomd.xml is not found. When attempting to browse the repository at https://nvidia.github.io/libnvidia-container/stable/centos8/x86_64/, I receive the error:
# Unsupported distribution! # Check https://nvidia.github.io/libnvidia-container

However, when I add the .repo configuration to my lab VM, yum/dnf are able to download and search for packages without incident.
Is there something I should be doing different when browsing the repository and/or trying to clone it?
Thanks!

@applematt the URL in question maps to the following folder: https://github.com/NVIDIA/libnvidia-container/tree/gh-pages/stable/centos8/x86_64
This folder contains the architecture-specific packages but not the repomd.xml. The https://github.com/NVIDIA/libnvidia-container/tree/gh-pages/stable/centos8/x86_64/repodata folder does.

@elezar , thank you!

Hi @applematt. The centos8 packages are used regularly by multiple users and many other distributions redirect to these repos. As such I wouldn't expect any issues with the repository.

@applematt thinking about this again, does accessing the raw file at https://raw.githubusercontent.com/NVIDIA/libnvidia-container/gh-pages/stable/centos8/x86_64/repodata/repomd.xml work?

Hi @elezar - Sorry for the delayed response. Let me try cloning the repository again and see if its fixed now.

It seems that did not resolve the issue. I'm still receiving this error from my mirror server:
Katello::Errors::PulpError: PLP0000: not well-formed (invalid token): line 15, column 75

In looking at the stack trace, python is throwing an exception for the xml_iterator which is called by parse_repomd.  The raw error from the XML parser is:
ParseError: not well-formed (invalid token)

I am not sure what's causing it to choke, so I'll keep digging and let you know if I find anything ... just in case anyone else is using Foreman+Katello or Satellite to mirror this repository.

@applematt thinking about this again, does accessing the raw file at https://raw.githubusercontent.com/NVIDIA/libnvidia-container/gh-pages/stable/centos8/x86_64/repodata/repomd.xml work?

Sorry ... I completely misunderstood your request. 🤦
Yes, I can access that file. I will see if I can parse it manually to identify the exact issue.


YAML comments

General Question
Is there are way to produce YAML comments from KCL?

There's not currently at the language level. Because there is no clear user stories and a good design and spec yet. Alternatively, this feature may be added in future versions, such as --emit-comments 🤔

Thanks for clarifying.


[RFC] Add reserved-memory support

This PR was inspired by #31077 (tagging @JordanYates)
What this RFC is about
This RFC is a potential answer to two different needs:

A driver needs to have exclusive access to a very specific memory region. For example frame-buffer area or some portion of memory at a very precise location that is shared among different SoCs on the same platform.
A driver needs to have access to a memory buffer mapped in memory with particular attributes (for example cacheability attributes) that can offer services to other drivers. For example some kind of driver managing a shared DMA memory pool region.

How this is solved on other OS
The Linux kernel is implementing the reserved-memory node for that, see the documentation
How this RFC is trying to solve this
The idea is having a light version of what Linux is doing. What I'm proposing here is formally introducing a reserved-memory node and a set of header files and macros doing the following:

For each reserved memory region in the DT a new memory region is created in the linker script using the DT_RESERVED_REGIONS() macro
For each reserved memory region in the DT a new section is created in the linker script using the DT_RESERVED_SECTIONS() macro
For each reserved memory region in the DT two new linker symbols are created marking the start and the end of the new section using the DT_RESERVED_SYMBOLS() macro

A couple of other DT_RESERVED_* macros are also introduced to retrieve at run-time information about start and size of the reserved-memory region.
Can you give me an example?
Sure. Let's say that we have this in the DT:
reserved-memory {
    compatible = "reserved-memory";
    #address-cells = <1>;
    #size-cells = <1>;
    ranges;

    res0: res0@42000000 {
        compatible = "dma-buffer-manager";
        reg = <0x42000000 0x1000>;
        label = "res0";
        non-cacheable;
        linker-section;
    };

    res1: res1@43000000 {
        reg = <0x43000000 0x1000>;
        label = "res1";
        no-mmu;
        linker-section;
    }
};

driver: driver {
    compatible = "driver";
    memory-region = <&res1>;
}

The dma-buffer-manager driver is managing the memory region 0x42000000-0x42001000 set with a non-cacheable attribute at boot time by MPU/MMU while the driver driver has access through the phandle to the memory region 0x43000000-0x43001000. These drivers can use the macros DT_RESERVED_GET_{SIZE,ADDR} and DT_RESERVED_GET{SIZE,ADDR}_BY_PHANDLE to access address and size of the appropriate memory region.
In the linker script two more regions are created res0 and res1 and two more sections .res0 and .res1. Also new linker script symbols are being exported reserved_res0_{start,end} and reserved_res1_{start,end}.
MEMORY
{
...
res0 (rw) : ORIGIN =<PHONE_NUMBER>, LENGTH = 4096
res1 (rw) : ORIGIN =<PHONE_NUMBER>, LENGTH = 4096
}

res0 : {
  reserved_res0_start = .;
  KEEP(*(.res0))
  KEEP(*(.res0.*))
  reserved_res0_end = reserved_res0_start + 4096;
} > res0

res1 : {
  reserved_res1_start = .;
  KEEP(*(.res1))
  KEEP(*(.res1.*))
  reserved_res1_end = reserved_res1_start + 4096;
} > res1

How this solves the original problem
Having a real mechanism to actually reserve pages is a complex matter that usually involves MMU / MPU. What we are doing here is creating new sections and allow driver to make use of these new sections at very precise location in memory. If the sections are overlapping with other sections at compile time we get an error.
Also (very important) having access to the linker symbols, easily allows architectural code to set properties on the memory regions. For example MMU and MPU code can set proper attributes to the memory regions.
For example we can now pass reserved_res0_start to a slab-allocator to be able to have easily slabs of non-cacheable memory.

res1 : {
  reserved_res1_start = .;
  KEEP(*(.res1))
  KEEP(*(.res1.*))
  . += 4096;
  reserved_res1_end = .;
} > res1

just realized that . += 4096 is only valid if the section is actually empty. Anyway, good enough for the first round of this RFC
:sweat_smile:
I'll wait for more comments before fixing everything fixable.

Why do we need zephyr,reserved?
Why do we need linker sections for this?
How does this play with the existing uses of reserved memory in devicetree already in tree today?

1. Why do we need `zephyr,reserved`?

To quickly access the node using DT_CHOSEN but I can probably remove that.

2. Why do we need linker sections for this?

Given that you could have this done using memory regions "far" from the used kernel space and accessing the memory using direct pointers in memory having sections is handy for several reasons:

If your reserved memory is overlapping with some other section you get an error at compile time
Having sections allows you to put variables in that section using __in_section()
Allows the code to create linker symbols and a set of helpers to easily manage the reserved region

3. How does this play with the existing uses of reserved memory in devicetree already in tree today?

The reserved-memory node today in Zephyr is not currently doing anything, it's just creating nodes to be used by some other code in an arbitrary way. It is also slightly misused because the sub-nodes are not defining reserved memory regions as but are mostly used to partition the space. We can make the approach in this PR co-exist with the current use by introducing a property in the nodes (for example something like create-section;) and create regions/sections/linker symbols only for the regions for which this property is defined, basically the equivalent of linker-region; property for #31077.

1. Why do we need `zephyr,reserved`?

To quickly access the node using DT_CHOSEN but I can probably remove that.

Lets remove it.

@carlocaione -- it sounds like you're saying you prefer to keep the compatible?

Yes. For now I'd like to keep it.

@nashif @mbolivar-nordic do you have any clue why the unit_testing is failing on CI?

If your reserved memory is overlapping with some other section you get an error at compile time

Just pointing out that this is not strictly true. It will only fail at link time if variables placed in two memory regions overlay one another. You can test this easily by just duplicating the FLASH memory region in linker.ld

Just pointing out that this is not strictly true. It will only fail at link time if variables placed in two memory regions overlay one another. You can test this easily by just duplicating the FLASH memory region in linker.ld

Thank you for the clarification. This is indeed what I see in my test where I usually create a buffer of the same size of the section to be used as memory pool. I can make that crated automatically, I'm open to any suggestion on how to improve this.

@carlocaione what we lack here (unless i missed it) is a generic sample that show-cases the usage of the reserved-memory API. I think it would be good to have it together with the RFC proposal.

Would like to see a tests / sample that actually does this, and how you intend to add this into the linker scripts.

Yeap, this makes two of us :)

I certainly agree with @ioannisg that devicetree is the place to be doing this sort of configuration. I am a little concerned that while this definitely solves a real problem, it either only solves a part of it, or it conflicts with other mechanisms we have for partitioning the address space.
Based on my (minimal) understanding of how the Linux memory allocation works, reserved-memory is intended to describe RAM reservation only. If this is how it should be used under Zephyr, it should be documented as such. If is is also intended to be used for FLASH reservation, then this conflicts with the use of fixed-partitions. Would we need to add the settings partitions to both in order for the region to both show in the linker and appear under flash_map.h?
Right now this is creating a second instance of #27471, except this time in RAM instead of FLASH. linker.ld is still generating the SRAM region naively from zephyr,sram, regardless of reserved-memory. If the reserved regions are for placeholding rather than compile time variables, the linker will happily allocate application RAM into our reserved memory regions without warnings.
Ideally the solution would also allow us to remove the DT_REGION_FROM_NODE_STATUS_OKAY macros from linker.ld. Most of them are specifying RAM devicetree nodes, it seems silly to be generating RAM memory regions via two different mechanisms.
I feel that a complete solution to these problems requires one partitioning method for FLASH (application location/size, settings partition, etc) one for RAM (application location/size, displaybuffer mem, etc). This would imply that reserved-memory should also be used for specifying application RAM.
In short, I'm not convinced that the Linux reserved-memory concept is sufficient for the problems that we need to solve for embedded systems. I would be leaning towards a RAM version of fixed-partitions which can be placed under any RAM devicetree node.
One of the Zephyr Development Summit Mini-Conference's is intending to address precisely this problem and others, so I would suggest that we hold off on merging this pending the outcomes of that discussion (June 10th).

Based on my (minimal) understanding of how the Linux memory allocation works, reserved-memory is intended to describe RAM reservation only. If this is how it should be used under Zephyr, it should be documented as such. If is is also intended to be used for FLASH reservation, then this conflicts with the use of fixed-partitions. Would we need to add the settings partitions to both in order for the region to both show in the linker and appear under flash_map.h?

No. This commit is not intended to tackle FLASH reservation or mappings. The only allowed use for the reserved-memory mechanism is for RAM reservation. I can make that explicitly but this commit wants to follow the usual (aka Linux) intended use for the reserved-memory node, that is RAM reservation and partitioning. FLASH is out of this picture.

Right now this is creating a second instance of #27471, except this time in RAM instead of FLASH. linker.ld is still generating the SRAM region naively from zephyr,sram, regardless of reserved-memory. If the reserved regions are for placeholding rather than compile time variables, the linker will happily allocate application RAM into our reserved memory regions without warnings.

This is correct. As I mentioned before one possible solution is to create compile time variables in the sections to get at least a compile time error. On this point I didn't have any better idea and I'm open to any suggestion. Without MMU is hard to actually "reserve" memory and exclude that from normal usage.

Ideally the solution would also allow us to remove the DT_REGION_FROM_NODE_STATUS_OKAY macros from linker.ld. Most of them are specifying RAM devicetree nodes, it seems silly to be generating RAM memory regions via two different mechanisms.

This PR is mostly an extension to that, trying to gather the data directly from DT and adding the sections for a very precise goal, DT_REGION_FROM_NODE_STATUS_OKAY is a more general partitioning tool. Actually for what I'm trying to do in this PR memory regions are not even needed at all, I could create only sections instead if we want to reduce the overlap.

I feel that a complete solution to these problems requires one partitioning method for FLASH (application location/size, settings partition, etc) one for RAM (application location/size, displaybuffer mem, etc). This would imply that reserved-memory should also be used for specifying application RAM.

Again, I'm not sure why FLASH is being brought on the table. The reserved-memory node is used to create reserved portion of memory for DMA, direct access, shared memory, CMA, etc... I'm not sure what are the requirements for FLASH partitioning, but the tool introduced in this PR is not dealing with that.

In short, I'm not convinced that the Linux reserved-memory concept is sufficient for the problems that we need to solve for embedded systems. I would be leaning towards a RAM version of fixed-partitions which can be placed under any RAM devicetree node.

What's the difference? Only the davicetree location? Because on the contrary I think that we should follow what has been already implemented on Linux, with a specialized reserved-memory node listing all the reserved regions.

One of the Zephyr Development Summit Mini-Conference's is intending to address precisely this problem and others, so I would suggest that we hold off on merging this pending the outcomes of that discussion (June 10th).

Yup, I won't miss that.

I included it because @ioannisg mentioned flash partitioning and I wasn't clear on the Linux binding. It does have some relevance in that we need to partition both FLASH and RAM somehow, and the closer the two solutions are to each other the more we can share in the implementation.

On this point I didn't have any better idea and I'm open to any suggestion

As I hint at in the "one partitioning method" comment, I think the only robust solution is to reduce the size of the SRAM region so that it doesn't overlap reserved memory (via reserved-memory or any other solution). This requires being explicit in how large application RAM should be, rather than the current implicit situation. This also links in to the partition comment below.

What's the difference? Only the davicetree location?

By directly hanging the partitions under a devicetree node, you could do different things based on whether a partition is defined at all. If for example you had:
		sram2:memory@20020000 {
			compatible = "mmio-sram";
			reg = <0x20020000 DT_SIZE_K(32)>;
		};

You would generate linker region sram2, but with:
		sram2:memory@20020000 {
			compatible = "mmio-sram";
			reg = <0x20020000 DT_SIZE_K(32)>;
			parititions {
				compatible = "ram-partitions";
				app<EMAIL_ADDRESS>				lib1<EMAIL_ADDRESS>				lib2<EMAIL_ADDRESS>			};
		};

You would generate app, lib1 and lib2 instead. I am assuming that the following statements are true:

RAM devicetree nodes should result in one or more linker memory regions
If part of a RAM block is 'reserved', that memory range should not exist in other memory regions

I can't really see a way to do this if all 'partitions' live under reserved-memory (if the described behavior is desired).

I included the FLASH comments because @ioannisg mentioned flash partitioning and I wasn't clear on the Linux binding. It does have some relevance in that we need to partition both FLASH and RAM somehow, and the closer the two solutions are to each other the more we can share in the implementation.

Agree, if we can find some common ground I'll be happy to share the implementation :)

As I hint at in the "one partitioning method" comment, I think the only robust solution is to reduce the size of the SRAM region so that it doesn't overlap reserved memory (via reserved-memory or any other solution). This requires being explicit in how large application RAM should be, rather than the current implicit situation. This also links in to the partition comment below.

Yes, I thought about this but that would be really unpleasant to manage if we would like for example to reserve one single page in the middle of the SRAM region, because you would end up with something like:
MEMORY {
  SRAM1 (wx) : ORIGIN = 0x40000000, LENGTH = (XXX * 1K)
  RES: (wx) : ORIGIN = 0x40040000, LENGTH = (4 * 1K)
  SRAM2 (wx) : ORIGIN = 0x40041000, LENGTH = (YYY * 1K)
}

The real problem is that sometimes you are not really free to decide whether your reserved memory should be placed in memory. Think about some kind of shared memory between several SoCs on the same platform to be placed at some very specific address in memory that could end up being in the middle of some region.

By directly hanging the partitions under a devicetree node, you could do different things based on whether a partition is defined at all. If for example you had:
		sram2:memory@20020000 {
			compatible = "mmio-sram";
			reg = <0x20020000 DT_SIZE_K(32)>;
		};

You would generate linker region sram2, but with:
		sram2:memory@20020000 {
			compatible = "mmio-sram";
			reg = <0x20020000 DT_SIZE_K(32)>;
			parititions {
				compatible = "ram-partitions";
				app<EMAIL_ADDRESS>				lib1<EMAIL_ADDRESS>				lib2<EMAIL_ADDRESS>			};
		};

You would generate app, lib1 and lib2 instead.

That would be really inconvenient in the case I mentioned before. Think for example if I need to reserve two buffers with some particular cache-ability attributes to use as memory pools. If I understand correctly your point I should do something like:
	sram2:memory@20020000 {
 			compatible = "mmio-sram";
 			reg = <0x20020000 DT_SIZE_K(32)>;
 			parititions {
 				compatible = "ram-partitions";
                                sram_beginning<EMAIL_ADDRESS>                                buf1<EMAIL_ADDRESS>                                sram_middle<EMAIL_ADDRESS>                                buf2<EMAIL_ADDRESS>                                sram_end<EMAIL_ADDRESS> 			};
 		};

This looks painful to me. I should be able to just define buf1 and buf2 under reserved-memory node and the code should take care of all the details for me.

I am assuming that the following statements are true:
* RAM devicetree nodes should result in one or more linker memory regions

* If part of a RAM block is 'reserved', that memory range should not exist in other memory regions

I can't really see a way to do this if all 'partitions' live under reserved-memory (if the described behavior is desired).

Also these statements are not exactly true because RAM devicetree nodes could not necessarily result in one or more linker regions. What we need are sections and possibly linker script symbols to mark start and end of those sections. For example instead of having something like this (generated by the current PR):
MEMORY {
  RES0 (rw) : ORIGIN = 0x40000000, LENGTH = 0x1000
}
...
res0 : {
  _reserved_res0_start = .
  ...
  _reserved_res0_end = _reserved_res0_start + 0x1000;
} > RES0

You could have something like:
res0 0x40000000 : {
  _reserved_res0_start = .
  ...
  _reserved_res0_end = _reserved_res0_start + 0x1000;
}

So I'm adding the memory regions just for clarity but the main work here is done by the sections. This is probably not important for this discussion but I just wanted to put this on the table as well.
Now, there are two more things I don't like about your proposal of having partitions as child-nodes of mmio-sram nodes:

This is not the standard way to define reserved-memory nodes. Like it or not Linux has already defined a way to do that with a standalone node. We could diverge from that but I don't think that would bring many advantages.

I think that it is conceptually wrong to think the reserved-memory regions as "belonging" to some other memory region. You are not partitioning anything here, you are defining an entirely new section for some peculiar use.

Yes, I thought about this but that would be really unpleasant to manage if we would like for example to reserve one single page in the middle of the SRAM region, because you would end up with something like:

I agree that such a situation is unpleasant to manage, but how is such a situation handled using reserved-memory?
MEMORY {
  SRAM (wx) : ORIGIN = 0x40000000, LENGTH = (1M)
  RES: (wx) : ORIGIN = 0x40001000, LENGTH = (4 * 1K)
}

So  you have a two memory regions, one of which lies over the other.
In terms of the linker script, this results in something like:
{
	__data_ram_start = .;
	*(.data)
	*(".data.*")
	__data_ram_end = .;
} > GROUP_LINK_IN(SRAM)

{
	__res_start = .;
	*(.res)
	*(".res.*")
	__res_end = .;
} > GROUP_LINK_IN(RES)

The first 4K of SRAM is fine, no issues. But as soon as you go past 4K, you're overriding the reserved memory.
More importantly you have no way of placing variables after the memory region you've reserved.

The real problem is that sometimes you are not really free to decide whether your reserved memory should be placed in memory. Think about some kind of shared memory between several SoCs on the same platform to be placed at some very specific address in memory that could end up being in the middle of some region.

Are there examples of this situation where reserved memory sits in the middle of the main SRAM address space?

This looks painful to me. I should be able to just define buf1 and buf2 under reserved-memory node and the code should take care of all the details for me.

I agree it is painful, but I believe that is the price that must be paid to ensure all RAM is usable. reserved-memory doesn't take care of all the details for you, it just stops you from being able to use any memory after the first reserved-memory address. This was one of the major problems with my first PR on this topic, see https://github.com/zephyrproject-rtos/zephyr/pull/31077#issuecomment-760770572 (albeit for flash rather than ram).

You are not partitioning anything here, you are defining an entirely new section for some peculiar use.

I disagree with this, by definition you are partitioning an existing address space into multiple address spaces by saying that these addresses are reserved. You're not magically creating some new memory addresses that didn't previously exist.

I included the FLASH comments because @ioannisg mentioned flash partitioning and I wasn't clear on the Linux binding. It does have some relevance in that we need to partition both FLASH and RAM somehow, and the closer the two solutions are to each other the more we can share in the implementation.

Thanks for your feedback @JordanYates. My apologies for mentioning FLASH here, too; I understand it was confusing, as it leads to thinking about physical memory partitioning. So, let's focus on RAM.
I believe that the intention of this RFC PR is not to solve the problem of physically partition memory areas; a problem that concerns primarily, multi-image, multi-core applications with a common (e.g. global) memory resource. To my understanding, this PR aims at addressing a simpler problem: in a single-core single Zephyr images, we would like to have more control on some areas of the image memory that will be used by certain components of our application. By control, I am referring to:

being able to reserve parts in the image RAM and place these areas there
generate and expose linker symbols that reference the boundaries of the areas
allocate certain variables/buffers there
configure (attribute) these areas in a custom way, based on the application needs

Since all this is done inside a Zephyr image, I believe this problem is orthogonal to the partitioning-problem, which concerns mainly multi-image applications.
In brief, we would like to add some more user-control on how the build system (linker) is generating and populating sections.
Note that this is already the case for some existing features (e.g config NOCACHE_MEMORY), where we instruct the linker to reserve some sections for defining non-cachable  buffers.
Historically, we have been defining several sections in our linker for the various kernel and application needs (user memory, read-only stuff, heap, execute-from-ram etc.), but now we would like to put a bit more control over the properties of some of these sections.
Assuming that all the information about the "control" we want to apply, is available at build time, I believe that DeviceTree is the right place to describe our needs, and the reserved-memory seems to be a convenient concept to use (open to alternative suggestions here).
My point is that we should not hold this back, until we have a holistic approach that addresses, also, the multi-image fixed partitioning problem, as I do not anticipate much overlap. I'd suggest we de-couple the two problems from each other.
As the focus is on creating sections from DT information, would you be more comfortable with this proposal, if we do not include the framework for defining regions? I understand that it is not ideal to generate regions by two different mechanisms.

I agree that such a situation is unpleasant to manage, but how is such a situation handled using reserved-memory?
MEMORY {
  SRAM (wx) : ORIGIN = 0x40000000, LENGTH = (1M)
  RES: (wx) : ORIGIN = 0x40001000, LENGTH = (4 * 1K)
}

So you have a two memory regions, one of which lies over the other.
In terms of the linker script, this results in something like:
{
	__data_ram_start = .;
	*(.data)
	*(".data.*")
	__data_ram_end = .;
} > GROUP_LINK_IN(SRAM)

{
	__res_start = .;
	*(.res)
	*(".res.*")
	__res_end = .;
} > GROUP_LINK_IN(RES)

The first 4K of .data is fine, no issues. But as soon as you go past 4K, you're overriding the reserved memory.

Yes, you are in theory, but you are not going to ever find yourself in this situation because the compiler would stop you at compile time if any section is overlapping with each other (again, assuming that you have some kind of variable in .res to fill up the section).
Let's take a real example. Let's say that I want to have a memory pool for DMA and I want to be able to configure this memory pool using MPU so that it has some special no-cache attribute. To be able to do this I'd like to reserved some memory somewhere at a know address so that I can use this address in the MPU code to set the cache-ability attribute and use the same address for the slab allocator. This is a real case where I don't care about partitioning or memory regions, I just want to be able to precisely locate a buffer in memory using a section.
Now, let's take the qemu_cortex_a53 board, just because I'm familiar with that and see how the hello_world sample is organizing the memory in this case.
Looking at the map file, everything is basically in different sections between the start and end symbols:
0x0000000040000000                _image_text_start = .
0x0000000040000000                z_mapped_start = .
... {a lot of sections here}
0x000000004005b000                _image_ram_end = .
0x000000004005b000                _end = .
0x000000004005b000                z_mapped_end = .
0x0000000048000000                __kernel_ram_end = 0x48000000

Now, what I would do in this case is to have something like:
reserved-memory {
    compatible = "reserved-memory";

    reserved: reserved@42000000 {
        reg = <0x42000000 0x8000>;
        label = "reserved";
        linker-section;
        non-cacheable;
    };
};

So that I can create at 0x42000000 a section that I can use to place the buffer to be used as memory pool. This section is not overlapping with any other section and if it overlapped, we would have got a complain from the linker already.

More importantly you have no way of placing variables after the memory region you've reserved.

I'm not sure I follow you here, sorry. As in the example reserved regions should be located far from the image sections, possibly at the end, otherwise as stated before you would get a linker error. If we get no linker error we can be pretty sure that no Zephyr variable is going to be allocated there (pretty much everything in Zephyr is inside some section).

Are there examples of this situation where reserved memory sits in the middle of the main SRAM address space?

Maybe not in the middle, but the point is that you still have to be able to point to a specific region in memory and have exclusive access to that. Doing that having a section to a very precise memory address looks to me like a good idea.

My point is that we should not hold this back, until we have a holistic approach that addresses, also, the multi-image fixed partitioning problem, as I do not anticipate much overlap. I'd suggest we de-couple the two problems from each other.

In that case it feels like this PR (or a precursor) should be addressing/fixing the existing in-tree usage of reserved-memory.

11 of 16 uses are for partitioning RAM for multi-image builds.
2 of 16 are using reserved-memory to declare flash regions (mps2_an521_nonsecure & mps2_an521_remote)
3 of 16 are using it as intended in the PR, shared memory between CPU cores.

As the focus is on creating sections from DT information, would you be more comfortable with this proposal, if we do not include the framework for defining regions? I understand that it is not ideal to generate regions by two different mechanisms.

Yes. That would allow us to split the problem into regions defining which memory is available to the application, while reserved-memory can be used for generating sections at addresses within that application.

I'm not sure I follow you here, sorry. As in the example reserved regions should be located far from the image sections, possibly at the end, otherwise as stated before you would get a linker error. If we get no linker error we can be pretty sure that no Zephyr variable is going to be allocated there (pretty much everything in Zephyr is inside some section).

I am trying to explore the combination of two concerns. Firstly you state that sometimes you have no control over where these special memory sections should be placed. The second is that the location that you place the first reserved-memory section at is now essentially the end of application RAM, baring other dedicated reserved-memory sections after the first.
Using your example:

SRAM0 starts at 0x40000000, 128MB (Ending 0x48000000)
reserved starts at 0x42000000, 32KB (Ending 0x42008000)

How do variables get placed in the memory region <0x42008000 - 0x48000000> now?
Using less than 32MB of RAM is fine, as that fits before 0x42000000.
Using more than 32MB of RAM will never compile, because it overlaps with reserved.
Therefore by adding this reserved-memory section, you only have automatic access to 32MB of RAM instead of 128MB.
For your example you can just move the address, but what about for those regions which must be at defined addresses?
Note that I don't think there is necessarily a solution to this problem, I just think it has been ignored. In this particular example, the 'best' thing to do would be to shift all of your application ram to start at 0x42008000, at least then you get ~95MB of RAM instead. This was another benefit of the partition approach, in this example you could just switch zephyr,sram to sram_end (from your previous comment).

In that case it feels like this PR (or a precursor) should be addressing/fixing the existing in-tree usage of reserved-memory.

This is what I tried to do adding the linker-section property. The sections are created only if this property is present, otherwise nothing is done, and the existing in-tree usage of reserved-memory are still valid.

Using your example:
* SRAM0 starts at 0x40000000, 128MB (Ending 0x48000000)
* reserved starts at 0x42000000, 32KB (Ending 0x42008000)

How do variables get placed in the memory region <0x42008000 - 0x48000000> now?

We have two cases:

Nothing is placed in that memory region and we are fine (and we know that at compile time already)
Something is going to be placed there and we get an error at compile time so we can fix it, possibly moving around the reserved section

I think this is acceptable TBH.

Using less than 32MB of RAM is fine, as that fits before 0x42000000.

Yup.

Using more than 32MB of RAM will never compile, because it overlaps with reserved.

Correct. And why this is a problem? I think this is a perfectly reasonable behavior. I know that this is not the same as on Linux where we can work around the region, but I think this is the best we can do with what we have right now.

Therefore by adding this reserved-memory section, you only have automatic access to 32MB of RAM instead of 128MB.

Ok I think this point needs a bit of discussion because I think that even without the reserved-memory section you are only using the 32MB. All the sections (stack, bss, heap, etc...) are mapped in different sections that are allocated before _image_ram_end / z_mapped_end symbols, that means that the space between _image_ram_end and __kernel_ram_end is available for reserved sections.
Let's make an example, samples/synchronization for qemu_cortex_a53_smp. With no reserved memory regions defined, the end of the map file shows:
0x0000000040060a78                __data_ram_end = .
0x0000000040061000                . = ALIGN (_region_min_align)
0x0000000040061000                _image_ram_end = .
0x0000000040061000                _end = .
0x0000000040061000                z_mapped_end = .
0x0000000048000000                __kernel_ram_end = 0x48000000
0x0000000007ff7000                __kernel_ram_size = (__kernel_ram_end - __kernel_ram_start)

My question is: can we say that all the variables (in data, bss, heap, stack, ...) are allocated somewhere before the _end symbol so that we can safely use the space between _end and __kernel_ram_end to host the sections for the reserved memory regions?
If we agree on this point (and please, correct me if I'm wrong) then the presence of the reserved-memory sections is not reducing at all the available memory, we are just using some space that it wouldn't be used anyway.

For your example you can just move the address, but what about for those regions which must be at defined addresses?

Yes, agree that we have a problem when the regions at a defined address overlap with the used portion of the memory, but there is no easy solution to that. In that case the user should find a way to change the address.

Note that I don't think there is necessarily a solution to this problem, I just think it has been ignored. In this particular example, the 'best' thing to do would be to shift all of your application ram to start at 0x42008000, at least then you get ~95MB of RAM instead. This was another benefit of the partition approach, for this example you could just switch zephyr,sram to sram_end (from your previous comment).

I don't think that you can always move the RAM location as you please (I'm thinking for example when using Zephyr as EL3 payload with TF-A), but if we agree on the point above I think that this is not even needed given that we are not going to use the full 95MB anyway.

This is my reasoning as to why the Linux approach may not be the best for us. With dynamic memory allocation you just allocate around reserved-memory, whereas we are doing all of our memory assignment at link-time.

Totally agree, I'm just trying to come up with a poor man's implementation of that :smiley:

This is what I tried to do adding the linker-section property

I somehow missed that this was required instead of just generating sections on all reserved-memory's.
This is the same solution as was present in #31077, I am curious if the start of @ioannisg's https://github.com/zephyrproject-rtos/zephyr/pull/31077#issuecomment-760770572 is relevant here.
Apart from ROM vs RAM, I don't see the difference.

and the existing in-tree usage of reserved-memory are still valid

Technically true, but the meaning of reserved-memory has changed from: "A way to define a memory range in devicetree for any purpose" to "A way to define a memory range in devicetree, and if you add this special flag, and the range is in RAM, you will get a linker section". It's not the end of the world, but it doesn't feel great.

My question is: can we say that all the variables (in data, bss, heap, stack, ...) are allocated somewhere before the _end symbol so that we can safely use the space between _end and __kernel_ram_end to host the sections for the reserved memory regions?

Sure, but the value of _end changes as you update applications. Maybe when I enable blockchain in my sweet machine learning code I go from using 24MB of RAM to 71MB. The solution in that case is to defined a second reserved-memory and redirect zephyr,sram, but that is starting to look a lot like a RAM fixed-partitions 😄.

In that case it feels like this PR (or a precursor) should be addressing/fixing the existing in-tree usage of reserved-memory.

11 of 16 uses are for partitioning RAM for multi-image builds.
2 of 16 are using reserved-memory to declare flash regions (mps2_an521_nonsecure & mps2_an521_remote)
3 of 16 are using it as intended in the PR, shared memory between CPU cores.

@JordanYates I fully agree about (2) (and (3), of course, if fine).
For (1), I understood from the discussion with @carlocaione that it is OK to keep using the reserved-memory, as it is now, as a means for allocating RAM in multi-image builds. This can be done by omitting the linker-section property; then the linker won't generate an explicit linker section, however, DeviceTree will still expose the reg-property details, so image RAM allocation may use them.
And yes, the above looks similar to your original proposal in #31077, in the sense that you had also used DT properties to instruct the linker to take actions :)

This is the same solution as was present in #31077, I am curious if the start of @ioannisg's #31077 (comment) is relevant here.
Apart from ROM vs RAM, I don't see the difference.

I am not 100% which part of the comment you refer to (I am going to risk an assumption that it is the following part:)

A limitation that I spot in the current implementation is that all the flash area beyond the storage_partition (or, rather, the first partition with the linker-region property) cannot be used by the Zephyr for the application image. This is problematic for all the boards that define the storage partition right after the boot partition. There has to be found a way to by pass this limitation (alternatively all the boards that not define storage_partition at the end will need to re-adjust their existing flash layout)

If so, yes, I still think that it is not good if the existing solution results in any available memory area being un-usable. But as far as I understood, this is not the case. @carlocaione could you confirm that we can have auto-generated linker sections using the DT reserved-memory information, while ensuring the Zephyr build system won't be not leaving any parts of RAM un-usable? Would be greate if you could show case this with a sample code in this PR :)

Technically true, but the meaning of reserved-memory has changed from: "A way to define a memory range in devicetree for any purpose" to "A way to define a memory range in devicetree, and if you add this special flag, and the range is in RAM, you will get a linker section". It's not the end of the world, but it doesn't feel great.

That's probably accurate, but I do not see why this is a problem: we're shaping reserved-memory to a more flexible definition, where it can accommodate the needs of different use-cases. The reserved-memory concept is not widely used in Zephyr today (as you mentioned there are ca 15 uses of it, and at least 2 uses on defining flash regions are missuses and needs to be corrected), so it will definitely not result in any considerable "noise" in the Project. The solution ensures backwards-compatibility with respect to the existing usage of reserved-memory, anyways.

but that is starting to look a lot like a RAM fixed-partitions 😄.

Well, might be. But I do not think the intention is to partition an image RAM into fixed-partitions. The main intention is to reserve some RAM inside the image for exclusive use and/or attribution.
True, we do, currently, use the reserved-memory to define allocated RAM in multi-image builds, so that is not new in this RFC, though. Reserved-memory has been promoted as a better way to describe how to allocate RAM in multi-image builds, instead of using fixed-partitions: I recall the community argued that fixed-partitions were suitable to describe actual flash partitions, but  did not favor extending fixed-partitions usage on RAM.

@ioannisg @tejlmand I added a commit on top with a sample app to show the usage of the helpers, let me know if you feel like there is something missing or you want to suggest any improvement.
Replying to @ioannisg

If so, yes, I still think that it is not good if the existing solution results in any available memory area being un-usable. But as far as I understood, this is not the case. @carlocaione could you confirm that we can have auto-generated linker sections using the DT reserved-memory information, while ensuring the Zephyr build system won't be not leaving any parts of RAM un-usable? Would be greate if you could show case this with a sample code in this PR :)

Not exactly sure how to prove that but I'll think about it. Anyway I think I already kinda responded to this in my comment https://github.com/zephyrproject-rtos/zephyr/pull/35460#issuecomment-851342865. The point is that this assert is true if the two following points are true at the same time:

If two sections are conflicting at build time we get an error.
All the variables and all the memory used by Zephyr at run time are located into some section. FWICT this is true for stack, heap, bss, data, etc...

Replying to @JordanYates
Let's try to approach this another way because I think we have understood each other position by now. How can I improve the current state of the RFC so that we can meet halfway?

Let's try to approach this another way because I think we have understood each other position by now. How can I improve the current state of the RFC so that we can meet halfway?

Honestly I think the best approach is to wait until the 10th and the outcomes of the Mini-Conference. This is only 6 days after the earliest time this could be merged.
I was creating slides last night and reviewing current "partitioning" schemes, and I think there is a good chance the solution will be to use reserved-memory and autogenerate linker regions for each. That ends up looking very similar to this PR AFAICT, just without linker-section. Mostly I don't think we should merge this, then 6 days later decide that reserved-memory is the way to go for a general solution and then have to change the behavior immediately.

While I feel that the problem that this solves will be addressed as part of the larger partitioning discussion, I don't have any technical objections to this being merged.

@carlocaione, maybe I'm wrong but should the basic idea of reserved memory be to exclude it from the linker? And afterwards, using the compatible specifier add it (if required) somehow to the linker again?

@carlocaione, maybe I'm wrong but should the basic idea of reserved memory be to exclude it from the linker? And afterwards, using the compatible specifier add it (if required) somehow to the linker again?

Well, yes, but how do you exclude it from the linker? You have basically two ways to achieve that without resorting to complex solutions: either (1) you define a section and use that for that specific purpose (and that is the solution that I proposed here) or (2) you define a separate region (and that is the solution proposed by @JordanYates).

@carlocaione, maybe I'm wrong but should the basic idea of reserved memory be to exclude it from the linker? And afterwards, using the compatible specifier add it (if required) somehow to the linker again?

Well, yes, but how do you exclude it from the linker? You have basically two ways to achieve that without resorting to complex solutions: either (1) you define a section and use that for that specific purpose (and that is the solution that I proposed here) or (2) you define a separate region (and that is the solution proposed by @JordanYates).

Maybe it is possible to move the "positive" definitions (setting it as a linker region, ...) into the usage by the driver (if required). And to leave the negative definition only in the reserved-memory: reducing/splitting the SRAM section. There also exists the possibility to add a "positive" definition using<EMAIL_ADDRESS>

Maybe it is possible to move the "positive" definitions (setting it as a linker region, ...) into the usage by the driver (if required). And to leave the negative definition only in the reserved-memory: reducing/splitting the SRAM section. There also exists the possibility to add a "positive" definition using<EMAIL_ADDRESS>
I'm not sure I fully understood your proposal but that looks like similar to what @JordanYates is proposing. So basically there are two proposals on the table right now.

My idea is leveraging this PR. This solution doesn't touch SRAM but each reserved-memory node is creating an overlapping region to SRAM containing a section. Since you won't get any error if two sections are overlapping when one is empty we have to be sure that the reserved-memory region contains a "filling" variable so that you get a linker error if you are stepping over something else in SRAM, in that case you simply relocate your reserved-memory region to a different address. This proposal has the problem that you can access the reserved-memory region only by direct memory pointers (because of the "filling" variable) but that is usually not a problem. On the other hand it's an easy solution, you don't touch your SRAM and as long as your reserved memory nodes are not stepping over something important, you can organize your memory regions pretty easily.

@JordanYates proposal is more convoluted but what he is proposing is basically using for the reserved-memory node a non-overlapping memory region. This means indeed that when you add a new reserved-memory node, you have to shuffle and reorganize your memory map (for example splitting the SRAM if the reserved-memory region is in the middle) manually to accommodate things. For example with 2 reserved memory nodes you will have two regions for those and your SRAM split in 3 parts and you also have to think which one is the biggest / more suitable to host your .bss / .data / etc...

Do you have a different proposal?

Do you have a different proposal?

I would say that the reserved-memory node would exclude the memory from the SRAM, like in @JordanYates proposal, however it would not include this in the linker (reserved-memory only "excludes" it). The addition to the linker is done by the driver (if required).
If the setup does not require the exclusion of the memory (e.g. to reserve all memory in the s, ns setup) an overlay is used to delete the reserved memory-node:
&sram0 {
         reserved-memory {
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;

		sram0_ns: image_ns@20040000 {
			/* Non-Secure image memory */
                        reg = <0x20040000 0x40000>;
		};
	};
};

To generate an image:
a. for the complete region: delete the sram0_ns node and use sram0,
b. for only the s region: use sram0 (without the delete),
c. for the ns region:  use sram0_ns

I'd like to proceed ASAP with this. I don't think we have reached a fully shared solution about SRAM reservation but what's proposed here it's simple and good enough I guess. @JordanYates is working on a more complete solution involving flash and SRAM partitioning as well and that could be merged on top when it is ready, no objections.
This problem is complex and apparently everyone has a different idea on how to approach this but at this point perfect is really the enemy of good. So, we can keep discussing about this, merge this or push for another solution but this is blocking issue for me so I'd really like to keep the ball rolling about this :)

@galak please take a look at your convenience.

@mbolivar-nordic @galak addressed your comments
@JordanYates feel free to modify this PR if your PR is merged before this one.

@mbolivar-nordic It turns out that deprecating DT_ENUM_TOKEN is making the CI failing. Any suggestion?

@galak ping

Can we please merge this? @nashif or @galak?

@carlescufi can we move this forward please? :)

So this looks good, my only concern is adding DT_RESERVED_MEM_REGIONS / DT_RESERVED_MEM_SECTIONS to linker.ld unconditionally.
As its reasonable for someone to have reserved memory nodes w/o labels and this would somewhat break things.

One alternative is to generate the sections names from the node labels instead of the label property as in https://github.com/zephyrproject-rtos/zephyr/pull/36365.

So this looks good, my only concern is adding DT_RESERVED_MEM_REGIONS / DT_RESERVED_MEM_SECTIONS to linker.ld unconditionally.

This won't be a problem anymore (and it will be reworked) once the @tejlmand work on the linker script generation will be merged. It's really not useful trying to fix this sort of things now when the whole system will be reworked soon.

As its reasonable for someone to have reserved memory nodes w/o labels and this would somewhat break things.

As suggested by @JordanYates this can be fixed once his PR #36365 will be merged (and FWIW that approach looks sane to me).

So do we add a Kconfig option to enable the support.

Not clear what you are asking here, support for what?

@galak @JordanYates added this to dev-review with the hope that we can settle it today.

So I'd say either we have a customer linker script for the sample and drop the changes to the generic arm64 linker script or add a Kconfig option that wraps the changes in the linker script.
I dont like the idea of adding something like this and knowing its going to change with @tejlmand changes.  Lets either not add it right now or limit it to just the sample at this time.

So I'd say either we have a customer linker script for the sample and drop the changes to the generic arm64 linker script or add a Kconfig option that wraps the changes in the linker script.

@galak changed to have a modified linker script only for the sample.


add a converter to tfrecords to cvat/utils

add a converter to tfrecords with the proper documentation in one clean commit.

:+1:


SCIM APIs given 500 if one of the userstore connection went down

Description:
If one of the user stores connection URL is wrong and when we invoke SCIM API it fails with
{"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],"detail":"Error while listing usernames across all domains. ","status":"500"}
But we can add the domain=abc.com as the query parameter in your requests. This will search for the abc.com user store to fix this
https://localhost:9443/scim2/Users?domain=abc.com
But it should be great if is fixed to skip the User stores where the connection is not established in SCIM operations

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Silently fail flagComment request if reportAction has been deleted

Details
Coming from this comment, flagging a deleted reportAction should silently fail since deleted messages are can't be flagged.
cc @dangrous
Fixed Issues
$ https://github.com/Expensify/App/issues/21707
Tests

Send a message from account A to account B
In account B, hover over the sent message and click on reply in thread and send a message as a thread reply
Hover over the first thread message and click on the flag icon
Go to account A and go to the original chat where the thread started off and delete the first message where the thread reply is on
Go to account B and select a severity from the panel. For eg. "Intimidation"
Verify that the modal is dismissed and you still see [Deleted message] in the thread
From account A send more messages to account B
From account B, verify that you can flag those messages normally both in the main chat and in threads

[x] Verify that no errors appear in the JS console

Offline tests
N/A
QA Steps
Same as tests

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://github.com/Expensify/App/assets/22219519/dd58d2fc-212b-4e5b-8870-aed6e2fc11d4

Mobile Web - Chrome
https://github.com/Expensify/App/assets/22219519/0825f9e2-9160-46d8-b5ed-d47612a750bb

Mobile Web - Safari
https://github.com/Expensify/App/assets/22219519/1df6911e-c89b-421f-aac9-1ae172ae831a

Desktop
https://github.com/Expensify/App/assets/22219519/b19ff27e-c316-4519-b5dd-670337596e50

iOS
https://github.com/Expensify/App/assets/22219519/a5bcc196-5a59-470e-b8c1-18ccfd1ec6d8

Android
https://github.com/Expensify/App/assets/22219519/6b1229c2-d477-4f76-8550-b1d69772565b

Updated!

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

@eVoloshchak I think that's expected and happens on main too. Once you delete the reportAction the route flag/:reportID/:reportActionID is no longer available and we display the not found page.

not sure why i got assigned here

removing myself though

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/luacmartins in version: 1.3.43-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/luacmartins in version: 1.3.43-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/luacmartins in version: 1.3.44-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/jasperhuangg in version: 1.3.43-7 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Properly support writing DATE and DATETIME fields.

@fpoyer, could you have a look to this?

Code provided is valid as far as I can tell.
I merged this code into commit 876024f4e6c13a7f22ec47addbb1dae4f94b3c43 of PR #28

integrated in the #28


[Feature]user access page-level permission

Summary
Hi，There
Does appsmith have plans to make user access page-level permission functions?
Motivation
different view user access application have different permission,they can see different menu and  access page by click menu
now if user has application permission,they can access all page.

like this application have sidebar and breadcrumb

user have different permission access different page


Add Error Handling for types in Filters in Queries

The filters where written to expect certain data types for the different operators (ie. numeric type for >, <, =, ...)
If you were to run
select * from procs where uid="root";
it will crash the program because it will attempt to convert "root" to an integer without checking it is one.
(It is expecting select * from procs where uid="0"; (yes the quotations are counter-intuitive))
Here is the code that causes the error:
FilterOp::Eq => row.lookup(&x.subject) == (x.target.parse::<u32>().unwrap()),

done. :dog:


Fp2.eql

Hello,
first of all thanks for this nice library.
I tried to use Fp2.eql but does not work.
I use version 1.2.0.
It always returns true  even if the points are different.
Currently I need to use .toHex() and then compare them as strings.
Any clue on whether this is a bug or a misunderstanding/misuse of the library of mine?

> Fp2.eql(Fp2.ZERO, Fp2.ONE)
false


Function for CREATE UNIQUE

Do you think there should be function to avoid duplicated nodes? Or can this already be done somehow?

Hi,
This feature is not available in the CRUD section of the API (i.e. createNode and so on). This is so because these operations map directly to operations offered by Neo4j's REST API and as far as I know they don't offer CREATE UNIQUE for nodes (otherwise please let me know).
However, CREATE UNIQUE is available in Neo4j's Cypher query language, with this driver you can send cypher queries using these calls

OK. Lets hope that this is reasonably fast. I am currently trying to store the gitgub event stream into Neo4j. 46 GB from January to September this year.


InternalServerError: cannot find ptrref matching typeref 362ae9cb-5217-11ee-b2e0-e5bb0db8e869 when adding an update to a link property

edgedb 3.2 on cloud

update Bom
filter .title = "dfd"
set {
  components += (
    update Component filter .sku = "5" set {
      @relationship := "ddfdsssss"
    }

  )
};
InternalServerError: cannot find ptrref matching typeref 362ae9cb-5217-11ee-b2e0-e5bb0db8e869
Hint: This is most likely a bug in EdgeDB. Please consider opening an issue ticket at https://github.com/edgedb/edgedb/issues/new?template=bug_report.md

Here is schema

type Bom  {
		title: str;
		multi components: Component {relationship: str; qty: float32; instruction: str;};
		multi notes: str;
	}

type Component {
        name:  str;
        sku: str;
    }

I intend to construct above block to update properties and link properties together.
But the same structure with Insert is work, let change Update to insert
insert

Any update?
I tested it with select, it work correctly too. Only fail in update.


[REQUEST] Variable with Unique value for each BOT

Hi
please add a variable with a unique value for each bot
and not changeable after it's creds/data or proxy changed
like the bots id

i found botnum in fixed variables and that's enough for me
Thanks Ruri