problem with dimensionality for non-periodic boundary conditions in lammps.base

Hi everyone,
in write_structure_block function the get_dimensionality method from AiiDA's StructureData class is used to compute dimensionality and write Lammps input files. The problem is that get_dimensionality actually computes the number of periodic boundary conditions which is not Lammps' dimensionality if I understand correctly.
For example the following structure leads to a Lammps error :
cell = [[1,0,0],
        [0,1,0],
        [0,0,1]]
structure = orm.StructureData(cell = cell, pbc = [True,True,False])

because write_structure_block writes in the Lammps input file :
dimension 2
boundary p p f

instead of :
dimension 3
boundary p p f

@JPchico thanks for your reply! I think the problem is the other way around in this case: we would like a 3D simulation with a non-periodic boundary condition in LAMMPS but AiiDA assumes only 2 dimensions.
I suppose the second solution will be necessary at some point to allow for more boundary condition types than periodic and fixed but, for simpler cases wouldn't it be possible to compute the dimension for LAMMPS as the length of the cell list from the StructureData?
dim = len(structure.cell)

Hi @JDaubin
Okay I understand now, I think that is not possible, as the cell in AiiDA always has three lattice vectors. So just modifying the size of the cell would not work. In some programs one can set that one of the vectors is equal to zero, this is the interpreted as basically the size is given by the cartesian coordinates along that direction.
I think that the issue is that in the aiida sense a 3D structure by definition has periodic boundary conditions in each direction. This I think is the result from the StructureData being built for mostly DFT calculations. I think this is actually something that maybe one could raise in the aiida discourse .
I think that for the current implementation of the StructureData one needs to add the overwrites.
Maybe there is another way without it, but I cannot think about it right now.

I made a discourse post raising this issue. Feel free to write anything that I missed @JDaubin . I also have made a branch in my fork dealing with this, I'll be testing it soon and see if it works to solve this issue.

Thanks for raising @JDaubin and pointing us to this issue @JPchico! We're currently in the process of redesigning the StructureData, so understanding more use cases is very valuable. I can see how the dimensionality of a system is not necessarily directly determined by the periodic boundary conditions. One system I can imagine is a 3D metal in which you are looking at heat transport in one direction.
Just to understand, what problem are you studying here? What are the boundary conditions in the 3rd direction? How many different types of boundary conditions does LAMMPS support?

hi @mbercx and @JPchico, thanks for the work done and your interest in this issue!
Unfortunately I am no expert neither in using LAMMPS nor molecular dynamics so I won't be able to give a detailed explanation of the use case. I am in the process of automating with AiiDA an existing workflow which uses LAMMPS to study dislocations in metals. In this stage LAMMPS is used for the relaxation of atoms between two plates which are "glued together" so the boundary atoms along the z direction are fixed with a zero velocity. For more context and a better explanation, the full workflow and this specific step are described in the 2.1.3 section of  L M Dupuy et al 2024 Modelling Simul. Mater. Sci. Eng. 32 035015.
LAMMPS supports 4 kinds of boundary conditions:

periodic
non-periodic and fixed
non-periodic and shrink-wrapped
non-periodic and shrink-wrapped with a minimum value

Great, thanks for the explanation @JDaubin. We'll consider the use case in our updated version of the StructureData, but that'll still take some time. So for now it would be better to add one of the workarounds that @JPchico suggested.

@JDaubin I have made a fork in which the overrides to the dimension and the boundary types can be passed in the parameters dictionary directly. Of this way it should be possible to handle the situation that you have. I'll add some notes in the documentation about this and then I'll make a PR to solve this issue.

Thanks a lot @JPchico, I just tested the new branch and it works as expected for my use case. I only have 2 comments:

in the json schema I think structure.dimension could be restricted to 2,3 instead of 1,2,3 because LAMMPS doesn't allow 1 for this command.
I was surprised with the requirement of python 3.9 instead of 3.8.

No worries, thanks for the comment on dimension 1 will change that.
Yeah this is because the latest release of aiida-core has dropped python 3.8 that is why. Is that a problem?

No, actually I have been using python 3.8 only because of #116 but now that you fixed this issue it isn't a problem anymore.

Aha, yes that is fixed in the develop branch, will be merging that once the PRs are approved. The issue was not actually python 3.8 if not the jsonschema version that has changed how some validation happens and was causing the problems. I have about changing to pydantic to avoid this problem, but that is a major change that I think should be taken for a new major version.

Fixed via #122


New Linux mount API

I would like to add support for the new Linux mount API. This API currently does not have man pages but I'll attach some recent drafts below. Would such a Linux-specific API be suitable for this project?

NAME
fsopen, fsmount - Filesystem parameterisation and mount creation
SYNOPSIS
#include <sys/types.h>

#include <sys/mount.h>

#include <unistd.h>

#include <fcntl.h> /* Definition of AT_* constants */

#include <sys/mount.h>

int fsopen(const char *fsname, unsigned int flags);

int fsmount(int fd, unsigned int flags, unsigned int mount_attrs);

Note: There are no glibc wrappers for these system calls.
DESCRIPTION
fsopen() creates a blank filesystem configuration context within the
kernel for the filesystem named in the fsname parameter, puts it into
creation mode and attaches it to a file descriptor, which it then
returns. The file descriptor can be marked close-on-exec by setting
FSOPEN_CLOEXEC in flags.
After calling fsopen(), the file descriptor should be passed to the
fsconfig(2) system call, using that to specify the desired
filesystem and security parameters.
When the parameters are all set, the fsconfig() system call should
then be called again with FSCONFIG_CMD_CREATE as the command
argument to effect the creation.

[!] NOTE: Depending on the filesystem type and parameters, this
may rather share an existing in-kernel filesystem representation
instead of creating a new one. In such a case, the parameters
specified may be discarded or may overwrite the parameters set by a
previous mount - at the filesystem's discretion.

