text:
drivers: working with flash partitions - a MTD API

The storage subsystem provides a flash_map API that allows the user to
work with dts defined partition through a flash_map structure. There is
at present no API to work with dts partitions directly.
The present PR proposes such a direct API.
In order to use a specific partition (e.g. the storage partition) the
following lines are used to create a link to the partition structure:
const struct mtd_part *part = MTD_PART_GET(storage);

Is a base to solve #34227

The partition erase_block_size is not yet specified in the dts.

Added the proposal to dev-review to know if the proposal would be accepted.

@de-nordic, I can understand that from your perpective (mcuboot, mcumgr, DFU) this PR gets -1. But maybe your perspective needs some adaptation :-).
The goal of this PR is to provide a simple method for ZEPHYR applications to use partitions. These applications are nvs, fcb, simplefs, ... They all don't need a flashmap description of all partitions that are available, they just need (secured) access to the partition so that there actions are limited to the partition itself.
This PR would reduce the size of applications by:
a. eliminating unused info
b. providing a simple routine for retrieving the erase block size that just requires 1 extra uint32, while removing the code for searching the blocksize and removing the need for CONFIG_FLASH_PAGE. This can just be defined as a partition property in the dts.

Added support for read-only partitions

Extension error (zephyr.doxyrunner):
Handler <function doxygen_build at 0x7f1d5126bca0> for event 'builder-inited' threw an exception (exception: Doxygen process returned non-zero (1))
FAILED: CMakeFiles/html

This looks like an issue in @gmarull's extension.

There's an issue in Doxygen:
(.venv) ➜  zephyr git:(flash_partition) ninja -C doc/_build doxygen
ninja: Entering directory `doc/_build'
[1/1] Running /usr/bin/doxygen
FAILED: CMakeFiles/doxygen
cd /home/gmarull/ws/teslabs/zephyr/zephyr/doc && /usr/bin/doxygen /home/gmarull/ws/teslabs/zephyr/zephyr/doc/_build/zephyr.doxyfile
/home/gmarull/ws/teslabs/zephyr/zephyr/include/storage/flash_partition.h:132: error: argument 'fa' of command @param is not found in the argument list of flash_partition_erase(const struct flash_partition *fp, off_t off, size_t len) (warning treated as error, aborting now)
ninja: build stopped: subcommand failed.

I'll check why it's not seen on CI, seems like an issue in the extension.

There's an issue in Doxygen:
(.venv) ➜  zephyr git:(flash_partition) ninja -C doc/_build doxygen
ninja: Entering directory `doc/_build'
[1/1] Running /usr/bin/doxygen
FAILED: CMakeFiles/doxygen
cd /home/gmarull/ws/teslabs/zephyr/zephyr/doc && /usr/bin/doxygen /home/gmarull/ws/teslabs/zephyr/zephyr/doc/_build/zephyr.doxyfile
/home/gmarull/ws/teslabs/zephyr/zephyr/include/storage/flash_partition.h:132: error: argument 'fa' of command @param is not found in the argument list of flash_partition_erase(const struct flash_partition *fp, off_t off, size_t len) (warning treated as error, aborting now)
ninja: build stopped: subcommand failed.

I'll check why it's not seen on CI, seems like an issue in the extension.

Thanks, I can fix that.

During the dev-review meeting there was a concern by @d3zd3z regarding the definition of a fixed erase block in a partition.
First of all: as the flash device is known in the flash partition there is no limit what so ever to define a get_sectors routine.
More important, why making a fixed setting (configurable in devicetree):
a. Most applications use a fixed erase-block-size,
b. WITHIN a partition support of varying block sizes would be highly questionable, this is certainly not supported by any system I have seen.
c. It would allow easy definition of a block-size for use in block-devices.
d. It would allow very easy definition of the number of sectors used by nvs/fcb: size/erase-block-size, no need to do whatever code to step over sectors.
e. By defining it at the partition level there is no need to define it again inside a subsystem (e.g. sector-size and sector-number in nvs).
f. As the value is valid as long as it is a multiple of the page-size, it is possible to change the value so that it best matches the requirements.

During the dev-review meeting there was a concern by @d3zd3z regarding the definition of a fixed erase block in a partition.
First of all: as the flash device is known in the flash partition there is no limit what so ever to define a get_sectors routine.
More important, why making a fixed setting (configurable in devicetree):
a. Most applications use a fixed erase-block-size,
b. WITHIN a partition support of varying block sizes would be highly questionable, this is certainly not supported by any system I have seen.
c. It would allow easy definition of a block-size for use in block-devices.
d. It would allow very easy definition of the number of sectors used by nvs/fcb: size/erase-block-size, no need to do whatever code to step over sectors.
e. By defining it at the partition level there is no need to define it again inside a subsystem (e.g. sector-size and sector-number in nvs).
f. As the value is valid as long as it is a multiple of the page-size, it is possible to change the value so that it best matches the requirements.

There is no use case, in form of real in code use, in this PR that validates the addition (tests do not count).
All extensions, that are currently not required, should be moved to separate PR; this is extension to structure that takes memory space and has not been proven, in code change, to be needed so far.
Inclusion of erase_block and read_only should be in separate PR, and discussed there; discussion on them distracts from the main purpose of the PR: is this the valid and ready replacement for the current functionality of flash map API.

There is no use case, in form of real in code use, in this PR that validates the addition (tests do not count).
All extensions, that are currently not required, should be moved to separate PR; this is extension to structure that takes memory space and has not been proven, in code change, to be needed so far.
Inclusion of erase_block and read_only should be in separate PR, and discussed there; discussion on them distracts from the main purpose of the PR: is this the valid and ready replacement for the current functionality of flash map API.

@de-nordic, thanks for the comment. This PR proposes a new api to work with partitions, it is not meant ONLY as a direct replacement of what we have now. At the moment we do NOT have a good way to work with partitions (as illustrated by the comment of @jfischer-no during the dev-review meeting). The PR aims at providing a API to work with partitions. It does however still takes into consideration that it is also to be used by the flash_map API so that a transition from flash_area to flash_partition is not impossible.
As this is a PR it is open for improvements and I am always open to discussions about why a certain solution/addition was chosen.
Regarding the addition of read-only: it has been possible for a long time to make a partition read-only, it was however neglected by the flash_area API -> this is a correction, that should be in the initial PR.
Regarding the addition of a erase-block-size: this does not increase the size at all, it reduces the size as there no longer is a requirement to find out the sector size using the get_sectors routine. Suppose in the present solution we need to get the sector-size and there is a get_sectors routine, everytime we need the get_sectors routine there will be a pointer to this routine inside the code. The size of this one pointer is what is taken up by the erase-block-size in the proposed solution, the get_sectors routine is removed from flash and this is what is saved.
The question is "are heterogeneous sectors needed inside a partition ?", my proposal answer is "No" and use that as a means to reduce code. If the answer is, "Yes, we need that because then I can ...", a revision of the API would be needed (I do not consider "this is how we have it at the moment" a valid "Yes").
If this is just a question about naming, would it not be better to specify a "default-erase-block-size" instead of specifying "erase-block-size", no problem.
Regarding other discussion topics: "should the flash_partition_check be inside the API ?" My answer would be "No", this is not a property of a partition but of an image inside a partition. So IMO flash_partition_check should be removed.

Btw, everyone seems to forget about this: https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/subsys/fs/littlefs/boards/nrf52840dk_nrf52840.overlay
This is file system level configuration for FS done via DTS.

This PR proposes a new api to work with partitions, it is not meant ONLY as a direct replacement of what we have now.

Putting the rename aside, which may be ok move, it does exactly what the original API does: it limits operations on flash to predefined range. I am actually considering this as a valid candidate.

At the moment we do NOT have a good way to work with partitions (as illustrated by the comment of @jfischer-no during the dev-review meeting).
As far as I can tell, @jfischer-no concern was towards lack of declaration of "block" devices rather than partitions.

The PR aims at providing a API to work with partitions. It does however still takes into consideration that it is also to be used by the flash_map API so that a transition from flash_area to flash_partition is not impossible.

Again it logically does the same thing as the flash map API, however you name it.

Regarding the addition of read-only: it has been possible for a long time to make a partition read-only, it was however neglected by the flash_area API -> this is a correction, that should be in the initial PR.

There is no reason to add this: the only reason that this may be useful is to detect that user has failed to correctly select partition to write and destroys data, something that should be detected during tests.
Adding this, with all code paths within Zephyr  that will be checking the constant, will affect all code that access flash via flash_partition API even if 99.9% of users will never have the bug or will fix it at test phase; which is programmer's error.

Regarding the addition of a erase-block-size: this does not increase the size at all, it reduces the size as there no longer is a requirement to find out the sector size using the get_sectors routine. Suppose in the present solution we need to get the sector-size and there is a get_sectors routine, everytime we need the get_sectors routine there will be a pointer to this routine inside the code. The size of this one pointer is what is taken up by the erase-block-size in the proposed solution, the get_sectors routine is removed from flash and this is what is saved.
The question is "are heterogeneous sectors needed inside a partition ?"