The file descriptor also serves as a channel by which more comprehensive
error, warning and information messages may be retrieved from the kernel
using read(2).
Once the creation command has been successfully run on a context, the
context is switched into need-mount mode which prevents further
configuration. At this point, fsmount() should be called to create a
mount object.
fsmount() takes the file descriptor returned by fsopen() and
creates a mount object for the filesystem root specified there. The
attributes of the mount object are set from the mount_attrs
parameter. The attributes specify the propagation and mount restrictions
to be applied to accesses through this mount.
The mount object is then attached to a new file descriptor that looks
like one created by open(2) with O_PATH or open_tree(2).
This can be passed to move_mount(2) to attach the mount object to a
mountpoint, thereby completing the process.
The file descriptor returned by fsmount() is marked close-on-exec if
FSMOUNT_CLOEXEC is specified in flags.
After fsmount() has completed, the context created by fsopen() is reset
and moved to reconfiguration state, allowing the new superblock to be
reconfigured. See fspick(2) for details.
Message Retrieval Interface
The context file descriptor may be queried for message strings at any
time by calling read(2) on the file descriptor. This will return
formatted messages that are prefixed to indicate their class:
"e <message>"
:   An error message string was logged.
"i <message>"
:   An informational message string was logged.
"w <message>"
:   An warning message string was logged.
Messages are removed from the queue as they're read.
EXAMPLES
To illustrate the process, here's an example whereby this can be used
to mount an ext4 filesystem on /dev/sdb1 onto /mnt.
sfd = fsopen("ext4", FSOPEN_CLOEXEC);
fsconfig(sfd, FSCONFIG_SET_FLAG, "ro", NULL, 0);
fsconfig(sfd, FSCONFIG_SET_STRING, "source", "/dev/sdb1", 0);
fsconfig(sfd, FSCONFIG_SET_FLAG, "noatime", NULL, 0);
fsconfig(sfd, FSCONFIG_SET_FLAG, "acl", NULL, 0);
fsconfig(sfd, FSCONFIG_SET_FLAG, "user_attr", NULL, 0);
fsconfig(sfd, FSCONFIG_SET_FLAG, "iversion", NULL, 0);
fsconfig(sfd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
mfd = fsmount(sfd, FSMOUNT_CLOEXEC, MS_RELATIME);
move_mount(mfd, "", sfd, AT_FDCWD, "/mnt", MOVE_MOUNT_F_EMPTY_PATH);

Here, an ext4 context is created first and attached to sfd. This is then
told where its source will be, given a bunch of options and created.
Then fsmount() is called to create a mount object and move_mount(2)
is called to attach it to its intended mountpoint.
And here's an example of mounting from an NFS server and setting a
Smack security module label on it too:
sfd = fsopen("nfs", 0);
fsconfig(sfd, FSCONFIG_SET_STRING, "source", "example.com/pub/linux", 0);
fsconfig(sfd, FSCONFIG_SET_STRING, "nfsvers", "3", 0);
fsconfig(sfd, FSCONFIG_SET_STRING, "rsize", "65536", 0);
fsconfig(sfd, FSCONFIG_SET_STRING, "wsize", "65536", 0);
fsconfig(sfd, FSCONFIG_SET_STRING, "smackfsdef", "foolabel", 0);
fsconfig(sfd, FSCONFIG_SET_FLAG, "rdma", NULL, 0);
fsconfig(sfd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
mfd = fsmount(sfd, 0, MS_NODEV);
move_mount(mfd, "", sfd, AT_FDCWD, "/mnt", MOVE_MOUNT_F_EMPTY_PATH);

RETURN VALUE
On success, both functions return a file descriptor. On error, -1 is
returned, and errno is set appropriately.
ERRORS
The error values given below result from filesystem type independent
errors. Each filesystem type may have its own special errors and its own
special behavior. See the Linux kernel source code for details.
EBUSY
:   The context referred to by fd is not in the right state to be used
by fsmount().
EFAULT
:   One of the pointer arguments points outside the user address space.
EINVAL
:   flags had an invalid flag set.
EINVAL
:   mount_attrs, includes invalid MOUNT_ATTR_* flags.
EMFILE
:   The system has too many open files to create more.
ENFILE
:   The process has too many open files to create more.
ENODEV
:   Filesystem fsname not configured in the kernel.
ENOMEM
:   The kernel could not allocate sufficient memory to complete the
call.
EPERM
:   The caller does not have the required privileges.
CONFORMING TO
These functions are Linux-specific and should not be used in programs
intended to be portable.
VERSIONS
fsopen(), and fsmount() were added to Linux in kernel 5.1.
NOTES
Glibc does not (yet) provide a wrapper for the fsopen() or
fsmount() system calls; call them using syscall(2).
SEE ALSO
mountpoint(1), fsconfig(2), fspick(2), move_mount(2),
open_tree(2), umount(2), mount_namespaces(7),
path_resolution(7), findmnt(8), lsblk(8), mount(8),
umount(8)

NAME
fsconfig - Filesystem parameterisation
SYNOPSIS
#include <sys/types.h>

#include <sys/mount.h>

#include <unistd.h>

#include <sys/mount.h>

int fsconfig(int *fd, unsigned int cmd, const char *key,

 const void __user *value, int aux);

Note: There is no glibc wrapper for this system call.
DESCRIPTION
fsconfig() is used to supply parameters to and issue commands
against a filesystem configuration context as set up by fsopen(2) or
fspick(2). The context is supplied attached to the file descriptor
specified by fd argument.
The cmd argument indicates the command to be issued, where some of the
commands simply supply parameters to the context. The meaning of key,
value and aux are command-dependent; unless required for the
command, these should be set to NULL or 0.
The available commands are:
FSCONFIG_SET_FLAG
:   Set the parameter named by key to true. This may incur error
EINVAL if the parameter requires an argument.
FSCONFIG_SET_STRING
:   Set the parameter named by key to a string. This may incur error
EINVAL if the parser doesn't want a parameter here, wants a
non-string or the string cannot be interpreted appropriately.
value points to a NUL-terminated string.
FSCONFIG_SET_BINARY
:   Set the parameter named by key to be a binary blob argument. This
may cause EINVAL to be returned if the filesystem parser isn't
expecting a binary blob and it can't be converted to something
usable. value points to the data and aux indicates the size of
the data.
FSCONFIG_SET_PATH
:   Set the parameter named by key to the object at the provided path.
value should point to a NULL-terminated pathname string and aux
may indicate AT_FDCWD or a file descriptor indicating a
directory from which to begin a relative pathwalk. This may return
any errors incurred by the pathwalk and may return EINVAL if the
parameter isn't expecting a path.
Note that FSCONFIG\_SET\_STRING can be used instead, implying
AT\_FDCWD.

FSCONFIG_SET_PATH_EMPTY
:   As FSCONFIG_SET_PATH, but with AT_EMPTY_PATH applied to the
pathwalk.
FSCONFIG_SET_FD
:   Set the parameter named by key to the file descriptor specified by
aux. This will incur EINVAL if the parameter doesn't expect a
file descriptor or EBADF if the file descriptor is invalid.
Note that FSCONFIG\_SET\_STRING can be used instead with the file
descriptor passed as a decimal string.

FSCONFIG_CMD_CREATE
:   This command causes the filesystem to take the parameters set in the
context and to try to create filesystem representation in the
kernel. If it can share an existing one, it may do that instead if
the filesystem type and parameters permit that. This is intended for
use with fsopen(2).
FSCONFIG_CMD_RECONFIGURE
:   This command causes the filesystem to apply the parameters set in
the context to an already existing filesystem representation in
memory and to alter it. This is intended for use with fspick(2),
but may also by used against the context created by fsopen()
after fsmount(2) has been called on it.
EXAMPLES
fsconfig(sfd, FSCONFIG_SET_FLAG, "ro", NULL, 0);

fsconfig(sfd, FSCONFIG_SET_STRING, "user_xattr", "false", 0);

fsconfig(sfd, FSCONFIG_SET_BINARY, "ms_pac", pac_buffer, pac_size);

fsconfig(sfd, FSCONFIG_SET_PATH, "journal", "/dev/sdd4", AT_FDCWD);

dirfd = open("/dev/", O_PATH);
fsconfig(sfd, FSCONFIG_SET_PATH, "journal", "sdd4", dirfd);

fd = open("/overlays/mine/", O_PATH);
fsconfig(sfd, FSCONFIG_SET_PATH_EMPTY, "lower_dir", "", fd);

pipe(pipefds);
fsconfig(sfd, FSCONFIG_SET_FD, "fd", NULL, pipefds[1]);

RETURN VALUE
On success, the function returns 0. On error, -1 is returned, and
errno is set appropriately.
ERRORS
The error values given below result from filesystem type independent
errors. Each filesystem type may have its own special errors and its own
special behavior. See the Linux kernel source code for details.
EACCES
:   A component of a path was not searchable. (See also
path_resolution(7).)
EACCES
:   Mounting a read-only filesystem was attempted without specifying the
'ro' parameter.
EACCES
:   A specified block device is located on a filesystem mounted with the
MS_NODEV option.
EBADF
:   The file descriptor given by fd or possibly by aux (depending on
the command) is invalid.
EBUSY
:   The context attached to fd is in the wrong state for the given
command.
EBUSY
:   The filesystem representation cannot be reconfigured read-only
because it still holds files open for writing.
EFAULT
:   One of the pointer arguments points outside the user address space.
EINVAL
:   fd does not refer to a filesystem configuration context.
EINVAL
:   One of the source parameters referred to an invalid superblock.
ELOOP
:   Too many links encountered during pathname resolution.
ENAMETOOLONG
:   A path name was longer than MAXPATHLEN.
ENOENT
:   A pathname was empty or had a nonexistent component.
ENOMEM
:   The kernel could not allocate sufficient memory to complete the
call.
ENOTBLK
:   Once of the parameters does not refer to a block device (and a
device was required).
ENOTDIR
:   pathname, or a prefix of source, is not a directory.
EOPNOTSUPP
:   The command given by cmd was not valid.
ENXIO
:   The major number of a block device parameter is out of range.
EPERM
:   The caller does not have the required privileges.
CONFORMING TO
These functions are Linux-specific and should not be used in programs
intended to be portable.
VERSIONS
fsconfig() was added to Linux in kernel 5.1.
NOTES
Glibc does not (yet) provide a wrapper for the fspick() system call;
call it using syscall(2).
SEE ALSO
mountpoint(1), fsmount(2), fsopen(2), fspick(2),
mount_namespaces(7), path_resolution(7)

NAME
fspick - Select filesystem for reconfiguration
SYNOPSIS
#include <sys/types.h>

#include <sys/mount.h>

#include <unistd.h>

#include <fcntl.h> /* Definition of AT_* constants */

int fspick(int dirfd, const char *pathname, unsigned int flags);

Note: There is no glibc wrapper for this system call.
DESCRIPTION
fspick() creates a new filesystem configuration context within the
kernel and attaches a pre-existing superblock to it so that it can be
reconfigured (similar to mount(8) with the "-o remount" option).
The configuration context is marked as being in reconfiguration mode and
attached to a file descriptor, which is returned to the caller. This can
be marked close-on-exec by setting FSPICK_CLOEXEC in flags.
The target is whichever superblock backs the object determined by dfd,
pathname and flags. The following can be set in flags to control
the pathwalk to that object:
FSPICK_SYMLINK_NOFOLLOW
:   Don't follow symbolic links in the terminal component of the path.
FSPICK_NO_AUTOMOUNT
:   Don't follow automounts in the terminal component of the path.
FSPICK_EMPTY_PATH
:   Allow an empty string to be specified as the pathname. This allows
dirfd to specify a path exactly.
After calling fspick(), the file descriptor should be passed to the
fsconfig(2) system call, using that to specify the desired changes
to filesystem and security parameters.
When the parameters are all set, the fsconfig() system call should
then be called again with FSCONFIG_CMD_RECONFIGURE as the command
argument to effect the reconfiguration.
After the reconfiguration has taken place, the context is wiped clean
(apart from the superblock attachment, which remains) and can be reused
to make another reconfiguration.
The file descriptor also serves as a channel by which more comprehensive
error, warning and information messages may be retrieved from the kernel
using read(2).
Message Retrieval Interface
The context file descriptor may be queried for message strings at any
time by calling read(2) on the file descriptor. This will return
formatted messages that are prefixed to indicate their class:
"e <message>"
:   An error message string was logged.
"i <message>"
:   An informational message string was logged.
"w <message>"
:   An warning message string was logged.
Messages are removed from the queue as they're read and the queue has a
limited depth, so it's possible for some to get lost.
EXAMPLES
To illustrate the process, here's an example whereby this can be used
to reconfigure a filesystem:
sfd = fspick(AT_FDCWD, "/mnt", FSPICK_NO_AUTOMOUNT | FSPICK_CLOEXEC);
fsconfig(sfd, FSCONFIG_SET_FLAG, "ro", NULL, 0);
fsconfig(sfd, FSCONFIG_SET_STRING, "user_xattr", "false", 0);
fsconfig(sfd, FSCONFIG_CMD_RECONFIGURE, NULL, NULL, 0);

RETURN VALUE
On success, the function returns a file descriptor. On error, -1 is
returned, and errno is set appropriately.
ERRORS
The error values given below result from filesystem type independent
errors. Each filesystem type may have its own special errors and its own
special behavior. See the Linux kernel source code for details.
EACCES
:   A component of a path was not searchable. (See also
path_resolution(7).)
EFAULT
:   pathname points outside the user address space.
EINVAL
:   flags includes an undefined value.
ELOOP
:   Too many links encountered during pathname resolution.
EMFILE
:   The system has too many open files to create more.
ENFILE
:   The process has too many open files to create more.
ENAMETOOLONG
:   A pathname was longer than MAXPATHLEN.
ENOENT
:   A pathname was empty or had a nonexistent component.
ENOMEM
:   The kernel could not allocate sufficient memory to complete the
call.
EPERM
:   The caller does not have the required privileges.
CONFORMING TO
These functions are Linux-specific and should not be used in programs
intended to be portable.
VERSIONS
fsopen(), fsmount() and fspick() were added to Linux in
kernel 5.1.
NOTES
Glibc does not (yet) provide a wrapper for the fspick() system call;
call it using syscall(2).
SEE ALSO
mountpoint(1), fsconfig(2), fsopen(2),
path_resolution(7), mount(8)

NAME
move_mount - Move mount objects around the filesystem topology
SYNOPSIS
#include <sys/types.h>

#include <sys/mount.h>

#include <unistd.h>

#include <fcntl.h> /* Definition of AT_* constants */

int move_mount(int from_dirfd, const char *from_pathname,
 int to_dirfd, const char *to_pathname,
 unsigned int flags);

Note: There is no glibc wrapper for this system call.
DESCRIPTION
The move_mount() call moves a mount from one place to another; it
can also be used to attach an unattached mount created by fsmount()
or open_tree() with OPEN_TREE_CLONE.
If move_mount() is called repeatedly with a file descriptor that
refers to a mount object, then the object will be attached/moved the
first time and then moved again and again and again, detaching it from
the previous mountpoint each time.
To access the source mount object or the destination mountpoint, no
permissions are required on the object itself, but if either pathname is
supplied, execute (search) permission is required on all of the
directories specified in from_pathname or to_pathname.
The caller does, however, require the appropriate capabilities or
permission to effect a mount.
move_mount() uses from_pathname, from_dirfd and part of
flags to locate the mount object to be moved and to_pathname,
to_dirfd and another part of flags to locate the destination
mountpoint. Each lookup can be done in one of a variety of ways:
[*] By absolute path.
:   The pathname points to an absolute path and the dirfd is ignored.
The file is looked up by name, starting from the root of the
filesystem as seen by the calling process.
[*] By cwd-relative path.
:   The pathname points to a relative path and the dirfd is AT_FDCWD.
The file is looked up by name, starting from the current working
directory.
[*] By dir-relative path.
:   The pathname points to relative path and the dirfd indicates a file
descriptor pointing to a directory. The file is looked up by name,
starting from the directory specified by dirfd.
[*] By file descriptor.
:   The pathname points to "", the dirfd points directly to the mount
object to move or the destination mount point and the appropriate
*_EMPTY_PATH flag is set.
flags can be used to influence a path-based lookup. A value for
flags is constructed by OR'ing together zero or more of the following
constants:
MOVE_MOUNT_F_EMPTY_PATH
:   If from_pathname is an empty string, operate on the file referred
to by from_dirfd (which may have been obtained using the
open(2) O_PATH flag or open_tree()) If from_dirfd
is AT_FDCWD, the call operates on the current working
directory. In this case, from_dirfd can refer to any type of
file, not just a directory. This flag is Linux-specific; define
_GNU_SOURCE to obtain its definition.
MOVE_MOUNT_T_EMPTY_PATH
:   As above, but operating on to_pathname and to_dirfd.
MOVE_MOUNT_F_NO_AUTOMOUNT
:   Don't automount the terminal ("basename") component of
from_pathname if it is a directory that is an automount point.
This allows a mount object that has an automount point at its root
to be moved and prevents unintended triggering of an automount
point. The MOVE_MOUNT_F_NO_AUTOMOUNT flag has no effect if
the automount point has already been mounted over. This flag is
Linux-specific; define _GNU_SOURCE to obtain its definition.
MOVE_MOUNT_T_NO_AUTOMOUNT
:   As above, but operating on to_pathname and to_dirfd. This
allows an automount point to be manually mounted over.
MOVE_MOUNT_F_SYMLINKS
:   If from_pathname is a symbolic link, then dereference it. The
default for move_mount() is to not follow symlinks.
MOVE_MOUNT_T_SYMLINKS
:   As above, but operating on to_pathname and to_dirfd.
EXAMPLES
The move_mount() function can be used like the following:

move_mount(AT_FDCWD, "/a", AT_FDCWD, "/b", 0);

This would move the object mounted on "/a" to "/b". It can also be
used in conjunction with open_tree(2) or open(2) with
O_PATH:

fd = open_tree(AT_FDCWD, "/mnt", 0);
move_mount(fd, "", AT_FDCWD, "/mnt2", MOVE_MOUNT_F_EMPTY_PATH);
move_mount(fd, "", AT_FDCWD, "/mnt3", MOVE_MOUNT_F_EMPTY_PATH);
move_mount(fd, "", AT_FDCWD, "/mnt4", MOVE_MOUNT_F_EMPTY_PATH);

This would attach the path point for "/mnt" to fd, then it would move
the mount to "/mnt2", then move it to "/mnt3" and finally to
"/mnt4".
It can also be used to attach new mounts:

sfd = fsopen("ext4", FSOPEN_CLOEXEC);
fsconfig(sfd, FSCONFIG_SET_STRING, "source", "/dev/sda1", 0);
fsconfig(sfd, FSCONFIG_SET_FLAG, "user_xattr", NULL, 0);
fsconfig(sfd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
mfd = fsmount(sfd, FSMOUNT_CLOEXEC, MOUNT_ATTR_NODEV);
move_mount(mfd, "", AT_FDCWD, "/home", MOVE_MOUNT_F_EMPTY_PATH);

Which would open the Ext4 filesystem mounted on "/dev/sda1", turn on
user extended attribute support and create a mount object for it.
Finally, the new mount object would be attached with move_mount()
to "/home".
RETURN VALUE
On success, 0 is returned. On error, -1 is returned, and errno is set
appropriately.
ERRORS
EACCES
:   Search permission is denied for one of the directories in the path
prefix of pathname. (See also path_resolution(7).)
EBADF
:   from_dirfd or to_dirfd is not a valid open file descriptor.
EFAULT
:   from_pathname or to_pathname is NULL or either one point to a
location outside the process's accessible address space.
EINVAL
:   Reserved flag specified in flags.
ELOOP
:   Too many symbolic links encountered while traversing the pathname.
ENAMETOOLONG
:   from_pathname or to_pathname is too long.
ENOENT
:   A component of from_pathname or to_pathname does not exist, or
one is an empty string and the appropriate *_EMPTY_PATH was
not specified in flags.
ENOMEM
:   Out of memory (i.e., kernel memory).
ENOTDIR
:   A component of the path prefix of from_pathname or to_pathname
is not a directory or one or the other is relative and the
appropriate *_dirfd is a file descriptor referring to a file
other than a directory.
VERSIONS
move_mount() was added to Linux in kernel 4.18.
CONFORMING TO
move_mount() is Linux-specific.
NOTES
Glibc does not (yet) provide a wrapper for the move_mount() system
call; call it using syscall(2).
SEE ALSO
fsmount(2), fsopen(2), open_tree(2)

NAME
open_tree - Pick or clone mount object and attach to fd
SYNOPSIS
#include <sys/types.h>

#include <sys/mount.h>

#include <unistd.h>

#include <fcntl.h> /* Definition of AT_* constants */

int open_tree(int dirfd, const char *pathname, unsigned int flags);

Note: There are no glibc wrappers for these system calls.
DESCRIPTION
open_tree() picks the mount object specified by the pathname and
attaches it to a new file descriptor or clones it and attaches the clone
to the file descriptor. The resultant file descriptor is
indistinguishable from one produced by open(2) with O_PATH.
In the case that the mount object is cloned, the clone will be
"unmounted" and destroyed when the file descriptor is closed if it is
not otherwise mounted somewhere by calling move_mount(2).
To select a mount object, no permissions are required on the object
referred to by the path, but execute (search) permission is required on
all of the directories in pathname that lead to the object.
To clone an object, however, the caller must have mount capabilities and
permissions.
open_tree() uses pathname, dirfd and flags to locate the
target object in one of a variety of ways:
[*] By absolute path.
:   pathname points to an absolute path and dirfd is ignored. The
object is looked up by name, starting from the root of the
filesystem as seen by the calling process.
[*] By cwd-relative path.
:   pathname points to a relative path and dirfd is AT_FDCWD. The
object is looked up by name, starting from the current working
directory.
[*] By dir-relative path.
:   pathname points to relative path and dirfd indicates a file
descriptor pointing to a directory. The object is looked up by name,
starting from the directory specified by dirfd.
[*] By file descriptor.
:   pathname is "", dirfd indicates a file descriptor and
AT_EMPTY_PATH is set in flags. The mount attached to the
file descriptor is queried directly. The file descriptor may point
to any type of file, not just a directory.
flags can be used to control the operation of the function and to
influence a path-based lookup. A value for flags is constructed by
OR'ing together zero or more of the following constants:
AT_EMPTY_PATH
:   If pathname is an empty string, operate on the file referred to by
dirfd (which may have been obtained from open(2) with
O_PATH, from fsmount(2) or from another open_tree()).
If dirfd is AT_FDCWD, the call operates on the current
working directory. In this case, dirfd can refer to any type of
file, not just a directory. This flag is Linux-specific; define
_GNU_SOURCE to obtain its definition.
AT_NO_AUTOMOUNT
:   Don't automount the terminal ("basename") component of pathname
if it is a directory that is an automount point. This flag allows
the automount point itself to be picked up or a mount cloned that is
rooted on the automount point. The AT_NO_AUTOMOUNT flag has no
effect if the mount point has already been mounted over. This flag
is Linux-specific; define _GNU_SOURCE to obtain its
definition.
AT_SYMLINK_NOFOLLOW
:   If pathname is a symbolic link, do not dereference it: instead
pick up or clone a mount rooted on the link itself.
OPEN_TREE_CLOEXEC
:   Set the close-on-exec flag for the new file descriptor. This will
cause the file descriptor to be closed automatically when a process
exec's.
OPEN_TREE_CLONE
:   Rather than directly attaching the selected object to the file
descriptor, clone the object, set the root of the new mount object
to that point and attach the clone to the file descriptor.
AT_RECURSIVE
:   This is only permitted in conjunction with OPEN_TREE_CLONE. It
causes the entire mount subtree rooted at the selected spot to be
cloned rather than just that one mount object.
EXAMPLE
The open_tree() function can be used like the following:

fd1 = open_tree(AT_FDCWD, "/mnt", 0);
fd2 = open_tree(fd1, "",
                AT_EMPTY_PATH | OPEN_TREE_CLONE | AT_RECURSIVE);
move_mount(fd2, "", AT_FDCWD, "/mnt2", MOVE_MOUNT_F_EMPTY_PATH);

This would attach the path point for "/mnt" to fd1, then it would copy
the entire subtree at the point referred to by fd1 and attach that to
fd2; lastly, it would attach the clone to "/mnt2".
RETURN VALUE
On success, the new file descriptor is returned. On error, -1 is
returned, and errno is set appropriately.
ERRORS
EACCES
:   Search permission is denied for one of the directories in the path
prefix of pathname. (See also path_resolution(7).)
EBADF
:   dirfd is not a valid open file descriptor.
EFAULT
:   pathname is NULL or pathname point to a location outside the
process's accessible address space.
EINVAL
:   Reserved flag specified in flags.
ELOOP
:   Too many symbolic links encountered while traversing the pathname.
ENAMETOOLONG
:   pathname is too long.
ENOENT
:   A component of pathname does not exist, or pathname is an empty
string and AT_EMPTY_PATH was not specified in flags.
ENOMEM
:   Out of memory (i.e., kernel memory).
ENOTDIR
:   A component of the path prefix of pathname is not a directory or
pathname is relative and dirfd is a file descriptor referring to
a file other than a directory.
VERSIONS
open_tree() was added to Linux in kernel 4.18.
CONFORMING TO
open_tree() is Linux-specific.
NOTES
Glibc does not (yet) provide a wrapper for the open_tree() system
call; call it using syscall(2).
SEE ALSO
fsmount(2), move_mount(2), open(2)

Do you know what problem these new syscalls are intended to solve?

The original motivation and an older version of the api is discussed here.
I'm particularly interested in the ability to create anonymous mounts. That is, mounts that are not visible in the file system:
#include <sys/syscall.h>
#include <linux/mount.h>
#include <unistd.h>
#include <fcntl.h>

int main(void) {
	int cfg = syscall(SYS_fsopen, "proc", 0);
	syscall(SYS_fsconfig, cfg, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
	int mnt = syscall(SYS_fsmount, cfg, 0, 0);
	int fd = openat(mnt, "cpuinfo", O_RDONLY);
	char buf[128];
	while (1) {
		int bytes = read(fd, buf, sizeof(buf));
		if (bytes <= 0) {
			break;
		}
		write(1, buf, bytes);
	}
}

Implemented here.

The article only mentions that the new API relieves the requirement for all mount options to fit within 4096 bytes.  Is that the only benefit?

Thank you for taking the time to look into this.
Unfortunately, after trying to use nix in an application I'm working on, I found that I'm not really comfortable with the nix API. I've written my own bindings instead: https://github.com/mahkoh/uapi
Therefore I'm not interested into pushing for the inclusion of the new mount API into nix at this time. Of course you (or anyone else) can still use the nix-style code I posted above and include it in nix under the nix license.

Ok, I'll close the issue then.  Reopen it in the future if you ever decide to come back to it.


Unify passage of disconnectedNodeAcknowledged param

Please consider unifying passing disconnectedNodeAcknowledged as query parameter everywhere.
Multipart form data support in Swagger 2.0 ain't that great.

Can you please create a JIRA for this and reference it in your pull request? Thanks.
https://issues.apache.org/jira/browse/NIFI

@pvillard31 created a ticked for improvement: https://issues.apache.org/jira/browse/NIFI-7780
I'm not sure how to sell this change back to community, please advice
Thanks


Lookup tab

Existing features:

[x] Enter address

Um, this is a bit unclear. In Snow Leopard, this was clearly a dig front-end:

But in Catalina, the "select the information to lookup" drop-down is gone, and the output vastly simplified:

However, that's not the (default) output of host, dig, or dscacheutil, for that matter?
I feel like we should do these new features:

[x] Let users choose between dscacheutil and dig and explain why (see below)
[x] When choosing dig, bring back the drop-down to let users choose a particular record
[x] For dig: -x (reverse lookup). Either in the above drop-down, or as a checkbox.

(•) macOS Directory Services (`dscacheutil`): matches Safari's behavior
( ) BIND (`dig`): matches Unix behavior, and offers more option

Not bad for entirely in XAML.

Now if only we could figure out all the options in that drop-down…


Release pending upgrades as 0.12.5

Those changed should be released: https://github.com/CosmWasm/rust-optimizer/compare/v0.12.4...main.
See https://github.com/CosmWasm/rust-optimizer/wiki/Releasing

Running with a rust-optimizer built from main didn't give me the error. Releasing that should be a fix!

Release completed


fix: create a pack for alert-engine

Issue
Recent changes added alert-engine in base entreprise features pack.
When Alert Engine will adopt the node's license framework, that would have added alter engine to all "planet" licenses.
Description

Created a specific pack to that the feature is known in the license model
Remove AE feature from the entreprise pack
Add to AE feature "galaxy" and "universe" tiers

This way, when AE adapots node's license framework :

License with "planet" tier will not infer alert-engine feature, hence it is not added by accident.
galaxy and universe tier will include AE feature automatically.

** This does not affect the current behaviour, license generator is not impacted **
Additional context

Gravitee.io Automatic Deployment
🚀 A prerelease version of this package has been published on Gravitee's private artifactory, you can:

use it directly by updating your project with version: 4.6.0-fix-ae-license-SNAPSHOT
download it from Artifactory here

:tada: This PR is included in version 4.6.0-alpha.3 :tada:
The release is available on:

4.6.0-alpha.3
GitHub release

Your semantic-release bot :package::rocket:


Use NSProxy to implement ObjC protocols

This is half the solution to protocol implementation. It adds a user visible class in package:objective_c called DartProxy, which is based on NSProxy. It stores a map from selector to block, so users can implement methods using blocks. DartProxy objects are built using DartProxyBuilder, which is just a helper to build that map. There are no changes to ffigen code generation in this PR.
The other half of the solution will be code-gen for protocols that will make things more ergonomic, by hiding the details of DartProxy. It may be the case that some advanced use cases (eg implementing multiple protocols) may still need to use DartProxy, but I can still make it a bit more ergonomic than it is in protocol_test.dart once that code-gen lands.
Overview:

Classes:

SEL (aka selector) represents the name of a method. It does not encode the arg/return types. It's essentially a canonicalized string. We create it using sel_registerName.
NSMethodSignature represents the type of a method. It doesn't include the name. We can construct it from a const char* that encodes the arg/return types. We don't actually have to implement these signature encoding rules though, because we can do protocol_getMethodDescription(proto, selector,...).types.
NSInvocation represents a single method call. It contains a SEL, a NSMethodSignature, a target object (which we bypass using invokeWithTarget), and a list of arguments. It also has space for the result.
NSProxy is a class that lets us respond to arbitrary methods. It checks whether we implement a method using respondsToSelector, checks the signature using methodSignatureForSelector, and then invokes the method using forwardInvocation.
DartProxy is our implementation of NSProxy, and has a map from SEL to (NSMethodSignature, user's block). Since SELs are already canonicalzed, we can use these pointers directly as map keys.
DartProxyBuilder is used to build DartProxys. It has the same sort of map as DartProxy, but it's mutable. When constructing a DartProxy, we make an immutable (shallow) copy of that map, so that DartProxy objects can be accessed from arbitrary threads without worrying about synchronization.

The design of this solution relies on the fact that ObjC blocks are objects that can receive messages. But there's a bit of a difference in the way they receive them. Instead of the selector selecting which method is invoked, it's passed as an ordinary argument.

The NSInvocation args for an ordinary object look like [target, selector, first arg, second arg...], whereas for a block they look like [block, first arg, second arg...].
So in DartProxy.forwardInvocation we could construct a new NSInvocation and copy across all the args except the selector, or we could just write blocks that take the SEL as an extra arg that they ignore. I went with the second option.

protocol_test.m current manually defines all the method blocks. Once code-gen support for protocols lands, this won't be necessary.
Now that we're bundling both C and ObjC into the package:objective_c dylib, I had to rewrite the build script a bit.
This PR doesn't support implementing class methods, only instance methods. See #1149

https://github.com/dart-lang/native/issues/1040

coverage: 91.204% (+0.2%) from 90.956%
when pulling 3fe4c5c0769366dd358477fdae6ad4c8c1d11847 on proto
into 89c00ed1d19d7102de418faee64c0c70bb27af0c on main.

Let me see if I understand the high level picture:

protocols is the Objective-C terminology for what is an interface in Dart or Java. (With the exception that Objective-C protocols can also have static methods which have dynamic dispatch. https://github.com/dart-lang/native/issues/1149)
The NSProxy uses some kind of reflection to dispatch arbitrary method invocations on it. This is similar to the way we use proxies in JNIgen. cc @HosseinYousefi
When a DartProxy is passed to objective C, it holds on to blocks created from Dart methods. Once the DartProxy object reaches refcount 0 in objective C, it is GCed, as such the blocks are refcount decremented, and if the blocks ref count gets 0, they are deleted, which then informs Dart that the closure is no longer referenced (already implemented).

We should be weary of cycles, similar to with JNIgen. If your Dart closure captures a Dart object that holds on to an objective C object that holds on to the Dart proxy that holds on to that closure.

I think it might be useful to add the code gen to this PR (or stack a PR on top of this), and look at some example code users would write with the code-genned code to ensure we don't accidentally create extra cyclic references.


I get an ERROR TypeError: Cannot read property 'forEach' of null...

I'm submitting a ...  (check one with "x")
[ x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ x] support request

Current behavior

Not too sure how the bug (2 errors - keep reading) manifests.  But it has something to do when assigning the fields in the formly-form...
<form [formGroup]="universalForm" (ngSubmit)="submit()">
  <formly-form [model]="model" [fields]="allFields$ | async" [options]="options" [form]="universalForm"></formly-form>
  <button type="submit" class="btn btn-primary submit-button" [disabled]="!universalForm.valid">Submit</button>
  <button type="button" class="btn btn-default" (click)="options.resetModel()">Reset</button>
</form>

...asynchronously in the html file; something to do with loading the form.  All is good until I do a forkjoin operation. ex.
console.log('no error here');
this.allFields$ = forkJoin(obs1, obs2)
      .pipe(
        map(([first, second]) => {
          console.log({first});
          console.log({second});
          const fieldList = first.concat(second);
          console.log(fieldList); // is now a proper formlyFieldConfig[]
          return fieldList;
        })
      );

I have console.logged and there is no error until the allFields$.forkJoin assignment. After I console.log('no error here') I get the error in the console:

ERROR TypeError: Cannot read property 'forEach' of null
at<EMAIL_ADDRESS>(ngx-formly-core.js:625)

I did try to put it in afterViewInit, but still same issue. Also, I saw that only undefined is being inspected, but not null:
FormlyFormExpression.prototype._checkFields = /**
     * @param {?} form
     * @param {?=} fields
     * @param {?=} model
     * @param {?=} options
     * @return {?}
     */
    function (form, fields, model, options) {
        var _this = this;
        if (fields === void 0) { fields = []; } /****line 625****/
        fields.forEach(function (field) {
            _this.checkFieldExpressionChange(form, field, _this.getParentModel(model, field), options);
            _this.checkFieldVisibilityChange(form, field, _this.getParentModel(model, field), options);
            if (field.fieldGroup && field.fieldGroup.length > 0) {
                _this._checkFields(field.formControl ? /** @type {?} */ (field.formControl) : form, field.fieldGroup, _this.getParentModel(model, field), options);
            }
        });
    };

Maybe do a if (fields == null) or a combination of (fields === void 0 || fields === null) might help?
I fiddled a bit more and it seems to be an asynchronous issue.  If I have
fields = [];
and I have [fields]=fields, no errors nor any form fields(as expected).
In the end, I do get the results that I want oddly enough.  I just want to avoid any errors in the console.

Expected behavior

Everything the same but without the errors. (see above image for the errors)
What is the motivation / use case for changing the behavior?

I get fields configurations from more than 1 source(s)
Please tell us about your environment:

Angular version: 7.2.0
**Formly version: ** "@ngx-formly/core": "^4.8.2",

Thanks again for the quick response.  But I hate to say it, it is now definitely a asynchronous issue.  I reinstalled formly.
When I do [fields]="allFields$ | async" in the formly-form element, I still get an error.  Depending on when I get the values from my datasources (I think), I get errors that have to do with for-each of undefined.
At the moment, my workaround, is to subscribe directly in the components .ts file as opposed to the components html file.  ex.
 ...<formly-form [model]="model" [fields]="allFields" [options]="options" [form]="universalForm"></formly-form>...
and
    this.allFields$ = forkJoin(obs1, obs2)
      .pipe(
        map(([first, second]) => {
          console.log({first});
          console.log({second});
          const fieldList = first.concat(second);
          console.log(fieldList);
          return fieldList;
        })
      );
    this.allFieldsSubs$ = this.allFields$.subscribe((fields: FormlyFieldConfig[]) => {
      this.allFields = fields; // fix to remove errors from formly (has trouble with  (observable|async) ops)
    });

I have it working without errors for now.  This is just an informational heads up and for anyone else whom has similar issues.  Keep up the good work!

fixed in 5.0.4, you can pass null or undefined to fields.


Memory Leak After Reimporting Assets

Build:      Unity Editor v 5.6.0a5 (64-bit)
Platform: Windows 10 (64-bit)
Project:   ScriptableRenderLoop
Clicking 'Reimport' on an asset folder causes the memory consumption of the "Unity Editor" process to go up.
Depending on the size of the folder, it could be several hundred MB at a time.
This memory is never released, so if you perform this action multiple times, then the Editor eventually runs out of memory and crashes.
Tested scenes (reimport the entire "Assets\ScriptableRenderLoop" folder):

FPTL.unity
GlobalIlluminationTest.unity
HDRenderLoopTest.unity
LayeredLitTest.unity

Fixed.


groupby substring doesn't work on SQL Server

The following DQL SELECT SUBSTRING(t.field,1,6) as subField from table GROUP BY subField
translates to SQL as SELECT SUBSTRING(t0_.Field,1,6) as sclr_0 from table GROUP BY sclr_0
but SQL Server does not accept grouping by an alias (ref)
It would probably work on MySQL for example (ref)
Repeating the DQL with GROUP BY SUBSTRING(t.field, 1, 6) yields a doctrine semantical error
To bypass this, I'm getting the SQL query without the groupby operation, then just appending it
    $sql = $qb2->getQuery()->getSql();
    $sql .= " group by SUBSTRING(t0_.Field, 1, 6)";

    $connection = $bf->getConnection()->prepare($sql);
    // call any "$connection->bindParam" calls here
    $connection->execute();
    return $connection->fetchAll(\PDO::FETCH_ASSOC);

It would be nice if it were supported.

Given that SQL Server is the only platform that regularly screws up SQL semantics, I think this won't be fixed on our side, as it increases complexity massively just for one quite exotic vendor :-\

Lol! No problem :+1:


C++20: More compliance fixes in fmtlib use.

Risk Level: Low
Testing: Unit Tests
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A
Signed-off-by: Yan Avlasov<EMAIL_ADDRESS>

We currently are not building in C++20 conformance mode, I think. This was flagged internally during transition of internal toolset to C++20 conformance.


Fix email adapter config mappings

Issue/Task Number: 528
closes #528
Overview
This PR fixes a wrongly named mapping for the email local adapter setting.

Closing this as it's being fixed in #527


Pull in semver 1.0.3 'x' fix

As requested in https://github.com/rust-lang/rust/pull/85983#issuecomment-854682640 -- a Cargo.toml update to ensure Cargo-the-library users always get https://github.com/dtolnay/semver/pull/247. Fixes https://github.com/rust-lang/cargo/issues/9543.

r? @Eh2406
(rust-highfive has picked a reviewer for you, use r? to override)

@bors: r+
Thanks again for the quick fix!

:pushpin: Commit f5c2645899c6564149ca4325a07202260123e24d has been approved by alexcrichton

:hourglass: Testing commit f5c2645899c6564149ca4325a07202260123e24d with merge 71c1760bae6f4d3166cd8819fb0842802d207a20...

:sunny: Test successful - checks-actions
Approved by: alexcrichton
Pushing 71c1760bae6f4d3166cd8819fb0842802d207a20 to master...


Widgets inconsistently respect the parameters of most immediate MediaQuery above in the tree.

I am constructing and adding my own MediaQuery into the widget tree.

I am changing parameters on my new MediaQuery in relation to the MediaQuery above me in the widget tree.

The values I am changing are textScaleFactor along with size in conjunction with devicePixelRatio.

When I change the textScaleFactor, text widgets below the new MediaQuery change their text size accordingly.

When I change size + devicePixelRatio, the scaffold and elevated button do not respect this change, and do not draw scaled.

The expected behaviour is the Widgets would consistently respect the parameters of the nearest MediaQuery. If I can modify textScaleFactor why can I not modify display size via size+devicePixelRatio, or vice versa?
Observe the following minimal example and specifically refer to the commented variables....
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      builder: (context, child) {
        var mediaQuery = MediaQuery.of(context);

        var newTextScaleFactor = 1.0; // varying this has effect
        var newDevicePixelRatio = 4.0; // varying this has no effect

        var physicalPixelWidth = mediaQuery.size.width * mediaQuery.devicePixelRatio;
        var physicalPixelHeight = mediaQuery.size.height * mediaQuery.devicePixelRatio;
        var newSize = Size(physicalPixelWidth / newDevicePixelRatio, physicalPixelHeight / newDevicePixelRatio);
        return MediaQuery(
          data: MediaQuery.of(context).copyWith(textScaleFactor: newTextScaleFactor, devicePixelRatio: newDevicePixelRatio, size: newSize),
          child: Navigator(
            onGenerateInitialRoutes: (state, routeName) => [
              MaterialPageRoute(
                builder: (_) {
                  return Overlay(initialEntries: [OverlayEntry(builder: (context) => const MyHomePage())]);
                },
              )
            ],
          ),
        );
      },
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key}) : super(key: key);
  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text("Test App"),
      ),
      body: Center(
        child: ElevatedButton(
          onPressed: () {},
          child:  const Text("Test Text"),
        ),
      ),
    );
  }
}

@Scott-Tenera
Upon running your code sample on latest stable (2.8.1), varying newTextScaleFactor and newDevicePixelRatio (e.g 0.5 and 2.0), the mediaQuery does make the effect and changes on screen are reflected:

If this isn't the expected behavior, then can you elaborate on expected vs actual result ?
Also provide your flutter doctor -v and the use case you are trying to achieve.

@darshankawar . I would just like to confirm that mofifying newDevicePixelRatio without modifying newTextScaleFactor does result in a UI change. Does you scaffold appbar get larger? This is not what I am observing, so maybe there is a bug here that is only symptomizing in my environment.
As mentioned in the initial post, I expected the moodifying newDevicePixelRation (and by extension newSize) to result is a display scale change. Like you mentioned, this is what you are seeing, but not what I am seeing with the same code.
Did you test on an emulator?
I am specifically running on a emulator with the following config.ini using system image..
system-images;android-28;google_apis_playstore;x86_64
PlayStore.enabled=false
abi.type=x86_64
avd.ini.encoding=UTF-8
disk.dataPartition.size=6442450944
hw.accelerometer=yes
hw.audioInput=yes
hw.battery=yes
hw.cpu.arch=x86_64
hw.dPad=no
hw.device.hash2=MD5:869d76256fcdae165862720ddb8343f9
hw.device.manufacturer=Google
hw.device.name=Nexus 6P
hw.gps=yes
hw.lcd.density=480
hw.lcd.height=2560
hw.lcd.width=1440
hw.mainKeys=no
hw.sdCard=yes
hw.sensors.orientation=yes
hw.sensors.proximity=yes
hw.trackBall=no
image.sysdir.1=system-images/android-28/google_apis_playstore/x86_64/
tag.display=Google Play
tag.id=google_apis_playstore