Depends of designation: if it is for streamed, sequential, data, or image of an application or data that is read only then
no, because "sectors"/"pages" are erased as data crosses from one to another; the erase_block is then useless;
In case of file systems: yes;  you can not reliably write efficient file system when your sectors change in size and if system does not use direct flash/mtd/magnetic device sector size, it will affect wear and/or speed.
Btw. the problem of non-uniform "sectors"/"pages" is nearly completely relevant to internal flash of SoC.
The FAT file system is an example of the problem: we define sector, for compatibility, to be 512 bytes, but on nrf flash it is written to 4096 byte pages, this means that each time one of sectors is to be written, there is possibility that the entire page needs to be erased and rewritten. Addition of the "erase_block" in API that should only limit flash access by offset and size is another level this can be broken or misconfigured.
I guess that the erase_block  would collect several pages as one bigger chunk: not useful for image/stream writes; bad for file systems.
The flash_pages_info, the flash_area_get_sectors` may need fix instead.

If this is just a question about naming, would it not be better to specify a "default-erase-block-size" instead of specifying "erase-block-size", no problem.

None. The flash partitioning, as the any other partition scheme, like MBR, GPT, Amiga RDB, BSD label, and so on, should never dictate sector size (effectively erase block), it may dictate partition start alignment, but not sector size - this is always taken from the hardware for software to decide what to do with the info.

Regarding other discussion topics: "should the flash_partition_check be inside the API ?" My answer would be "No", this is not a property of a partition but of an image inside a partition. So IMO flash_partition_check should be removed.

This may be moved to separate unit or as library function. The removal of functions that are considered non needed is separate issue.

The flash layout API was established for support any flash page layout. I see no point to left this behind.
I can see place for erase_block as value which can help to simplify some solutions not aimed to support homogenous layouts.
I strongly believe that @jfischer-no concerns on API that might be used by mass storage device are layer much above subject of this API. Such an API will probably use this API amongst others to implement much sophisticated behaviors.

Btw, everyone seems to forget about this: https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/subsys/fs/littlefs/boards/nrf52840dk_nrf52840.overlay
This is file system level configuration for FS done via DTS.

You mentioned it yesterday, and probably it will need some work, but I don't see any reason why the proposed PR would be incompatible with this. In fact this shows even the power of the proposed method:
a. We introduce a way to work with partitions that is good for zephyr.
b. We convert everything that is in zephyr to use this API (fcb, nvs, littlefs, ...)
c. We convert flash_map to use flash_partitions.
During the transition all conversions can be tested and introduced separately and if something is broken it will be limited.

At the moment we do NOT have a good way to work with partitions (as illustrated by the comment of @jfischer-no during the dev-review meeting).
As far as I can tell, @jfischer-no concern was towards lack of declaration of "block" devices rather than partitions.

I don't think so, why is flash_disk, using the flash API rather than flash_map? Because flash_map is crippled by it's interface going through some struct that puts all partitions in an array and then gets a partition from this struct. Also look at the littlefs code about getting the block size, line 557 of little_fs.c "There is no flash_area API to get the maximum page size, so we have to make one", and what is really needed is a page size because the code will not work when a partition is created spanning heterogeneous sectors.
The same is valid for nvs, because of the flash_map interface it is only used in the initialisation and at the time I even resisted against that.

The PR aims at providing a API to work with partitions. It does however still takes into consideration that it is also to be used by the flash_map API so that a transition from flash_area to flash_partition is not impossible.

Again it logically does the same thing as the flash map API, however you name it.

As said by naming it differently you can make a save and controlled transition.

Regarding the addition of read-only: it has been possible for a long time to make a partition read-only, it was however neglected by the flash_area API -> this is a correction, that should be in the initial PR.

There is no reason to add this: the only reason that this may be useful is to detect that user has failed to correctly select partition to write and destroys data, something that should be detected during tests.
Adding this, with all code paths within Zephyr that will be checking the constant, will affect all code that access flash via flash_partition API even if 99.9% of users will never have the bug or will fix it at test phase; which is programmer's error.

Let's turn this around, should I file a bug report because flash_map does not respect a "read-only" flag that I have set in the dts ? Once this bug report is present it would be OK to add a "read-only" flag?

Regarding the addition of a erase-block-size: this does not increase the size at all, it reduces the size as there no longer is a requirement to find out the sector size using the get_sectors routine. Suppose in the present solution we need to get the sector-size and there is a get_sectors routine, everytime we need the get_sectors routine there will be a pointer to this routine inside the code. The size of this one pointer is what is taken up by the erase-block-size in the proposed solution, the get_sectors routine is removed from flash and this is what is saved.
The question is "are heterogeneous sectors needed inside a partition ?"

Depends of designation: if it is for streamed, sequential, data, or image of an application or data that is read only then
no, because "sectors"/"pages" are erased as data crosses from one to another; the erase_block is then useless;
In case of file systems: yes; you can not reliably write efficient file system when your sectors change in size and if system does not use direct flash/mtd/magnetic device sector size, it will affect wear and/or speed.
Btw. the problem of non-uniform "sectors"/"pages" is nearly completely relevant to internal flash of SoC.
The FAT file system is an example of the problem: we define sector, for compatibility, to be 512 bytes, but on nrf flash it is written to 4096 byte pages, this means that each time one of sectors is to be written, there is possibility that the entire page needs to be erased and rewritten. Addition of the "erase_block" in API that should only limit flash access by offset and size is another level this can be broken or misconfigured.
I guess that the erase_block would collect several pages as one bigger chunk: not useful for image/stream writes; bad for file systems.
The flash_pages_info, the flash_area_get_sectors` may need fix instead.

If this is just a question about naming, would it not be better to specify a "default-erase-block-size" instead of specifying "erase-block-size", no problem.

None. The flash partitioning, as the any other partition scheme, like MBR, GPT, Amiga RDB, BSD label, and so on, should never dictate sector size (effectively erase block), it may dictate partition start alignment, but not sector size - this is always taken from the hardware for software to decide what to do with the info.

So there is no discussion that this would reduce code size rather then increase.
In the API there is no "dictation" of sector size or erase block size, it is a user configurable entry that can be used to help the user of the partition to get a well formulated block size or sector size. The default if not specified is the complete sector size. In most cases I would select is as the page size, but for nvs, fcb it makes sense to have fewer sectors so I would increase it if wanted, effectively using the erase-block-size to control the number of sectors needed. This would remove all code related to defining and checking the number of sectors, again a reduction in code size.
Introducing this one property gives many possible code reductions, and if there are users that would like more fine grained info about the real hardware limits, it is always possible.
From my knowledge of the zephyr system and flash usage this would reduce code size in 100% of the cases and in the other (using non-heterogeneous blocks !) the increase in code size is 1 word.

Regarding other discussion topics: "should the flash_partition_check be inside the API ?" My answer would be "No", this is not a property of a partition but of an image inside a partition. So IMO flash_partition_check should be removed.

This may be moved to separate unit or as library function. The removal of functions that are considered non needed is separate issue.
It is not a separate issue when introducing a new API.

The flash layout API was established for support any flash page layout. I see no point to left this behind.
I can see place for erase_block as value which can help to simplify some solutions not aimed to support homogenous layouts.

Actually the the flash_page info functions are only missing confirmation whether there is uniform page size across the device;
otherwise the get by offset and get by idx functions are all that is required.

The flash layout API was established for support any flash page layout. I see no point to left this behind.
I can see place for erase_block as value which can help to simplify some solutions not aimed to support homogenous layouts.

IMO the reason this was used in mynewt is that they were working with the complete flash and not with a partition.

I strongly believe that @jfischer-no concerns on API that might be used by mass storage device are layer much above subject of this API. Such an API will probably use this API amongst others to implement much sophisticated behaviors.
I think the comment originated from the problem working with partitions and the direct usage of the flash API.

IMO the reason this was used in mynewt is that they were working with the complete flash and not with a partition.

If they have been using "complete flash" why do they need flash areas in the first place? and once more flash areas == flash partitions.

IMO the reason this was used in mynewt is that they were working with the complete flash and not with a partition.

If they have been using "complete flash" why do they need flash areas in the first place? and once more flash areas == flash partitions.

If they were defining areas as just an offset. Areas are a naming that was inherited by copying this from mynewt.

But while going through the code, I think there is one subsystem that allows the use of heterogeneous blocks: fcb, this however means that we should not use fcb for settings, as there is a possibility of losing data when we have been writing to a large sector and we have to copy all data in a smaller sector.

I don't think so, why is flash_disk, using the flash API rather than flash_map? Because flash_map is crippled by it's interface going through some struct that puts all partitions in an array and then gets a partition from this struct.

Do you even read what I write? I am not talking about keeping the current flash map API way of obtaining the flash area object, or how the device has been obtain for each operation; that is why I have tried to resolve to compile time generated device pointers in the first time, and that is why I did my PR and that is why I consider this also to be candidate.
General idea of what you do is exactly the same as flash area, it is just a fence over some flash device that says where you can play. The execution is different.

Also look at the littlefs code about getting the block size, line 557 of little_fs.c "There is no flash_area API to get the maximum page size, so we have to make one", and what is really needed is a page size because the code will not work when a partition is created spanning heterogeneous sectors.

It does not say: "we are missing constant with the value" but rather that there is no lib call that will report max page size in given range. So no It does not state we need erase_block set to some value, but rather that there is a need for  simpler way to find actual maximum value, within the area range, instead of doing this loop.
The above has also one advantage over just setting some value via DTS: switching partition to other device does not require altering the value of erase block, because driver will figure out.
We have flash_get_page_info_by_offs and flash_get_page_info_by_idx that are able to get page info, we could probably do flash_partition_get_page_info_by_offs , etc to mimic the flash_* API to do the same with the range of flash_partition, and simplify the access. But this is not an issue for the PR.

and what is really needed is a page size because the code will not work when a partition is created spanning heterogeneous sectors.

So how does it fix the problem? It just hides it.

Let's turn this around, should I file a bug report because flash_map does not respect a "read-only" flag that I have set in the dts ? Once this bug report is present it would be OK to add a "read-only" flag?

Maybe rather to remove the flag? The bug report you propose will spawn next one, to support it in flash_partition_write that will basically affect all write operations just for someone to figure out that the label in FLASH_PARTITION_GET(get) is incorrect, yet the execution path, within flash_partition_write, will remain, and will be basically code executed for no reason for 99.9% of users, for every write via API.

So there is no discussion that this would reduce code size rather then increase.

I have not commented on size of code anywhere, and this is speculation that the PR is not proving, that is why, again, the extensions should be separate PR, with some change to exiting solution to show how to use the feature.

In the API there is no "dictation" of sector size or erase block size, it is a user configurable entry that can be used to help the user of the partition to get a well formulated block size or sector size. (...)

It kinda is, because it has to be supported  internally within flash_partition_erase and probably flash_partition_write, otherwise what is the sense?
If the user has to make own calculations then the user may just pick any value anyway, and the write_block is no more useful than #define; in both cases user may just go for flash_pages_info.

From my knowledge of the zephyr system and flash usage this would reduce code size in 100% of the cases and in the other (using non-heterogeneous blocks !) the increase in code size is 1 word.

From my knowledge this requires separate PR for discussion, so that we can focus on taking (or not taking) the flash_partition API as de-facto back-end for flash map API.

Regarding handling flash devices where the erase blocks vary in size. So far, everything I can find that uses MCUboot on these types of devices, always limits it to a set of sectors that have the same erase size. Although MCUboot has a bunch of code to try and support partitions that don't have constant sector sizes, I'm not sure how well this actually gets tested. The only configuration I see as needing to be supported is when the upgrade slot is an external device, in which case it can have a different erase size than the main device.
I would suggest we try to propose simplifying the use of variable erase block sizes within MCUboot, and if we can successfully do that, then having this new API just return a simple erase block size.
This could still be supported on devices with varying block sizes, as long each individual partition does not cross a boundary between sizes.  For example an ST device has 4 16K blocks, a 64K block, and 3 128K blocks. Typically, MCUboot resides in a 64k block, and the 3 128k blocks are used for images. The 16k blocks are used for persistent storage.
If anyone is aware of an MCUboot configuration where it tries to store code images in a partition where the block differs, please let us know.

To summarize the remarks on the PR for using flash partitions:
a. Does the flash partition API need to provide support for read-only partitions ?
b. Should the flash partition API always use the erase block size retrieved from a flash page API or should it be possible to specify a block size in the partition configuration (by no means limiting the usage to only this block size) ?
c. Should a flash partition API provide a image hash validation routine (the hash is not stored on the partition) ?
If there is extra info needed on the questions, do not hesitate.