flutter doctor - v
[✓] Flutter (Channel stable, 2.8.1, on Ubuntu 20.04.3 LTS 5.11.0-46-generic, locale en_CA.UTF-8)
    • Flutter version 2.8.1 at /home/tenera/snap/flutter/common/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 77d935af4d (4 weeks ago), 2021-12-16 08:37:33 -0800
    • Engine revision 890a5fca2e
    • Dart version 2.15.1

[!] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /usr/local/android-sdk
    • Platform android-31, build-tools 30.0.3
    • ANDROID_HOME = /usr/local/android-sdk
    • Java binary at: /usr/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.13+8-Ubuntu-0ubuntu1.20.04)
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/linux#android-setup for more details.

[✓] Chrome - develop for the web
    • Chrome at google-chrome

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/linux#android-setup for detailed instructions).

[✓] VS Code (version 1.63.2)
    • VS Code at /usr/share/code
    • Flutter extension version 3.32.0

[✓] Connected device (2 available)
    • Android SDK built for x86 64 (mobile) • emulator-5554 • android-x64    • Android 9 (API 28) (emulator)
    • Chrome (web)                          • chrome        • web-javascript • Google Chrome 97.0.4692.71

! Doctor found issues in 2 categories.

I just tested on a physical android device running Android 8.0, and changing newDevicePixelRatio had no effect.
@darshankawar Are you SURE you actually observed changes to newDevicePixelRatio having an effect, or was it just newTextScaleFactor.