b. Should the flash partition API always use the erase block size retrieved from a flash page API or should it be possible to specify a block size in the partition configuration (by no means limiting the usage to only this block size) ?

It makes me uncomfortable when the flash API doesn't convey information about the true characteristics of the underlying flash device. Sometimes, this gets implemented writes that silently read/erase/write with the idea that they will help out application code that isn't expecting flash devices to be complicated. This can result in devastating data loss if power is lost between the erase and the data being rewritten. The loss situations of lying about erase blocks seems less significant, but there are still possible scenarios.
The conclusion I draw from this, is that if we do decide to drop the variable sector size mapping part of the API, then we are also asserting that partitions can never contains blocks of different sizes. For example, in the ST 416+64+3128 device, there could be one or more partitions covering the 4 16K blocks, a partition covering the 64Kb block, and 1 or more covering the 3 128Kb blocks. But, a partition that includes say the 4 16K blocks and the 64K block (stating that there are just 2 64K blocks) should not be allowed.
As far as I can tell, all of our use of the ST device is this way, and I'm trying to investigate to see if there are any other configurations that people use. Given that MCUboot doesn't really test these varying-block-size partitions, I don't have high expectations that the code works, either.

@de-nordic, @nvlsianpu, @d3zd3z, I have been thinking about the variable block size problem, here is what I was thinking:
a. An optional parameter block-size can be specified for a partition.
b. When this block-size is specified flash_partition_get_ebs() returns this optional parameter.
c. When the block-size is not specified and FLASH_PAGE_LAYOUT is enabled flash_partition_get_ebs() returns the constant block size (if it is constant), if it is not constant it returns an error-code (-EINVAL).
d. A function flash_partition_get_block_of(fs, off, &block) that returns the block-offset (in the partition) and the block-size of the address off is pointing to. This function will be different based on the FLASH_PAGE_LAYOUT property.
e. When FLASH_PAGE_LAYOUT is not enabled and the optional parameter is not specified the partition is considered as one erasable block (so ..._get_ebs() returns the partition size).
This way:
a. Variable block sizes are supported, and construction of "sectors" is also supported,
b. There is a way to detect a non-constant block size for a user that needs it,
c. There is a way to "short-circuit" the flash page layout when it is known that the device has a constant blocksize,
d. By default nothing changes if FLASH_PAGE_LAYOUT is selected.

cc @erwango

^^ That sound reasonably.
Regard b.

When this block-size is specified flash_partition_get_ebs() returns this optional parameter.

Flash node in dts might also defined (native) block-size for the flash memory. Maybe it can be used if the partition node not defines it on its own.

@nvlsianpu, @de-nordic, I have updated to include support for non-uniform flash layout even in a partition.
To give an idea, the removal of flash_page support (by specifying the partition erase block size) saves about 400 bytes in rom.

@de-nordic @Laczen

I am just asking to have separate PR on extensions that can be added anytime but require some discussion and are currently distracting from quick adaptation of the API.

I think worth to divide PR to more subjects, this will help to get some of them faster.  @de-nordic  As I already understood you would leverage this API in the flash_area reworking efforts.

The erase_block and the read_only require separate PR, because there are various things we do not agree on.
We need to focus, within this PR, to review the solution as the replacement for flash_area* within zephyr, as there is no need to let both exist internally; with some agreement on need to change the name of flash_area* to something more appropriate, this may be the PR to got with.
I will review the rest of the code later, so far -1; I am just asking to have separate PR on extensions that can be added anytime but require some discussion and are currently distracting from quick adaptation of the API.

@de-nordic, Your reaction is rude and impolite.
From the start I have stated that this PR was NOT a replacement or a quick adaptation of flash_area. It is a proposal API to work with partitions.
The proposal allows the writing and reading and erasing of blocks in a partition and also provides some other functions that can be handy when working with partitions on flash.
It also guarantees that when using this API there will be no accidental overwrites of data stored in read-only partitions.
It also adds a optional property that allows a partition to specify a erase-block-size that is larger than(or equal to) the erase-block-size that is dictated by the hardware erase block size. This is usefull for users that could take advantage of it and allows significant reduction in image size. Yes this can be wrongly defined, but so can a hardware pin in the dts, when someone modifies a dts it is expected that there is basic knowledge on hardware limitations. There is no intention (and there never was) to limit erases to this specified block size.
As examples where this optional property can be used:
a. To define a sectorsize (and thereby sectorcount) in nvs and fcb,
b. To define a blocksize (if possible) on a partition that has different hardware erase-block-sizes internally, but is used by a system that expects constant block sizes,
c. To define a erase-block-size for a block device that would store multiple blocks on one erase-block and where the hardware page size is no good fit. As an example of this a UBI like logical block to physical block translator that would store 512 byte blocks on a 1024 byte page size system.
d....
@nvlsianpu, thank you for trying to negotiate, but I can't see any good reason to remove both read-only and the optional erase-block-size from the API.
@de-nordic, remove yourself as a reviewer.

The way this PR is, it is kind of like flash_area_v2.
I do not think it is, or should be, a subsystem. From the API point of view it should not be much different than a (raw) flash API, or better, it should be a mandatory part of (raw) flash API, and use like all drivers the device API. So in the simplest case there is only one partition that occupies the whole raw flash area (the same regarding flash_area).  So just like that:

(x) Application, FS, ...

(2)  flashdisc, DFU, NVS  (always operates on a partition e.g. partition storage))

(1)   raw flash API (read, erase, write API to a flash paritition)

nor-flash, nand-flash, xyz-flash (SoC/SPI/I2C raw flash device)

The way this PR is, it is kind of like flash_area_v2.
I do not think it is, or should be, a subsystem. From the API point of view it should not be much different than a (raw) flash API, or better, it should be a mandatory part of (raw) flash API, and use like all drivers the device API. In the simplest case there is only one partition that occupies the whole raw flash area (the same regarding flash_area). So just like that:
(x) Application, FS, ...
(2) flashdisc, DFU, NVS (always operates on a partition e.g. partition storage))
(1) raw flash API (read, erase, write API to a flash paritition)
nor-flash, nand-flash, xyz-flash (SoC/SPI/I2C raw flash device)

@jfischer-no, thank you for adding your comments. Is my understanding correct that you are proposing to add this under drivers/flash_partition ? This indeed seems logic as we are defining the partitions in the dts. Also this way zephyr users would find this interface quicker.
The flash_partition API should indeed be the way higher-up systems are working with flash.
I don't know if it's possible/wanted to deny applications/higher-up systems direct access to the raw flash device interface. Denying this raw access would definitely make testing of the raw flash (flash_partition) API a lot more difficult.

@jfischer-no, thank you for adding your comments. Is my understanding correct that you are proposing to add this under drivers/flash_partition ? This indeed seems logic as we are defining the partitions in the dts. Also this way zephyr users would find this interface quicker.

Rather drivers/flash/mtd_partition.c or drivers/flash/mtd_common.c or drivers/flash/flash_common.c

The flash_partition API should indeed be the way higher-up systems are working with flash.

No, I think it should be upper part of flash driver API and the only interface to higher layer.

I don't know if it's possible/wanted to deny applications/higher-up systems direct access to the raw flash device interface. Denying this raw access would definitely make testing of the raw flash (flash_partition) API a lot more difficult.

It is not denied, it still operates on raw flash but with advantages you mentioned above:

The proposal allows the writing and reading and erasing of blocks in a partition and also provides some other functions that can be handy when working with partitions on flash.
It also guarantees that when using this API there will be no accidental overwrites of data stored in read-only partitions.

@jfischer-no, this seems like a good idea, I would go for mtd_partition.c. For the full fledge mtd support like in linux my knowledge of flash devices is to limited.
Should we go for a mtd_write(struct *mtd_info, off, data, len) approach or keep something like mtd_partition_write(struct *mtd_partition, off, data,len) ?

@jfischer-no, I have updated the proposal
I am considering defining mtd_write(...) routines instead of mtd_part_write(...) and renaming the mtd_part structure to mtd_info.
Also routine mtd_create_partition() could be added (it is just a struct definition).

@nvlsianpu, thank you for trying to negotiate, but I can't see any good reason to remove both read-only and the optional erase-block-size from the API.
I see,
@Laczen Consent helps to have work done. Actually I was really thinking that these feature were nice and might be added in separate discussion (PRs). Point is that when we have to long discussion it is hard to get to the point of PR.
I bet that if it is easy to prove that  feature is useful, then it will be accepted anyway. From the other hand iterative development allow to divide effort into easier manageable chunks.

@de-nordic, remove yourself as a reviewer.

That you both are not agreed on technical issue doesn't mean that anyone can exclude someone from discussion. Domink has spent much time on this and related subject, missing his review mean waste of his efforts and time.

@jfischer-no, updated the PR to allow working with mtd masters as well as partitions.

authors: Laczen carlescufi d3zd3z de-nordic gmarull jfischer-no nvlsianpu


text:
Update modbus to explicitly check for tx_completed. add uart tx complete method for modbus on sam0

Fixes an issue with modbus not explicitly checking for TX completed before disabling TX and de-asserting the de pin if present in half duplex mode over RS485. This results in data loss during last byte transmission described in issue #38264.
For devices such as the NRF series uart_irq_tx_ready and uart_irq_tx_complete are the same function and waiting for tx completion is implicitly enforced and the modbus driver would succeed.
Therefore because modbus requires tx to be completed fully before disabling DE, an explicit check should be added before disabling transmission.
PR #38310 attempts to fix this issue however the fix adds additional driver and hardware specific methods to the uart api which are unnecessary for a driver that should be hardware agnostic at the higher level.
This PR attempts to solve the issue in a minimalistic way that does not impact existing functionality as mentioned here https://github.com/zephyrproject-rtos/zephyr/issues/38264#issuecomment-912834588
Also added 9d2758b8a7051d47adf4fadf360d1012f5940bb1 to correct an intermittent race condition with TXC sometimes not firing after transmit done. Per the samD21 datasheet, writing a 0 to any bit in INTFLAG has no effect. However writing a 1 clears the flag.
Therefore the old line
regs->INTFLAG.reg |= SERCOM_USART_INTENCLR_RXS;

is the equivalent of
regs->INTFLAG.reg = regs->INTFLAG.reg;

effectively clearing all set INTFLAG's and also breaking any later code checking those flags for validity.

Hi @rocky134 ,
LGTM, just a few style adjusts.

source: gharchive/pull-request

repo: zephyrproject-rtos/zephyr

license_type: permissive

license_source: github-api


text:
IRQ x86 cleanups

These are old patches I made for vt-d, but they are not vt-d specific at all and are good to get I think.