I would just like to confirm that when you modify newDevicePixelRatio without modifying newTextScaleFactor does result in a UI change. Correct?

I initialy updated both newDevicePixelRatio and newTextScaleFactor and saw the change. I later tried to just change newDevicePixelRatio which didn't change anything on screen, indicating it doesn't have any effect, that led me to this open issue which sounds similar to your case, https://github.com/flutter/flutter/issues/32115. Check that and underlying comments and see if it helps.


Doesn't compile on Kali

Hey domas, take a look at it:
t@kali:~/Desktop/Tools/sandsifter# make
cc  -c injector.c -o injector.o -Wall
injector.c:321:93: warning: excess elements in array initializer
.start={.bytes={0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}, .len=0},
^~~~
injector.c:321:93: note: (near initialization for ‘total_range.start.bytes’)
injector.c:322:91: warning: excess elements in array initializer
.end={.bytes={0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff}, .len=0},
^~~~
injector.c:322:91: note: (near initialization for ‘total_range.end.bytes’)
injector.c: In function ‘inject’:
injector.c:817:2: warning: asm operand 7 probably doesn’t match constraints
asm volatile ("
^~~~~~~
injector.c:817:2: error: impossible constraint in ‘asm’
Makefile:38: recipe for target 'injector.o' failed
make: *** [injector.o] Error 1

This happens only when building with -fPIC, right? On Debian Sid/unstable, just running make I get the error below.
$ make
cc  -c injector.c -o injector.o -Wall
[…]
cc  injector.o -O3 -Wall -l:libcapstone.a -o injector -pthread
/usr/bin/ld: injector.o: relocation R_X86_64_32S against undefined symbol `dummy_stack' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Makefile:35: recipe for target 'injector' failed
make: *** [injector] Error 1

Then building with -fPIC, your error can be reproduced.
$ make CFLAGS="-fPIC"
cc -fPIC -c injector.c -o injector.o -Wall
[…]
injector.c: In function ‘inject’:
injector.c:778:2: warning: asm operand 15 probably doesn’t match constraints
  __asm__ __volatile__ ("\
  ^~~~~~~
injector.c:778:2: error: impossible constraint in ‘asm’
Makefile:38: recipe for target 'injector.o' failed
make: *** [injector.o] Error 1

I reproduce exactly paulmenzel's result on Debian stretch with the following environment:
# cc --version
cc (Debian 6.3.0-18) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# apt-cache policy python3-capstone libcapstone3 libcapstone-dev python-capstone
python3-capstone:
  Installé : 3.0.4-1
  Candidat : 3.0.4-1
 Table de version :
 *** 3.0.4-1 500
        500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status
libcapstone3:
  Installé : 3.0.4-1
  Candidat : 3.0.4-1
 Table de version :
 *** 3.0.4-1 500
        500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status
libcapstone-dev:
  Installé : 3.0.4-1
  Candidat : 3.0.4-1
 Table de version :
 *** 3.0.4-1 500
        500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status
python-capstone:
  Installé : 3.0.4-1
  Candidat : 3.0.4-1
 Table de version :
 *** 3.0.4-1 500
        500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status

I compiled capstone master from scratch, worked on mint 18

@f4grx have a look at #2 -- Try adding -no-pie to the linker step, it resolves the exact same issue I had on Arch.

Yes, doing the change below fixes the problem.
-       $(CC) $(CFLAGS) $< -O3 -Wall -l:libcapstone.a -o $@ -pthread
+       $(CC) $(CFLAGS) $< -O3 -Wall -no-pie -l:libcapstone.a -o $@ -pthread

I can get it to compile by changing the following:
+ [esp]"p"(&dummy_stack.dummy_stack_lo),
-  [esp]"i"(&dummy_stack.dummy_stack_lo),

But I'm not entirely sure if the p constraint is correct. The binary tends to only run through 1 iteration after compilation. I'm thinking that the issue has to do with the fact that since I'm running this on an x86 system, and the dummy_stack struct members are both 64 bits, it's trying to read in a 64 bit value into a memory operand, which is probably no bueno.
Could prob just patch to add a macro based on system architecture for this structure.


search: Hide typeahead on page load to avoid half-rendered state.

This fixes an issue where the typeahead container was being rendered without anything in it:

The issue is that the search typeahead container isn't hidden on page load. We hide it when the search bar gets closed, but if the page is loaded with the search bar expanded then it's still visible even though there's nothing rendered in the typeahead container.

@amanagr perhaps you can review and make a recommendation?

Oh! This looks like a bug with how the Typeahead is initialized.
const CONTAINER_HTML = '

'; should actually be
const CONTAINER_HTML = '

'; so that we are not showing empty content by default.
@evykassirer you should also verify other typaheads after making this change.

It looks like we only want to do that when it's not a tippy element, because those are the elements we have in the DOM always and show() and hide() when relevant.
I pushed a new commit that does it that way -- @amanagr what do you think?

Yes, we only want to hide the container for non-tippy instances right now but that might change in the future. Also, having a hide call in the constructor can lead to confusing behaviour down the road due to the way state of the typeahead might be set in the hide call. So, we should have the constructor start with
const CONTAINER_HTML = '

'; and let the typeahead decide if they want to be shown or not.

How are you thinking of having the typeahead decide if they want to be shown or not?
Currently the tippy instances use CONTAINER_HTML only through this.$container which is only used here: content: this.$container[0]!.
One option is to move this.$container.show(); to always be called in show() instead of only when this.non_tippy_parent_element is true, which feels more intuitive to me? But I can also add .$container.show(); to the end of all non-search new Typeahead` calls. Which sounds better to you @amanagr ?

One option is to move this.$container.show(); to always be called in show() instead of only when this.non_tippy_parent_element is true

Yeah, that seems right.

Looks good to me. Tested for various typeaheads and search bar.

Merged, thanks @evykassirer and @amanagr!


[Feature Request]: ADD NUMBER IN RATINGS..

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
ADD NUMBER IN RATINGS.. WITH STARTS LIKE FOLLOWING IMAGE..
Use Case
NUMBERS ARE MORE EFFECTIVE THAN STARTS..
Benefits
NUMBERS ARE MORE EFFECTIVE THAN STARTS..
Add ScreenShots

Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

/assign

@Soujanya2004 we display this inevery listing in homepage..

@Meetpidev

@Soujanya2004 will send PR in FEW minutes


-split With \G Stops After First Split

Steps to reproduce
"ABCDEFGH" -split '(?<=\G..)(?=..)'

Expected behavior
In PS 7.0.3 and earlier, this is the output:
AB
CD
EF
GH

Actual behavior
In PS 7.1.0, this is the output:
AB
CDEFGH

Workaround
This works in PS 7.1.0:
[regex]::Matches("ABCDEFGH", "..") | % Value

Environment data
Name                           Value
----                           -----
PSVersion                      7.1.0
PSEdition                      Core
GitCommitId                    7.1.0
OS                             Microsoft Windows 10.0.19042
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Removing \G from the pattern restores multiple splits, which suggests that the \G anchor indeed is the source of the unexpected behaviour.
"ABCDEFGH" -split '(?<=..)(?=..)'
#                      ^
#                    No \G

NOTE: Below is not the desired output; it is shown here only to illustrate the behaviour without \G.
AB
C
D
E
F
GH

@sharpjs Thanks for your report!
This broke in PowerShell 7.1 Preview1 after we moved to .Net 5.0. PowerShell uses .Net Regex so it is .Net issue.
I see you have an experience in .Net - please create a simple C# demo, open new issue in .Net Runtime repository and reference the issue for tracking.

Just to offer a pragmatic workaround in the meantime: "ABCDEFGH" -split '(..)' -ne ''

Fixes in .NET runtime repo:
6.0.0: https://github.com/dotnet/runtime/pull/44975 (merged)
5.0.x: https://github.com/dotnet/runtime/pull/44985 (WIP as of this writing)

@sharpjs Thanks!

The fix is not documented to be in .NET 5.0.1 as of this writing, but my repro test went from red to green with the installation of .NET 5.0.1.  So, looks like upstream is fixed.


[pre-sve] write on active-calendar-type attribute of Time Format Localization cluster fails

Problem
In testcase TFL-2.2 step 8

expected behavior

TH writes 0 to ActiveCalendarType attribute and write request is successful with status code 0x00

actual behavior

write fails with General error: 0x87 (CONSTRAINT_ERROR)

system configuration
-  DUT used : ESP32
-  app use: all-clusters-app
- chip-tool and DUT commit id : 425f1fb916ca154deeb75cd82cd5196778aba152 (pre-sve SHA)

logs
-  esp32: esp32.txt
- chip-tool: th.txt

I believe this was fixed by https://github.com/project-chip/connectedhomeip/pull/18236, which post-dates the pre-sve SHA by a day or so. @PSONALl are you in a position to verify that on tip?

I believe this was fixed by #18236, which post-dates the pre-sve SHA by a day or so. @PSONALl are you in a position to verify that on tip?

@bzbarsky-apple yes this issue is fixed now, so closing this issue


bug(portal): Unable to edit only admin actor in account

If an account has only 1 admin, an attempt to edit any field on the actor will result in a warning of:
You may not demote the last admin.

Fixed by #4347


User Dashboard

Store the User details in LocalStorage ,while he/she SignUp so that the SignOut is shown inplace of SignIn.
In Dashboard , the User Details of the Current User in Localstorage Must be Used.  Means ,if the User gives his/her details as A DONOR ,Only then the dashboard will be shown to him/her. (i.e the informations filled by him in the DONAR FORM.)

I Have Done The Above Idea, IF you Like the Idea ,I can do a Pull Request.

No reply


📝Translate README to Russian

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

Thanks for taking the time to contribute this localization pull request. However, we are not able to accept contributions to this historical reference repository at this time.


Lightbox function not working correctly in Android browser

I noticed on my Android 4.0.4 tablet that the "lightbox function" (where you view the images in large and navigate back & forth) is not working correctly in the Android stock browser. The image is displayed, but if you try to navigate instead you scroll the album behind that picture. It's a strange behaviour.
However, if you use a current chrome for Android app, it works.

Closing the issue because it's outdated and maybe fixed.


Should string number be converted to number when eval?

When evaling number string, we automatically convert it to real number.
But sometimes, we need it to be number string. For example, in chakra radio, chakra will change number to string number.
Is it nessesary to keep this logic?

Maybe we can add some test cases in this issue to describe the desired behavior?
For example:
1 -> Number: 1
'1' -> String '1'
{{ 1 }} -> Number: 1
{{ '1' }} -> String '1'
cc @chenenpei

The 4 cases mentioned above are desired, while the second one does not work as expected so far.
Since we are passing an object to the renderApp function, values' types in this object are self-evident. It might not necessary to cast a numeric string to a number.
The behaviour of chakra-ui radio can be found in this issue:
https://github.com/chakra-ui/chakra-ui/issues/2931#issuecomment-761758604

There is another factor to be consider. When user change property in form, do we have to convert the value of input to number or boolean?


Fixed #24777 -- Added support for statement_timeout in the database backends.

Closing per ticket.

Since the PR is not accepted, do you have any idea to address the  issue stated in this ticket. https://code.djangoproject.com/ticket/24777.

There is also connection_created signal which should allow running arbitrary SQL for new connections. So, I don't think there is need for this feature.

How do connection_created aware the  query statement it is going to execute? Since we want the timeout is query statement based.

@yhuanghamu this PR was never about adding a queryset/connection level API to set the timeout in a query aware way. It was solely about adding a DATABASES setting to set the timeout on connection creation which can effectively be emulated by using a connection_created signal receiver.

@charettes Thanks for pointing it out, my question is kind of different.
Since the expected running time of queries varies, it make sense to set different timeout based on the type of query to avoid long running query.
However i think the connection_created signal show a promising direction.

How do connection_created aware the query statement it is going to execute? Since we want the timeout is query statement based.
But my concern is connection_created receiver has no knowledge on what kind of queries it is going to execute.  so i won't help to address my question.

A higher level question might be , how do we avoid some query consume too much resources. queryset level timeout might be one approach. Is there any better solution?

@yhuanghamu this is probably be directed at a support channel instead but what I've done in the past is limit query durations based on the role the process is running. For example, you might want to limit HTTP workers to 1 second queries but allow longer queries on your background workers.


#51 README update + labels

See #51

They did have a light background to try and save a little space, but I was able to just turn it transparent and so it'll work on either theme now. Also added the docs link 😉


Sync DM-Player Issues

Hi everyone, from one day to the next, and without me having made any changes to the PC, the program no longer updates the movements made by the DM or the Players. Example: If I move a pawn from the DM session the players don't see it move, and vice versa if the players move from the DM session I don't see any change. In the image there is the only error i find.

This is likely related to #1545. The current workaround is to delete C:\Users\macma\AppData\Local\Temp\caxa\applications\dungeon-revealer-windows and rerun Dungeon Revealer.


Update check_config for MEMCG_KMEM

- What I did
- How I did it
- How to verify it
- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)
CONFIG_MEMCG_KMEM is removed since 4.6, it's accounted by default
since 4.6, so it's merged to CONFIG_MEMCG.
Signed-off-by: Qiang Huang<EMAIL_ADDRESS>