@tbursztyka I'm concerned about how this could apply to other platforms, because I don't see how.
The arch specific MSI vector + IRQ allocation doesn't match on other platforms at all, where the MSI translater is a separate IP not pre-configure by the boot firmware.
I pushed #40566 and in this PR I simply disable all these IRQ handling functions because I can't make them match.
Why can't MSI handling be dynamic and use pcie_msi_vectors_allocate(), pcie_msi_vector_connect() & pcie_msi_enable() ? Is the legacy PCI IRQ support hidden in these calls ?

The arch specific MSI vector + IRQ allocation doesn't match on other platforms at all, where the MSI translater is a separate IP not pre-configure by the boot firmware.

Yes and your PR did what was necessary to hide this pcie_alloc_irq(). Maybe I missed some ifdef in the include/sys/arch_interface.h then (should be under #ifndef CONFIG_PCIE_CONTROLLER  ...)

Why can't MSI handling be dynamic and use pcie_msi_vectors_allocate(), pcie_msi_vector_connect() & pcie_msi_enable() ? Is the legacy PCI IRQ support hidden in these calls ?

I am not touching anything about that in this PR.

The arch specific MSI vector + IRQ allocation doesn't match on other platforms at all, where the MSI translater is a separate IP not pre-configure by the boot firmware.

Yes and your PR did what was necessary to hide this pcie_alloc_irq(). Maybe I missed some ifdef in the include/sys/arch_interface.h then (should be under #ifndef CONFIG_PCIE_CONTROLLER ...)
@superna9999 ah indeed my patches removed your #ifdef, something went wrong while rebasing.

Why can't MSI handling be dynamic and use pcie_msi_vectors_allocate(), pcie_msi_vector_connect() & pcie_msi_enable() ? Is the legacy PCI IRQ support hidden in these calls ?

I am not touching anything about that in this PR.

Perhaps it's not the right place to discuss about this, but I don't like how I disable these functions, so I wanted to be sure they were related to legacy PCI irqs ?

Why can't MSI handling be dynamic and use pcie_msi_vectors_allocate(), pcie_msi_vector_connect() & pcie_msi_enable() ? Is the legacy PCI IRQ support hidden in these calls ?

I am not touching anything about that in this PR.

Perhaps it's not the right place to discuss about this, but I don't like how I disable these functions, so I wanted to be sure they were related to legacy PCI irqs ?

The way it's disabled is fine to me. The impact of x86 behavior on pcie code design would be larger than that, then perhaps it would be necessary to revise that design.
To be fair, the irq/vector management in x86 within Zephyr would need a good refresh. x86 vectors are always linked to an irq, thus the need to allocate one, even on MSI/MSI-X PCIe device. Old design inherited from the very beginning of zephyr when it only supported legacy PC platform.


text:
[WIP] ci: proposal to restructure github workflow files for portability

This commit is a proposal to move the execution code out of the
workflow files to scripts. This should allow for better portability,
keeping only github (and sometimes AWS) specifics in the workflow files.
This is work in progress
The reason for this proposal is to make easier enablement of Zephyr
CI systems outside of github.
This commit shows only one change (compliance.yaml), its sole
purpose is to start a conversation. Your feedback is welcome.
Signed-off-by: Yves Vandervennet yves.vandervennet@nxp.com

Any comment?

For the sake of transparency, here's a log of my discord chat with Stephanos:
yves — 08/29/2022
Hi, I saw your comment on github. Can you help me understand how reusable is this CI? And what do you mean by "nuanced"?
Thanks
stephanos — 08/29/2022
by "nuanced," I mean one or more of the following:

specific to how GitHub/GitHub Actions works

specific to environment (GitHub Actions virtual runner environment, docker image, ...)

specific to the upstream process

we will likely never accept approach like this upstream.
yves — 08/29/2022
Well, how can any of the runtime instructions be specific to github? References to github vars, etc I understand. But how can 'pip install ..." be specific to github? As it is today, that is my understanding, none of the runtime for CI is reusable. Companies may not be allowed to use github or maybe they have their own CI systems.
With the current structure of the workflow files, how can a company keep up with the upstream CI with workflow files providing so much CI runtime code?
stephanos — 08/29/2022
what do you think scripts/ci/check_compliance.py does?
the rest of it is really just glue code
yves — 08/29/2022
check compiance that's it
stephanos — 08/29/2022
you only need to call scripts/ci/check_compliance.py in your workflow/pipeline to make it work.
yves — 08/29/2022
Hmm, we may be misunderstanding each other here...
How about twister?
stephanos — 08/29/2022
scripts/twister?
the rest of the code is, once again, just glue code
https://github.com/zephyrproject-rtos/example-application/blob/main/.github/workflows/build.yml
this is possibly the simplest workflow running twister
really we don't need an extra script for this
yves — 08/29/2022
I am still not aligned, I'll explore some more.
I see that the notion of 'glue code' is different. Please understand I am not trying to make a big stink of all this. All I am trying to do is reuse what is run by the community because we want to run the same tests prior to submitting our PR's.
And by tests -> I mean what are defined as workflows....
stephanos — 08/29/2022
we already have all the logic outside the workflows. there are dedicated scripts for that.
we are not going to accept any changes that moves the code inside the workflows (what we call "glue code") out to a script unless you can provide a very good rationale for that.
yves — 08/29/2022
OK. Sorry if I appear 'pushy' or even 'thick' but how is the following glue code? It's setting up the env to run the rest....
      west init -l .  true

      west config --global update.narrow true

      west update 2>&1 1> west.update.log  west update 2>&1 1> west.update2.log

I am obviously off in my understanding
So let's not continue here, we might just go in circles...
stephanos — 08/29/2022
if you're talking about update.narrow, it's just telling west to do a shallow clone.
you, or anyone else downstream, may or may not want to do that.
once again, you can easily reproduce what the upstream CI does because we already provide the scripts for them.
what is in the workflow files is more or less specific to how WE (upstream) want to handle things, and also many things specific to upstream.
yves — 08/29/2022
OK. Thanks.
yves — 08/31/2022
Are you OK if I post some of your comments to github?
Just for other people to follow
stephanos — 08/31/2022
sure. I would suggest moving this discussion to a thread in #infrastructure channel so this is publicly visible
yves — 08/31/2022
Yes. I heard of one person who wants to chime in
I believe it will be over github.
So, I have to add one comment I have not made yet... I hear your comment about nuanced code, yet, a lot of it is common to any CI, i.e. west commands, etc
stephanos — 08/31/2022
I don't understand what you mean exactly
are you talking about refactoring common functions out?
yves — 08/31/2022
That is my goal, yes.
That is the spirit of what I am doing
stephanos — 08/31/2022
there are not that many common functions and each workflow tends to have slightly different requirements, and the amount of the common code is minimal so I would not put efforts into that.
yves — 08/31/2022
OK : common = common to all CI setups
or systems should I say
stephanos — 08/31/2022
if we really think something is worthy of deserving a generalised implementation, then we can write an "action" for it.
yves — 08/31/2022
That could be a "githuby" way  of going
stephanos — 08/31/2022
to my understanding, what you are doing is to implement your own CI for Zephyr
yves — 08/31/2022
But would this enable other CI systems??
Not that I know
stephanos — 08/31/2022
no. that is beyond the scope of the upstream CI.
stephanos — 08/31/2022
I would suggest implementing your own based on the upstream one first, instead of trying to introduce changes to the upstream CI to fit your needs.
there are many history and details involved in the upstream CI, also future roadmap/plans on how it's going to change.
yves — 08/31/2022
I get the recommendation. My purpose is to make it easier for downstream CI's to keep up with changes in the upstream CI
That is it
stephanos — 08/31/2022
you will be wasting a lot of time by trying to change the upstream CI without being heavily involved in the process.
yves — 08/31/2022
I wish we could talk to each other... What do you mean by that?
stephanos — 08/31/2022
it's not like we overhaul the upstream CI every month
there are tens of downstream users that implement their own Zephyr CI loosely based on the upstream process.
and they don't have any major issues.
yves — 08/31/2022
OK. I was not implying there would be a ton of issues... Perhaps I am thinking in too broad terms.
stephanos — 08/31/2022

Perhaps I am thinking in too broad terms.

I would say so. keeping your own (downstream) pipeline in sync with the upstream CI is really not much effort
in fact, you should almost never need to do it.
maybe once a year
the upstream CI is mostly just running twister (and maybe docs build). the rest is just specific to the upstream project process.
so you really don't need to care about the rest
yves — 08/31/2022
I see. Okey dokey, thanks for the chat.


text:
Native: entropy device/driver for native_posix

Added pseudo-random entropy device for the native_posix board
+
Changes in samples/drivers/entropy so it is tested in the native_posix regression

Codecov Report

Merging #6128 into master will increase coverage by <.01%.
The diff coverage is 76.92%.

@@            Coverage Diff             @@
##           master    #6128      +/-   ##
==========================================
+ Coverage   52.88%   52.88%   +<.01%
==========================================
  Files         412      417       +5
  Lines       40274    40358      +84
  Branches     7801     7819      +18
==========================================
+ Hits        21297    21345      +48
- Misses      15761    15786      +25
- Partials     3216     3227      +11

Impacted Files
Coverage Δ

drivers/entropy/entropy_native_posix.c
76.92% <76.92%> (ø)

subsys/random/rand32_timer.c
0% <0%> (-100%)
:arrow_down:

samples/drivers/entropy/src/main.c
55% <0%> (ø)

tests/drivers/entropy/api/src/main.c
48.64% <0%> (ø)

subsys/random/rand32_entropy_device.c
70% <0%> (ø)

include/entropy.h
75% <0%> (ø)

kernel/device.c
60% <0%> (+5%)
:arrow_up:

Continue to review full report at Codecov.

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

Do we have a need to set the seed?

Absolutely. We need to be able to reproduce tests. We don't want unpredictability.
+
We don't really need a "good" random number generator. Just something good enough to exercise the code with different data. For that random() should be way more than enough. We don't run in native_posix to generate cryptographically sound data, just to test.

I'm a little concerned about not having entropy in the native posix environment. There is a concern about repeatability, which is somewhat valid, but if this code is ever used to make real connections to external services, those connections will be completely insecure, possibly revealing more than is expected.
The behavior of cryptographic operations should not depend on a particular sequence coming from a random source (in fact, if it does, this can be considered a security vulnerability, as it suggests information can be revealed through timing attacks). Do we know of actual tests that produce different results, or is this just speculation?

authors: aescolar-ot codecov-io d3zd3z


text:
DNM: Purposefully erroneous PR for testing compliance check

TESTING PR DNM. Using this to check for a bug that might be in the compliance checking workflow.

Zephyr CI is not meant to perform random testing. Please report any issues you're facing instead.


text:
github: west_cmds: add missing anytree package

Add missing anytree package, runners started to fail on it:
../pylib/twister/twisterlib/runner.py:60: in <module>
    from anytree import Node, RenderTree
E   ModuleNotFoundError: No module named 'anytree'

Tagging as 4.0, does not really affect the release.

looks like some of the changes from #81129 didn't go through CI? /cc @nashif

CI is currently broken, so adding the Hotfix label.

Attn @dkalowsk @mmahadevan108

authors: cfriedt fabiobaltieri kartben


text:
CI tests for vouching deployment scripts

We need to add tests for zos/packages/vouching/src/scripts that are run with npm run test in CIs.

Addressed by #212

source: gharchive/issue

repo: zeppelinos/zos

license: MIT


text:
example/devices server can't receive message

I run example in example/devices. But server can't receive message pid.  It seems blocked.

Is that a BUG in example/device/server.py on line 43? I think should be: clients = context.socket(zmq.ROUTER), If type is zmq.DEALER，will be block.

#774 introduces a more up-to-date device example.

repo: zeromq/pyzmq


text:
[Bug]: Minimizing a floating window and then un-minimizing, window comes back tiled

Before you make the issue, confirm that

[X] You are running the master build from GitHub actions
[X] You have read the FAQ and the usage instructions
[X] You have searched pull requests and issues and have found none similar to your issue
[X] This problem comes from a failure in the tiling system and not a missing feature

Describe the bug
Whether I manually float a window, or have a window floated due to being in the Polonium config's filter section, if I minimize the window, and then un-minimize it, it comes back tiled rather than floating.
This is only occurring in Plasma 6. In Plasma 5 the window would come back floating.
To reproduce

Float a window
Minimize that window
Un-minimize that window
See the window tiled rather than tiled

Expected behavior

Float a window
Minimize that window
Un-minimize that window
See the window floating in it's original location

Relevant log output
$ journalctl --user --no-pager -e | grep -i "polonium"
# returns empty

Screenshots and videos

Screencast_20240313_094708.webm

Additional context
No response

experiencing the same thing

Somewhat related: If I lock my screen and come back after something like 10 minutes, none of my tiled windows are "tiled" when i return (I think kwin causes a crash). The only way to re-tile my windows without closing them outright is this minimizing trick/bug.

Try the latest commit again and see if anything has changed.

Can confirm working correctly now, thanks

authors: CountMurphy FantasyPvP msmol zeroxoneafour

repo: zeroxoneafour/polonium


text:
The table "issue"

A very useful piece of code to combine the power of tabulary (self-adjusting column width with LCR instead of lcr) and longtable: https://tex.stackexchange.com/a/197808
Then, from I understand, we will need a \tableCell macro, that may take as a parameter the colspan and rowspan (and translate into \multicolumn and \multirow if needed), to be close to the traditional HTML syntax.
To protect table, instead of using minipage (my initial idea), the adjustbox package seems more promising to include arbitrary environement (like, for example, lists, code or other things). The idea being to embed it in the previous command.

I’m working on it. The most difficult thing is the code management. If someone has a killer idea...

At which level ?

We're ready on our side. Keep us posted on your progress here :)

At which level ?

We can’t use minted in an array. verbatim can’t be used in tabu, longtable, etc. (but it can be used in tabu*).

We're ready on our side. Keep us posted on your progress here :)

I don’t have really usable code. Could a first iteration use \multicolumn and \multirow ?

We can’t use minted in an array. verbatim can’t be used in tabu, longtable, etc. (but it can be used in tabu*).

Even in minipage or adjustbox ?

Even in minipage or adjustbox ?

Nope, see that https://tex.stackexchange.com/questions/119842/how-to-use-fancyvrb-verbatim-in-tabularx

Oh. I thought about that and my conclusion was that length_of_text/number_of_column - 2*margin_of_tabular was a "good" width, since we cannot know in advance the width. But I didn't check if it was possible to get the number of column easily.

Here informations about arrays packages (french).

Any news?

In a PM (MP), @artragis told us that he was working on something :-°

By the way, @artragis, were you able to fix all of those issues on rebber side with the command already provided?

yep, in rebber, when you have code inside a table, we move the code.

Ok, nice. I will do some tests in the future :)

Ok, I think we are good here (still need to think about #93, though)

authors: Karnaj artragis pierre-24 vhf

repo: zestedesavoir/latex-template


text:
outdated examples

examples/brainfuck.rs is outdated, probably some other examples are also outdated.
error[E0107]: trait takes 0 lifetime arguments but 1 lifetime argument was supplied
   --> src/syntax/parser2.rs:19:25
    |
19  | ...> impl Parser<'a, &'a str, ...
    |           ^^^^^^ -- help: remove this lifetime argument
    |           |
    |           expected 0 lifetime arguments
    |
note: trait defined here, with 0 lifetime parameters
   --> /home/antonping/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-0.9.2/src/lib.rs:141:11
    |
141 | pub trait Parser<I: Clone, O> {
    |           ^^^^^^

error[E0107]: trait takes 2 generic arguments but 3 generic arguments were supplied
   --> src/syntax/parser2.rs:19:25
    |
19  | ... -> impl Parser<'a, &'a str...
    |             ^^^^^^ expected 2 generic arguments
    |
note: trait defined here, with 2 generic parameters: `I`, `O`
   --> /home/antonping/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-0.9.2/src/lib.rs:141:11
    |
141 | pub trait Parser<I: Clone, O> {
    |           ^^^^^^ -         -
help: replace the generic bound with the associated type
    |
19  | fn parser<'a>() -> impl Parser<'a, &'a str, Error = Vec<Instr>, extra::Err<Simple<'a, char>>> {
    |                                             +++++++

error[E0433]: failed to resolve: use of undeclared crate or module `extra`
  --> src/syntax/parser2.rs:19:57
   |
19 | ...<Instr>, extra::Err<Simple<'...
   |             ^^^^^ use of undeclared crate or module `extra`

error[E0425]: cannot find function `via_parser` in this scope
   --> src/syntax/parser.rs:61:23
    |
61  | ...r_with(via_parser(nested_de...
    |           ^^^^^^^^^^ help: a function with a similar name exists: `skip_parser`

None of them are outdated, they're just using the main branch. The examples are only compatible with the 1.0.0-alpha.x releases (the latest being alpha.5). If you're using 0.9, you'll need to look at examples at the 0.9 tag. However, I'd recommend using 1.0 since there have been a lot of substantial changes and improvements since 0.9.

I see. thanks for infomation.

authors: AntonPing zesterer

repo: zesterer/chumsky


text:
Semantics of the dot operator

As a compromise between hoisting all names into the top level and disallowing UFCS, the syntax x.f tries to resolve to the field f on x, but if such a field doesn't exists, then it looks up f in the lexical scope and calls it with x as the first argument. The implementation of this will presumably generate a "potential field" name for f during the name resolution pass, which can then be disambiguated by the typing pass when x's type is known.
The name resolver could special case Dot(_, Name(n)) syntax and only mark that as a potential field while anything else (like x.(x => x + 1)) will be resolved lexically. Another possibility is to not special case at all and mark any names on the right side of the dot as a potential field, which would give us a fairly weird version of Pascal's with:
let a = class
  let x: Int = 0
  let y: Int = true
end

let b = a.(if something => x else => y)

x and y in the if-expression would resolve to the field names of a, while something would be resolved lexically.
This could potentially be pretty neat behavior (and it may simplify the name resolver somewhat), but it could also make for weird and unintuitive code.

One thing to consider is how this works with patterns: if we allow it, then we may want it in the pattern too which could make things more difficult down the line.
var a = class
  var x: Int = 0
  var y: Int = 1
end

set a.(if something => x else => y) += 2

Another thing is the nesting of it all. Consider something like this:
let a = class
  let x: Int = 0
  let y: Int = 1
end

let _ = a.(then
  break f(5)
where
  fun f(z: Int) => x + y
end)

This is deeply weird code and probably shouldn't be written. I don't think the language would be worse off by preventing it altogether, while it may lead to inscrutable code if it's allowed.
The performance impact either way should be negligible, since we need the MaybeField part of the name anyway. Any bottlenecks would in that case happen in the typechecker.


text:
Visualisation difference when quantized and compressed

We are using meshoptimizer to compress and quantize gltf files. When using compress and quantize separately, everything works as expected. But if we combine those operations, there is visualization difference in generated gltf files when they are rotated. Attached are the gltf files before and after compression and quantization .Any thoughts? /
cube.zip

I'm a little bit confused by this because I can't directly reproduce this.
Specifically:

I can see the difference between cube_orig.gltf and cube.gltf in a viewer
However, when I process cube_orig.gltf with a recent build of gltfpack, the resulting model looks the same as cube_orig.gltf
cube.gltf from your .zip file has some odd parts, like a doublesided flag on the material even though it doesn't appear in the original file.

Can you verify whether the cube.gltf in your attachment was indeed produced from cube_orig.gltf, and note the exact command line you're using as well as which version of gltfpack this is (OS, whether it's npm or native binary, etc.)?

... oh, wait, cube.gltf isn't even produced by gltfpack? I see the necessary extensions, but the metadata is off (generator should be gltfpack):

{"version":"2.0","generator":"V1.0.0.0","extras":{"Author":"VI","InitialView":"UJhUVVU1QYTzP6qqqtKmxAXAVFVVla6x+j8AAACAeiL3vwAAAAA+UqwBCCxAGurvvz4sDHC9INoRCAA/CRAk6j+l80AqBSESQA==","CurrentView":"UPBPZDa5UWt11T/a6CCcfUsGwHFD/Wmt+wFAK2uS/4RN9r9AOgl0Rxinv6444MEOpPC/fHLd2Qki37+YDOoPU+XgP96oZ72iRuY/pfNAKgUhEkA="}

I'm going to close this because there's no extra information provided and it's likely to be a bug in user code assuming this is using custom C++ code that uses meshoptimizer library but doesn't use gltfpack.
I'd recommend double checking that the buffer with normals uses meshopt_encodeFilterOct with a reasonable number of bits (eg 8) to encode the floating point input data, and that normals that are fed to meshopt_encodeFilterOct are unit length.

authors: prajwalshelar zeux

repo: zeux/meshoptimizer


text:
Using expressions, converters ...

Seems that personsStats != 0 & async: { property: value} or personsStats & async: { property: value} != 0 or personsStats | isNotZero & async: { property: value} or personsStats & async: { property: value} | isNotZero aren't possible.
one way to allow evaluation of the async bound value would be:
personsStats & async: { property: value, converter: isNotZero}
thoughts? other options (well, i could filter the stream, but i need that for several values separately. hence too much code repetition to be a good idea)?
edit: ah, asyncIsNotZero works: eg
import { filter} from 'rxjs/operators';

export class asyncIsNotZeroValueConverter {
  toView(stream, option) {
    return stream.pipe(
      filter(data=> data[option] !== 0)
    );
  }
}

<div repeat.for="attribute of attributes" if.bind="stats | asyncIsNotZero:attribute.name & async: { property: attribute.name}">

something more generic would be nice still

Yeah like an async adapter for valueconverters. Essentially it could be as proposed with converter, but this breaks chaining and looks rather clunky right? Ideally we could use personStats | toAsync: isNotZero : otheropts & async: { ... }. In worst case the VC would have to be passed in as a string.


text:
Optimizations

Mainly, users should be detached from the member, and should be stored separately in the state.

Completed most of the items I had in mind for this, so closing.

license: isc

license_source: bigquery


text:
Minor Typo Fix

Notices a minor typo in RpcServiceModel

:+1:

I see this is in 1.4, I am using 1.2.* for PHP 5.4 support and the error is still present.

It seems to have been introduced in v1.0.5.

@alex-patterson-webdev I just tagged also 1.2.2

@ezimuel Thanks!

authors: alex-patterson-webdev ezimuel gabrielsomoza takethefake

repo: zfcampus/zf-apigility-admin


text:
BC break in 1.0.4 - caused by missing EventManager

Hi,
as posted in the Google Group, the release 1.0.4 introduced a BC break, caused by this change:
https://github.com/zfcampus/zf-rest/pull/45/files#diff-27d39cef7a1867425e9edef6ad8e0c9eL146
See https://groups.google.com/a/zend.com/forum/#!topic/apigility-users/Opau-60Z334
A fix would be to re-add the missing line:
$controller->setEventManager($events);
This is also a potential Unit-Test: checking if the Controller events are fired.
This is somewhat linked to https://github.com/zfcampus/zf-rest/issues/47 but I don't understand the problem behind it and why this one line was removed in first place, so I didn't want to sent in a simple pull-request re-adding this one missing line.

Okay, using a different Event Identifier fixed the problem.
This code was used with 1.0.3 and worked
$events->attach('ZF\Rest\RestController', 'fetch', array($this, 'onFetch'),10);
where 1.0.4 requires
$events->attach('ZF\Rest\Resource', 'fetch', array($this, 'onFetch'),10);

repo: zfcampus/zf-rest


text:
实现原理的网页消失了

我想做我们学校的抢课脚本,还有方法吗

嗯 博客不维护啦，我给你CSDN链接
https://blog.csdn.net/weixin_44178605/article/details/107175624


text:
🛑 JSONDiff is down

In 81a5211, JSONDiff (https://www.jsondiff.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: JSONDiff is back up in caa8946.

repo: zgrossbart/jdd-upptime


text:
jeecg-boot 2.3版本 swagger文档里的接口文档显示不全

版本号：jeecg-boot 2.3版本
问题描述： 自建的jeecg-boot-module-hello包， swagger文档里的没有该包里的接口文档
截图&代码：
友情提示： 未按格式要求发帖，会直接删掉。

猜测有两种可能：
1、如果你使用的是微服务方式，需要你在gateway的application-dev.yml配置文件中加入jeecg-boot-module-hello这个服务的路由配置，只有加了这个，Swagger才能进行聚合；
2、如果你使用的是单体方式，你可以检查jeecg-boot-module-hello这个组件中的包结构是否符合jeecg的开发规范

看看是不是gateway路由网关没有做配置
jeecg-cloud-module\jeecg-cloud-gateway\src\main\resources\application-dev.yml

authors: Victoryli mark0614 zhangdaiscott

repo: zhangdaiscott/jeecg-boot


text:
修改了项目名称后，online在线开发提示资源未找到

jeecg-boot 版本号：2.1.3
问题描述：
按照JeecgBoot常见问题大全的问题5修改了项目名称，调整为mkkj-boot
前后端重起之后，online在线开发页面的新增按钮打开后，提示【资源未找到】；
原有的在线开发修改同样提示【资源未找到】

OnlineForm.umd.min.js
修改一下，
Ne=c.a.create({baseURL:"/jeecg-boot


text:
🛑 ZY is down

In bb88289, ZY (https://ziyuan.baidu.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ZY is back up in c10eeed.

repo: zhaodylan/uptime-ziyuan


text:
提个建议，可不可以让它每次对话都使用emoji呢，就比如在问题前加上use emoji之类字段

前置确认

网络能够访问openai接口 #351
python 已安装：版本在 3.7 ~ 3.10 之间，依赖已安装
在已有 issue 中未搜索到类似问题
FAQS 中无类似问题

问题描述

简要说明、截图、复现步骤等，也可以是需求或想法

终端日志 (如有报错)
[在此处粘贴终端日志]

环境

操作系统类型  (Mac/Windows/Linux)：
Python版本  ( 执行 python3 -V )：
pip版本  ( 依赖问题此项必填，执行 pip3 -V)：

配置在 single_chat_reply_prefix 试试看

配置在 single_chat_reply_prefix 试试看

是想让它发东西的时候带上emoji；像bing一样，不是用来区分机器人的，也许可以试试在每个问题后加上“使用emoji回答”？

人格描述里添加，"character_desc": “"每句话里都有emoji”，效果如下

如果把"emoji"换成"表情"，它会发用符号构成的表情，类似~(●'◡'●)

authors: iknow2333 oreeke zhayujie

repo: zhayujie/chatgpt-on-wechat


text:
Readme

Is there more of a description on how to make this work/use it?
It looks really awesome

ths for your suggestion
USAGE directory:
php config.php --path=data --check
php config.php --path=data --dump
file:
php config.php --path=data/test.xlsx --dump
php config.php --path=data/test.xlsx --check
excel file formation
line 1 : column description
line 2 : column type int/string
line 3 : column scope int scope/string length
line 4 : column relative relative another file's column
line 5 : column name json key
see data/test.xlsx

authors: ibuilder zhengjinhua

license: mit


text:
so里面方法调用成功了，但是执行结果和实际的不符合

代码如下
as为a105f8066a99cef28b4888
加密后应该是011942db0edec3e7c1571d56ec1480a3ee1c1c1c2c461c4c66a6c6
我得到的是   0195b691e32348c706295e5e6d42f719421c1c1c2c461c4c66a6c6
后面一部分是正确的，前面是错误的，能不能帮忙看下

代码：dm.zip

mas有随机字段，如果你模拟的随机字段和cms.so里的相同，结果就会一致


text:
先添加了冒险岛后再加了英雄联盟，最后两个点击删不掉

后两删不掉 倒数第三个可以 删掉之后就正常了

试了下 没有问题， 请具体描述流程

一键导入冒险岛 再一键导入英雄联盟往下滚动最后两个删除不掉，必现！

必现步骤：先点一下图片 再去点删除按钮 ，无论哪行

repo: zhoufanglu/simple-maker


text:
RuntimeError: CUDA out of memory

so i reduce my batch_size = 3 and num_worker = 1
then i gave me this error

Hello @ianphoi,
please refer to this issue https://github.com/zhulf0804/PointPillars/issues/2#issuecomment-1155941738.

thank you, solved it

How to run the train.py in a GPU?
Since when I was running the train.py with batch size of 1, it take forever and I notice that it runs on my cpu and not gpu

It runs on GPU by default.

how many epoch does I need to train because the program have been running for 20 hours and it is currently at epoch 63. Should i change my num worker and batch size. Currently my num worker =1, batch size = 2

is it possible to pause the train.py which window can do by pressing control + pause and the change the num worker and batch size then continue to resume the program?

Hi @ianphoi,

160 epochs. It takes about 20 hours to train the model (160 epochs) on one RTX 3090 GPU card with the default parameters.
Not yet. I'll update the code by supporting model resuming in the future.

Best.

Hi @ianphoi,

160 epochs. It takes about 20 hours to train the model (160 epochs) on one RTX 3090 GPU card with the default parameters.
Not yet. I'll update the code by supporting model resuming in the future.

Best.

alright thank you. You mention that  it uses GPU right. But when I was running the train.py, my task manager indicates zero usage of GPU.


text:
compiling zig on windows without visual studio

I'd like to log progress on it somewhere. Can't wait to try out zig on windows.
Author intends to get zig working with visual studio first, and only then work on other compilers. But I can't get visual studio to work here, so I have to wait. But let's try working in parallel...
First, ci/appveyor/build_script.bat is pretty confusing. The most confusing part is getting three vars, which evaluate to this on my system:
ZIG_LIBC_LIB_DIR
C:/msys64/mingw32/i686-w64-mingw32/lib
ZIG_LIBC_INCLUDE_DIR
C:/msys64/mingw32/i686-w64-mingw32/include
ZIG_LIBC_STATIC_LIB_DIR
C:/msys64/mingw32/lib/gcc/i686-w64-mingw32/6.3.0
It looks like their purpose is locating crt1.o and crtbegin.o. Shouldn't it be possible to work without them? Support table says that compiling freestanding exe on windows already works.
Is it possible to make 4 build targets for windows instead of one?
32bit
32bit-freestanding
64bit
64bit-freestanding

I'd like to log progress on it somewhere. Can't wait to try out zig on windows.

Glad to hear that because I've been doing a lot of work on windows in the past couple weeks.

It looks like their purpose is locating crt1.o and crtbegin.o. Shouldn't it be possible to work without them? Support table says that compiling freestanding exe on windows already works.

It is possible to work without them. These are needed if you want to include libc .h files such as stdlib.h or if you want to link against libc (which you almost certainly will have to if you depend on any C libraries).
If you wanted to run the zig compiler tests you would need a working libc as well since some of the tests test libc integration.

Is it possible to make 4 build targets for windows instead of one?
32bit

--target-os windows --target-arch i386 --target-environ msvc

32bit-freestanding

--target-os freestanding --target-arch i386 --target-environ msvc

64bit

--target-os windows --target-arch x86_64 --target-environ msvc

64bit-freestanding

--target-os freestanding --target-arch x86_64 --target-environ msvc
If you want artifacts to have the mingw C ABI instead of msvc, change msvc to gnu.
I think we need to update the linker code in zig for --environ gnu to work on windows. We also might want to wait for llvm 6.0 which has a mingw environ target and LLD supports the mingw linker args.
However you can always use zig to create a mingw compatible .o file using --environ gnu and use the mingw linker (or just mingw clang) yourself.
We do have zig building successfully with mingw and it looks like most tests are passing, so you should be able to play with this.

--target-os freestanding --target-arch i386 --target-environ msvc

Are those cmake arguments? If those are zig arguments, I need to get zig itself first. I asked you to modify ci/appveyor/build_script.bat , so that it doesn't have that weird bash magic. and just compiles.
Can you at least upload compiled zig for windows somewhere?

These are needed if you want to include libc .h files such as stdlib.h or if you want to link against libc (which you almost certainly will have to if you depend on any C libraries).

I don't depend on any C libraries. That's the whole point of freestanding exe files: only system provided dll. I'm a fan of demoscene, you see. Size matters, and all. I'll probably actually rewrite most of the libraries in zig, or at least those that I need.

If you wanted to run the zig compiler tests you would need a working libc as well since some of the tests test libc integration.

Can't care less about those tests, don't want to wait for them to pass. These are probably not necessary for me.
When I say "freestanding", I mean exe file that doesn't depend on C runtime, and only interacts with system provided dll directly. Is that the right use of that word? Or "freestanding" actually means just some object code that can't be even run by itself?

Can you at least upload compiled zig for windows somewhere?

I'm working on it as we speak. Here's the checklist I'm going through: #302

I don't depend on any C libraries. That's the whole point of freestanding exe files: only system provided dll. I'm a fan of demoscene, you see. Size matters, and all. I'll probably actually rewrite most of the libraries in zig, or at least those that I need.

Right. This is one of the main use cases of zig, so I am excited for you to try it out. In this case you do not need the ZIG_LIBC* configure arguments.
Can you try building with mingw without those configure arguments? It should work fine and then panic if you try to do anything with libc.
"freestanding" in zig lingo means that you are either compiling your own OS or targeting an OS that zig doesn't know about. (See the list output by zig.exe targets).
You're targeting Windows so you'll want to either compile natively (no --target-* arguments) or use --target-os windows. This has some effects on the code generated by LLVM, for example it will generate __chkstk calls if a stack frame is larger than a page, and it will mangle DLL calls by prepending an underscore, and do the stdcall mangling convention.
If you're doing demoscene stuff I'm guessing you want to avoid __chkstk as well as write your own startup code instead of relying on zig's startup code: https://github.com/zig-lang/zig/blob/a4310cf8b4f104802360cb854e2dcc48802301a6/std/special/bootstrap.zig#L34-L44
(actually now that I think of it, we should figure out how to tell LLVM to turn off __chkstk in release-fast mode)
And probably your own compiler-rt and memcpy/memset implementations instead of zig's compiler-rt and zig's memcpy/memset.
In this case I think you're right that freestanding is what you want. I've used freestanding to build an OS but I haven't tried to run freestanding code on windows yet and I'd like to do that before recommending something to you.
Perhaps you could live with zig's startup code and target windows for a little bit, then when you want to really optimize the last 1% we can move forward on this? Or play around with freestanding, hack on zig, sounds like you know what you're doing. I'm on IRC if you want to chat.
Don't forget to build with --release-fast to omit all the safety checks. :zap:

Size matters, and all.

One more thing. We currently have these build modes:

Debug (safety on, fast compilation, slow runtime performance, big binary)
ReleaseSafe (safety on, slow compilation, medium runtime performance, big binary)
ReleaseFast (safety off, slow compilation, fast runtime performance, big binary)

I'm considering adding

ReleaseSmall (safety off, slow compilation, medium-fast runtime performance, small binary)

Is this something you would be interested in?

Ideally ReleaseFast and ReleaseSmall should be the same, don't see much reason in separating those. But until we get there, sure, why not.
I'll set CodeGen.libc_static_lib_dir to empty string and see if anything breaks. I'll also start rewriting build system in bash and makefiles, because I'm having troubles with understanding cmake.

Ideally ReleaseFast and ReleaseSmall should be the same, don't see much reason in separating those. But until we get there, sure, why not.

Here are a couple reasons:

SIMD instructions. Sometimes faster code using SIMD ends up being bigger.
Unrolling loops. Sometimes unrolling loops is faster and takes up more space in the binary.

I'll also start rewriting build system in bat and makefiles, because I'm having troubles with understanding cmake.

ok. feel free to post an error log, I can probably tell you how to fix whatever happened.

It sounds like it will also make simplier assembly. Then yes, it's a good idea, make ReleaseSmall.

Issue to track it: #531

How do you think, will zig build as a 32bit app? Or I must have it 64bit?

Currently the zig compiler only works as 64-bit. We'll make it work as a 32-bit application when we self-host (See #89)

Ok, zig got built, and it actually works. Except it deadlocks on exit. Really weird.
I create this _.zig file next to zig.exe, with this content:
use @import("std").os.windows;
export fn WinMainCRTStartup() -> INT {
    _ = MessageBoxA(null, c"hello", c"title", 0);
    return 0;
}

and type this to compile it:
zig build-exe _.zig --target-os windows --target-arch i386 --target-environ gnu --release-fast -mwindows

It works nicely, result works, but zig itself never exits.
I tried to get callstack with x64dbg, here it is. Ignore everything that's not "Comment", read from bottom to top:
Address           To                From              Size              Comment                                            Party
000000000022F848  000007FEFD8A1420  000000007763C3EA  100               ntdll.000000007763C3EA                             System
000000000022F948  00000000773E06D0  000007FEFD8A1420  90                kernelbase.000007FEFD8A1420                        System
000000000022F9D8  0000000064941EAD  00000000773E06D0  60                kernel32.00000000773E06D0                          User
000000000022FA38  00000000649421A0  0000000064941EAD  80                libwinpthread-1.0000000064941EAD                   User
000000000022FAB8  0000000064942721  00000000649421A0  B0                libwinpthread-1.00000000649421A0                   User
000000000022FB68  000000006FCD8A7C  0000000064942721  30                libwinpthread-1.0000000064942721                   User
000000000022FB98  0000000070216BFB  000000006FCD8A7C  80                libstdc++-6.000000006FCD8A7C                       User
000000000022FC18  00000000701C11D7  0000000070216BFB  60                llvm.0000000070216BFB                              User
000000000022FC78  00000000701C12D8  00000000701C11D7  50                llvm.00000000701C11D7                              User
000000000022FCC8  0000000077612B31  00000000701C12D8  120               llvm.00000000701C12D8                              System
000000000022FDE8  0000000077612940  0000000077612B31  30                ntdll.0000000077612B31                             System
000000000022FE18  000007FEFDD499E2  0000000077612940  40                ntdll.0000000077612940                             System
000000000022FE58  00000000004014D5  000007FEFDD499E2  D0                msvcrt.000007FEFDD499E2                            User
000000000022FF28  000000000040152B  00000000004014D5  30                zig.00000000004014D5                               User
000000000022FF58  00000000773E59DD  000000000040152B  30                zig.000000000040152B                               System
000000000022FF88  000000007761A631  00000000773E59DD  50                kernel32.00000000773E59DD                          System
000000000022FFD8  0000000000000000  000000007761A631                    ntdll.000000007761A631                             User

ntdll kernel32 msvcrt ntdll kernelbase are system dlls, libstdc++-6 libwinpthread-1 are from mingw-w64 (for some reason they are added to every program compiled with mingw, unless they are linked statically), there is llvm, there is zig
What I understood from it, is that zig calls exit from msvcrt, then other system dlls, then for some reason control flow goes back into llvm, then libstdc++, it calls pthread_cond_wait from libwinpthread, then some other system dlls.
I guess pthread_cond_wait is the cause of this. I'm not sure why llvm code gets executed at closing program, that's some C++ magic right here.

I'm not sure why llvm code gets executed at closing program, that's some C++ magic right here.

It doesn't happen with the msvc build, so it seems like a bug in mingw. Can probably work around by patching zig to call _exit (skips atexit handlers) instead of exit when built with mingw. Do you want to try it?

Replaced return EXIT_SUCCESS with _exit(EXIT_SUCCESS) and ExitProcess(EXIT_SUCCESS), no effect.
I replaced this one: https://github.com/zig-lang/zig/blob/8cfb0cfbcee8161c52f71bccc3cf1b8d988f83b0/src/main.cpp#L793
Linking is so slow here.

Deadlock on application exit is often caused by invocation of user code in DllMain when a DLL is unloaded. Such code is subject of restrictions but few care.
This is the hammer to exit w/o notifying DLLs:
TerminateProcess(GetCurrentProcess(), EXIT_SUCCESS);
Alternatively, it may be possible to unload suspected DLL manually (by repeatedly calling FreeLibrary/FindLibrary) before termination.

I think we want to do this on Windows anyway. There is no point in calling a DLL unload code.

I'm new to git, how can I keep TerminateProcess in the code, but still get updates?
TerminateProcess worked nicely, now I don't have to open task manager every time.

@pluto439
When you want an update:
git stash
git pull
git stash pop

Can you send me the diff so that  I can merge it upstream? GitHub pull request is easiest for me but I don't mind if you just want to paste a diff.

It's a terrible thing to merge, it only works on windows, it only works for one combination of console commands. But it works for now.
Probably should recompile llvm instead, maybe they fixed it by now.
Also don't know how to make diff here.

Also don't know how to make diff here.

git diff

It's a terrible thing to merge, it only works on windows, it only works for one combination of console commands. But it works for now.

ok

It takes 6 minutes to link zig.exe together. I need to decrease that time somehow if I want to get anywhere.
I suspect that adding -Wa,-mbig-obj to compiler flags might help. Need to add them somewhere in deps/lld/CMakeLists.txt. Where exactly should I add them?
https://stackoverflow.com/questions/16596876/object-file-has-too-many-sections

deps/lld/CMakeLists.txt is ignored. All cmake stuff is in the root CMakeLists.txt. Search for LINK_FLAGS.

-Wa,-mbig-obj didn't work.
Built lld as dll, it worked, linking only takes 10 seconds. Object files were so odd, they had thousands of sections.
I replaced this:
    add_library(embedded_lld_lib ${EMBEDDED_LLD_LIB_SOURCES})
    add_library(embedded_lld_elf ${EMBEDDED_LLD_ELF_SOURCES})
    add_library(embedded_lld_coff ${EMBEDDED_LLD_COFF_SOURCES})

with this:
    add_library(embedded_lld_lib SHARED ${EMBEDDED_LLD_LIB_SOURCES})
    add_library(embedded_lld_elf SHARED ${EMBEDDED_LLD_ELF_SOURCES})
    add_library(embedded_lld_coff SHARED ${EMBEDDED_LLD_COFF_SOURCES})

    target_link_libraries(embedded_lld_coff ${LLVM_LIBRARIES} ${CLANG_LIBRARIES} ${CMAKE_THREAD_LIBS_INIT} embedded_lld_lib)
    target_link_libraries(embedded_lld_elf ${LLVM_LIBRARIES} ${CLANG_LIBRARIES} ${CMAKE_THREAD_LIBS_INIT} embedded_lld_lib)
    target_link_libraries(embedded_lld_lib ${LLVM_LIBRARIES} ${CLANG_LIBRARIES} ${CMAKE_THREAD_LIBS_INIT})

And to free myself from ninja install every time, changed this:
install(TARGETS zig DESTINATION bin)

to this:
install(TARGETS zig DESTINATION .)

Ah if that improved link time, you night also improve link time by linking against libLLVM.so instead of individual libraries and the .so versions of clang libraries instead of .a

You would edit cmake/Findllvm.cmake and cmake/Find clang.cmake

Yeah, I'm already linking to LLVM.dll that came with msys2, I didn't compile it myself. It's probably the reason why it deadlocks. It worked like that out of the box, without me editing findcmake files.

Uploaded everything I said in this thread as a mingw.patch, since I now know how to do those. In a zip, github doesn't support .patch
mingw.zip
To create:
git diff > mingw.patch
To apply (made pa.bat for it):
git apply mingw.patch
To reverse (made pu.bat for it):
git apply -R mingw.patch
I guess I'll just keep unapplying and applying this patch every time I need to get newest version from git.
To actually compile, use this:
mkdir build
cd build
cmake -G"Ninja" .. -DCMAKE_INSTALL_PREFIX=.
ninja install

To get a short beep once it's done compiling, use this:
ninja && python -c "print '\7'"

authors: PavelVozenilek andrewrk pluto439

repo: zig-lang/zig


text:
Extension issue

Issue Type: Bug
Extension Name: html-css-class-completion
Extension Version: 1.20.0
OS Version: Windows_NT x64 10.0.19042
VS Code version: 1.58.0

:warning: We have written the needed data into your clipboard. Please paste! :warning:

Please provide more information.

authors: ar-dehghan-a zignd

repo: zignd/HTML-CSS-Class-Completion


text:
Make the vinyl file available as template variable.

The vinyl file is now available as _file variable. The _target variable has two properties, the _target.path contains the full target path and _target.relative contains the relative target path.
I find this really useful, when piping multiple templates through gulp like this:
gulp.task('build-pages', function () {
    return gulp
        .src(['pages/**/*.twig'], {base: 'pages'})
        .pipe(twig(...))
        ...;
});

Well, merged somewhat. I have added some testing and repositioned some stuff because I have let some PR's open way too long and merged them in a funky order. Sorry about that.

authors: tristanlins zimmen

repo: zimmen/gulp-twig


text:
Update http4s-dsl to 0.23.24

About this PR
📦 Updates org.http4s:http4s-dsl from 0.23.20 to 0.23.24
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s", artifactId = "http4s-dsl" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.http4s", artifactId = "http4s-dsl" }
}]

labels: library-update, early-semver-minor, semver-spec-patch, version-scheme:early-semver, commit-count:1

Superseded by #1059.

repo: zio/zio-json


text:
Correctly derive annotations for enum cases

/claim #651

@pablf Could you uncomment the test assertion in line 90, please? That was the assertion that made me discover the bug.

repo: zio/zio-schema


text:
[Bug]: email verified, doesn't work in user edit

Preflight Checklist

[X] I could not find a solution in the documentation, the existing issues or discussions
[X] I have joined the ZITADEL chat

Environment
Self-hosted
Version
v2.39.1
Describe the problem caused by this bug
in user edit dialog, when changing user domain, email verified checked, doesn't work
To reproduce
1- in user edit dialog
2- change user domain
3- tick email verified checkbox
Screenshots

Expected behavior
No response
Operating System
No response
Relevant Configuration
No response
Additional Context
No response

Hei @chezgi
Thanks for reporting this issue.
I have verified and it looks like the frontend doesn't send the verified bool.

Hi @Universe-stack,
I don't have permission to assign persons to issues.

I understand. Maybe @hifabienne can. Hi @hifabienne , can you assign me to this task? Thanks.

Hei @Universe-stack
Thanks for your offer.
I assigned you

Thanks..

I reviewed the form on the website to confirm the above issue but I didn't encounter it. Below is a video to verify.
After changing my email on the form, the verified tag turned to unverified and I had to request for a code to verify the new email again. I think this works as expected. Please correct me if I'm wrong.
Thanks.
https://github.com/zitadel/zitadel/assets/76141133/5386678d-cc87-4472-b3f7-e9c5ee0182e9

hei @Universe-stack
The screen recording you show, is from the customer portal. this is not included in this github repository (zitadel/zitadel), as it is private, because we need it to manage our SaaS service.
The right place is when you go to your instance domain https://acme-dxzbrv.zitadel.cloud/ then to users, and to a specific detail of a user.

hei @Universe-stack
The expected behavior is that when I change the email, and enable email verified, that the email is directly verified, without sending a code to the email address.
The API already allows that, you can send email_verified as a bool = true, if the checkbox is enabled in the ui.
The code of the console is not private, only of the customer portal.
You can find it here: https://github.com/zitadel/zitadel/tree/main/console

hei @Universe-stack
Do you still work on this issue?

Yes Fabi. Thanks for reminding me.

Hei @hifabienne I think this issue can be closed as it was fixed in #7844

thanks @doncicuto

authors: Universe-stack chezgi doncicuto hifabienne

repo: zitadel/zitadel


text:
Improve Benchmarking

With this issue, we consolidate our plans and communication about our efforts in benchmarking.
We want to achieve:

[ ]  Identify which endpoints we want to benchmark and how they perform on ZITADEL Cloud so we know which bottlenecks we should optimize.
[ ] https://github.com/zitadel/DevOps/issues/29 Describe clear scaling advice so customers know their system requirements.
[ ] #6585 Test the performance continuously with deterministic conditions to ensure ZITADEL keeps being performant
[ ] #4424 Run stress tests to ensure ZITADEL scales as expected in real-world conditions and loads

@fforootd @adlerhurst Instead of closing the issues I found, they pretty much matched the points we identified and are already discussed. Therefore, I linked them and left them open. Are you fine with this? Did I miss something?

Are the issue actionable already, to me most of it looks like "thoughts".
I think we should make clear what goals in what order we want to achieve.

authors: eliobischof fforootd


text:
greedy-nbv & target-pomdp approach?

does this repo also contain code for greedy-nbv & target-pomdp? I want to run the comparison. Thanks!

Track it down from here: https://github.com/zkytony/cos-pomdp/blob/master/experiments/thor/experiment_thor.py#L43

authors: khuechuong zkytony

repo: zkytony/cos-pomdp


text:
Prefix shared functions to prevent symbol conflict when linking

Prevents symbol conflict when linking native API against compatibility API. See #1279.
crc32_braid.c:(.text+0x60): multiple definition of `crc32_braid'; ../../compat/libz.a(crc32_braid.c.o):crc32_braid.c:(.text+0x70): first defined here
deflate.c:(.text+0x1a50): multiple definition of `read_buf'; ../../compat/libz.a(deflate.c.o):deflate.c:(.text+0x1a40): first defined here
deflate.c:(.text+0x1ae0): multiple definition of `fill_window'; ../../compat/libz.a(deflate.c.o):deflate.c:(.text+0x1ae0): first defined here
inflate.c:(.text+0x460): multiple definition of `fixedtables'; ../../compat/libz.a(inflate.c.o):inflate.c:(.text+0x450): first defined here
zutil.c:(.text+0x0): multiple definition of `zng_calloc'; ../../compat/libz.a(zutil.c.o):zutil.c:(.text+0x0): first defined here
zutil.c:(.text+0x60): multiple definition of `zng_cfree'; ../../compat/libz.a(zutil.c.o):zutil.c:(.text+0x60): first defined here
zutil.c:(.text+0x70): multiple definition of `zlibng_version'; ../../compat/libz.a(zutil.c.o):zutil.c:(.text+0x80): first defined here
zutil.c:(.text+0xb0): multiple definition of `zng_alloc_aligned'; ../../compat/libz.a(zutil.c.o):zutil.c:(.text+0xc0): first defined here
zutil.c:(.text+0x160): multiple definition of `zng_free_aligned'; ../../compat/libz.a(zutil.c.o):zutil.c:(.text+0x170): first defined here
/usr/bin/ld: ../libz-ng.a(zutil.c.o):(.rodata+0x0): multiple definition of `zlibng_string'; ../../compat/libz.a(zutil.c.o):(.rodata+0x0): first defined here

Rebased.

This looks great, thank you. I'd love to have this available, and I'd be happy to adapt the Rust package to use a version with this change.

What are the remaining blockers for integrating this?

@Dead2 this one is ready too.

@Dead2 have you seen this?

@nmoinvaz I did, but I have a different possible solution that I want to present. Just have to get the time to gather and present all the relevant details 😉

Has there been any movement on this?

@nmoinvaz Will this need any changes to accomodate #1322 or other recent changes?
I don't see any conflicts, but I'd like you to chime in too before merging this. Perhaps a rebase would be best in any case.

From what I can see, I think it should be okay to merge both. I have rebased this PR as requested.

authors: Dead2 dzenanz joshtriplett nmoinvaz

repo: zlib-ng/zlib-ng

license: Zlib


text:
Models too f-ing awesome, overshadowing other mods

Not sure if this is a bug, but it is a piece of feedback I had to offer.

It's not exactly a bug, but thank you!


text:
Push descriptor variants of tests not using push layouts

Not sure how this is possible because it used to work.
But I just noticed the push descriptor variants of tests are not creating pipelines using those descriptor layouts.
So non of the push test seem to be testing what the should.
For instance, layout_basic_push is not used for anything.

Are you sure? Those tests have been refactored into macros https://github.com/zmike/vkoverhead/blob/main/src/vkoverhead.c#L1346 so you won't be able to grep for them.

I guess I was missing that those tests don't do any draws. Sorry for the noise.

authors: djdeath zmike

repo: zmike/vkoverhead


text:
How to add authorization headers in network files ?

I want to Play a audio file with user authentication. Can anyone tell me how to move with this ?

@zmxv, i need it too

Download them first?

Hi! You can load the data first, then pass it to new Sound(). I hope this helps!

authors: imbudhiraja paulmelnikow tromario zmxv

repo: zmxv/react-native-sound


text:
0.13.1 should have been semver breaking release

It seems that the 0.13.1 introduced breaking changes into the API. Here is a user report in a downstream crate that got broken by the update: https://github.com/nushell/nushell/pull/530
It would be best if the 0.13.1 release could be yanked and a 0.14.0 release be done instead. Thank you!

Ok, sorry about that.

@zonyitoo thanks! I'd still definitely appreciate a new (semver breaking) release as it brings those crossbeam updates.

Yes. I am adding a feature gate to optionally enable decimal128 supports.

I have already pushed a commit: https://github.com/zonyitoo/bson-rs/commit/00edb6e47542da0e03b0ca0e592a64dc3958e33d .
Decimal128 could be enabled by feature = "decimal128". Will be released with 0.14.0.

Published v0.14.0. And I think this issue is fixed. Closing.
Again, sorry about the breaking change.

repo: zonyitoo/bson-rs