LGTM

LGTM


AMBARI-26090: Add Livy as Individual Service to Ambari Bigtop Stack

What changes were proposed in this pull request?
Adding Apache Livy as its own service in Ambari. Apache Livy is a service supported by Bigtop, but has not had support in Ambari. This PR adds this support.
See BIGTOP-4149 which adds support for Livy to bigtop-select as well as additional build arguments so that the Livy RPMs have proper naming and directory structure.
How was this patch tested?
Manual tests, install service, startup service, test functionality of Livy via CLI against livy server.

(Please explain how this patch was tested. Ex: unit tests, manual tests)
(If this patch involves UI changes, please attach a screen-shot; otherwise, remove this)
Please review Ambari Contributing Guide before opening a pull request.

@paulyakovlev and @carmenblaine3 are the developers who worked on this change; I just opened the PR on their behalf due to GM repository / PR management policies, if any folks have questions about these changes :)

LGTM +1  @virajjasani any suggestion on your side?

I might need some time to learn about Livy. You are good to proceed with merging in sometime @JiaLiangC

@virajjasani  Currently in the process of creating an Apache account and related procedures. It will take some time until the PMC grants me write access to the project. After that, I will merge the changes

Thank you Jia for all your effort in the project these last few months

Thank you for your kind words. Your support and recognition mean a lot to me.

@paulyakovlev and @carmenblaine3 @Danori Thank you for your valuable contribution!


[KYUUBI #5104][TEST] BatchesResourceSuite - expose the metrics with operation type and current state

:mag: Description
Issue References 🔗
This pull request fixes #5104
Describe Your Solution 🔧
Make sure that the batch is already running before deleting it.
Types of changes :bookmark:

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

Test Plan 🧪
Behavior Without This Pull Request :coffin:
GA sometimes fails
Behavior With This Pull Request :tada:
GA success
Related Unit Tests
BatchesV2ResourceSuite
expose the metrics with operation type and current state

Checklist 📝

[x] This patch was not authored or co-authored using Generative Tooling

Be nice. Be informative.

Thanks, merged to master/1.8


How to export?

I needed to know how to write the serving function to export the trained xlnet model.
I have this right now:
def serving_input_fn():
with tf.variable_scope("model"):
feature_spec = {
"input_ids": tf.FixedLenFeature([MAX_SEQ_LENGTH], tf.int64),
"input_mask": tf.FixedLenFeature([MAX_SEQ_LENGTH], tf.int64),
"segment_ids": tf.FixedLenFeature([MAX_SEQ_LENGTH], tf.int64),
"label_ids": tf.FixedLenFeature([], tf.int64),
}
serialized_tf_example = tf.placeholder(dtype=tf.string,
shape=[None],
name='input_example_tensor')
receiver_tensors = {'examples': serialized_tf_example}
features = tf.parse_example(serialized_tf_example, feature_spec)
return tf.estimator.export.ServingInputReceiver(features, receiver_tensors)
EXPORT_DIR = 'gs://{}/export/{}'.format(BUCKET, TASK_VERSION)
estimator._export_to_tpu = False # this is important
path = estimator.export_savedmodel(EXPORT_DIR, serving_input_fn)
This is throwing me errors.
Please note: this is the function that I used for Bert, and as I am no expert in tensorflow, I don't understand why it won't work.
It throws a type mismatch error

Hello @jinamshah , have you resolved this issue? If not, let me know and I can help debug.

Hey @lukemelas I was able to resolve this issue. I wrote my own function to help me do this.
Thanks!

Great!

I believe this issue can be closed.

I was also getting type mismatch errors while exporting model.
TypeError: Tensors in list passed to 'values' of 'ConcatV2' Op have types [int32, int64] that don't all match.
How did you resolve this issue?

@ashgorithm
			for name in list(features.keys()): 				t = features[name] 				if t.dtype == tf.int64: 					t = tf.cast(t, tf.int32) 				features[name] = t
I believe this would help you.
Basically, the input is required to be int32

@jinamshah would you be able to share your solution? I am having the same problem

@jinamshah would you be able to share your solution? I am having the same problem

+1, please!

@jinamshah would you be able to share your solution? I am having the same problem
+1 Please!!

Hey I solved it :) @jinamshah @AndrewPelton @hexiaoyupku
        with tf.variable_scope("foo"):
          feature_spec = {
              "unique_ids": tf.FixedLenFeature([], tf.int64),
              "input_ids": tf.FixedLenFeature([FLAGS.max_seq_length], tf.int64),
              "input_mask": tf.FixedLenFeature([FLAGS.max_seq_length], tf.float32),
              "segment_ids": tf.FixedLenFeature([FLAGS.max_seq_length], tf.int64),
              "cls_index": tf.FixedLenFeature([], tf.int64),
              "p_mask": tf.FixedLenFeature([FLAGS.max_seq_length], tf.float32)
          }

          serialized_tf_example = tf.placeholder(dtype=tf.string,
                                                 shape=[FLAGS.predict_batch_size], #[None],
                                                 name='input_example_tensor')

          receiver_tensors = {'examples': serialized_tf_example}
          features = tf.parse_example(serialized_tf_example, feature_spec)

          for name in list(features.keys()):
            t = features[name]
            if t.dtype == tf.int64:
                t = tf.cast(t, tf.int32)
                features[name] = t

          return tf.estimator.export.ServingInputReceiver(features, receiver_tensors)

  if FLAGS.do_export:
    estimator._export_to_tpu = False  # this is important
    print("Estimator save model..")
    estimator.export_savedmodel('export_t', serving_input_fn)```

Could someone please send me an example of http post request to this serving?
thanks!


Version 16.3 componentWillMount

Given the fact you will remove (not recommend) to use this method anymore, but just componentDidMount to do a data fetch, for example, how will server rendering will work in the future (cause componentDidMount is not called on the server)?

componentWillMount was not useful for one-pass server rendering anyway because it is synchronous so you can’t wait for the data. So if you already have it synchronously, you might as well read it in the constructor.
If you did two rendering passes (which is bad for performance but somewhat works around the issue) then you can keep using UNSAFE_componentWillMount in the short term. It‘s not safe for async rendering, but your code was already relying on a slow pattern (rendering twice) so it’s better to be explicit about it.
In the longer term, the plan is to introduce first-class support for data fetching in React via an API we’re calling “suspense”. As mentioned in the blog post, we recently shared a sneak peek into the future of React, and the second part of the talk directly addresses this.
Hope it helps!

Thank you very much for your quick answer!

hi @gaearon , why componentWillMount is not safe for async rendering. Will the async rendering trigger componentWillMount twice?

@monkindey : yes, that's exactly why.  React can pause and restart the process of rendering a component tree, in which case a component could start to get mounted several times.

Thank @markerikson , it makes sense to me.

@gaearon Using a constructor you have more boilerplate than if you were to use componentWillMount. For example, this issue I made helps explain the issue: https://github.com/facebook/react/issues/10972
Not sure if there would be another lifecycle event that would act as a constructor because right now constructor initialization is like a one off when it could be more reusable.

If it's boilerplate you're specifically concern about you can use the experimental (stage 3) class properties transform and write code like
class MyComponent extends React.Component {
  state = {
    color: this.props.initialColor
  };
  // ...
}

That’s what we do at FB.

@gaearon Perfect! Thanks!

I actually don't understand why two phase rendering is bad, when you load data:


Refactored sync and implemented parallel syncing.

Can you please review my comments in PLAT-2905 and confirm this change aligns with it accordingly.
Also, please confirm that by "parallel" it's only parallel when then userId/deviceId is different?  Multiple sync's should be run sequentially and not in parallel for a given userId/deviceId.

Yeah multiple sync's will be run only if deviceId not the same as currently running sync, but userId ignored.


Prefer TabBarTheme normalization migration guide

Steps to reproduce
Create a TabBarTheme instance with type declaration.
// Current TabBarTheme API in stable channel version: 3.24.5
final TabBarTheme tabTheme = Theme.of(context).tabBarTheme;

Expected results
Expect the current API usage to compile on beta/master channels OR expect the API to be documented as a totally breaking none compiling change in the coming breaking not-yet-released changes lists here: https://docs.flutter.dev/release/breaking-changes#not-yet-released-to-stable
Actual results
Using
// Current TabBar API in stable channel version: 3.24.5
final TabBarTheme tabTheme = Theme.of(context).tabBarTheme;

on beta channel version 3.27.0-0.2.pre or master 3.27.0-1.0.pre.763 the line does not compile.
There is no documentation (yet) about the coming breaking changes that causes this API to break in a manner that does not even compile.
Related PR https://github.com/flutter/flutter/pull/156253
To compile the line on beta channel version 3.27.0-0.2.pre or master 3.27.0-1.0.pre.763 you have to use:
// New TabBar API in latest beta channel version: 3.27.0-0.2.pre and
// master channel version: 3.27.0-1.0.pre.763
final TabBarThemeData tabTheme = Theme.of(context).tabBarTheme;

The change is a part of "normalizing" component theme efforts, but the none compiling breaking change needs to be documented before it is released, which is expected to happen soon. This is just a friendly reminder to document the breaking change! 😃
Code sample
Code sample
import 'package:flutter/material.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      debugShowCheckedModeBanner: false,
      home: HomePage(),
    );
  }
}

class HomePage extends StatelessWidget {
  const HomePage({super.key});
  @override
  Widget build(BuildContext context) {
    // Current TabBar API in stable channel version: 3.24.5
    final TabBarTheme tabTheme = Theme.of(context).tabBarTheme;
    // The above current API in stable is broken in beta and master,
    // meaning in coming next stable, it will not even compile!

    // New TabBarTheme API in latest beta channel version: 3.27.0-0.2.pre and
    // master channel version: 3.27.0-1.0.pre.763
    // final TabBarThemeData tabTheme = Theme.of(context).tabBarTheme;

    // Expect to find information about the TabBarThemeData class in the
    // Flutter documentation about coming none compiling breaking changes!
    // https://docs.flutter.dev/release/breaking-changes

    return Scaffold(
      appBar: AppBar(title: const Text('Home screen')),
      body: const Center(child: Text('Just some text')),
    );
  }
}

Flutter Doctor output
Doctor output
[✓] Flutter (Channel master, 3.27.0-1.0.pre.763, on macOS 15.1.1 24B91 darwin-arm64, locale en-US)
    • Flutter version 3.27.0-1.0.pre.763 on channel master at /Users/rydmike/fvm/versions/master
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 0104a81f55 (4 hours ago), 2024-12-10 00:31:10 -0500
    • Engine revision 0338d1c7d7
    • Dart version 3.7.0 (build 3.7.0-226.0.dev)
    • DevTools version 2.41.0

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/rydmike/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
      This is the JDK bundled with the latest Android Studio installation on this machine.
      To manually set the JDK path, use: `flutter config --jdk-dir="path/to/jdk"`.
    • Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 16.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 16B40
    • CocoaPods version 1.16.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)

[✓] IntelliJ IDEA Community Edition (version 2024.2.5)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin version 83.0.3
    • Dart plugin version 242.24931

[✓] VS Code (version 1.95.3)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.102.0

[✓] Connected device (4 available)
    • Pixel 7 Pro (mobile)            • 28131FDH300NJG        • android-arm64  • Android 15 (API 35)
    • macOS (desktop)                 • macos                 • darwin-arm64   • macOS 15.1.1 24B91 darwin-arm64
    • Mac Designed for iPad (desktop) • mac-designed-for-ipad • darwin         • macOS 15.1.1 24B91 darwin-arm64
    • Chrome (web)                    • chrome                • web-javascript • Google Chrome 131.0.6778.109
    ! Error: Browsing on the local area network for iPhone. Ensure the device is unlocked and attached with a cable or associated with the same local area
      network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code -27)
    ! Error: Browsing on the local area network for hype’s iPhone. Ensure the device is unlocked and attached with a cable or associated with the same local
      area network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code -27)
    ! Error: Browsing on the local area network for MrPinkPro. Ensure the device is unlocked and attached with a cable or associated with the same local area
      network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code -27)

[✓] Network resources
    • All expected network resources are available.

Reproducible using the steps outlined above.
cc @QuncCccccc

flutter doctor -v
[✓] Flutter (Channel stable, 3.24.5, on macOS 15.1.1 24B91 darwin-arm64, locale en-US)
    • Flutter version 3.24.5 on channel stable at /Users/deanli/dev/stable
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision dec2ee5c1f (4 weeks ago), 2024-11-13 11:13:06 -0800
    • Engine revision a18df97ca5
    • Dart version 3.5.4
    • DevTools version 2.37.3

[!] Flutter (Channel beta, 3.27.0-0.2.pre, on macOS 15.1.1 24B91 darwin-arm64, locale en-US)
    • Flutter version 3.27.0-0.2.pre on channel beta at /Users/deanli/dev/beta
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision fc011960a2 (4 weeks ago), 2024-11-14 12:19:18 -0800
    • Engine revision 397deba30f
    • Dart version 3.6.0 (build 3.6.0-334.4.beta)
    • DevTools version 2.40.1

[!] Flutter (Channel master, 3.27.0-1.0.pre.763, on macOS 15.1.1 24B91 darwin-arm64, locale en-US)
    • Flutter version 3.27.0-1.0.pre.763 on channel master at /Users/deanli/dev/master
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 0104a81f55 (5 hours ago), 2024-12-10 00:31:10 -0500
    • Engine revision 0338d1c7d7
    • Dart version 3.7.0 (build 3.7.0-226.0.dev)
    • DevTools version 2.41.0

This undocumented none-compiling breaking change is now live. As expected it broke the build after upgrading to 3.27.0. It is still also not mentioned in the released breaking changes.
https://docs.flutter.dev/release/breaking-changes#released-in-flutter-3-27 Update coming soon I guess 😉

undocumented none-compiling breaking change

This is not the case @rydmike please review our breaking change policy. https://github.com/flutter/flutter/blob/master/docs/contributing/Tree-hygiene.md#handling-breaking-changes
This change was found to be non breaking, and is part of ongoing work to normalize material themes.
Updating TabBarTheme typing to TabBarThemeData is also not a difficult migration.
As always, you are welcome to submit tests to the flutter/tests directory for us to run changes against.

If a past existing Flutter API does not even compile after upgrading, it is pretty hard broken, regardless of what the policy definition of a breaking change says.
Sure it is an easy fix, and yes it is part of the normalization, I'm well aware, but it still breaks the build. Thus API is hard broken 🤷🏻♂ 😃

Updating TabBarTheme typing to TabBarThemeData is also not a difficult migration.

This is not necessarily true.
If a dependency of my app uses TabBarTheme, I cannot upgrade my Flutter SDK until its author publishes a fix. Upgrading to that dependency's new version might require me to address other breaking changes from that dependency. These problems are compounded if I don't upgrade my dependencies frequently, or if a package is unmaintained.
We should assume any breaking change - regardless how minor - can cause significant friction to our customers.

We understand the current policy is not satisfying to all users’ expectations.
We’ve actually been working on drafting new policies for breaking changes, deprecations and flutter/tests over the last few months.
Until those updates roll out though, I am not going to fault any contributor for following our policies as they are currently documented and enforced.
As for this particular issue, it was in fact documented in the release blog, please see the section on “Normalizing Material Theming”. OP also consulted on the issue. I can’t help but wonder why DialogTheme and CardTheme, which were also changed in the same way, have not been subjected to the same level of scrutiny.
Regardless, we have created a migration guide for this change in https://github.com/flutter/website/pull/11489, which should soon be available on the breaking change section of the website. Please see that guide for help in updating your code.
PS - I did not write our current policy on breaking changes, I’d ask that folks not attack the messenger here and refer to our code of conduct. Thnx!

Expected results
Expect the current API usage to compile on beta/master channels OR expect the API to be documented as a totally breaking none compiling change in the coming breaking not-yet-released changes lists here: https://docs.flutter.dev/release/breaking-changes#not-yet-released-to-stable

Closing as resolved by https://github.com/flutter/website/pull/11489.


Ruby header files missing?

Describe the bug
Currently using ubuntu 20.04 64-bit, for some reason, when using fullstaq ruby (tried v 2.6 and 2.7), I am unable to compile racc when bundling my application.
I've installed build-essential and ruby-dev packages on the machine.
Similarly, trying to do a
gem install bcrypt
fails as well.
The install/bundle works fine when using the system ruby (ruby2.7) that comes with Ubuntu.
Not sure what would be the cause of this failure.
Is fullstaq-ruby unable to find the Ruby header files?

When using Fullstaq Ruby, you don't need ruby-dev, because ruby-dev belongs to the distribution-managed Ruby version. The Fullstaq Ruby packages already contain headers.
Installing bcrypt indeed fails for me as well. But it's not because of missing Ruby headers, but because it tries to look for 'mkdir' in the wrong directory:
make: /usr/bin/mkdir: Command not found

This in turn happens because when Ruby was compiled, it somehow detected that mkdir was in /usr/bin (instead of /bin):
>> require 'rbconfig'
>> pp RbConfig::CONFIG['MAKEDIRS']
"/usr/bin/mkdir -p"

And that in turn happens because the Fullstaq Ruby packages for Ubuntu 20.04 were built inside a Docker container. In the Docker image for Ubuntu 20.04, mkdir is in both /usr/bin and /bin:
$ docker run -ti --rm ubuntu:20.04 ls /usr/bin/mkdir
/usr/bin/mkdir
$ docker run -ti --rm ubuntu:20.04 ls /bin/mkdir
/bin/mkdir

Yet on an Ubuntu 20.04 VM, it is not:
$ ls /usr/bin/mkdir
ls: cannot access '/usr/bin/mkdir': No such file or directory
$ ls /bin/mkdir
/bin/mkdir

🤔

Upon further investigation, it seems that the rogue /usr/bin/mkdir only appears in the Ubuntu 20.04 Docker image. It doesn't appear in the Ubuntu 18.04 image, nor in the Debian 10 image.
I'll have it removed from our build images, which should fix this problem.

If it's of any help, I'm running into this issue on a Ubuntu 20.04 VPS that is using OpenVZ.

Fixed. Updates will be published when the CI finishes.

It seems my initial analysis of this problem was wrong, and the fix never worked in the first place. See #101 for a follow-up.


Update Azure Coreos To Kubernetes 0.15.0

update azure coreos to kuberenetes 0.15.0 and etcd 2.0.9
add affinity group variable to azure coreos scripts

Thanks for squashing! Will merge on green.

Can  you update docs/getting-started-guide/README.md to show that Azure is using 0.15?  Thanks.

@idosh thanks very much!


Force encoding in dmtx

Since swapping to dmtx, Barby::DataMatrix.new now autodetects the encoding to use and cannot be overridden.  Semacode did not do numeric encoding so this wasn't a problem, but we have mail inserter equipment, 100s of $thousands, that cannot read numeric encoding datamatrix.
I will fork and do a PR unless someone beats me to it, but we need to be able to tell dmtx to use ascii encoding even if the data is numeric, through barby.

That actually isn't the problem, both are using ascii encoding. The more I dig into this the weirder it gets. Semacode used someone else's encoder function which had a one-off bug, and rather than fix it the semacode author just appended a space to the data, artificially increasing the symbol size.  It also uses a lookup table to determine symbol size rather than calculate it efficiently the way dmtx does.
What I actually need is a way to force dmtx to artificially use a less efficient symbol size than is required for the data.  The inserters will read 18x18 but they will not read 14x14.  I don't know why, I didn't build them and I can't force them to support 14x14.  So I may have to do a PR on both barby and dmtx.


fix(auth): FR-1561 - changed back button for MFA recovery page

https://frontegg.atlassian.net/secure/RapidBoard.jspa?rapidView=3&modal=detail&selectedIssue=FR-1561&assignee=5da57de11094ed0c44fe7825

https://frontegg.atlassian.net/secure/RapidBoard.jspa?rapidView=3&modal=detail&selectedIssue=FR-1561&assignee=5da57de11094ed0c44fe7825

https://user-images.githubusercontent.com/54889005/105848258-66b2a580-5fe7-11eb-89c1-411ccb19073c.mov

https://user-images.githubusercontent.com/54889005/105848258-66b2a580-5fe7-11eb-89c1-411ccb19073c.mov

@aviadmizrachi I think the button in recovery page "Back to token screen" is not good. Can you please suggest other text?

@aviadmizrachi I think the button in recovery page "Back to token screen" is not good. Can you please suggest other text?

@AntonReact please check why the test checks have failed

@AntonReact please check why the test checks have failed


Add mod support

Hi, thank you for providing this lib. I'm not sure if you're still maintaining it, but it's been useful for a project I'm working on. I added the following fixes below. If they're ok, please consider merging them.
added support for go mod
go.mod, go.sum files and a v1.0.0 tag
fixed a broken test
gin-contrib/sessions has changed its public interface and that was stopping the tests from building.
Thank you!

Merged, thank you :)


Is settings sync on or off?

Testing #145623, but I don't know/think it is related.

go to https://insiders.vscode.dev
open a remote repository, sign into GitHub
go to the Account icon on the Activity Bar, choose "Sign in for Settings Sync"
choose to use your Microsoft account

Result: I'm prompted that SS is on and that I have to turn SS on, which is is?

@sandy081 maybe you?

@chrisdias Following the steps, I only see the second prompt that Settings Sync was turned off from another device but not both the prompts. First prompt Settings Sync is turned on is shown only if you turn on sync manually. I do not see you turned on Settings Sync manually in the steps. I assume that you would have turned on sync before these steps and the prompt was there already?

in an InPrivate Window, go to https://insiders.vscode.dev
click on Open Remote Repository button in Explorer
Choose Open Repository from GitHub in quick pick
Allow the extension 'GitHub Repositories' to sign in using GitHub
Sign into GitHub, using 2FA
Authorize Microsoft
Now I'm prompted to log in with my Microsoft credentials into GitHub, so Sign In with microsoft id

since i am on Mac I use my Password, then I'm prompted to authenticate with the app on my phone
Again, authorize Microsoft account

Once logged in, but do not choose a repository to open (for me it hangs), click on the Account Icon and Turn on Settings Sync
Uncheck everything but Keyboard Shortcuts
Click Sign in & Turn on
Choose Insiders
Choose Sign in with Microsoft

Result: the two prompts noted above.
I'll try to do a video...

https://user-images.githubusercontent.com/1487073/159806896-441a6bd0-8e86-4b45-bff1-cf4bd7df77ac.mp4

Thanks for the steps. I can reproduce.

Here are simple steps to reproduce this:

Start VS Code freshly (new user data dir and new extensions dir)
Turn on Settings Sync and select only Keyboard Shortcuts
Choose Settings Sync service in which you have not synced before
🐛 Both prompts are shown


Allow copy_image, blit_image and copy_buffer source and destination to be the same image

This PR added a fix to allow copy_image, blit_image and copy_buffer to work with src and dest images/beffers being the same.
The doc: srcImage and dstImage can be the same image or alias the same memory.
This was achieved by locking only one image exclusively if both are the same. And in order for this to work safely, we need to add checks for overlapping regions, since regions cannot overlap in memory in any of the above mentioned commands.
Entries for Vulkano changelog:
- Allowed `copy_image`, `blit_image` and `copy_buffer` to work with `src` and `dest` images/beffers being the same.
But, regions from src to dest must not overlap.

I also made an example, a copy from image with some edits

Nice fix! Can you make this work for buffer self-copies too? And image blits maybe?

Yes sure

I noticed in the docs, that in these commands, while its allowed to have the same buffer for src and dest, regions must not overlap. I'll work on adding some checks to make sure the regions are not overlapping.

Now the implementation is complete, and is safe. I'll edit the example to include the other functions to showcase them.

I think this is now ready for review.

Not related to your PR directly, but I wonder if there's a neat way to demonstrate things without making a full Rust program for each one.

Yes, I was thinking of similar thing. An idea is to make a nice flow for unit tests, we can create a mock device and try to replicate some gpu functionality on the cpu. if we got this working or something similar, we can do better unit tests (to handle all vulkan documentation) and we can use doctests easily.

@Amjad50 Thank you very much for your work! The code looks good and all examples work as expected. No regressions detected. PR merged :+1: